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:

expired_login

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:

post_is_locked_ui

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

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

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

Lock table user mouseover:
nyt_lock_notice

Popup for lock within Post Editor:
nyt_lock_popup

#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

Today we had our first scheduled meeting.

Consensus was, for a first pass:

  • Display a simple lock/padlock icon next to locked posts within the post list screen, leaving the “Request Lock” button for the post edit screens.
  • When a post is locked, hide the Quick Edit link, and disable batch edit for the post
  • To unlock a post, the user will enter the post edit screen, then click a button to request a lock. This will trigger a request to appear for the user with the current lock, where they can decide whether or not to allow the new lock.

As far as development tasks go, @azaozz is planning on finishing a first run at the “Heartbeat” API to be committed before the end of the week. I’ll begin working on the list table changes for post listings. We’re currently looking for volunteers to aid, as there’s plenty of room for help! Additional tasks will include the UI for handling post lock requests and auto-save to local storage.

We’ll certainly chat more about this tomorrow in dev chat, and are planning another meeting this Friday (2013–01–25), at 21:00 UTC (the same time as dev chat), unless this doesn’t work for many of you looking to help. Please post here, or come to the chats if you’re interested in helping with this project, and we’ll get in touch with you for further details!

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

Autosave and Post Locking

Components and design

As Mark pointed out earlier, this task includes several different components:

“WP Heartbeat” API, #23216. This will do polling or long-polling so the server is able to send data and notifications to the browser. The primary use will be for setting, monitoring or taking over a post lock. Additionally it will be used to send autosave data to the server. It looks like we won’t need long-polling for now as post locks are not that time sensitive. A “standard” polling every 15 seconds would be sufficient.

Post locking. How exactly to lock a post and how a user can take over the lock? Best would be to prevent user B from being able to edit the post while user A is still writing or editing. Some ideas discussed at the IRC meetup yesterday are to overlay a transparent div over the editor and/or set the form fields to read-only. There will be a button for user B to take over the lock, clicking it will prompt user A to save the post and close the browser tab. While user B is waiting to take over, we could show a non-editable “preview” of the content (even inside the editor) updated with every “heartbeat”.

In addition we would show whether a post is being edited on the Posts screen (list table) , perhaps with the same type of button to request taking over. Other ideas welcome.

Autosave to the browser’s local storage, #23220. Keep several revisions of the content on the user’s hard drive, saving every 10 seconds and “flushing” to the server every 2 minutes (same as currently). After saving to the server (including saving a draft or publishing), empty the local storage and start again. So at the end of creating or editing a post, the local storage will be empty.

This will require “plugging into” the revisions API for restoring revisions from the local storage and some UI for letting the user recover the last revision from local storage when it exists.

Log-in expiration warnings. Update the current functionality to use the new heartbeat API and improve the UX and UI. We can detect cookies expiration earlier and show a warning that would open an iframe so the user can log in again. After that interim log-in, we will need to update all nonces.

Office hours

The first feature team meeting in IRC will be next Tuesday, 22 January at 1pm PST / 21:00 UTC. Please join us if you’re interested in participating in the development of any of the above components.

#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