Ready to get started?Download WordPress

Make WordPress Core

Tagged: UI Toggle Comment Threads | Keyboard Shortcuts

  • Dominik Schilling (ocean90) 2:17 pm on April 16, 2014 Permalink
    Tags: , , UI   

    Dashicons in WordPress 3.9 

    WordPress 3.8 has introduced an icon font for the WordPress admin, named Dashicons. Dashicons includes 167 icons until now.
    WordPress 3.9 includes 30 new fresh and clean icons. Thanks to all contributors to ticket #26936, especially @melchoyce and @empireoflight.

    Media Icons

    All media file type icons got a huge facelift, see #26936. There are also two new icons for the playlists feature.

    Icon CSS Class Code
    dashicons-media-archive f501
    dashicons-media-audio f500
    dashicons-media-code f499
    dashicons-media-default f498
    dashicons-media-document f497
    dashicons-media-interactive f496
    dashicons-media-spreadsheet f495
    dashicons-media-text f491
    dashicons-media-video f490
    dashicons-playlist-audio f492
    dashicons-playlist-video f493


    With the update to TinyMCE 4.0 you can now use four new icons for editor related UI.

    Icon CSS Class Code
    dashicons-editor-contract f506
    dashicons-editor-break f464
    dashicons-editor-code f475
    dashicons-editor-paragraph f476


    Use dashicons-external for external uses or randomize a list with dashicons-randomize.

    Icon CSS Class Code
    dashicons-external f504
    dashicons-randomize f503

    WPorg specific: Jobs, Profiles, WordCamps

    We all WordCamps.

    Icon CSS Class Code
    dashicons-universal-access f483
    dashicons-universal-access-alt f507
    dashicons-tickets f486
    dashicons-nametag f484
    dashicons-clipboard f481
    dashicons-heart f487
    dashicons-megaphone f488
    dashicons-schedule f489


    Have you already tried the live widget previews? You should. The following icons are created for this feature.

    Icon CSS Class Code
    dashicons-archive f478
    dashicons-tagcloud f479
    dashicons-text f480


    The minus icon has an alternative icon, plus now too. Welcome.

    Icon CSS Class Code
    dashicons-plus-alt f502


    End of .

    Icon CSS Class Code
    dashicons-microphone f482

    To get a complete overview of all icons please visit http://melchoyce.github.io/dashicons/.

  • Jen Mylo 10:14 pm on November 17, 2012 Permalink
    Tags: teams, UI   

    I made a proposal over on the UI group blog that we abolish the UI group.

    GASP! But why would you want to kill your baby, Jane??

    tl;dr version: Core UI should just be part of this /core team with a UI component owner. Instead of a separate UI group (that wound up being the core ui/css group), we create a central Design Corps made up of designers (graphic, interaction, web, print, etc) that contribute to all the groups across the wp project, not just core UI.

    Proposal has some support over on UI blog in comments.


    • Helen Hou-Sandi 10:18 pm on November 17, 2012 Permalink | Log in to Reply

      You know mine :) Heartily agree!

    • Ipstenu (Mika Epstein) 6:00 am on November 18, 2012 Permalink | Log in to Reply

      I think this is a good idea. I would think it’d fold UI ‘fixes’ in fast. The only lingering question I would have is how to handle @lessboat‘s user tests? That’s UI, but it’s also a different aspect of WordPress that’s … usability? Testing? I’m not entirely sure what it should be, but it may make core very busy it that comes along. Other hand? Core team’s gotta know where users are getting lost (which is why I follow UI).

      • Jane Wells 1:13 pm on November 18, 2012 Permalink | Log in to Reply

        I posited the possibilitly of a Testing group (usability, QA, etc) similar to the design corps. The amout of raw data Dave has been posting is usually left to the researchers, though, with designers and devs getting summary reports for the whole group of tests rather than piecemeal one by ones. The key to reducing noise there is to to rethink how those results are being shared, and to provide access to the deep dive, but to post more manageable, actionable pieces for the broader group as the main blog posting.

    • Amy Hendrix (sabreuse) 2:24 pm on November 18, 2012 Permalink | Log in to Reply

      I’m down with it.

    • Mark Jaquith 4:36 am on November 20, 2012 Permalink | Log in to Reply


    • Dwain Maralack 2:04 pm on November 20, 2012 Permalink | Log in to Reply

      It just makes sense.

  • Jen Mylo 7:20 pm on May 4, 2011 Permalink
    Tags: , UI   

    For all you SVN-uppers, don’t freak out: we’re trying out the style refresh that’s been being talked about over on the UI blog, and things might look a little ugly as we get it all worked out.

  • Jen Mylo 5:29 pm on February 25, 2010 Permalink
    Tags: , interaction models, , navigation, UI, UX   

    Menus UX Manifesto 

    A Menus Manifesto?

    Now that the new menu system patch is in and working, I’ve been able to start going through it for UI stuff. The are some things I think we should consider changing to fit into the WP UI, though based on timing I’m also okay with letting some of it slide until next release if needed. Here are the things on my mind, which hopefully we can touch on during today’s dev chat.

    • Icons. The edit/delete/view icons are inconsistent with the way we handle actions everywhere else in WordPress. We have two options here: we can have icons made that will match WP core icons, or we can get rid of the icons and change the UI a bit to match existing interaction models. If we go with icons, I’ll ask Ben to make us some that match better, which might be the better part of valor to get 3.0 out on time, rather than trying to make everything perfect. Release early and keep iterating, right?
    • Accessibility. The menus function as it stands now is completely inaccessible. There doesn’t seem to be a no-JavaScript version, which we have to have. It will be clunky and ugly, like widgets, but we NEED to do this. Icons for actions rather than text is an accessibility no-no, which is another reason to move away from them eventually, but the bigger problem is that we need a no-JS version. I’m emailing the accessibility list to see if anyone there is willing to pitch in and help.
    • Little arrows on the left of each item. These should be removed. We use little arrows everywhere else to indicate an open/close functionality. If we need a symbol to indicate hierarchy we could use dashes like some other plugins do, or better and more attractive, just indent the bar itself? We also need to get rid of those little mini-arrows in the modules on the right when you click on View All.
    • Everywhere else in the admin, the right-left convention is opposite of how it is on this screen. For example, in Widgets, the available widgets are on the left and the completed sidebars are on the right. On categories and tags, you add on the left and see the updated list on the right. It would probably make sense to swap the menu and the menu controls so the controls are on the left and menus are on the right.
    • Buttons. The Save button should use the primary button class (blue). It should also be furthest to the right. Delete should not be a button, but a red link, and to the left.
    • Display. Like some other people, I’m wondering why each menu has to have its own screen, when it’s generally a pretty narrow column.
    • Default menu. When you first go to the menu screen, it says you don’t have any menus, to create one, but that’s both confusing and incorrect. There is a default menu in place using pages (or categories, in some themes). We should either a) (and preferably) Display the pre-existing menu as Main Menu or some such, or b) change the default text to explain that they currently use the default menu, and this screen is for customizing. It’s also highly unclear how someone should name a menu, or what the relationship is between menus and themes. If someone creates 20 menus but none are supported by the theme, what will happen? It should really pre-fill what menus you have available to you, just like it does with sidebars on the widgets screen.
    • The click to add icons perform the same action as the page/category titles themselves. The icons impair accessibility. If we are to have a second addition mechanism, it should be a text link, not an icon.
    • The mechanism for adding URL and adding page/category is inconsistent. Pages and categories have a list from which you can add, while links are added to menu directly. It would be more consistent to create link rather than add link when it’s first entered, then have link appear in a list below, as the pages and categories do, so that links could be added to/removed from menus without just deleting them. This would also follow the principle we established in widgets that you shouldn’t lose settings when you deactivate something like that.
    • The metaboxes down the right all show the on-hover gray arrow in the right header corner, but the boxes don’t collapse. Either make the boxes collapsible or get rid of the hover arrows.
    • Instead of the edit icon, each menu item should have the hover arrow, which would open it to the edit view. Then we should use save/close/delete as in widgets, thus getting rid of the delete icon as well. This is the interaction model for this type of metacontent and should be followed.
    • I don’t really see the need for a View link (icon) from each menu item.
    • Whatever we do in terms of these changes, hooks need to be included so that Woo can get their own current look back if they choose, as that was part of the agreement.

    This is the kind of thing that we need a styleguide for, which the UI group has recently started working on. :)

    • Carl Hancock 6:13 pm on February 25, 2010 Permalink | Log in to Reply

      Great points Jane. The one area I don’t necessarily agree with is moving the toolbox to the left and the menus to the right so it is more in line with what is done with Widgets. I guess thats because I look at editing menus more like editing posts, pages, or even the appearance editor.

      The main content is the main column and the toolbox items are on the right.

      If anything i’d say that the Categories, Tags, and Widgets area stray from that convention when most everything else in WordPress maintains a “navigation bar – content – sidebar toolbox” type of layout.

      • Jane Wells 8:20 pm on February 25, 2010 Permalink | Log in to Reply

        Not a bad point. Maybe we should swap the widgets orientation. :)

        • Carl Hancock 8:28 pm on February 25, 2010 Permalink | Log in to Reply

          Thanks. Worth looking into, it’s tough with the widgets because of requiring enough space for both the active widgets area AND the widget collection you choose from.

          One thing I never understand is why Categories and Tags stray from the way Posts, Pages and Media Library are displayed.

          Why not have the first page when you go to Categories be the table/grid of Categories and then an “Add New” button just like when you go to Edit Posts/Pages. I know it’s for the convenience of quickly adding a category or tag, but it strays from the other areas of the site that have a table of existing data items, and then an add/edit page.

          Honestly I think thats the route to take with Menus. Instead of doing it all on one screen.

          • Screen 1 would be a table/grid of the available menus with an Add New button.
          • Screen 2 would be the add/edit screen for adding or editing a Menu.

          When you go to Menus you would get Screen 1 which would be presented in similar fashion to Edit Posts or Edit Pages. A list of your menus which you can then choose to edit one or add a new one.

          Cramming everything into one screen is certainly a departure from the rest of WordPress so it would be nice to have it in line. I think how Posts and Pages are managed is a good model to use for Menus.

        • ocean90 8:31 pm on February 25, 2010 Permalink | Log in to Reply

          Compromise: The menu widgets should be make draggable so that everbody can style it themselves, like the Post and Pages.

        • Carl Hancock 8:36 pm on February 25, 2010 Permalink | Log in to Reply

          Forgot to mention, splitting it into 2 screen would also allow you to have some quick edit functionality with it so that you could add something like a default menu flag option so you could quickly set the default menu that is used when the template function call is used WITHOUT passing a menu name/id. Right now I believe it just pulls in the first menu alphabetically. Would also allow for more flexibility in the future for additional functionality.

    • Ryan 7:41 pm on February 25, 2010 Permalink | Log in to Reply

      If when visiting the Menus admin page there are no menus defined, we can create a menu containing all top-level pages. Woo did this but the functionality hasn’t been added back yet after the schema port.

      There are two ways to add menus to a theme. The first is when the theme explicitly calls wp_nav_menu(). The second is by using the widget. Any menu can be displayed as a widget meaning any widget supporting theme can have a menu.

    • kgraeme 7:47 pm on February 25, 2010 Permalink | Log in to Reply

      Thanks for bringing the accessibility issue to the forefront on this. I had asked wpmuguru if it had come up and he said yes, but seeing it on the dock here is great. I agree that handling it like the widgets should be fine.

      For the hierarchy display/editing, I’d love to see the same underlying code be able to be used for the Page Order and Category heirarchy editing.

    • Dean Robinson 10:43 pm on February 25, 2010 Permalink | Log in to Reply

      I only played with the new menu system for the first time yesterday (liking what I’m seeing so far), so some of the things I noticed may not be issues I just may not have looked close enough yet ;)

      Icons – I noticed the “non-matching” icons straight away, I’d probably go for text labels to match interaction in other parts of the admin – text labels would also be better for aspects such as translation?
      Little Arrows – I was clicking furiously on the little arrows until I realised that didn’t actually do anything… bullet point might be a good option, a dash could also possibly get confused for +/- open/close?
      Default menu – Kind of a agree with this, I wasn’t sure what I had to do to get started when I first hit the menu setup page. Did I have to start adding items to a menu, did I have to create one first, did I have to name it ‘appropriately’. Looks like the new sidebar widget thats been added to display the custom menus should take care of the themes that won’t have support built in straight away.. providing they support widgets.
      Non-collapsible metabox – that makes sense, probably should be collapsible
      Hover arrow instead of edit icon – yeah, the more widget like the interface is the less learning users will need to do to start using the new menus, that can’t be a bad thing

    • Martin Lormes 1:59 pm on March 7, 2010 Permalink | Log in to Reply

      I hope I am not too late with this:

      When I started playing around with the menus feature i instantly wondered why I could add existing pages and categories to the menu but not the links I had added to the “Links” section. And then from a different perspective but it’s the same question: Why are the “custom links” stored in the wp_posts table and not in wp_links? (Or maybe it’s not the same question and we need both, custom links stored as a custom post type in the wp_posts table AND the ability to add “links” to our menus!?)

    • Keith 7:54 pm on April 19, 2010 Permalink | Log in to Reply


      Some late feedback. I notice this new menu system doesn’t support a default “home” page. Any plans to addthis? My theme index page is a static home page. The only way to get it into the menu is to create a new home page and redirect.

  • Ryan Boren 3:12 am on April 22, 2009 Permalink
    Tags: , UI   

    The plugins management page has been overhauled to better match other management pages. There are status filters for All, Active, Recently Active, Inactive, and Update Available. There’s also search and paging with a screen option for setting the number of plugins to show per page.

  • Ryan Boren 3:09 am on April 22, 2009 Permalink
    Tags: UI   

    When on a management page, the Favorite Actions dropdown now defaults to the create page that corresponds to that management page, and vice-versa. For example, visit edit.php and the dropdown displays “Create Post”. Visit post-new.php and the dropdown displays “Edit Posts”.

  • Ryan Boren 3:06 am on April 22, 2009 Permalink
    Tags: UI   

    plugins.php and edit-comments.php remember the last status filter you selected. Try it out. If we like this we can add it to other pages that have filters.

  • Ryan Boren 6:44 pm on March 30, 2009 Permalink
    Tags: UI   

    “Screen Options” for the post, page, comment, and media management pages now allows setting the number of items to show per page.

    • amfprod 9:51 pm on March 30, 2009 Permalink | Log in to Reply

      Woo! This is an excellent addition.

    • Baris Unver 10:45 pm on March 30, 2009 Permalink | Log in to Reply

      relevant thing: it’d be better if you “delete” the items (with jQuery), not “hide” them. the “wp.com stats” widget on dashboard still tries to load stats, even if it’s hidden.

  • Michael Adams (mdawaffe) 11:13 pm on November 6, 2008 Permalink
    Tags: UI   

    Working on Quick Edit styling

    • Baris Unver 1:24 am on November 7, 2008 Permalink | Log in to Reply

      Please, make it light. Don’t need TinyMCE for example, even quicktags could be unnecessary.

    • Nick 5:17 am on November 7, 2008 Permalink | Log in to Reply

      Yeah… make it light, but please include a dropdown for categories and leave the add tags field.

      Then, I could write my aside posts from the dashboard… that would be awesome…

      Or is their already a plugin that creates an Advanced Quick Editor?

    • mdawaffe 9:53 pm on November 10, 2008 Permalink | Log in to Reply


      This is for Quick/Bulk Edit (an inline editor on the 2.7 equivalent of 2.6’s Manage -> Posts admin page) not QuickPress (the write-a-new-post-from-the-dashboard feature).


  • Mark Jaquith 7:44 am on November 3, 2008 Permalink
    Tags: UI   

    Changed Publish Module style to offer more flexibility. Having the columns side-by-side was too cramped and would have been a nightmare for translators.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc