WordPress.org

Make WordPress Core

Tagged: UI Toggle Comment Threads | Keyboard Shortcuts

  • Dominik Schilling (ocean90) 3:31 pm on December 20, 2014 Permalink |
    Tags: , , , UI   

    Dashicons in WordPress 4.1 

    WordPress 4.1 includes 20 new fresh and clean icons. Thanks to @liljimmi, @melchoyce and @empireoflight.

    Media Icons

    Icon CSS Class Code
    dashicons-controls-play f522
    dashicons-controls-pause f523
    dashicons-controls-forward f519
    dashicons-controls-skipforward f517
    dashicons-controls-back f518
    dashicons-controls-skipback f516
    dashicons-controls-repeat f515
    dashicons-controls-volumeon f521
    dashicons-controls-volumeoff f520

    Posts Screen (updated)

    Icon CSS Class Code
    dashicons-align-left f135
    dashicons-align-right f136
    dashicons-align-center f134
    dashicons-align-none f138

    Misc

    Icon CSS Class Code
    dashicons-phone f525
    dashicons-building f512
    dashicons-store f513
    dashicons-album f514
    dashicons-palmtree f527
    dashicons-tickets-alt f524
    dashicons-money f526

    To get a complete overview of all icons please visit developer.wordpress.org/resource/dashicons/.

     
    • Stagger Lee 4:38 pm on December 20, 2014 Permalink | Log in to Reply

      Why dont you reconsider cooperating with Fontawesome community. To ease burden from WP community. They have a vibrant community, add new icons fast when someone needs them, have more than double icons compared to Dashicons, licence is compatible with WP philosophy as i can see it.

      http://fortawesome.github.io/Font-Awesome/cheatsheet/

    • Rami Yushuvaev 8:05 pm on December 20, 2014 Permalink | Log in to Reply

      How about align justify?

    • Avi_Lambert 8:14 pm on December 20, 2014 Permalink | Log in to Reply

      I like this.

      Icons enhance ux.

      Good show devteam.

    • Slava UA 10:45 am on December 21, 2014 Permalink | Log in to Reply

      “dashicons-money” is not about money at all (imo)

    • Scott Fennell 3:22 am on December 22, 2014 Permalink | Log in to Reply

      I’m happy dashicons is a *thing* now, but I would agree — what does the money one have to do with money?

      Also, I’m surprised to see that Twentyfifteen uses Genericons. I would have assumed the bundled themes would use the icon font that comes with core.

      • Ipstenu (Mika Epstein) 5:40 am on December 22, 2014 Permalink | Log in to Reply

        The money is a person on a bill note and coins. Which is what most nation’s money looks like. All hail the queen and that.

        Also Dashicons are made for the backend of WP, not the front, so they aren’t intended for themes.

        • Bonesnap 7:44 pm on December 22, 2014 Permalink | Log in to Reply

          I agree that’s the intention of the money dashicon, but in reality it looks like some kind of profile icon. When I saw it I had no idea it was a money icon.

          I second a collaboration with Font Awesome.

          • bishless 9:07 pm on December 22, 2014 Permalink | Log in to Reply

            Agreed. Initially, I thought it a couple cuddling on the couch watching an episode of The Daily Show.

            What about focusing on coins? https://i.cloudup.com/VFri9igqED.png (doesn’t have to be this one… but maybe a polished version of it?)

            • Daniel McClure 7:59 pm on December 23, 2014 Permalink

              Agreed, the money one seems a little off.

              In other news; I have no idea why there is a palm tree icon included but I love it and will make sure to sneak it into one of my plugins somehow 😉

        • Leo Caseiro 3:09 am on January 9, 2015 Permalink | Log in to Reply

          I was going to say the same. The money one doesn’t really look like a money at all.

          The font-awesome is a good reference: http://fortawesome.github.io/Font-Awesome/icon/money/

        • Scott Fennell 10:47 pm on January 9, 2015 Permalink | Log in to Reply

          Is there anything wrong, per se, with using dashicons on the front end? I’ve done it in client plugins and I find it really convenient.

          • Ipstenu (Mika Epstein) 11:39 pm on January 9, 2015 Permalink | Log in to Reply

            Code wise, no. But the size ratio is ‘off’ a little so things won’t scale well compared to FontAwesome or Genericons

            • Scott Fennell 6:21 am on January 10, 2015 Permalink

              Thank you for the reply!

              Can you elaborate on that? What does it mean for the size ratio to be off? What won’t scale well? In what sense?

  • Helen Hou-Sandi 7:08 pm on December 19, 2014 Permalink |
    Tags: , , , , UI   

    Core CSS: A potential roadmap to sanity 

    At the community summit, we discussed a core CSS roadmap, initially a discussion about preprocessors in regard to their role in WordPress, both in the admin and in bundled themes. Recently, there has been significant discussion about the initial use of a preprocessor in the development of Twenty Fifteen that was not included when it landed in core. We discussed what role preprocessors may play with our default theme development and core WordPress for the long term.

    In this post, you will find some history, some observations, and an outline of where we can go next to bring some sanity to our admin CSS as well as move into the future.

    (More …)

     
    • Kevin Miller 7:08 pm on December 19, 2014 Permalink | Log in to Reply

      Any chance of an Admin Style Guide getting done with all of this as well? It’s long over due in my opinion

      This was a good start https://github.com/helenhousandi/wp-style-guide

      • Helen Hou-Sandi 7:10 pm on December 19, 2014 Permalink | Log in to Reply

        Yep, that’s what the pattern library is about. I didn’t get into much specific detail for the roadmap, but my goal would be for the generated documentation to serve as both visual test material as well as a publicly accessible guide for developers.

    • mindctrl 7:39 pm on December 19, 2014 Permalink | Log in to Reply

      What’s the proposal for collecting statistics and performance data?

      • Helen Hou-Sandi 9:12 pm on December 19, 2014 Permalink | Log in to Reply

        Nothing proposed yet, this is “just” a roadmap. I’m sure there will be many discussions and a lot of work to come.

      • Aaron Jorbin 9:58 pm on December 19, 2014 Permalink | Log in to Reply

        Now that this published, there will be a build/test tools roadmap that mentions some potential options for collecting these statistics. That roadmap will be published by the end of the year.

    • PeterRKnight 7:56 pm on December 19, 2014 Permalink | Log in to Reply

      As a plugin developer I continually have issues trying to get my UI to match the look and feel of the rest of the admin, but it’s a real tedious business without some kind of preprocessor functionality. One thing that might go less noticed is how various classes and elements are tied to javascript logic.

      When using common css classes (so you don’t have to add custom css) often comes with surprises. For example, you can’t easily replicate the accordeon-like panels that are used by widgets without creating new css classes. If you have a spinner element somewhere in your UI, you have to watch that it’s not activated by some other WordPress script because the selector used by a WP script is broader than it needs to be. There’s all kinds of these little issues like these that crop up that make working alongside the native admin css not so fun..

      It would be great to see a clearer approach so that it becomes easier to build custom components that utilize native styles and desired patterns. How javascript is being used to target elements based on css classes is something that shouldn’t be overlooked.

      • Michael Arestad 9:31 pm on December 19, 2014 Permalink | Log in to Reply

        I know the pattern library will help in those areas. We could maybe even a section specifically designed to help plugin authors use components in a friendly way.

    • Morten Rand-Hendriksen 8:50 pm on December 19, 2014 Permalink | Log in to Reply

      This looks like a solid plan. Creating standards and a pattern library will make future development and 3rd party development much easier and more consistent.

      IMO the preprocessor discussion is a distraction. It’s a conversation about tools when the real issue is with the code itself. It is a conversation worth having, but it is one that only makes sense once everything else is in place.

    • Konstantin Obenland 8:56 pm on December 19, 2014 Permalink | Log in to Reply

      Great post Helen, thank you!

      newer contributors who are often put off by issues such as the sheer volume of styling or the potential for uncaught side effects

      I’ve been contributing for a while now, but when it comes to admin CSS, I definitely consider myself a “new contributor”. In one ticket I worked on in 4.1 that touched the admin CSS, the potential of uncaught side effects really affected my confidence in my proposed patch. It’s a LOT to grasp and to double check.

      CSS is one of the languages I consider myself more familiar with, so I would love to get involved and help out in any way I can.

      • Michael Arestad 9:33 pm on December 19, 2014 Permalink | Log in to Reply

        Part of what we discussed was implementing a system that compares before/after of each view so you can be alerted if a certain percentage changes on particular views. This would be handy to help ensure a CSS change isn’t breaking other pages.

      • Andrew Nacin 10:49 pm on December 19, 2014 Permalink | Log in to Reply

        I’ve been contributing for a while now and I don’t go near admin CSS.

    • Morgan Estes 10:24 pm on December 19, 2014 Permalink | Log in to Reply

      I did some work about a year ago with trying to get the Sass files inline with the existing CSS coding style guides. Looks like it’s time to take a look at it again and see where I can help.

      https://core.trac.wordpress.org/ticket/26905

    • Gary Jones 10:12 am on December 22, 2014 Permalink | Log in to Reply

      I’ve looked into the tools available or a while, and here are my thoughts on tools that are not already in use (cssjanus, autoprefixer etc.).

      grunt-wp-css is a wrapper for CSSComb (and currently CSS Beautify), which is pre-configured to format CSS to match the WP CSS coding standards. CSSComb is great, but not if everyone has to setup their configuration each time and stay up to date with changes in the coding standards. The default config for the Grunt package also has an opinionated order of properties, which match the suggested grouping in the standards, and it includes fixes not found in the default CSSComb configs.

      CSSComb can also apply to Sass (though it’s waiting on the rule-delimiter property to be supported), so having the same coding standards generally apply as it does to CSS would make sense. Sass has some extra features not covered by CSSComb though, and like the difference between JSCS and JSHint (coding standards vs coding practices), grunt-scss-lint can be used to state and automatically test against these areas.

      One of the big advantages of Sass I find, is being able to put media queries (MQs) right inside (or after) the selector that’s being affected, instead of creating a disconnect and pushing all MQs down several hundred lines to the bottom of the file or into a new file. Keeping the code modular is better for organisation – new contributors don’t have to worry about looking elsewhere for declarations that would also need to be changed. The initial disadvantage of this though, is that the resulting CSS has multiple MQ wrappers for each breakpoint or condition. This can be fixed with grunt-combine-media-queries though, which unwraps MQ blocks and re-wraps them with one MQ block per breakpoint or condition and pushes them all to the bottom. That gives the best of both worlds – code in context when developing, code following the cascade in production.

      It’s a different mindset that some can’t get their head around, but mobile-first styles (i.e. use of min-width in MQs) can make for simpler and reduced code – your styling from one end of the range and working in one direction, instead of starting in the middle and working in both directions. Taking advantage of the natural 100% width of elements means only having to split that into multiple-columns when the screen is wide enough, instead of giving that from the start, and then having to re-define 100% when the screen is small enough. The initial disadvantage of mobile-first is that IE8 and below doesn’t support it. However grunt-stripmq can take a stylesheet and generate a version for IE that has media queries stripped out, so that the desktop styles always apply over the original small-screen styles. In the context of concatenated output from load-styles.php and any intent to bump the minimum version of IE supported above 8, this may not be worthwhile now, but still worth considering if it was the only objection to wanting mobile-first styles.

      grunt-colorguard is a handy tool for finding color values that are extremely similar, but not exact, so that the number of unique colours can be dropped. This also then simplifies the task when using variables within admin Sass to ensure consistency.

      An alternative pattern library to consider is Hologram (which can also be used via grunt-hologram). It looks for inline documentation blocks inside .scss (or .css, .md or a few other file types irrelevant to WP) and produces a living style guide. It supports JavaScript inside the component demos. It’s not a WP plugin, and the output is standalone to any WP install.

      Whatever guidelines and code standards are developed, I’d like to see them be discussed in terms of how suitable tools can be configured to automatically test against them. This removes far more ambiguities than a textual explanation alone, and more importantly, it’s something the whole community can use, not just core.

      • Helen Hou-Sandi 3:09 pm on December 22, 2014 Permalink | Log in to Reply

        Yes, a large piece of this is utilizing and expanding the tooling setup we have now to enable steps forward. We will have meetings to hash out details as we start moving along this roadmap. Thanks for such a great start!

        • Gary Jones 3:47 pm on December 22, 2014 Permalink | Log in to Reply

          I’d really love to see a separate Make group (and Slack channel) for build tools, code standards, pattern libraries, static analysis of current code etc. Basically everything that falls under development practices or methodologies covering the how, not the what that Make/Core covers.

          I think it’s a big enough topic to garner discussion and expertise that fall outside of just how Core works, which can be influenced by, and report back to Core, but can be applicable to both core and code in the wider WP community. Think how Accessibility and Polyglot aspects have their own groups, and can direct core development, but can also influence the wider community.

          Is that something that can be looked into / how do I convince folks it’s needed?

          • Helen Hou-Sandi 8:01 pm on December 22, 2014 Permalink | Log in to Reply

            My instinct would be to continue to include that where we currently do (Make/Core, for the most part) and split off if it truly proves to be distracting or overpowering. I don’t see why Make/Core couldn’t cover more – I often wish it did.

            I would also be loath to hindering progress on this roadmap, which is already years in the making. There are so many areas that go beyond what specifically needs to be accomplished here – preprocessors, PHP, etc. I am not questioning the material, but rather the committee-first approach.

            • Gary Jones 9:00 pm on December 22, 2014 Permalink

              I don’t see it being a distraction from core, but I do see the rest of core being a distraction from being able to discuss the roadmap and move it forward. Splitting taxonomy terms, Menu Customizer and DFW changes, for instance, have little direct impact on whether SCSS is used for generating wp-admin styles, or which grunt tools to use to do X, or why the code standards need to have Y documented. The former are the outcomes, while the latter is the processes.

              Folks can be in both Slack channels, and follow both Make/ groups, but it allows those who have an interest in standards, Sass, Grunt or other tooling, to have their own focused area.

              WordPress has grown organically, and the items you’ve listed, once achieved, will definitely help the project, but I feel that a project 11.5 years mature shouldn’t need to still be looking at such basics as naming conventions and coding standards. A group (or at least a Slack channel) to drive it forward can have those discussions and present them to the rest of the community for feedback, in the same way that Accessibility and Polyglot groups have established themselves.

            • Aaron Jorbin 9:56 pm on December 22, 2014 Permalink

              “Accessibility and Polyglot groups have established themselves.” The key thing you are pointing out with both of those groups, is that they have established themselves. I don’t think there has been any demonstration that another group dedicated towards tooling has established itself.

              I personally think that the creation of more groups distracts people. Groups should form organically and when they have demonstrated that they are a separate group, we create the space for them not the other way around.

    • Pete Schuster 2:30 pm on December 22, 2014 Permalink | Log in to Reply

      If we’re going to make the switch to SCSS it would be nice to implement a Linter as well to keep things tidy. I also have some proof that property sorting reduces file size as well: http://peteschuster.com/2014/12/reduce-file-size-css-sorting/

    • Helen Hou-Sandi 7:27 pm on December 23, 2014 Permalink | Log in to Reply

      I am following along with/participating in the CSS Chassis project: https://github.com/jquery/css-chassis/, as I feel that this is a great opportunity for us to play nicely with other major projects. I think we will likely influence each other – for instance, the decision has been made to use the BEM naming convention (recognizable by its double dashes and double underscores), which was a specific item discussed at the community summit and something I believe we can adopt as well.

  • 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

    TinyMCE/Editor

    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

    Sorting

    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

    Widgets

    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

    Alerts/Notifications/Flags

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

    Icon CSS Class Code
    dashicons-plus-alt f502

    Misc/CPT

    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 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.

    Thoughts?

     
    • 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

      Agree.

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

      It just makes sense.

  • Jen 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 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

      Hi,

      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.

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