Tuesday, August 25, 2009

Drupal redux

Going back to the previous post, I'm thinking out loud that it is difficult to see where site feature configuration stops, and content creation begins, under Drupal.

Clearly, there is a sense of partitioning of the high level administration interfaces. The incoherence of the user interface is seen in the lack of specialization in the Administer->Content Management interfaces. On the one hand, from the Drupal team's point of view, the generalized user interface performs its function and is probably very scalable. If I were them, I might have written the admin interfaces to minimize or totally avoid the need for add-on developers to provide user interface code beyond declaring the essential parameters. On the other, from the user's point of view, it is undifferentiated and mechanically produced, a shelf-rack-unit interface where every slot looks the same. The only visual differences on the interfaces are in the presence of some additional tabs or parameters.

I'm just starting to get to know Drupal, so perhaps this is a misconception on my part. I don't see generalized user interfaces as a bad thing, per se, but in the quest for uniformity it appears that explicit support for guiding the user's work flow in their role as a content creator was overlooked or punted.

Joomla, btw, seemed to make a mistake going the other way. By focusing the architecture upon several user content creation work flow requirements, the underlying database has evolved as a set of discrete tables, where each represents a specialized type of data ("user", "section", "category"). The admin interface of each add-on is essentially a one-of program, with each add-on carrying with it a substantial amount of procedural code.
Post a Comment