The 24-hour mobile framework: Why you never hear “There’s a site for that!”

Let’s face it. Mobile apps haven’t just caught on … they’ve caught on frickin’ fire. Meanwhile, mobile web sites are … barely smoldering.

I say mobile web developers should emulate success. Don’t model your site after a big-screen web site. Don’t rely on the presence of native browser controls. Make your site design as self-contained as possible … In particular I think the jQuery Mobile folks were smart to standardize on a back button at the top left corner and a home button at the top right … ‘cuz that’s where they go on a big-screen web browser.

 

The 24-hour mobile framework: Whither jQuery mobile?

jQuery mobile promises to transform mobile web development much as jQuery changed the big-screen web world. In other words, it will become the new standard for progressive enhancement when it matures, and when developers learn to use it judiciously and appropriately.

For now I intend to make it available for high-grade devices.

The 24-hour mobile framework: Wireframe

Hour 3: Without further ado, here’s the eyeball-searing wireframe at a representative 320×480.

Note we have a primary top bar for branding, navigation, and essential controls. Below that is an optional secondary bar for UI, status messages, etc.

One might argue that the home icon belongs in the upper left-hand corner rather than the back button. Certainly this is a common practice for full-size web sites … but the upper left-hand corner is also the traditional place for browser navigational controls.

One might also argue that a back button is unnecessary, since all mobile device/browser combos have some sort of hard or soft back button. True, but we’ll need navigational controls when wrapping sites in native phone apps. (We’ll get to that in Hour 25.)

Some might also wonder why this wireframe left out radiused corners. The answer is simple … we ain’ t using radiused corners. Mobile device screens are small enough … why waste a few precious pixels on fancy corners?

The 24-hour mobile framework: Requirements

If this were a real-world project, the requirements phase would take up 23 of the 24 allotted hours. But I’m a naive, ignorant coder, so I’ll go about things bass ackwards: formulate the requirements in a single hour, leaving most of the time for implementation.

Let’s start by defining “software framework” … more specifically by defining “web application framework.” Wikipedia differentiates frameworks from libraries, APIs, and applications by the presence of features such as inversion of control, extensibility, and default behavior. Once again as with enterprise-grade software, we find ourselves bogged down in vagueness. Both classic APIs and libraries tend to be extensible, and conform to the “Hollywood principle” of “don’t call us, we’ll call you.” Woefully incomplete applications or application toolkits may be pimped as “frameworks,” saving the vendor the trouble of shipping a useful implementation of anything. Things get even fuzzier in the web business: a simple web page template with external CSS and JavaScript libraries could meet the definition of a framework as it possesses reusability, extensibility, default behavior, and inversion of control.

So yeah, a cynic could say with some justification that anything and everything qualifies as a web framework. But as a developer, I feel compelled to create something useful and non-trivial. So this project will strive to deliver:

1. A useful templating engine that supports multiple device/client families.
2. A device detection filter that interfaces with the templating engine.
3. A basic set of style sheets that supports common mobile design paradigms.
4. Basic site navigation components.
5. Integration with a commonly used web application platform.
6. Bonus: Integration with a caching engine.

And now the fun begins.

The 24-hour mobile framework

In order to dispel the myth that mobile web development is an arcane art restricted to an anoited few, I will create a device-agnostic mobile web framework with 24 hours of actual coding and integration work.

I’m long past the days of 24-hour coding marathons, so I’ll spread those 24 hours over the next month or so.

OpenCms + OSWorkflow = :)

Checked in on the OpenCms world after a long absence to find a new workflow module — this one using my personal favorite workflow engine, OSWorkflow.

I haven’t tried it yet, but I have no reason to think that I’ll be displeased.

Currently experimenting with …

• Liferay (now adopted by Sun as Java Web Something or Another)
• OpenXava
• jMaki + Spring

People are listening

Updated my test install of OpenCms to 7.5 the other day. As usual the update went smoothly with no problems to speak of. And I was pleased to see that the demo site had been changed to “The Wonderful World of Flowers.”

Here’s the background: My employer evaluated OpenCms last year but decided against it. A number of reasons were put forth (e.g. workflow, user interface) but I still think the major reason was the negative impression left by the OpenCms demo site … which at the time was a review of German regional sausages.

As I noted (sadly) in an e-mail sent to Alkacon shortly after that disastrous demo, regional cuisine is very important to ethnic/cultural identity. However, Americans tend to associate sausages with … solid waste, among other things. In particular Californians — who see tap water as deadly poison — have a hard time identifying with a product that subconsciously glorifies the consumption of bodily toxins.

I have no way of knowing whether my feedback inspired this change. I do hope it helps Alkacon succeed in the North American market. Not that I have anything against bratwurst, weisswurst, knockwurst, or … OK, maybe I’ll draw the line at blutwurst

Cascade Server: Competent and predictable

I’ve spent the past year or so up to my armpits in Hannon Hill’s Cascade Server. My overall impression is that it’s a competent and (mostly) predictable product. But as content management systems go that’s pretty high praise.

I’ve used the SOAP interface to migrate about 8,000 pieces of content (articles, images, etc.) from Vignette V6 and V7 into Cascade Server. There are a few real “gotchas” that made life difficult. For example, link tracking isn’t activated automatically when creating or editing content through the web services interface, at least in Cascade 5.x. Documentation in 5.x is a bit skimpy. There’s no way to output “structured data” as plain text — HTML yes, XML yes, PDF yes, RTF yes … but not plain text.

But for the most part, Cascade Server works as advertised. It doesn’t claim to solve all your problems, but it is quite good at managing and publishing static Web pages. I look forward to the 6.x upgrade, which introduces a “site” metaphor that will help to bring cross-site links under control.

There is one feature of Cascade Server that deserves special mention — the versioning system. As configured by default, each edit to a page creates a new version. It’s trivial to view / audit / compare / roll back / revert between versions. Most importantly, initiating a workflow will create a new version and bind that version to the workflow instance. Editors, approvers, and publishers will work on that version and that version alone. I think it’s even possible to have multiple versions of an article in multiple workflow instances — for example, one version in publishing workflow and another version being bounced around in editing workflow for a later update. To some people this might sound like a bug — but large organizations have silly needs.

Obviously this versioning capability comes at a cost. Cascade Server is very database-intensive, and can be very CPU-intensive depending on the complexity of your XSL stylesheets. (Yes, Xalan has never been accused of excessive speed, nor efficiency.) Its scalability depends in large part on the scalability of your MySQL installation. Hannon Hill recommends circular replication, something which sounds great in theory but scares the living crap out of me in practice. I’d recommend keeping either a very good DBA or a gold-plated support contract to back up large installations.

Workflow: “A bunch of spoiled brats”

I’m not a drooling rabid fan of JBoss’ jBPM workflow engine, but I do agree with many of the sentiments expressed by jBPM lead developer Tom Baeyens in “The State of Workflow,” on jboss.com.

If database systems are like a respected, wise man telling a clear story, then workflow must be a bunch of spoiled brats shouting their own truth at each other. …

[W]orkflow management systems are at the very initial phase of the technology hype curve. … One of the observations that form the basis of this statement is the overwhelming number of concepts used. None of the numerous specs and tools in this area is similar.

Baeyens explains in detail why the concept of “activities” should be discarded in favor of “states” and “actions.” Baeyens then:

Many vendors of workflow management systems will let you believe that with their graphical process designer it only takes a business analyst to create process definitions. This vision originates from the fact that programming is hard. …

I’d disagree with the assertion that “programming is hard.” Certainly it’s not easy, but it’s not as hard as developing and codifying the actual business procedures … finding that delicate balance between oversimplification and analyzing everything to death.

While not having to write code is a good thing, most vendors go overboard on this and don’t foresee a mechanism to integrate code into a process definition … Developing process definitions requires input from -and collaboration between- a business analyst and software developer. A good graphical process designer should support this collaboration.

Here I’d have to agree 2000 percent. A GUI workflow builder seems simple and “intuitive” at first glance. Just keep in mind that the actual workflow engine has no such sense of human intuition. It helps to be able to explain the fine details of complex processes in a language that the workflow engine speaks.