Auto-save draggable forms

Subscribing.

Marking critical, I can't do that sadly - hope someone else picks up.

The changes in block.js delete also the code that stops a user from moving a block to a not allowed region. That should be put back.
The changes in tabledrag.js should add the case when there is an error in saving the changes too. On line 807 there is a new empty line that should be removed.

I figured out a way to submit practically every form using JS which we can use for these UIs that supports returning form errors. I'll post a patch tomorrow.

Baris - the regions are allowed, just not for certain blocks, so they can't be greyed out across the board. This is to stop you from making your site unusable by disabling the 'system content' block (which actually contains the block admin screen, and all other admin screens).

While I'm a bit concerned about saving people's mistakes without a corresponding undo button, I think I like this.

I've been working on a site with a lot of blocks recently (probably about 30-50), and the most irritating bit of working on that site is enabling a block by putting it into a region, saving it. Scrolling back up to find the block again, then clicking configure to get block visibility rules. You can get 'round it by opening configure in a new firefox tab but it's easy to forget.

This would (probably) also fix another annoyance - open the configure link in a tab to delete a custom block, delete it, then try dragging another block and saving the form - you'll get a validation error because it tries to save the 'missing' block which is still in the form.

This is nowhere critical.

I have some doubt about this from a UX perspective. What do the UX gods think?

Also, I think 'auto save' feature has been considered and rejected when drag-n-drop was being worked on in D6, so at least we'd need to reevaluate the reasons given back then.

From the 11 users we observed in our last usability test, about 6 initially forgot to save blocks. But corrected it fairly fast, so if 50% of our users fail. I think its pretty critical.

I think its an quick fix, to a big issue -hence why it should be critical.

I defer to the UX gods.

@Bojhan: It's a quick fix in that it won't be a 100KB patch, but if we want to fix this properly, we'd probably need to expand the current AHAH feature set (Communication between JS and the server for forms) and that will take some time to figure out. I expect I will have at least a preliminary patch this evening.

Sure, I never imply easyness of code :)

So the situation where this most concerns me is places like book administration, taxonomy drag and drop, menu links where you have lots of items, it's easy to drag stuff into the wrong tree, then want to refresh/back out of that page to start again. If we have autosave, then just trying stuff out can leave you with a massive job to fix your changes.

We'll need some feedback on the page to say it's been autosaved, I'm wondering if we can keep very basic revisions in the form cache to provide an undo button - just for changes made while on the page.

@Baris
When the main content was converted to a block it was a discussion and they decided to use an alert and move the block back where it came from so that is the desired behavior.
The fact that now a block will always be added as first it's a bug and I marked your issue as a duplicate. The bug is known and there is even a patch for it, but got forgotten here #477018: Reordering blocks doesn't work as it should

catch: I think we need to evaluate that on a page by page basis, or as you said initiate a pattern. I don't see for the scope of this issue, that we should map it to those cases already.

Let's get some work done on this.

Bojhan, afaik this issue tries to implement it for every draggable form across the board - so if we have a blanket autosave for those forms, we need to make sure we don't make things worse.

I don't feel we should, it only makes the scope of this issue larger. Instead a generic pattren, then an issue for blocks, then see where else it applies. Because it doesn't always apply.

Baris - there's no select list on menu, term or book administration - it's those pages that concern me. Like Bojhan said we should probably just leave them out of the patch.

I don’t think auto-saving this form is a good idea for several reasons:

• We don’t auto-save other forms in Drupal, so this form would be an exception. This might confuse users even further (“why is this form automatically saved, but that form isn’t?”)
• There’s currently no way to undo the changes. With auto-save, it’s way too easy to destroy the block configuration.

Instead of auto-saving, we could prompt the user when he leaves the form with unsaved changes. Safari is doing that for most other forms, but not for the block settings form.

Ohh gosh :(. I really didn't want to turn this into a discussion, because that could drag on for a long while. Anyway, yes its an exception and it won't confuse users if we give good feedback. Even if it is the odd one in the crowd, with good feedback I don't feel it would confuse them too much - but obviously we need to apply this all over the board.

Why would someone destroy the block configuration? I don't see how its much more destroying then a save button. Its not like you go to the block page, to play with blocks.

We could do the model when unsaved changes, but it seems like a compromise.

Why are you thinking that it won't confuse users?

If the changes are saved instantly it's impossible to "revert" to the previous state by canceling changes. It happened to me occasionally that the dragging script went nuts and placed blocks in regions I didn't want (maybe because the browser scrolled up or down automatically). IMHO, reordering (not configuring) blocks is a very explicit operation that should be confirmed; it's not something you do every day.

@kkaefer Because I feel when we give the feedback of yellow to fading to blue it will make sense. It shouldn't trigger before the mouse is released. Looking at the usability tests we ran, almost every single individual forgot to save - which makes this a very critical issue, just giving a confirmation will just trigger more use of an bad pattren.

Of course there are times when this isn't going to work, ie when your browser scrolls up. But it won't save until you release, so I don't see it being such a very big problem. There are times when undo could be useful, I do not disagree with that - but making the barrier to change lower, should also mean that people won't mind just fixing their mistake.

As I said, this could easily turn into a discussion about explicitly asking them to confirm stuff. But as I am trying to point out, that's a bad software pattren - 80% of the people make changes, and they want these changes. Only a very small percentage makes a mistake and wants to undo it all.

subscribing

I'm with kkaefer on that one. However, autosave can be interesting, but it would be interesting if it would be possible to turn of that feature.

This could be implemented independent from the tabledrag.js. We should write a generic "autosave form" script so that we can say that a certain form autosaves. The tabledrag.js script would then just invoke the form autosave and the "autosave form" script takes care of the rest (e.g. disabling the submit button while saving or obtaining new form tokens or determining changes between the current form and the newly rendered form after a save).

subscribing...

Subscribing.

I am of the opinion that an undo feature should be a required part of making this particular solution—autosave—an acceptable change.

In fact, the problem being solved is people leaving forms without saving changes. Autosave is not the only solution. If the key problem is people wanting to configure blocks immediately having moved them to a new region, the configure link could trigger a confirmation whether the user wanted to confirm unsaved changes, before moving on to the configuration page. That would ensure users get the behaviour they expect (they have made the change to the blocks and they haven't lost it) without the significant regression that there is no way to undo a mistake—not even by refreshing the page.

Don't get me wrong—I think autosave would be fabulous. I just think it would be fundamentally flawed without a "Revert" (to previous configuration) button.

Here's something else to think about—if you have block changes autosaving, then if someone is working on a live site (it happens) the blocks will be moving live on the site one-by-one as they are making changes, rather than a user being able to create an entire new configuration and then save it. That would likely not be desirable for all users.

I've been working on a site with a lot of blocks recently (probably about 30-50), and the most irritating bit of working on that site is enabling a block by putting it into a region, saving it. Scrolling back up to find the block again, then clicking configure to get block visibility rules. You can get 'round it by opening configure in a new firefox tab but it's easy to forget.

You know, the simplest possible solution to this problem would be to just add to the configure links:
target="_blank"

That way, every configure link would open in a new window and you'd never throw away your new block setup.

In fact, this is such a common-sense and quick patch that I'm going to post an issue for that now. In the event that a more sophisticated solution is implemented, it can go by the wayside. But in the meantime, we can at least have that guaranteed to be in D7.

ETA: #515530: Prevent loss of user's changes when clicking configuration links in Block admin page

Sadly this doesnt seem possible before January 15th, would love to reopen this for Drupal 8.

Downgrading all D8 criticals to major per http://drupal.org/node/45111

When reworking this plz consider also to implement http://drupal.org/node/1268530.
I guess those two issues home some points in common.

Subscribe

Big fat -1 from me. Reordering stuff usually takes several steps, which can take a couple seconds / minutes to get right : place this row here, that other row there, hide that other one, *then* apply all atomically. We cannot force users to only take intermediate steps that have to correspond to a "valid" state you'd want to see live. If any single row drag gets applied instantly, I would get scared each time I have to reorder stuff on a live site.

+ a draggable row has other components apart from the d-n-d handle (take Field UI's "Manage display" : each row has selects for label display and formatter, plus formatter settings in an ajax subform), which are *not* autosaved (and that we wouldn't want to autosave), so having just the reordering be autosaved would get fairly confusing.

Autosave was explicitly left out for those very reasons when d-n-d landed in d6, and those reasons have not changed since then. I do not really see how we could suddenly decide we discard them. If usability tests show there is a misunderstanding around this, then UX enhancements should focus on how we make the behavior clearer, not on changing it, because IMO we can't.

Along with agreeing 100% with yched in #42...

I question how this might cause problems for accessibility, haven't thought it through so tagging.

See somewhat related: #1272990: Make tabledrag warning message show when row weights are enabled, and add WAI-ARIA live region

Closed #376107: Ajax support / Auto-save support for tabledrag.js, and from #42 it sounds like this one just need to be marked "won't fix"?

I agree with a "won't fix" here, but maybe at least showing a warning when navigating away from a page with unsaved row changes would solve the core UX issue while not creating others?

As much as i hate the "table drag shuffle" of move save configure i agree with yched here as well as it relates to "invalid intermediary steps" especially as it relates to other uses of draggable tables (field ordination, etc).

Marking wontifx as that seems to be the consensus but i agree that our current UI/UX is broken for most new users because everyone i train always forgets to save first and has to redo their work.

+1 for the "you edited without saving modal" or even autosaving the form locally (object cache) and repopulating your changes with the option to revert at the top like views does.

Agree with won't fix for this suggestion. Am still keen to progress #515530: Prevent loss of user's changes when clicking configuration links in Block admin page if it has any support.

See #1644090: [Meta] form data loss

Nothing to review here, so removing tag.

fixing tags.