[development] Requiring node revisions

[Dries Buytaert]

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. ;-)

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.

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 ...

> * Lots of users are accustomed to editing Wikipedia, so seeing a
> revisions tab shouldn't be scary to new users of Drupal.

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.

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.   
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).

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. The current system  
allows for that, but it looks like the proposed changes might not.   
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.

Clearly, node revisions is also the feature that lets people shout:  
"Drupal can do more than a simple $site", again for different flavors  
of $site.  I'm *not* proposing to remove Drupal's versioning.  Quite  
the contrary.  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 ...

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. ;-)

> * 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.

--
Dries Buytaert  ::  http://www.buytaert.net/