Make WordPress Core

Tagged: UI Toggle Comment Threads | Keyboard Shortcuts

  • Helen Hou-Sandi 5:29 pm on September 17, 2015 Permalink
    Tags: UI   

    For those who don’t follow along with Make/Design and are interested in exploring some UI/UX ideas and projects, I just posted a few possibilities as a prompt of sorts. There are a number of needs, from strategy to interface design to front-end build to whatever back-end changes need to happen to support. None of those projects currently have active owners, so if you’re interested or if you have any ideas of your own, shout in the comments.

  • Helen Hou-Sandi 1:35 pm on August 20, 2015 Permalink
    Tags: , UI   

    8/20 UI Chat Agenda: 4.4 

    After a few weeks off from regular meetings while the final touches were put on 4.3, let’s have our weekly UI chat, today at 17:00 UTC. Inspired by @wonderboymusic‘s call for 4.4 wishlist items, let’s talk today about what our bigger projects are in the world of UI and UX, what our wishlist items are, and what we can reasonably target for 4.4.

    • chriscct7 5:47 pm on August 20, 2015 Permalink | Log in to Reply

      I think it’d be interesting to look at https://core.trac.wordpress.org/ticket/22959#comment:29 if someone’s interested in working on it

    • David Lingren 7:42 pm on August 20, 2015 Permalink | Log in to Reply

      I’d like to know the status of Ryan Boren’s “Retiring media-new.php” proposal (https://make.wordpress.org/flow/2015/01/29/retiring-media-new-php/).

      In addition to the browser uploader, media-new.php offers a number of hooks that allow plugin developers a way to extend its functions.

      My plugin, Media Library Assistant (https://wordpress.org/plugins/media-library-assistant/), adds a form below the drag-and-drop area on the Media/Upload New Media screen. The form allows users to set defaults for standard fields, taxonomy terms and custom fields that are applied to items as they are uploaded. It uses the ‘upload_post_params’ and ‘post-upload-ui’ hooks provided in media-new.php.

      I have not developed an alternative approach to this feature that works in the grid view or Media Manager Modal Window (MMMW). I have found it very difficult to extend grid view and MMMW, and I am concerned that a media-new.php replacement will have similar issues.

      I hope you will think through and meet the needs of plugin and theme developers in any media-new.php replacement effort. Thank you for your consideration.

      • Ryan Boren 5:05 pm on August 21, 2015 Permalink | Log in to Reply

        I replied over here. I updated that post with screenshots of media-new.php + MLA. At the moment, this is just a proposal I’ve been shopping around. It has some interest, but I don’t know if it will get developer time during 4.4

  • Helen Hou-Sandi 4:28 pm on June 4, 2015 Permalink
    Tags: , UI   

    UI Chat Agenda, 6/4 

    Quick check ins on:

  • Helen Hou-Sandi 4:56 pm on May 28, 2015 Permalink
    Tags: , UI   

    UI Chat Agenda, 5/28 

    Quick check ins on:

  • Helen Hou-Sandi 4:20 pm on May 21, 2015 Permalink
    Tags: , , UI   

    UI Chat Agenda, May 21 

    Quick check ins on:

    Specific assignments for:

    • Screen-by-screen sweep
    • Trac gardening

    We’ll finish off with open floor / impromptu Trac scrub and see what, if anything, can get committed now.

  • Helen Hou-Sandi 6:37 pm on May 11, 2015 Permalink
    Tags: , , , UI   

    Weekly core UI meetings for 4.3 

    Remember weekly UI chats? It’s been a couple years since they wound down, but I’d like to get them started again for at least the 4.3 cycle, as we have some efforts that are not specific to a given feature or component team. UI chats are also a great way for newer contributors to get involved, as there are often a number of smaller patches that can be made and committed quickly. We’ll hold meetings each Thursday, starting this Thursday, May 14, 2015 13:00 UTC-4 in the #design channel in Slack. Updates will be posted here on Make/Core.

    For this week, let’s touch on these points:

    • Better responsive list tables.
    • Getting rid of media-new.php.
    • Screen-by-screen sweep for low-hanging fruit on small screens and touch devices (e.g. inconsistent spacing or font sizes at a given media query point).
    • The state of the CSS roadmap.
    • Coverage for other working groups (passwords, network admin, editor, customizer, anything else?).
    • Bug gardening team (see the UI focus on Trac).
    • Open floor (sound off below ahead of time if you wish – remember that this is about admin UI).
  • 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


    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.


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


    • 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


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

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
Skip to toolbar