[development] Requiring node revisions
dries.buytaert at gmail.com
Thu Jun 7 14:42:53 UTC 2007
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/
More information about the development