Make WordPress UI

Updates from Chelsea Otakan Toggle Comment Threads | Keyboard Shortcuts

  • Chelsea Otakan 2:51 am on August 6, 2012 Permalink
    Tags: help, screen options   

    We did some brainstorming at Dev Day today around improving the Help and Screen Options tabs in the admin. Keep in mind nothing here is a final decision, just some exploration of what we thought would be easy wins to make these tabs more useful.

    Here are the problems with them right now:

    • Most users are blind to these tabs.
    • The labels and positioning give little indication as to what these tabs actually do.
    • For a lot of users, Help is not that helpful.
    • They’re position in the admin creates yet another point of navigation for users to be aware of (and per #1, most of them aren’t).
    • The very wide container for text makes a lot of the help text difficult to read.

    Here are some of the possibilities we brainstormed (see notes below image):

    Ideas:

    • Adding icons to these tabs would (hopefully) both make these tabs more visible and give a better indication as to what these tabs too.
    • Moving these to the right side of the toolbar would give even more context to what these do, as they would be grouped with other user-specific settings.
    • (6) The toolbar dropdown would allow for a slimmer content area for better readability.
    • (7) The slimmer content area would let us make screen options read like a list for better scannability.
    • (4/5) Putting the gear on the upper right would standardise with several other web apps (Twitter, etc).

    We discussed possible changes to the labels:

    • Screen Options -> Screen Preferences
    • Help -> Screen Help
    • (3) Removing the Screen Options label altogether and only showing the icon (since the gear icon is so universally recognised). Possible expanding this to Help.

    I did a hi-fi mockup of what the new Help dropdown might look like:

     
    • Ipstenu (Mika Epstein) 3:41 am on August 6, 2012 Permalink | Log in to Reply

      My only worry is that makes the menu bar very crowded. A lot if plugins add to that :/ The 2 b mockups I like because you could change the color and make them more visible. Pop a little :)

    • GrahamArmfield 9:42 am on August 6, 2012 Permalink | Log in to Reply

      Coming from an accessibility perspective I’d favour the combination of icons and words. But I don’t have a strong view about the positioning of the links – existing location/toolbar.

      There is a Trac ticket open (See #21326) about making the screen options more accessible to sighted keyboard users and screen reader users. I believe this has been accepted into 3.5. Any further changes to the functionality must ensure that the information and options are keyboard accessible and keyboard operable as appropriate. If a panel is to be used to contain the information it is important that focus is transferred to an appropriate place within that panel and that the tab order of any options makes sense. Will ‘Close Panel’ links be included at the bottom of the options/help?

      • Chelsea Otakan 6:25 pm on August 6, 2012 Permalink | Log in to Reply

        If we chose an approach with icons only, we would still leave and text in the DOM (we could use text-indent to hide the text) for screen reader compatibility. Ref: http://css-tricks.com/snippets/css/standard-css-image-replacement/

        “Any further changes to the functionality must ensure that the information and options are keyboard accessible and keyboard operable as appropriate. If a panel is to be used to contain the information it is important that focus is transferred to an appropriate place within that panel and that the tab order of any options makes sense. Will ‘Close Panel’ links be included at the bottom of the options/help?”

        AFAIK the current toolbar is keyboard accessible. It would theoretically use a lot of the same code as the current Toolbar and the current Help module. Since the menu item would now be above the content of the Help and Screen Options modules in the DOM http://core.trac.wordpress.org/ticket/21326 would be easier to resolve with the above approach.

        We could add “Close Panel” or “Dismiss” links, but, since I’m not familiar with this aspect accessibility, what’s the reasoning behind adding them?

    • Andrea Rennick 2:54 pm on August 6, 2012 Permalink | Log in to Reply

      On the other end, we’re making sure pages will be available in the codex to be able to link to them in screens like this, to explain to the user what those screens actually DO.

    • JerrySarcastic 9:59 pm on August 13, 2012 Permalink | Log in to Reply

      I like having the gear icon at the top right; it’s definitely a convention that users of social media, gmail, and other apps are becoming used to, so big thumb’s up on #4 and #5.

      In general I think moving Screen Options and Help to the menu bar is a big win. This is an area the user is already aware of and associates with performing various tasks in the dashboard, plus the visual contrast of the icons (and/or text label) against the dark background makes visual acquisition much easier.

      Staying with tabs, but giving them an icon (and perhaps a background color) helps address the issue of their invisibility, but not as effectively as moving them to the menu bar, IMHO.

      • Cliff Seal 7:39 pm on August 14, 2012 Permalink | Log in to Reply

        I agree with your reasoning and like 4 and 5 as well. The cog and the question mark are common enough to use alone (since accessibility is obviously being addressed), and I’d love to see the cog be the farthest thing to the right, followed by the question mark to the left, and then the ‘Howdy…’. As much tradition as the latter holds, it’s the least important, and could hypothetically be condensed to an avatar or profile icon itself to preserve space.

        I’ve rarely seen a new WordPress user even notice the existence of the ‘Screen Options’ as it is now. I think integrating it into the bar’ll help tremendously!

    • Cliff Seal 8:06 pm on August 14, 2012 Permalink | Log in to Reply

      Even if we hide the wording in favor of the cog/gear icon, what’s the reason we don’t use ‘View Options’ or something of that sort instead of using the word ‘screen’? Seems like it would be more suitable for what the options actually are.

    • Chelsea Otakan 10:35 pm on August 14, 2012 Permalink | Log in to Reply

      Thanks for all your feedback guys!

      Here’s an iteration for the screen options dropdown. According to some discussion, I rearranged the nav on the right side so the gear is on the far right.

      I also opened a ticket for this enhancement in 3.5 here: http://core.trac.wordpress.org/ticket/21583

      • Ipstenu (Mika Epstein) 10:47 pm on August 14, 2012 Permalink | Log in to Reply

        Wow… It’s amazing when you see something that simple and think ‘Yes, why doesn’t it look more like that?’

        Can we make the gear a more standout color? Right now one of the (many) issues is people just don’t see it.

      • JerrySarcastic 1:13 am on August 15, 2012 Permalink | Log in to Reply

        Looks great! What’s the concept behind the Settings sub-menu? Interesting idea…

      • Chelsea Otakan 1:33 am on August 15, 2012 Permalink | Log in to Reply

        Sorry, I completely spaced on explaining that. *headdesk*

        On Dev Day, we chatted about adding links to relevant settings screens that would show up at the bottom of the menu and including hooks so plugins can do the same.

        This way, we can allow easy access to global WordPress settings from this menu on relevant screens.

        • JerrySarcastic 4:33 pm on August 15, 2012 Permalink | Log in to Reply

          Ah, gotcha. I think it’s a great idea, but one that will need some context; if I’m a new user, I may not *get* what these settings do without a little explanation.

          That said, I’m all for finding a way to make relavent settings available. They can get a little buried in the Settings area of the dashboard. I know this is a point of frustration for the users I introduce to WordPress.

          • Chelsea Otakan 4:54 pm on August 15, 2012 Permalink | Log in to Reply

            I agree and think that’s also an overall problem with the nomenclature and labeling of the Settings screen :)

            I’ve thought a bit about this, but would love to hear any suggestions for better labels for the Settings screens. Its definitely something our users struggle with.

            • Cliff Seal 3:11 pm on August 16, 2012 Permalink

              I wonder if we should label (what was) Screen Options as ‘Admin Options’ or ‘View Options’ and the links to the General Settings as ‘Global Settings’, or something of that nature. I *love* giving more intuitive access to the latter like this. Well done!

        • Stephen Harris 4:46 pm on August 18, 2012 Permalink | Log in to Reply

          That’s a really good idea. My only concern is that the options tab always kept you on the same page – and these will navigate you away from it . Might user’s confuse the screen settings with the site wide ones? I suppose this is the almost the same point Jerry was making. Maybe add a label ‘Site Settings’?

          Great work though – it’s looking great!

      • Chelsea Otakan 4:52 pm on August 15, 2012 Permalink | Log in to Reply

        I’m not sold on the colors, but if the overall layout and concept seems good (so far most of the feedback has been positive) I think I’ll start working on a patch this week.

      • Joen Asmussen 6:52 pm on August 15, 2012 Permalink | Log in to Reply

        I love this. I really love this. Vast improvement over the “Screen options” tab.

        One teensy niggle, perhaps, is the contextual settings “quick links”. To a new user, several different links that lead to the same thing can be confusing. The user might ponder which link is the “right” link (even if the links lead to the same). The settings menu can be a hunt and peck experience, that’s a challenge entirely on its own. But adding the links here to alleviate that feels a little bit like a bandaid.

    • Ryan Duff 1:37 am on August 16, 2012 Permalink | Log in to Reply

      I skimmed, so forgive me if it was already mentioned and I missed it… but assuming this would fall back to current way if they have the admin bar disabled?

      ie. if admin bar was enabled for the current user, the links would be there and the old tab interface for screen options / help would be hidden, but if the admin bar was disabled (either across the board or for the current user, they tabs would be present so the options are available still?

      I’m a huge fan of the admin bar, but *still* run across client sites, themes, plugins, etc that just disable it for no good reason. Sad, but those use cases need to be considered as well.

      Otherwise, I love the way this looks and thinks it makes total sense to move them up there.

      • Andrew Nacin 4:01 am on August 16, 2012 Permalink | Log in to Reply

        The toolbar can only be disabled for the frontend, as it is integrated into the admin. Screen options and help are only available in the admin. So disabling it won’t have any effect.

        • Ipstenu (Mika Epstein) 11:20 am on August 16, 2012 Permalink | Log in to Reply

          To be fair, there are plugins and functions people use to disable it more. From what I’ve seen they do it not for the admins, but for the people who don’t need all that stuff and are just users. I think for those who disable it, it shouldn’t be a big loss, but it would cement that they’re going to have to start adapting to the over a year old new way.

          • Helen Hou-Sandi 1:10 pm on August 16, 2012 Permalink | Log in to Reply

            If you disable the toolbar entirely, you can’t log out. I hope people are not still doing that, because that’s not a good idea.

            • Ipstenu (Mika Epstein) 3:07 pm on August 16, 2012 Permalink

              There’s a plugin out there that puts the logout on the side-menu of the admin screen. I remember it coming up when people screamed about the toolbar being the only way to log out. I’m not delving back into the crazy pants of why we suck for requiring the toolbar. ;)

      • JasonBC 8:35 pm on August 19, 2012 Permalink | Log in to Reply

        I think that’s a valid concern. I have one site that doesn’t show the toolbar in single post view and I’ve seen others who’ve had problems with it disappearing from the font and back-ends.

  • Chelsea Otakan 11:50 pm on May 25, 2012 Permalink
    Tags: source files   

    There was a discussion on #20293 ( http://core.trac.wordpress.org/ticket/20293#comment:33 ) about starting to use the defunct design repository ( http://design.svn.wordpress.org ) to keep trac of design source files.

    We often end up waiting on people who have the working PSDs/Fireworks PNGs/etc for graphics or icons, or redrawing things (this happened for the admin bar icons that were made for retina displays) because the source files got lost of the persan can’t be contacted. For graphic elements we should make it a point to upload the working files as well as the production files. That way, if the original creator isn’t available someone else can pick it up with as many resources as possible.

    There’s more discussion on the ticket about having a page on this blog vs. a repository. I think the main advantages of a repository over trac or uploading to make/ui are:

    • I like uploading graphic files to tickets, but Trac has a very low file size limit. A lot of the heavier PSDs won’t be able to be uploaded to Trac.
    • By using a repository, we can not only have the resources, but we can track how they’ve changed over time.

    If we started using the repository we would have to come up with a good organization scheme. Some ideas:

    • A scheme based on where the corresponding production files live within WordPress (ex wp-admin/images/admin-bar.psd would correspond to wp-admin/images/admin-bay.png). This would make it harder to keep track of sketches, full page layouts, or design resources that don’t have an explicit tie to a production file.
    • A scheme based on the type of graphic (screen layouts, icons, graphics, etc).
    • A scheme based on feature

    If anyone has any more ideas on this, please comment :) I’m not super confident in any of the ones I presented above, so a good discussion about this is welcome.

    cc @jane

     
    • Helen Hou-Sandi 4:15 pm on May 26, 2012 Permalink | Log in to Reply

      I think a scheme based on where the corresponding production files are located would work well, although that sort of begs the question of where things go once they’re no longer used (could probably just stay there for reference). There could also be directories for sketches, full layouts, and other resources, if that would make sense, with further subdirectories if needed.

      • Ipstenu 1:46 pm on May 29, 2012 Permalink | Log in to Reply

        I think keeping them forever would be a good idea, since sometimes you go down a design track and wind up wanting to go back a little. Past reference is always good :)

        I’d order them by feature, and under feature have the subfolders.

        • Helen Hou-Sandi 1:26 pm on May 30, 2012 Permalink | Log in to Reply

          The issue I have with ordering by feature is the subjective nature of it, and the learn-ability for other contributors. Organizing production files by directory would make more sense and makes it easy to find a file you need for a patch, at least to me.

          As for “old” files, I wasn’t thinking delete so much as moving into another folder, but it’s probably not necessary anyway.

      • Chelsea 3:14 pm on June 17, 2012 Permalink | Log in to Reply

        Unless anyone has any further objection, I’m going to this up today with a structure based on where the production files live + other subdirectories for pre-production files such as sketches, mockups, and general resources.

    • Shane 4:22 am on May 28, 2012 Permalink | Log in to Reply

      We used svn as a source of document control for our design team for a couple years and finally decided to move to dropbox. We moved for the following reasons:

      • PSDs get BIG and when you version them, the amount of memory involved is simply ridiculous. Asking someone to checkout a 500GB design repo is asking a lot.
      • When we moved to many small repos to help offset the issue above, it began a where’s waldo problem where things got lost / duplicated.
      • You are depending on designers to be good about checking in source files. While many do, most designers are not as svn savvy as devs.
      • There is no awesome way to know if you are truly looking at the latest version (again checkin dependent)

      I know that the team prefers open source solutions and wonder if there is some comparable alternative to dropbox. It provided us instant access to changes, almost no education required for our design team. The downside was the over 2GB required financial outlay and there is the risk of deletion (although there is version history).

  • Chelsea Otakan 6:31 pm on September 27, 2011 Permalink
    Tags: flyouts   

    The current hover states for the Admin flyouts are still not quite there. Here’s what we’d like to improve about them:

    • We’d like both the hover state on first level items and second level items to be more contrasted. They are currently a pale grey gradient and light blue (See screenshot above).
    • The blue fade feels a bit off. Alternatives welcome.

    Experimentation encouraged!

     
  • Chelsea Otakan 8:10 pm on September 7, 2011 Permalink
    Tags: ,   

    Resurrecting these! This chat normally takes place on Tuesdays, but was postponed due to some storm difficulties.

    Reminder: Freeze is in two weeks. Responsive admin is our highest priority right now.

    Responsive Admin - #18198

    • Discussed some webkit bugs when styling the admin. @saracannon is looking onto resolving.
    • Newcomers hhsandi and sabreuse will be looking into styling list tables. Welcome!
    • @azaozz recommended a focus an tablet optimisation for 3.3. Still keeping an eye on mobile, but some editor issues may prevent full optimisation for 3.3.
    • Discussed the problem of TinyMCE compatibility.
      • Since iOS doesn’t support contentEditable, almost no WYSIWYG editors will work. iOS5 may be released before 3.3 and is slated to support contentEditable.
      • Will need to style tMCE buttons to be optimized for touch. Anyone on iOS5 welcome to help test :]

    Menu Flyouts – #18382

    • Currently in trunk. Yay @koopersmith. Any UI improvements/suggestions welcome.
    [New User] Experience

     

    View the IRC Logs for this chat. 

     

     
    • scribu 8:46 pm on September 7, 2011 Permalink | Log in to Reply

      That last item should really be called ” Experience”, to avoid confusion with “New “.

      • scribu 8:47 pm on September 7, 2011 Permalink | Log in to Reply

        One more time:

        That last item should really be called ”[New User] Experience”, to avoid confusion with “New [User Experience]“.

        • Chexee 9:15 pm on September 7, 2011 Permalink | Log in to Reply

          Haha, thanks! Edited the post te read correctly

        • Jane Wells 2:53 pm on September 10, 2011 Permalink | Log in to Reply

          Actually, no. The “feature” @koopersmith and I are working on there is actually three features. One is around new feature launches, one is around new wp users, and one is around new updates. So “New [User Experience]“ would actually be pretty accurate.

    • Marko 12:32 am on September 9, 2011 Permalink | Log in to Reply

      I would love to help with iOS5 stuff. Did notice I can now scroll in the view.
      Did download the newest TineMCE and upload that to my WordPress trunk installation.
      Not sure how to get the TinyMCE view.

  • Chelsea Otakan 6:16 pm on September 6, 2011 Permalink
    Tags: reschedule   

    This week’s chat has been rescheduled for tomorrow (Wednesday) September 7 at 18:00 UTC (11am Pacific, 2pm Eastern) due to storm difficulties.

     
  • Chelsea Otakan 7:24 am on April 17, 2011 Permalink
    Tags: search,   

    Searchbox Inventory for WordPress.org 

    Here’s the documentation of all the searchboxes I found across WordPress.org. Feel free to doublecheck me. Included screenshots for cases different from the standard header searchbox.

    Homepagehttp://wordpress.org/

    Showcasehttp://wordpress.org/showcase/

    • Standard Searchbox in the header (Searches Documentation/Codex)
    • Site Searchbox in Right Column (Searches entire Showcase/Same search parameters regardless of Tag or Flavor)
    • Screenshot: http://cl.ly/130G1e0J0y43073a2B0m

    Extendhttp://wordpress.org/extend/

    Abouthttp://wordpress.org/about/

    • Standard Searchbox in the header (Searches Documentation/Codex)
    • All Subpages have the same searchbox scheme

    Docshttp://codex.wordpress.org/Main_Page

    • Standard Searchbox in the header (Searches Documentation/Codex, has different placeholder text: Search the Codex vs Search WordPress.org)
    • All Subpages have the same searchbox scheme

    Bloghttp://wordpress.org/news/

    • Standard Searchbox in the header (Searches Documentation/Codex)
    • All Subpages have the same searchbox scheme

    Forumshttp://wordpress.org/support/

    • Standard Searchbox in the header (Searches Documentation/Codex)
    • Forum Searchbox in the left column
    • Screenshot: http://cl.ly/423B3N0i280e1N133R2J
    • Subpages and Forum Templates only have the standard Searchbox in the header

    Hostinghttp://wordpress.org/hosting/

    • Standard Searchbox in the header (Searches Documentation/Codex)

    Downloadhttp://wordpress.org/download/

    • Standard Searchbox in the header (Searches Documentation/Codex)
    • Subpages and Forum Templates only have the standard Searchbox in the header

    Also, found this to be a little unsightly: when on the Hosting page, the active tab in the main navigation touches up against the Downlaod tab. Could we add some margin here? Screenshot: http://cl.ly/101U161b411q19461x1D

     
    • Chelsea Otakan 7:51 am on April 19, 2011 Permalink | Log in to Reply

      My thoughts on improving search:

      Perhaps create a universal searchbox that can change context via a Dropdown submit button. Clicking on the button main part of the button would initialize the search. Clicking on the down arrow would let you choose a context and would initialize the search after clicking on a choice. (See sketches)
      Default context would change depending on the page. Plugin Directory would show Plugin search, etc.
      If we switch to one universal searchbox like this, the header searchbox seems to detached from the content. Perhaps move it closer to content area (in page header, rather than universal header) (see sketches).
      I like the main-focus of some of the pages on search (ex. http://wordpress.org/extend/plugins/), but the sidebar searchboxes are really transient (sometimes there, sometimes not there).

      Let me know if I’m totally off base.

      Sketches
      Searchbox: http://cl.ly/3Z1g2t1L0n0C2S2Y2d0Q
      Placement: http://cl.ly/2W1W3m0e302h2l2F2J2t

  • Chelsea Otakan 8:43 pm on April 12, 2011 Permalink
    Tags: ,   

    Jane was without internet today and John was traveling, so there was no official meeting. Here are some things to think about for next weeks meeting:

    • We should have a plugin for the full screen/distraction-free editor to test in the next few days. Will post an update when its available. Test the plugin this week to make sure the UI is comfortable and we’ll discuss possible improvements at next week’s meeting
    • Looking for a volunteer to inventory the position/location of all the search boxes on WordPress.org so we can start a discussion on standardizing them

    PS. There are still open challenges from Trac and some issues logged in previous posts. If anyone wants to revive or take a whack at these, please do.

     
  • Chelsea Otakan 11:56 pm on April 4, 2011 Permalink
    Tags: pressthis design   

    PressThis Take 2 

    I didn’t forget about this, just had a bit of a busy week last week. Based on the feedback from the chat 2 meetings ago, I went with the lighter colored PressThis bookmarklet.

    • I removed the highlight, making it flatter and less button-like.
    • Added a modified shadow and hovering hand cursor to make it look as if the bookmarklet is peeling off the page and is therefore supposed to be grabbed a la https://www.readability.com/bookmarklets

    PressThis Bookmarklet: http://cl.ly/0w1p3I0r1C25133Q0c46

     
    • scribu 1:45 am on April 5, 2011 Permalink | Log in to Reply

      That looks pretty cool :D

    • Dre 9:54 pm on April 10, 2011 Permalink | Log in to Reply

      Hi chexee, that looks great, I have one concern for what it’s worth. I think the shadow looks a bit deeper than it should, and I’m not sure that it properly flows with the rest of the buttons in admin.

    • Jane Wells 5:59 am on April 16, 2011 Permalink | Log in to Reply

      Looks good to me, but asking Matt Thomas to weigh in since it’s a UI departure and he’s the guardian of the brand.

    • Matt Thomas 4:19 pm on April 18, 2011 Permalink | Log in to Reply

      Sorry I’m late — I like this; it’s a departure but it’s a good way to illustrate that this is a different type of link. I agree with Dre above that the opacity of the shadow could be a little less intense; that would make it look more natural.

      • jane wells 4:25 pm on April 18, 2011 Permalink | Log in to Reply

        Ha! I *just* told Chelsea to put it on trac and you could comment there. :)

      • Chelsea Otakan 4:32 pm on April 18, 2011 Permalink | Log in to Reply

        haha, literally a few minutes before this comment.

        I’ll make the shadow more subtle (agree its too dark/intense) and start writing a patch for this.

      • chexee 9:55 pm on April 18, 2011 Permalink | Log in to Reply

        Here’s a version with a pulled back shadow: http://cl.ly/0Q2H2J032S0t3A113W0X

        Much better

      • chexee 11:38 pm on April 18, 2011 Permalink | Log in to Reply

        A few quick questions about the patch before I put it on trac. Started working on it, its a pretty quick one.

        Applied the .description text to the paragraph above, as they’re specific instructions directed at the button. Let me know if this is off-style and only meant for form elements.

        Reference screenshot: http://cl.ly/2Q1u3K0k290w2p3m2q3Q

        If it was unclear, the hand grabber was part of the graphic and was meant to be demonstrative. I added cursor: move to the link, which makes the cursor a 4-way pointer on hover. Is this too confusing?

    • Stephane Daury 7:16 pm on April 27, 2011 Permalink | Log in to Reply

      /happy_dance!

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel