Dev Chat Summary, April 29th

Agenda, Slack log.

Editor (#)
@azaozz@iseulde
Want to concentrate on mobile improvements, especially the toolbar, other buttons around the editor, and ajax saving. @iseulde will publish a list of all items they’ll work on. We will need to test on many mobile devices in couple of weeks, so please join them in the #core-editor Slack channel where they’ll also have weekly chats on Tuesday, 20:00 UTC.

Admin UI (#)
@helen

  1. Better responsive list tables – this involves some PHP-side API changes as well as UI work. The base thought here is that a narrow screened device is also often a mobile device, which may have limited bandwidth. That’s exactly the situation in which you don’t want to have to load more pages to see important information, and our current strategy of truncation is in direct conflict with that.
  2. Getting rid of media-new.php and exploring what a better list table+upload experience might be, both for JS and no-JS.
  3. Getting started on the admin CSS clean up roadmap @helen will be spinning up a kick off for that as well.
  4. Screen-by-screen sweep on touch and small screen devices, grabbing low-hanging fruit like “the spacing is off here” or “font sizes are inconsistent”.

UI chats are going to be spun up again to further this effort, stay tuned for when and where.

Network Admin UI (#)
@jeremyfelt

  • Piggyback on other Admin UI improvements. The network admin often seems quite a bit behind everything else. Responsive list tables would be fantastic.
  • Start looking at network admin screens on mobile. There are many places where workflow can be reimagined. @boren has shared some great thoughts previously, let’s have more conversation around that.
  • It may be possible to start working on what a future site switcher would look like. Especially on mobile, providing context can be tough when working on a network of many sites.
  • #22383-core and #31240-core for nicer ways of creating and editing sites. Might lead to some domain/path validation, which could be useful elsewhere and help address older tickets.
  • Under the hood, significant progress on WP_NetworkWP_Site, WP_Site_Query, and maybe WP_Network_Query would be nice.

@jeremyfelt will come up with a consumable list of 4.3 priorities by next week. Regular multisite office hours are Tuesday, 20:00 UTC in #core-multisite.

Partial Refresh (#)
@westonruter
This greatly improves performance of previewing changes in the Customizer for non-postMessage transport settings (JS-applied changes) by just refreshing the area of the page that has been changed. As such it eliminates some of the need to do postMessage in the first place, while also reducing the amount of duplicated logic that would have to be implemented in JS to mirror what is being done in PHP. This resurrects some code from the old Widget Customizer feature plugin developed for 3.9. Writeup and feature plugin are available at https://wordpress.org/plugins/customize-partial-refresh/

Customizer Transactions (#)
@westonruter
A low-level re-architecture of the Customizer plumbing that has a lot of side benefits and bugfixes, introducing some exciting possibilities for future feature plugins like scheduled settings, setting revisions, and drafted/pending settings. Partial Refresh is a dependency for this. Pull request available, but needs refresh. See proposal at https://make.wordpress.org/core/2015/01/26/customizer-transactions-proposal/. This was previously worked on for 4.2.

Customizer office hours are on Friday, 18:00 UTC in #core-customize.

Better Passwords (#)
@markjaquith

  1. Make “user chooses own password” non-default. We can generate better passwords than they can, and writing as secure password down on a sticky note is in general more secure than memorizing a weak password. So the default should be “give me a new password”, and “let me choose” should be something they specifically choose.
  2. When the use is generating their own password, we should encourage strong passwords more forcefully. Right now we just have a meter. We don’t tell them why it’s “weak”. We don’t tell them how to fix that. Simple feedback like “too short — add more characters!”, “Try adding some numbers and symbols!”. Not only that, we could actually make the addition for them. Show them their password attempt with some additions that would make it better.
  3. In order to help the user modify their chosen password, we need it to be visible. If they click “hide”, they can input it hidden for an “over shoulder” situation. Also gets rid of the annoying “enter twice” thing.
  4. Let’s not send passwords via e-mail anymore, it’s insecure. We’re not getting around “full access to e-mail means you can reset”, but we can stop passwords from sitting around in e-mail accounts forever.

Discussions will happen in #core-passwords. Time and day for regular meetings TBA.

Open Floor (#)

@jorbin has set up a Call for Tickets. Please feel free to add the tickets you want to work in the comments there.

#4-3, #meeting