This is a summary of the shiny updates…

This is a summary of the shiny updates chat from May 31. (Slack log)

Attendees: @ocean90, @swissspidy, @mapk, @afragen, @screamingdev, @ipstenu, @obenland

Topics:

  • Merge plan
    @swissspidy will have a merge proposal ready for review and publish on 6/2. Friday, 6/3, was set as the deadline for code changes so that there will be enough time to prepare a core patch prior to next weeks Feature Plugin meeting.
  • Overall status
    We discussed various options around how to display a notice on update-core.php when there are no updates pending. The issue of dismissible updates was brought up, and whether that could be deprecated. That should be brought before a bigger audience at the next dev chat. Allowing plugin installations from import.php came up as well; we need to find a solution there and make the experience better. We ended with discussing implementation details of various open tickets, that don’t have an effect on the bigger picture

Next meeting is on Tuesday June 7, 20:00 UTC.

#4-6, #shiny-updates, #upgrade-install

This is a summary of the shiny updates…

This is a summary of the shiny updates chat from May 24. (Slack log)

Attendees: @ocean90, @swissspidy, @mapk, @ryelle, @melchoyce, @adamsilverstein, @obenland

Topics:

  • Open Pull Requests
    • @swissspidy was waiting for feedback and a merge on PR120, which happened right after conclusion of the meeting.
    • @ryelle was waiting for clearance to re-globalize pagenow in order to make more parts of shiny updates testable.
  • Overall status
    We should be at a point where we can write the merge proposal and a patch in the coming week. We have one more week to fix more bugs and get some more user eyes on update-core and themes. @ocean90 mentioned two core tickets that should be fixed before merge, #13071 and #36914 and asked for review and testing there.

Next meeting is therefore on Tuesday May 31, 20:00 UTC.

#4-6, #meeting, #shiny-updates, #upgrade-install

Shiny Updates Chat Summary 5/17/16

This is a summary of the shiny updates chat from May 17. (Slack log)

Attendees: @ocean90, @swissspidy, @j-falk, @mapk, @ethitter, @obenland

Topics:

  • Accomplished work since last week
    • Review requests were posted to the Accessibility, Flow, Polyglots, and Design teams.
    • The feature project landing page was written and published.
    • @swissspidy merged update-core.php into master.
    • Lots of bug fixes and smaller enhancements went in.
  • Activate after install
    We discussed what the best way would be to provide users with the ability to activate a plugin after it was installed. @swissspidy offered to work on a way that would switch the install button to an activation link after the install queue emptied, so it can be user tested for a more informed decision.
  • Update core
    @swissspidy‘s update-core work was merged into master, where it will remain to receive a broader test coverage than it would in a branch. All updates (except for ‘update all’ button) work via ajax.
  • Open floor
    We decided on a new meeting time, 20:00 UTC, that is one hour later than before.

Next meeting is therefore on Tuesday May 24, 20:00 UTC.

#4-6, #shiny-updates, #upgrade-install

Shiny Updates Chat Summary 5/10/16

This is a summary of the shiny updates chat from May 10. (Slack log)

Attendees: @ocean90, @swissspidy, @paaljoachim, @j-falk, @mapk, @obenland

Topics:

  • Accomplished work since last week
  • Remaining work
    The landing page for feature projects still needs to be written, as well as contributor groups asked to review Shiny Updates. @ocean90 opened a few issues that need addressing as well. These things should all be done by the time of the next meeting though.
  • Activate after install
    Shiny Updates introduced a disconnect between installing a plugin and then activating it. @mapk offered to solicit more UX feedback to address what happens when there are plugin install request in the queue while the user wants to activate a plugin, and how WP signals a successful installation while changing the button action to Activate.
  • Open floor
    …was mostly spent on discussing approaches to update-core.php and inconsistencies between the theme and plugin install UI.

Next meeting is on Tuesday May 17, 19:00 UTC.

#4-6, #shiny-updates, #upgrade-install

Shiny Updates Chat Summary 5/3/16

This is a summary of the shiny updates chat from May 3. (Slack log)

Attendees: @ocean90, @swissspidy, @ethitter, @adamsilverstein, @mapk, @obenland

Topics:

  • Accomplished work since last week
  • Remaining work
    @obenland will work on the Shiny Updates landing page for feature projects and fix a bug that were discovered during the most recent user test. @mapk offered to conduct another user test focused on the new interactions with some learnings from the previous one. Goal is to identify any hiccups or behaviors that are unexpected to users. @swissspidy wants to continue working on update-core.php and see if we can get it into shape for 4.6.
  • Most recent user tests
    We briefly talked about the most recent user test (linked above). It showed a variety of bugs that @obenland initially assumed were based on being in subviews of the plugin list. After the meeting it turned out that the test site ran an outdated version of WordPress that didn’t include some of the date that Shiny Update needs to work. It was a good demonstration of progressive enhancement here though, as all actions still worked, they just weren’t shiny. More user tests to come, to make sure that users agree with the new interactions.
  • Schedule for 4.6 inclusion
    Next up is writing the merge proposal that was requested to be published around 6/1, definitely before 6/8.

Next meeting is on Tuesday May 10, 19:00 UTC.

#4-6, #shiny-updates, #upgrade-install

Shiny Updates Visual Records

https://make.wordpress.org/flow/2016/05/02/shiny-update-visual-records/

#4-6, #shiny-updates, #upgrade-install

Shiny Updates Kickoff for 4.6 Chat Summary

This is a summary of the shiny updates chat from April 26. (Slack log)

Attendees: @ocean90, @swissspidy, @ethitter, @adamsilverstein, @karmatosed, @obenland

Topics:

  • Remaining work
    On the updates-core.php side there is quite a bit of work remaining. On the plugin/theme management part outside of that, there is actually fairly little work remaining.
    Since the two parts vary in their readiness so much, it was proposed to go ahead with the theme/plugin management part and propose that for 4.6, while leaving the rest to be continued to be iterated on.
  • More user tests
    @obenland will reach out to @mapk and @karmatosed to get a final round of user tests in, to make sure the new workflows are up to par.
  • update-core.php changes
    Autoupdate settings will be pulled as they are not ready to be worked on yet. @swissspidy volunteered to work on #5, mainly merging the three tables and adding JS handlers for core and language updates.
  • Schedule for 4.6 inclusion
    Core patch should be ready by June 1 for merge on June 8. The remaining time is for creating visual records, user tests, and a merge proposal.

Next meeting is on Tuesday May 3, 19:00 UTC.

#4-6, #shiny-updates, #upgrade-install

Shiny Updates Chat

While 4.5 came a little too early for Shiny Updates v2, I think it would be worthwhile to try getting the plugin and theme management changes into WordPress 4.6. Regular chats have been dormant for a while, but I’d like to continue them starting Tuesday April 26 at 19:00 UTC in the #feature-shinyupdates Slack channel.

Topics for this first chat will include remaining work, the need for more user tests, how to proceed with update-core.php changes, and a schedule for 4.6 inclusion of shiny theme/plugin installs/updates/deletes.

There are still plenty of opportunities to get involved and help bring this iteration over the finish line. Please come join us next week and contribute to the abolishment of The Bleak Screen of Sadness™.

#4-6, #shiny-updates, #upgrade-install

Shiny Updates v2

Shiny Updates v2

What is Shiny Updates?

With the stated goal of “Hiding the The Bleak Screen of Sadness”, the shiny updates team is working on bringing a smoother experience for managing plugins and themes to WordPress.

Shiny Updates v2 is an effort to continue the shiny updates effort from WordPress 4.2. The original shiny update feature only includes shiny plugin updates. The new version aims to extend this to all aspects of updates, installs, and deletes for plugins, themes in WordPress.

There are numerous screens in the Admin that allow you to install, update, and delete themes, plugins and WordPress itself. Shiny updates is exploring ways to improve their design and especially to offer a better user experience by improving perceived performance and limiting confusing notifications.

What does it do?

The shiny updates plugin currently enables the following features:

  • Deleting single plugins, bulk updating and bulk deleting plugins from the plugin page.
  • Shiny plugin installs from the plugin install screen: multiple actions can be queued up.
  • Shiny theme installs, updates, and deletes, multiple queue-able, including multisite.

What is still being worked on?

Currently the team is brainstorming a complete rethink of the core updates page (update-core.php), working to improve clarity and enable easier Update All functionality. Work on that is happening here: https://github.com/obenland/shiny-updates/issues/5

How can I help?

Anyone can help by testing the plugin! Download and install the plugin, then test out all the shiny features: try installing, updating, and deleting plug7ins and themes, including bulk actions, on both single and multisite. Does everything work as expected? Are there any jarring flows? Missing notifications?

Please report any issues on the Github repository, or drop in the #feature-shinyupdates channel in Slack to ask questions or give feedback. It’s also where we have our weekly chats, on Tuesdays 19:00 UTC. Thank you!

P.S. Props @adamsilverstein for ghost-writing this post.

#feature-plugins, #needs-testing, #shiny-updates, #upgrade-install

Ideas for plugin/theme install/update UIs

In the last few releases, the theme and plugin installers received new UI. But the actual procedure of installing a plugin or theme is still old-school: a JavaScript alert confirms you actually did want to install something, then you get taken an ugly screen that prints out sentences of “Downloading package,” etc. If there is an error, everything stops. If it succeeds, you can activate what you just installed or go back to where you came from.

To say this is not the best experience is an understatement. We can streamline this entire flow while also adding some new functionality. Here’s the goal: Installing or updating a plugin or theme should not block you from continuing what you were doing. Secondarily: unnecessary and sub-par user interfaces should be eliminated.

Some ideas:

  • You should be able to install a plugin/theme without leaving the installer screens.
  • You should be able to continue searching and browsing for other plugins (or themes).
  • Multiple plugins/themes should be able to be queued for installation at once.
  • Progress is shown directly inside the installer. Details are only shown if there is an error.

How are we going to do this?

  • Once an install starts for an item, we can “lock” that item to the top left of the results, even if the user keeps browsing or searching for other things.
  • The plugin installer is not yet dynamic, so we’ll need to add infinite scroll and such to allow for continuous browsing (something we avoided doing in 4.0 due to time constraints).
  • We’ll need to come up with a UI for installing a plugin, such as a card-flip, a subtle progress bar, or button changes (“Install” “Installing…” “Installed!”).
  • Updating plugins, themes, and core (from the Dashboard → Updates, Plugins, and Themes screens) should be seamless and happen inline, which will be a completely different UI from installing.
  • We must make sure a user abort (leaving the page) is prevented and/or doesn’t stop the update. We must probably make sure that updates are queued (only one actually happening at once), as we have to take into account maintenance mode, conflicts, I/O operations, and such.
  • If the user is forced to enter FTP credentials, we can request it once in a modal, then send it with each Ajax request — much nicer experience.

The tracking ticket is #29820. Thoughts, ideas, challenges, suggestions, questions welcome.

#plugins, #themes, #upgrade-install