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.

Monday, August 17, 2009

Drupal: Too Primitive For Practical Use

It sometimes irks the developers among us that dumber and half-baked solutions gain so much momentum, in comparison to what they would consider the more elegant systems with well-engineered software architectures. Such is the case, for instance, when considering WordPress (the dumb one) or Joomla (the half-baked one) in comparison with Drupal (the engineered).

I'm admittedly not a hard-core Drupal developer, but I've done my share of PHP and loads of software development with database applications. I decided to spend the day setting up a Web site on Drupal. It was very illustrative of why Drupal is liked by institutional users, and so often tossed to the side by everyone else.

In comparison with Joomla, the core architecture of Drupal is indeed very elegant. It is sort of the Common Lisp of content management systems. And that is its biggest shortcoming. The problem with Common Lisp, contrary to appearances, is (not(the(nesting(of(parentheticals))))), but the expanse of details that a person must keep in active, working memory in order to construct a picture of what in the world is going on.

The processing of XML became not only commonplace but easy under node-oriented API's, and particularly with XPath, so the node architecture is not to blame for the overload. Rather, the Drupal community fails to recognize the benefit of encapsulation and task-oriented procedures.

Users have identifiable goals that have nothing to do with extracting modules or making node lists. Why is there no package management system? Drupal developers can obviously write coherent instructional procedures (see creating a gallery and creating another gallery), but the user interfaces hold them down. It is an extreme disadvantage to write user instructions when the necessary steps are at such a low level compared with those typically required for Drupal's half-baked cousin Joomla. In Joomla, when it works, installation and configuration is often as simple as a one-click upload and editing some settings.

Now, I decided to post this when I wanted to set up an image gallery -- actually a portfolio. I know how it should work, and I can even see how Drupal's nodes could be set up to configure the items, then queried to build the list, etc. But check out the links above if you haven't already. My only response from this morass is to laugh out loud. Are you serious people?

It makes sense to have features installed as separate modules. As a developer I think it is quite elegant actually. Yet as a user trying to get a deliverable out, it is just so much unnecessary clutter. What I want to see is packaged units I can install and use immediately. Ideally I would like to see the undercarriage of Drupal, but with packages to address specific user needs, much as Joomla components give coherent package management and configuration.

Friday, August 7, 2009

Google Wave: No Organizing Principle!

So, ironically one of the problems with Google Wave is that there is no sense of overarching structure when you open the Google Wave client.

Put another way, the question you are faced with when entering the client is,

WHERE DO I LOOK NEXT?

Waves have a rich capacity for internal structuring, and it works well for constructing narratives. But the current Google Wave client lacks just such a narrative itself.

Ideally, we should be able to specify that overarching UI narrative as a Wave. Or more precisely, a information structure derivable from a Wave.

This came to me because I was trying out the Wave Embedding tutorial. In Firefox 3.5 the sample complains:

An invalid or illegal string was specified" code: "12
https://wave.google.com/gadgets/js/core:rpc
Line 526

Well, when I go to the Google Wave client, how would I find the answer to my dilemma?
If "Search" is the first answer, that may be well and good, but it shouldn't be the answer to every such use. Otherwise, the Wavishness of the client is irrelevant -- I could just Google it.

HTML Tag Soup: Breaking The Web, One Tag At A Time

The ability to parse raw-in-the-wild HTML is of very great value, like composting food garbage or processing sewage to produce a usable product. But you wouldn't want to compost your evening meal or send fresh drinking water through a sewage plant, and you shouldn't expect an HTML parser to look at well-formed XML markup and give you the structured document you expect.

Why?

Tag-soup parsing is based on a set of one-of exceptions, specifically designed to produces predictable results when it is given HTML crap. Well-formed XHTML is not html soup but looks enough like it that you can pass it to the HtML5 parser and get something out. The problem is, what you get out is not what you said you wanted. So tag-soup browsing of Well-Formed markup is "WYWINWYG" - What You Want Is Not What You Get.

For Instance

If you write:

<div id="foo" style="border: thin solid red;" />
<div id="bar" style="border: thin solid green;">
<p>Paragraph inside green border, but NOT inside red border?</p>
</div>

You do not get two DIV siblings, you get that the first DIV is the parent of the second DIV. That's all by the soupy rules, now quantified by HTML5:



Paragraph inside green border, but NOT inside red border?




One might argue that the first div shouldn't be empty. That's not the point. The point is, that it is compatible with XHTML syntax, and means one thing by XML parsing but quite another by HTML parsing.

This, by the way, was true in HTML parsers before HTML5 -- I'm not picking on the Draft. We all know that sewage treatment plants provide a fundamental value. I just don't want people shoveling crap out the door and telling me that, according to some W3C Recommendation, it is food.