Autosave and Post Locking – 3/6

Improved user logout notification ( #23295 ) is now in core, and its UI has been tweaked to directly show the login box, rather than prompting first:


There’s been discussion as to whether it’s better not to block the user’s access to the editor/current page when we detect that you no longer have a login token, since it could stop a user while they’re in the middle of a sentence. Any opinions either way? Feel free to comment either here or on #23295.

A simple way to test the above is by removing your login cookie while working in WordPress (Firebug works well).

On local autosaves, there was a decision to pivot from the previous UX posted here, and instead integrate with the new revisions model. This code is still being worked on.

In the land of post locks, @azaozz posted a patch on #23697, that shows a dialog either when you visit a locked post, or when your post becomes locked. If you are visiting an already locked post, you have the option to break the lock. This is still in need of UX/UI love, but looks like this currently:


Finally, a patch on #23665 allows for one autosave per user per post, rather than per post, to let us keep an autosave from before you lost a lock. Testing on this, and the rest of the above welcome!

#3-6, #autosave-and-post-locking

Autosave and Post Locking – 2/13

This is a rather late update, and will serve for the last two; apologies!

Last week, we talked about the locks that went in, and @markjaquith suggested that we replace the “lock” with a Gravatar, which I like quite a bit. Will experiment with that to see if it can work.

Today we chatted about the most recent update to #23220 posted by @azaozz, which integrates the work done by @asannad (AmitSannad on IRC), and adds a UI for selecting which you’d like to restore: localsaves_screenshot

In addition, if it’s found that you have an autosave that has failed, and have a newer version locally, you’re warned (either on the Posts list or Post itself), and linked to the UI that allows you to restore the content (post content and title only) and save at will:

It was brought up during the chat by @nacin that the UI included in the patch might be more than we need, and that we should decide what is best for the user regarding restores, and perform it for them. We continue to chat about this, and opinions are welcome!

Lastly, there is a patch from @mintindeed on #23295 currently waiting for integration! That patch, and the one on #23220 could use some testing — let us know if you run into problems on trac.

We’ll be meeting again this Friday at 2100 UTC (1pm PST).

#3-6, #autosave-and-post-locking

Autosave and Post Locking Update 2/2

A quick update on status!

Earlier this week, the initial run at the Heartbeat API went in. @azaozz is continuing to work on it, and flesh out the API further ( #23216 ).

Tonight, the initial post lock view for the post listing was committed [23355] along with a temporary icon:

I took a look over an older version of the NYT plugin kindly contributed on #18515.
For discussion, I’m including a few examples of the UI/UX from the workflow included in it below.
We don’t necessarily think everything here is a good idea for core (for instance, the “get me out” buttons wouldn’t be necessary), and will likely go a different route for UI, but hoping to get a bit of discussion going regarding the UI/UX flow for the project.

Lock table:

Lock table user mouseover:

Popup for lock within Post Editor:

#3-6, #autosave-and-post-locking

Autosave and Post Locking Update, 1/25

We had our scheduled meeting today in IRC to continue planning the feature for this cycle.

@azaozz noted that he’s continuing work on the Heartbeat API #23216, on schedule for initial commit before next week.

I am continuing work on an initial pass for the post/page tables to display locks, and properly display edit/bulk edit links when locked. Should have an initial pass ready for view on Monday.

@mintindeed offered to help port his plugin to core for improved login expiration warnings, which is great! He’s created #23295 to track the efforts.

@asannad (AmitSannad on IRC) offered to help with localstorage Autosaves, which is being tracked on #23220. Initially, we’ll use a simple schema for storage, but will probably need something more complex later on to avoid collisions where multiple databases are used within the same domain.

As initial guidance for improved workflow for locks, we’re looking over the plugin mentioned in #18515. @nacin is checking with the authors to see if there’s a new version we can take a look at.

Our next meeting is on Tuesday, January 29th at 2100 UTC (1pm PST).

#3-6, #autosave-and-post-locking

Agenda for today’s autosave and post locking team…

Agenda for today’s autosave and post locking team meeting at 21:00 UTC:

  • Assign contributors for each component: Autosave in the browser storage, Post locking, Login expiration warning.
  • Further discussion on workflow for post locking, perhaps look at the plugin by jayminkapish on #18515.
  • Free-form Q&A.

#3-6, #autosave-and-post-locking

Autosave and Post Locking Update

#3-6, #autosave-and-post-locking, #team-update

Autosave and Post Locking

#3-6, #autosave-and-post-locking

WordPress 3.6: Autosave and Post Locking

I want, as a major 3.6 bullet point, that we should never lose posts due to expired cookies, loss of connection, inadvertent navigation (even if AYS’d), plugin or core errors on save, browser crashes, OS crashes, cats walking on keyboards, children drooling in keyboards, etc. I want people to trust WordPress with their posts. They should never fear that something they’ve spent time creating or editing should go away due to their mistake or ours or that of a third party. Mistakes and errors should be recoverable. I can’t stress enough how important it is that people believe this and have good reason to believe it. If a post gets lost, there is a catastrophic loss of trust, that could take years to be regained (if indeed it ever is). This is people’s time and their creative output we’re talking about. If we’re not valuing those things above all else, then our priorities are seriously out of order. This is an all-hands-on-deck item for 3.6. Even if you’re not actively working on the code or the copy or the UI or the UX I want you to be thinking about ways in which WordPress could better treat your creative output as the valuable artifact it is.

Things this will likely involve:

  • Local storage of post data while editing, in-between autosaves and manual saves.
  • More frequent “heartbeat” pings to the server (allowing data to hitch a ride at certain intervals, and also allowing us to quickly deliver messages back from the server about events).
  • Real and more granular post locking. Right now we just have a wimpy notice that isn’t a good deterrent against people simultaneously editing a post and overwriting each other’s changes.
  • Probably some interaction with the team working on improving Post Revisions.
  • UX work for making recovery from failure scenarios smooth, clear, and worry-free.

@aaroncampbell and I have chosen @azaozz to lead this, as it will probably be very JavaScript-heavy. There are a lot of moving parts here, so please leave a comment if you’re interested in this important, heroic, virtuous endeavor. 🙂

#3-6, #autosave-and-post-locking