saving, autosaving, versioning?...

Zanza · 2005-10-31 11:35:36

Ok, not sure where to post this, but…

In a site of mine it has just happened that a contributor hasn’t understood the saving mechanism. She returned on a draft to modify it. Then she clicked on the preview tab. At a glance everything was ok, and then she closed the browser! :))

Yes, without saving! :)

When returned to the article, obviously she hasn’t found the previous modifications.

This is a real case, not an hypotetical scenario.

Why it happened? Because she thought that if the article was on preview, then it was already saved. Now, some hints to evaluate how to avoid such a case:

1. Gmail has an autosave mechanism ajax-based. Should TXP have a similar tool when clicking on “html” or “preview” tab?
2. Should TXP autosave everything the user don’t save in a special record “unsaved writing” at regular interval, to avoid the case that user forget to save a version of article? In the future, even if user shut the browser, he/she can retrieve what he/she was writing from that record (
3. Implement a versioning mechanism with regular autosaving?

Only some hints to improve usability and error recovering…

Bye

Z-

Destry · 2005-10-31 13:49:13

Or there could just be a bright, bold red message that appears while viewing the preview tab that the changes are not saved until actually Saved This is not unlike how the forum works, or how wikis work, or the comments in a post for that matter (though it’s “Submit” rather than “Save” in that case). Simply having better status indication would work fine, be a lot faster/easier to implement, and it’s pretty standard fair.

Zanza · 2005-10-31 14:41:55

Yes, this is surely easier to implement. :)

But comparison with forum and wiki are not the case, in my opinion, because it is a different task. With cms user would write and archive. Like in Word. I apreciate very much that when you enter in TXP you are directed to the write tab, instead a big menu/dashboard/whatelse that require you to decide and find the correct option. It’s good usability, it’s task-oriented. You don’t have to think what to do: you do exactly what you wanted most of the time! :)

So If I write, I write. Sometimes I want to save for later revision. Sometimes I could forget to save or misunderstood what I’ve saved, like my contributor.

In forums you write and publish. It’s a different context, different schema. You don’t save for further revision. So you know that until you don’t push the submit button the task isn’t completed. The more, expert user knows about forum: but I want TXP and any CMS be oriented to unskilled user, that have major experience with desktop tools and think along.

Anyway, a message that the article isn’t saved is good, but maybe also a little annoying for experienced user. I’d like very much the autosave function appear sooner or later in a CMS. Why ask user things that the system can do by itself?

I know that versioning or autosave buffer should be a major implementation in db. But maybe just an autosave after the firts time user saved AND anytime he/she click on html or preview tab would be fine and not too hard to implement. Useful also in crash occasion, or black-out… it’s safer. Why not?

I agree also for a better status message, for the moment, but I’d like someone could think about it.

Bye!

Z

zem · 2005-11-01 22:18:51

3. Implement a versioning mechanism with regular autosaving?

The hardest part of versioning is not the technical bit. The code and design is not that difficult. It’s the UI.

Specifics and examples please. How might this work? What happens when two people edit an article simultaneously? When editing an article that’s already live, how do you select which version is the one that’s shown to the public? How do we present all this to the user without confusing and alienating them?

Zanza · 2005-11-02 10:48:32

>> zem wrote:

>> bq. 3. Implement a versioning mechanism with regular autosaving?

>The hardest part of versioning is not the technical bit. The code and design is not that difficult. It’s the UI.
> Specifics and examples please. How might this work? What happens when two people edit an article > simultaneously? When editing an article that’s already live, how do you select which version is the one that’s shown to the public? How do we present all this to the user without confusing and alienating them?

—

I don’t know TXP at the point I could make a specific.
At a glance I’d distinguish two problem.

1. More than one people editing simultaneously.
This should be avoided: how do TXP save the modifications? I don’t know. I think the problem of autosaving is the same of saving, here. Do you mantain the latest version saved and discard the one before? Without alerting user? The same politic should be used for autosaving. But maybe this need a revision.

2. If you mantain more than one version, then a politic is needed to decide which one is to show. Possibilities:
2. a: the latest version
2 b. introduce a difference between saved and published.

But this is about versioning, that is a future problem. The problem I described maybe could be avoided simply autosaving the article when the following is true:

1. (precondition) The author is editing an article that has already been saved at least once (even in the same session); that is, don’t activate autosaving if he is only writing a draft that he is not sure if to save or not. (I thought of this, but I doubt if is needed…)
2. (condition) he/she is switching to html or preview with a non saved edited version, or
3. (condition) he has not been saving the article for the last XXX seconds.

-Give visual clue to the save button. When the article is saved the save button shoud be “greyed”, and when the user edit again, the button should be “living” again…

More:

- the autosaving option could be deactivated in preferences, so the ones that don’t like can turn it off.

In this version, maybe autosaving is little more than a tech add-on, without worring about versioning or multiple authors working simultaneously on the same article. This is a rare case, after all, and if a site admin think this may happen oftem he can switch autosaving off.

May this help the discussion?

Bye

Z-

Joey · 2005-11-02 13:40:50

> zem wrote:

> bq. 3. Implement a versioning mechanism with regular autosaving?

The hardest part of versioning is not the technical bit. The code and design is not that difficult. It’s the UI.

Specifics and examples please. How might this work? What happens when two people edit an article simultaneously? When editing an article that’s already live, how do you select which version is the one that’s shown to the public? How do we present all this to the user without confusing and alienating them?

The UI of 37signals’ writeboard is great for versioning mechanism.

kalius · 2005-11-02 13:42:04

Adding a locked field to the article table? When a user click to edit and article it will get the article and set the locked field, other users than then click to edit the article are warned that they are seeing a read only version since other user is editing?

hakjoon · 2005-11-02 15:59:55

I think autosave should only really be implemented if TXP can at least handle having a live version and draft version of an article simultaneously. The save from autosave should never change the published version I think. That opens up a lot of room for partially constructed content appearing. Never mind this what Zanza suggested. ugh I’m having a bad morning.

In EZ Publish if you choose to edit an article that has a newer draft saved it will ask you which one you want to use. The interface is pretty clunky though. Writeboard is in fact pretty nice and simple.

I wonder if you would practically really need to manage more then 2 revisions at any moment?

Last edited by hakjoon (2005-11-02 16:03:47)

zem · 2005-11-03 00:19:35

Writeboard is in fact pretty nice and simple.

Writeboard’s requirements are much simpler than Textpattern’s. Just a few of the additional problems we face:

Multiple items to track (title, body, excerpt, custom fields, more?)
Date issues. Post dates are critical for some sites (date-based permlinks, event calendars). How do dates change when a revision is posted?
Interaction between the article status and revisions
Plain text and HTML are stored separately, does this mean we need a revision history for related settings like Use Textile?
Other potential future features like multilingual articles

Help with this kind of stuff is invaluable, and you don’t have to be a programmer to contribute: write use cases, mock up UI screenshots, think through the process, anticipate potential problems. The technical part is a small job compared with the rest.

zem · 2005-11-03 00:22:40

When a user click to edit and article it will get the article and set the locked field, other users than then click to edit the article are warned that they are seeing a read only version since other user is editing?

What happens when someone closes their browser without saving?

Again: you can greatly increase the chances of a feature being implemented by thinking through this stuff in advance. It doesn’t take a programmer to do that, and leaving it to the dev teams means they spend less time doing the hard part and more time doing stuff that could be done by someone else.

hakjoon · 2005-11-03 00:53:21

zem wrote:
Writeboard’s requirements are much simpler than Textpattern’s. Just a few of the additional problems we face

You are absolutely right there. I also think an interface like theirs would extremely crowded in the write panel pretty quick. Version interfaces are hard. Writeboard’s is the most intuitive I have sene but like you said it’s pretty simple. I was trying to keep the discussion going. Some thoughts on your thoughts.

Multiple items to track (title, body, excerpt, custom fields, more?)

In my opinion these should all be tracked as one revision. They all constitute the state of the post at a given point.

Date issues. Post dates are critical for some sites (date-based permlinks, event calendars). How do dates change when a revision is posted?

This is tricky. It seems to me that on a site focused on date based permalinks revisions should not constitute new posting dates (I could be wrong I don’t run any sites this way and ones I did in the past were magazine sites so publication date was static). On a more page based site however you could want exactly the opposite. Maybe something like the “Comments mean site is updated” switch for feed updates.

Interaction between the article status and revisions

I think a lot of depends on the number of revisions you would want to store. Personally I only see myself needing at most 3 statuses. Current, Draft, and archive. A specific revision would cycle through from Draft -> Current -> Archive. When someone edits a published article a new revision (Draft) would be created, this could also be were autosaving would happen. It would stay in this revision until its is promoted to live (Current), the currently published version would then get pushed to Archive. This si of course for my needs others might need more copies.

Plain text and HTML are stored separately, does this mean we need a revision history for related settings like Use Textile?

Seems to me that it should be store just like Title, excerpt, custom fields etc.

Other potential future features like multilingual articles

I don’t even know hwere to start there.

zem, don’t feel like these thoughts are directed at you to solve, just figuring we can discuss them out, all your points are very good. There is also the issue of an interface to rollback Draft to Current and Current to archive which is kind of teh point of having this in place at all. Wow I think this is the longest post I’ve written.

hakjoon · 2005-11-03 02:24:18

I threw up a quick mockup of a potential simple versioning interface. It only addresses one scenario with one new version, one current version and one archived version.

Process:

A new edit of an existing article would begin as article status draft and as a Draft version
When the article is set to status live it would become a Published version (maybe this should be a live version to match the article status (no Draft version would exist at this point).
The previously Live/Published version would then get moved to an Archived version.

You would not be able to set something to be Archived yourself, that would happen automatically by setting a draft to live.

You could replace the current state of your Write tab with any of the other states by clicking the version link. The version currently occupying the write tab would not be highlighted. This behavior is similar to how the Pages and Forms tabs work.

Anyway this was just a quick draft please add to it.

Textpattern CMS

Textpattern CMS support forum

#1 2005-10-31 11:35:36

saving, autosaving, versioning?...

#2 2005-10-31 13:49:13

Re: saving, autosaving, versioning?...

#3 2005-10-31 14:41:55

Re: saving, autosaving, versioning?...

#4 2005-11-01 22:18:51

Re: saving, autosaving, versioning?...

#5 2005-11-02 10:48:32

Re: saving, autosaving, versioning?...

#6 2005-11-02 13:40:50

Re: saving, autosaving, versioning?...

#7 2005-11-02 13:42:04

Re: saving, autosaving, versioning?...

#8 2005-11-02 15:59:55

Re: saving, autosaving, versioning?...

#9 2005-11-03 00:19:35

Re: saving, autosaving, versioning?...

#10 2005-11-03 00:22:40

Re: saving, autosaving, versioning?...

#11 2005-11-03 00:53:21

Re: saving, autosaving, versioning?...

#12 2005-11-03 02:24:18

Re: saving, autosaving, versioning?...

Board footer