saving, autosaving, versioning?...

alannie · 2005-12-20 16:44:07

zem, after I posted I realized I probably should have followed an use case format more like hakjoon’s. Sorry about that. Here goes again:

Boss tells employee to make some changes to an article on the website.
Employee logs into Textpattern, clicks on the Articles tab, and clicks on the article to be revised.
Employee makes the revisions, and saves the revisions.
Employee then notifies the boss of the revised article.
Boss reviews the newly revised article.
Boss approves the revised article. If the article weren’t already live, the boss would make it live at this point.

It’d be nice if there were a way to keep the unrevised article live while the boss reviews the revised version, and then when the boss approves the article, he/she could make it live. All the other current status options (draft, pending, etc.) make the article disappear from the site.

Is this what you were looking for? I am happy to help in whatever way I can.

Zanza · 2005-12-20 18:09:40

Just to add a little mess in the discussion, last week I heard of another TXP user that missed his changes when clicking on the “preview” tab and then exiting, being sure that changes were already saved. This is more a “please, allow autosave or at least a better feedback about unsaved preview” issue.

About the versioning, the need I feel is about that:

Mr. Jones is making an article. He doesn’t publish it. It needs a revision.
Peggy the blonde editor is checking the article. She find some things to change. She does. She alerts Mr.Jones: “Hey, I changed your article to fit our very high editorial standards. Please, have a look before publishing”.
Mr. Jones finds that in revising the article, Peggy cut an important sentence from his previous article. So he looks at the previous version he saved, copy the sentence and paste it in the new version of article. Then put in “pending“mode and call Peggy.
Peggy read the article and publish it.

Another scenario. One-person only.

Jimmy the thinker is writing an entry on his blog. He save the draft for further revision and go sleeping.
So it comes tomorrow. Jimmy wakes up and washes his teeth. Sorry, this is OT. He sits at the computer and gives a look at his previous article. He finds that the tone is not so good. So he makes major changes. Then he publishes it. In the article he cut some info that made the previous version too long. Now it’s shorter and smarter. Jimmy feels good.
That evening, coming from his thinkings, Jimmy the thinker think that the info he cut that morning may be a good, a very good new post.
He looks the previous version of the article laying in the versioning system, copy some link and some good sentences he originally wrote, and paste them in a brand new article, without the need of writing them down from scratch.
After published, he thinks: “I’m really looking smart, uh?”. After all, he’s Jimmy the thinker.

Z-

Last edited by Zanza (2005-12-20 18:10:41)

zem · 2005-12-20 23:48:23

A good start, thanks.

4/5/6 is where it gets fuzzy. How is the boss notified? Offline or automatically? What does the boss see when he reviews the revised article? How does he know what’s changed, and does he need to look at previous versions? How does he approve it and make it live? What happens if he wants to make changes first, or reject it? What actions are available (in the form of buttons, links, etc) during each of these steps?

alannie · 2005-12-21 00:23:22

zem wrote:

4/5/6 is where it gets fuzzy. How is the boss notified? Offline or automatically? What does the boss see when he reviews the revised article? How does he know what’s changed, and does he need to look at previous versions? How does he approve it and make it live? What happens if he wants to make changes first, or reject it? What actions are available (in the form of buttons, links, etc) during each of these steps?

For the purposes of this use case -

automatic notification would be super but not required.
what the boss sees when he reviews the revised article: the preview pane would work fine.
if the boss wants to make changes: he can do so from within the text pane.
to approve: boss would change status to “live”.
if he rejects the revision: boss would not change status to “live” and instead delete the pending revision or notify the employee (offline) to make further revisions.
actions during all those steps: the usual “Write” actions plus an additional option to keep the revisions in pending status while still leaving the original live version untouched. If there could be a version history as a list of links, that would be great. As soon as the boss changes the status of a pending version to “live”, the live version would then sync with that version. An option to delete the pending revision and leave the live page untouched would also be needed.

I realize that there are still details to figure out such as how to denote live vs pending versions in that list of versions, but I wanted to explain my situation in terms of need and defer to the expertise of the Textpattern programmers/UI designers in coming up with the most appropriate solutions.

If you want me to, though, I can throw out some more ideas for solutions, as long as you don’t mind that I’m coming from a place of relative ignorance on the inner workings of Textpattern. :)

scross · 2006-01-17 19:48:06

A simple online/offline system could be used, where only one version of an article can be online at a time. So you would have Ben, the article writer, and his boss.

1. Boss emails Ben telling him to make article for providing information about the company website.
2. Ben creates this, but it is ‘Offline’.
3. Boss checks what Ben has done and changes the status to ‘Online’.

=Later=======

4. Boss emails Ben telling him to update company information on the site.
5. Ben edits article, making necessary changes, but new version is ‘Offline’ and old ‘Online’ version is displayed.
6. Boss comes along and checks Ben’s work. Boss then changes the new version to ‘Online’ and the old version is changed to ‘Offline’.

This can continue for a long time. Dates are not updated, but the body of the article and the status are the only things versioned. You also would have version numbers or modification dates (to act like IDs) for each version.

Saving other fields and options for each version just makes things more complicated and difficult for the cms, the programmers and the users of the cms.

With a cms of this level, wishing to compete with other popular cms systems, a versioning system would really give it the edge.

Now…autosaving:

If the system created a new version for every field change it would be a nightmare. Instead an option should be set to enable a fallback. So data is saved, but into a different table for articles which aren’t directly saved. These unsaved articles can be removed through TXP, if they were deliberately not saved, or the user can copy the code into their article. This would really help, but wouldn’t mess up articles or make assumptions.

zem · 2006-01-17 21:17:30

I’ve added a page to TextBook for documenting the design:

Feature Requests

hakjoon · 2006-01-17 21:21:00

scross wrote:
If the system created a new version for every field change it would be a nightmare.

But a lot of those fields can be where the changes are. For example the change could be in the excerpt or perhaps, the article image. Also if important information is stored in the custom fields. Even settings like “use textile” could render a new version unusable if they don’t match how the version was created.

scross · 2006-01-17 21:46:51

that’s true…and is what makes producing a version control system for TXP is so difficult. So for each version we are looking at saving data about:

article body
article title
article excerpt
article categories
article status (online and offline)
article section
article comments? (yes or no)
article comments invitation
article date – users can change in a new version if they wish
article option: use textile?
cms option: use textile?
excerpt option: use textile?
custom fields

That’s a lot of data, but would probably be worth it. The problem we are facing is that the article can be affected by change in settings and environment. Something that could be out of our control is a change in link structure, so someone creates an article that links to another article in a certain way (rewrite scheme), but the rewrite scheme is changed and a new version links in that new way. The older version of the article, however, if brought back would have invalid links to other articles.

A way to prevent this is to design a txp tag specially for correctly rewrite scheme in older versions which lets the user enter data about the article, but not just give a link. Then Textpattern could parse this to format it correctly. An incorrect link in an old version could be obvious to a human, but if we made Textpattern try to sort these errors out, it would also break some links because they shouldn’t be converted.

I always find that code is really easy, compared to figuring out things would work out best so well done on your theory work on this everyone, it’s good ideas.

I have quite a lot of coding experience in php, so I will probably try out a few things on my local copy of Textpattern, to see if I can make anything of this.

misterk · 2006-01-23 23:59:09

I’d absolutely love to see this make its way into textpattern. I’d use it very simply to know that my stuff is always there, and as a way to see how my articles evolved as I moved through the writing and editing process. I mostly just like having all that information saved somewhere, and know it doesn’t just go poof.

In terms of mocking it up:

Have a versioning tab along with text, html, and preview. I don’t think that the versioning should be given a very predominant spot in the default editing interface. But pull up the versioning tab and it replaces the center fields with a list of versions, the option to create a new version.

The listing of versions could have time elapsed between versions and a significance of change metric (the amount of words added/removed?) to provide you with some general idea of which version is which. Also a changed_by field for those with more then one author.

I don’t think tabs within the versioning tab would be very doable – all the tabs can get confusing. But a way to see the fulltext of a certain version while maintaining any changes made to the newest version (in the text tab) would be necessary. You shouldn’t need to be able to edit the old versions.

You could have a current version, and a published version. Imagine a list of versions by date, newest on top. The published version would be bolded or have a highlighted background, but there could be newer (not yet published) versions above it.

Locking seems necessary, but it sucks to get locked out for any period of time. I don’t know how easy it is to work with diffs, and I don’t want things to be too complicated, but maybe a merge changes to current version option would help allow leniency controlling who edits when but making sure peoples changes aren’t overwritten.

There could also be a preference to let the Publish button either overwrite the current version or create a new version. If by default it created a new version, there ought to be a minor edit checkbox that overwrites the current version (as it is with writeboard).

I hope I’m not rambling too much.

It would be cool if there were a public interface to the versions, a good set of <txp:version> tags. Something like <txp:version_older>, <txp:version_count>, etc. Basic ways to display the newer and older versions to anyone browsing the site.

I think the fields that should be kept with each version are: title, body, excerpt, category, date, custom1..10, and the text filter used. I think Draft/Hidden/Pending/Live/Sticky are different from versions, and should apply to the article and all its versions. The same with comments, although maybe you could crib comments received against the public version at the the time the comment was posted. I don’t think you need to duplicate comments in storing them with a version.

Should older incarnations of an article HTTP 301’d to the newer version? It seems stupid to have to keep updating the permalink, so maybe just write date based url’s according to the initial date.

Also what to call it, versioning or revisioning? I don’t want to get too pedantic. But it seems like revising is more applicable.

I wouldn’t want to munge the textpattern codebase what little php I know, but I’d offer to help with interface issues.

jamiew · 2006-05-04 16:32:16

misterk: I’ve been stewing over this idea for a while and love all your ideas! Some thoughts:

I would call it “versioning,” but I’m a programmer… a “history” containing “revisions” might be more intuitive for people, and mesh w/ the syntax that most wikis use

Locking is an absolute must. The pain of doing an interactive diff (which both people will probably be doing simultaneously) is way more of a hassle both pragmatically and programmatically. Taking turns editing an article usually turns out better work anyway ;)

DokuWiki has an automatic n-minute timeout after which you have to Save or Preview the article to refresh the lock which has worked pretty well for me. Also helps prevent an edit lock leftover from a browser crash. Would be good if admins/higher-ranked users could hard-remove locks as necessary.

I’m a little confused over how to handle Article Status vs. Revision Status (for the “not yet published” revisions). A master Live/Pending/Draft and an individual revision Live/Pending/Draft could get confusing…

I think you were hinting at the idea of having a Notepad-plugin-esque comments box for the authors to add notes about what they’re thinking (perhaps in addition to an “Edit Summary”)

Once I’ve finished up my finals next week I’d love to bang out a prototype version! Anyone want to have a go at a visual mockup?

scross · 2006-06-17 17:01:13

The ideas that are coming out now are really great.

1. Don’t worry about what to call it just yet.

2. Concerning article and revision status I believe that the article should have the usual status and a revision should either be active or inactive. Only one revision can be active and this is the one that the article status applies to. It should be easy to change the active revision and see which one is the active one.

3. The idea of public side tags is great but if you wanted to show a certain revision it would be best to be able to know which one and for it to always link to that version. For this sake each revision could have a generated id number which would be visible to the user. They would then use that id to refer to the correct version:

<txp:version name=“original” />

You could also order the versions by their time and refer to the older version using your tag:

<txp:version_older />

4. Instead of locking the system could simply check whether the content of the file had changed since the time the edit was started and then show the user his version and the current version side by side so he could merge them together and probably submit either textbox by using a button below each one. I don’t like the idea of making a time limit because it might rush them or they might lose their content if they were too slow.

5. An optional revision summary is a good idea and probably wouldn’t be too hard to implement.

6. Revisions shouldn’t be created by saving an article/revision. A new version should be created specifically by clicking a link next to one of the versions to create a new version off of it. If you are editing a revision and click save it shouldn’t add a new revision but instead only save that revision. Otherwise the amount of revisions would just build up. However, a checkbox like you said (which would be by default unchecked) could be available that would allow a user to save into a new revision. Revisions should be deleteable by simply clicking a delete button next to them (with some sort of ‘Are you sure?’ dialog).

7. It would be best for Textpattern if the user could work with articles and never be bothered by versions unless they intend to use them. So it shouldn’t be right at the front but instead somewhere less “big”. So the system should work exactly the same for users that don’t understand and don’t use version control. You wouldn’t want to suddenly make the interface much more complex.

8. As you say the article status and the comments shouldn’t be linked to versions but most of the other stuff should.

Textpattern CMS

Textpattern CMS support forum

#25 2005-12-20 16:44:07

Re: saving, autosaving, versioning?...

#26 2005-12-20 18:09:40

Re: saving, autosaving, versioning?...

#27 2005-12-20 23:48:23

Re: saving, autosaving, versioning?...

#28 2005-12-21 00:23:22

Re: saving, autosaving, versioning?...

#29 2006-01-17 19:48:06

Re: saving, autosaving, versioning?...

#30 2006-01-17 21:17:30

Re: saving, autosaving, versioning?...

#31 2006-01-17 21:21:00

Re: saving, autosaving, versioning?...

#32 2006-01-17 21:46:51

Re: saving, autosaving, versioning?...

#33 2006-01-23 23:59:09

Re: saving, autosaving, versioning?...

#34 2006-05-04 16:32:16

Re: saving, autosaving, versioning?...

#35 2006-06-17 17:01:13

Re: saving, autosaving, versioning?...

Board footer