WordPress.org

Make WordPress Core

Updates from Helen Hou-Sandi Toggle Comment Threads | Keyboard Shortcuts

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

    UI Chat Agenda, 5/28 

    Quick check ins on:

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

    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: , , ,   

    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).
     
  • Helen Hou-Sandi 4:45 am on April 23, 2015 Permalink |
    Tags: ,   

    Spinners and dismissible admin notices in 4.2 

    There are two UI component changes in 4.2 aimed at better experiences moving forward that may affect plugin and theme authors. The first is the spinner element, which does come with a non-critical visual breaking change. The second is admin notices, which are an enhancement and do not affect current implementations.

    Core’s spinner is implemented using the .spinner class. Up until now, spinners have been hidden using display: none and then toggled using jQuery’s .show()/.hide() methods. While this works, it has two fundamental problems: it ties us to jQuery-specific helpers, and more importantly, does not reserve the space for the spinner when hidden, leading to elements moving around on the screen whenever the spinner would toggle. The more appropriate solution would be to use CSS’s visibility property, which does reserve the visual space, and control that visual behavior via a class so that any future changes to CSS are inherited by anybody using that component.

    To that end, to show a spinner, you should now add a class of .is-active to the spinner element, and remove that class when it’s no longer active. This state-communicating naming convention is a part of some of our longer-term goals when it comes to semantic markup, so also take note of that. The breakage here is that spinners will no longer show using jQuery’s .show() method, as all it does is set an inline CSS display property, and so you will need to account for that going forward. The best thing to do would be to update to toggling the class as noted, and if maintaining compatibility in the short term with older versions of WordPress is a concern, detect the version and inject CSS into admin_head that applies display: inline-block to .spinner.is-active. There are other methods for handling version compatibility as well, but this is likely to be the method that is most maintainable and easy to immediately understand. Work on this was handled in #22839.

    The second UI component that we’ve improved in a more visible manner is admin notices. Admin notices are often a source of confusion – if you publish a post and then refresh the edit screen, you’ll still get the notice that you’ve published the post, leading you to wonder if you’ve published it twice or what exactly is going on. They’re also distracting, takes up precious space, and can cause visual fatigue, leading to users ignoring notices that really do need their attention. So, we’ve done two things: one, we’ve made the vast majority of core notices user-dismissible (#31233), and two, we’ve also made sure those notices won’t come back when you refresh the page and have JavaScript on/working (#23367).

    Any notice can now be made dismissible by ensuring the it has the classes .notice and .is-dismissible (recognize that naming convention?). Core handles adding the close button and removing the notice for you. However, for the best possible user experience, you should ensure that those notices will not come back on a page refresh or when navigating to another page. There are two different paths for this. The first applies to notices that are added when a query arg is present in the URL, such as message=6. Core will now remove certain query args and use JS to replace the URL in the browser with that “cleaned up” version. By default, core handles 'message', 'settings-updated', 'saved', 'update', 'updated','activated', 'activate', 'deactivate', 'locked', 'deleted', 'trashed', 'untrashed', 'enabled', 'disabled', 'skipped', 'spammed', and 'unspammed'. To add (or remove) items to this array to accommodate your needs, use the removable_query_args filter.

    The second path, for notices that persist across different page loads, is to bind to the click event on the .notice-dismiss element in your own notice and trigger whatever it is your plugin may need to do to remember that the notice has been dismissed, such as storing a site or user option using Ajax. A note of caution that in an ideal scenario, core would eventually provide a framework for persistently dismissible notices that are not tied to query args, so be prepared for future changes if you choose to use this method.

     
    • NateWr 9:55 am on April 23, 2015 Permalink | Log in to Reply

      Thanks for posting! I almost missed this change. :)

    • Blue Liquid Designs 9:41 am on April 24, 2015 Permalink | Log in to Reply

      In supporting older WordPress versions with the new spinner modification wouldn’t you need to set `.spinner.is-active` to `visibility:visible`, not `display: inline-block;`?

    • Jonathan Bardo 6:37 pm on April 24, 2015 Permalink | Log in to Reply

      The lost notice connection spinner doesn’t show anymore. I think a css declaration is missing:

      #lost-connection-notice .spinner {
      visibility: visible;
      }

    • Jonathan Bardo 7:11 pm on April 24, 2015 Permalink | Log in to Reply

      Note to those wanting to bind to .notice-dismiss: Since .notice-dismiss is dynamically added to the dom you will want to add your event like this:

      $(‘.notice.is-dismissible’).on(‘click’, ‘.notice-dismiss’, function(event){});

      If someone has a better suggestion, please advise.

  • Helen Hou-Sandi 9:28 pm on April 5, 2015 Permalink |
    Tags: , , bikeshed,   

    Updates to the default admin color scheme 

    Over on Make/Design, @hugobaeta has posted about some subtle updates to the blues and grays of the default admin color scheme. Work on updating the admin has been completed in #31234. For those who are using those colors in their development, particularly any large areas of colors such as backgrounds, you may want to take a moment to update those values. There’s a handy guide to the changes on the post.

    While we haven’t yet settled on a sensible and semantic way to provide helpers or utilities for these kinds of CSS changes, thoughts and eyes are welcome on #26691 for that.

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

    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.

  • Helen Hou-Sandi 6:18 am on October 10, 2014 Permalink
    Tags: , ,   

    Scalable Dropdowns update 

    In our initial meeting on Wednesday (IRC log), we outlined some steps and a fairly aggressive timeline to get ourselves in a place where changes to wp_dropdown_users() (#19867) and wp_dropdown_pages() (#9864) are suitable for patch review.

    To that end, we’ve opened a handful of issues on GitHub for work and discussion, so that we can track completion. These tasks include evaluating various accessibility areas (touch, mobile, keyboard, screen reader), creating a JS wrapper, UI skinning, and page hierarchy representation. Please check them out and participate as you are able and willing. Let’s keep those issues task-oriented, however – any other questions or comments can go here.

     
  • Helen Hou-Sandi 2:53 am on October 8, 2014 Permalink
    Tags: , ,   

    Scalable Dropdowns and More, chat on 2014/10/8 

    In 3.9, I started taking a look at solving some long-standing scaling issues with dropdowns, notably those for users (#19867) and pages (#9864). I arrived at a conclusion about our mixed usage of autocomplete and autosuggest far too late to make it for 3.9, and did not add it to my plate for 4.0, but would like to tackle it again for 4.1.

    We can solve these issues smartly by using a combination of Ajax-powered autocomplete/suggest and smart defaults, e.g. users with the most content pre-loaded for quick access without having to run a search. As a brief overview of where I see us going with this – a roadmap, if you will: user dropdown, page dropdown, current instances of jQuery UI autocomplete (multisite users and new site), tags/nonhierarchical taxonomy UI, more built-in taxonomy UIs (#14877), and possibly more as we discover appropriate places. Not all of this will happen in 4.1 – think of this as not only a solution to long-standing, painful problems, but also a step in a series of many.

    To that end, we will be holding an initial chat at 19:00 UTC on 2014/10/8 to get things moving. @ericlewis and I have begun early development as a plugin – for more, see this particular branch, which experiments with using Select 2 as a JS helper library for the UI.

     
    • Jon Brown 7:03 am on October 8, 2014 Permalink | Log in to Reply

      I’m new and don’t know the history… I am not trying to reopen any debate. I’m wondering though if using Select2 is fairly settled? (Not because I have a personal preference between Select2, Selectize.js and Chosen, but rather I’d like to know how others wiser than me decided between them).

      • Helen Hou-Sandi 8:47 am on October 8, 2014 Permalink | Log in to Reply

        No hard decision has been made – that’s why it’s one branch in the plugin repo. Chosen doesn’t do Ajax/search on its own and Selectize is licensed Apache-only, though.

        • Jon Brown 2:19 pm on October 9, 2014 Permalink | Log in to Reply

          Ah… forgot APL2 is not compat with GPLV2 only compat with GPLV3. Anyway, was just wondering. I’ve used Select2 and Chosen a bunch in that past. Selectize looked like it had better tests and was lighter was all.

      • Dan Griffiths 10:33 am on October 8, 2014 Permalink | Log in to Reply

        Regarless of the licensing issues, Select2 has by far the best feature set of the three.

    • Max Bond 10:07 am on October 8, 2014 Permalink | Log in to Reply

      Don’t focus only on dropdowns!
      WordPress problem is wider – how to select wp data objects (post types entities, taxonomies, users) inside other objects.
      For example I have two custom post types: order and product. And I need to add product to order. Sounds simple, but there is no standard interface for such select! If needed to add user to order – the same interface should be used.
      Autocomplete/suggest – is good, but not enough. May be to use some kind of popup window (like media library)?

      • Helen Hou-Sandi 4:39 pm on October 8, 2014 Permalink | Log in to Reply

        We need to start with fixing long-standing bugs in existing functions, namely wp_dropdown_users() and wp_dropdown_pages() as linked in the Trac tickets above. As I said, there may be more possibilities as we take each step. If you have a citation for autocomplete/suggest not being good enough, I am all ears.

    • Gabriel Reguly 12:33 pm on October 8, 2014 Permalink | Log in to Reply

      I won’t be able to attend the chat, but would love if you do take into account the dropdown for sites in multisite installs.

      http://wpjourno.com/my-sites-toolbar-menu-wordpress-multisite/

      Cheers,
      Gabriel

    • Ben Hansen (ubernaut) 6:47 pm on October 8, 2014 Permalink | Log in to Reply

      sounds great!

  • Helen Hou-Sandi 11:39 am on September 3, 2014 Permalink
    Tags:   

    4.0 release plan update 

    If you’ve been following along with IRC and Trac activity over the last 24 hours, you’ll have noticed that there’s been a lot of it. We’ve had a number of issues pop up, and thus did not reach the targeted freeze of 16:00 UTC on 2014/09/02. If you haven’t been following along, I highly recommend it :)

    Given that, our new release target is shifted back one day to 16:00 UTC on 2014/09/04. We’ll still kick off two hours beforehand with various pre-launch checks and tasks. This means code freeze by 16:00 UTC on 2014/09/03 – just a few short hours from now. I would also like to run a number of those pre-flight checks in the hour or two before freeze to give us an early chance to squash anything that may come up during those. To that end, an RC2 has been built for final testing.

     
  • Helen Hou-Sandi 3:41 am on September 1, 2014 Permalink  

    4.0 release plan and 8/27 meeting summary 

    Per dev chat on 8/27 (summary below), we are targeting a release of 16:00 UTC on 2014/09/03, kicking off at 14:00 UTC on 2014/09/03 in #wordpress-dev. There are a number of steps to go through, including running unit tests, checking build, and testing various update and installation scenarios. We’ll also do a dry run at the same time on Tuesday, 9/2, before we enter a 24 hour code freeze.

    I’d also like to meet at 18:00 UTC on 2014/09/01 in #wordpress-dev to clear out all open tickets for 4.0 and do an RC2. It is a holiday (Labor Day) in the US, but I will be around throughout the day, as will other committers and contributors.

    Summary of 8/27 dev chat (IRC log):

    (More …)

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