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/