Quick check ins on:
Updates from Helen Hou-Sandi Toggle Comment Threads | Keyboard Shortcuts
Quick check ins on:
- List tables (@stephdau): #25408
- Media list table (@ericnkatz): #32398
- Select2 testing (@afercia): #31696
- Pattern library / CSS roadmap
- Screen-by-screen sweep: https://docs.google.com/spreadsheets/d/1evtUATA7EC834fB-Vo72kPpV05Lfqk_xzkAD7epQva8/edit#gid=0
- Open floor / ticket scrub and commit what we can.
Quick check ins on:
- List tables (@stephdau, @michael-arestad)
- Media list table @dh-shredder, @ericnkatz, @jacklenox)
- Select2 testing (@afercia, @ericnkatz, @jacklenox)
- Pattern library / CSS roadmap
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.
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).
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
.spinnerclass. Up until now, spinners have been hidden using
display: noneand 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
visibilityproperty, 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-activeto 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
.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.
Any notice can now be made dismissible by ensuring the it has the classes
.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
The second path, for notices that persist across different page loads, is to bind to the click event on the
.notice-dismisselement 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.
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.
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.
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.
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.
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.