[development] Requiring node revisions

[Derek Wright]

On Jun 7, 2007, at 7:42 AM, Dries Buytaert wrote:
>
> On 07 Jun 2007, at 11:04, David Strauss wrote:
>> * Fewer site administration options
>> * Cleaner node-editing pages for node administrators
>> * Less confusion over what checking the box does: "Aren't I  
>> creating a
>> new revision of the node even if I don't check it?"
>
> The above arguments seem to be different variations of the same. ;-)

Not quite true... they're all about the UI, but different parts of it.

"Fewer site administration options" is about the admin UI at admin/ 
content/types.  However, the later suggestions for a UI to control  
automatic pruning of revisions cancels this improvement.

"Cleaner node-editing pages for node administrators" is about the  
fact that everyone with administer nodes permissions always sees the  
revision-related UI.  This, too, is nullified by the question of the  
"Log" text area, though that could potentially be solved by yet more  
options at admin/content/types. ;)

"Less confusion over what checking the box does..." is a variation of  
the node-edit form simplification.  However, there are different ways  
to make the UI cleaner, and I believe this motivation is a good one  
for just removing the choice from the UI entirely, instead of finding  
a more clear way to present it.

> Node revisions is one of these things that people are not expecting  
> when they first start using Drupal as a simple blog, a forum, or  
> whatnot.  It is the kind of feature that makes them shout: "Drupal  
> is overkill for a simple $site!", for different flavors of $site.

Perhaps.  However, I maintain that the Drupal taxonomy UI and  
functionality is vastly more complicated, confusing, and overkill for  
some sites than node revisions are.  Yet, even though lots of people  
complain and shout, a huge percentage of sites end up using them  
eventually in some way.  The taxonomy functionality remains a default  
part of core because we realize that it's so fundamentally handy,  
once people get over the learning curve and start using it, they  
wonder how they ever lived without it.  I believe many "simple"  
sites, once they gain a little experience with node revision  
functionality, will embrace it.

> Furthermore, the most important "visual artifact" of node revisions  
> is not the "create new revision" checkbox, but the fieldset/ 
> textarea for the log message that is always expanded (fixed in  
> D6).  I argue that it is mainly the textarea that is confusing and  
> that feels like clutter/overkill -- especially because the checkbox  
> and the log message are not logically grouped. The proposed change  
> sounds somewhat counter-productive because the log message textarea  
> would become more prominent (while the checkbox goes away).  Not  
> sure if we win or loose ...

Agreed.  That's why I believe the text area should be controlled by a  
set of 3 radios: 1) expanded, 2) collapsed, 3) hidden.  It should  
default to hidden except for content types (and potentially a role- 
based and/or per-user setting) that are explicitly configured to have  
the fieldset present or expanded.  Then, by removing the checkbox (we  
always make a new revision), we solve the problem of the 2 UI  
elements being separated, and then we can just focus on the single  
remaining UI element and make it as slick as we want.

> One could argue that users are more accustomed with simple blogs,  
> forums, and straight-forward publishing tools than with Wikipedia,  
> or wikis in general.  For these users, a revisions tab and a log  
> message might be both scary and overkill.  Versioning takes a  
> special kind of mindset that not everyone ships with.  Making it  
> less visible for the user, while maintaining its functionality,  
> seems like a good idea.  It's like the auto-save feature in Word,  
> Google docs, Mail app, etc.

Exactly.  Explicit version control is one thing, but just about  
everyone grasps the notion of "undo", especially when editing text.   
The more we can simplify the revisions UI while making it an integral  
part of the system, the better Drupal will be.

> Of course, we could introduce a new setting to nuke the log message  
> and to make it 100% transparent, but it might render the "fewer  
> site administration options" argument moot.  Furthermore, if we  
> need more complex mechanisms to expire or tome revisions, that  
> might also conflict with the argument that this would simplify  
> administration.

These seem like different variations of the same. ;)  We'll have a  
slightly more complicated content admin UI, in exchange for more  
simplicity conceptually, in the node add/edit UI, and in the code  
(since we remove all the update code paths on node save and  
everything is always an insert).

> I think we need to investigate more -- and look at this from the  
> different use case (i.e. forum, blog, wiki, brochure site,  
> collaborative site, etc).

I think all kinds of Drupal sites would benefit from always having  
revisions enabled by default.  Site admins would have to go out of  
their way to either a) prune old revisions or b) harness more  
advanced aspects like log messages and roll-backs.  Sites that  
*really* care about the performance impact of the extra rows in  
{node_revisions} either have a) tons of nodes, b) tons of users, and/ 
or c) tons of edits of existing content.  Unless it's *only* c) and a  
small handful of users are so active on a tiny site that they create  
hundreds of thousands of rows in that table (highly unlikely),  
they're going to have to understand enough about tweaking the  
performance of their site and DB to be able to navigate a relatively  
simple admin UI for pruning old revisions.

> How often do we do a rollback on drupal.org?  How often have you  
> done a rollback of one of your blog posts? How often have you  
> rolled back a change on your company website?  If the answer is  
> "never" or "once a year" this should be reflected in the UIs.

IMHO, those are the wrong questions.  These are more appropriate:
- How often have you wondered who and when was the last person to  
modify something?
- How often do you wish you could have seen exactly what they changed?
- How often do you wonder how frequently something is being changed?
...

For myself, and probably a large majority of drupal.org users, the  
answer to these is "all the time".

> Let's think and brainstorm about this more, because we might be  
> able to improve the revision system *and* make it easier for the user.

I agree.  I think there are a bunch of revision-related UI  
improvements we could make.  I'd be thrilled to help (and David seems  
to be off to a great start) cramming a bunch of them into D6.

> I just wanted to point out that we should take this as an  
> opportunity to optimize the user experience for people that want to  
> do simple things, and that can't be bothered with rollbacks.  Let's  
> keep these users in mind ...

Again, it's not just about rollbacks.  Otherwise, I agree.

> As a Drupal user myself, I don't necessarily want to create a new  
> revision when I add missing commas to my posts.  It would just  
> create "revision noise".  Then again, if all of this happened  
> without me even knowing, I wouldn't make a point out of it.  Still,  
> the purist in me knows that such revisions will be 100% useless and  
> redundant even before they are created. Adding commas might become  
> a big deal. ;-)

True.  Perhaps a checkbox next to the log text area to indicate a  
minor edit is worth having.  Maybe if it's checked, we always delete  
the existing revision and replace it with the new one being  
inserted.  If it's already part of the advanced UI, maybe we want  
another checkbox like "Preserve existing log message" that auto- 
magically appears if you check the "Replace existing revision"  
checkbox or something.

>> * Better-tested node-saving code. I sometimes find modules that don't
>> work properly with revisions.
>
> I wonder why this is.  Are these modules using the proper APIs?   
> Maybe the solution is not to enforce revisions, but to improve our  
> APIs?  Or both?  I'm just playing the devil's advocate here.

In addition to the problem of the update vs. insert hooks, developers  
are taught that the fundamental thing in Drupal is the node and the  
nid.  Most Drupal tables have a nid column to JOIN on.  For revisions  
to work, you need a vid column, too.  For your module to work  
properly with revisions, you also have to consider core's  
{node_revisions} and vid, too, yet many developers apparently don't  
even know that body and title live there, not {node}.

-Derek (dww)

p.s. Yes, with proper caps, for all of you who always complain. ;)