cms

Recently a blogpost discussed Jen Lampton's superb conference session: "Wordpress is better than Drupal: developers take note." The author said that they really liked the session, but

• Wordpress isn't actually better than Drupal
• Because you can't compare Wordpress and Drupal
• So the usability issues arise from a false comparison
• And here's what's going to solve our problems instead

In the first paragraph or two it managed to simultaneously both praise Jen's talk and completely deny the core message of it. I think that highlights a number of trends in the way that the Drupal community as an aggregate (though by no means as a whole) tends to think about usability versus technology. Actually, I think the communities behind most large open-source projects behave this way, and it's ones like Wordpress or Ubuntu that are actually unusual. But I think it's worth talking about this phenomenon in the context of Drupal.

Apples and oranges

Anyone who argues a point of view can be sure they've ruffled some feathers, when someone else complains that they're "comparing apples and oranges." It's a definite sign that the complainer doesn't like the problem that's been raised, and instead wants to treat an informal analogy as if it were a keystone in a tense, logical structure; then attack the analogy instead. It's like hurling around cries of "ad hominem". It doesn't really prove or solve anything. Apart from anything else, what if my point is to compare apples with oranges?

Whatever you compare Drupal to, whatever your motives, whatever important (often fundamental) issues you want to highlight about the way Drupal does things... eventually you'll have to compare Drupal to something that isn't Drupal. You will have to compare the apple to some other fruit. That's the only comparison worth making. Are we just going to forever compare Drupal 5 to Drupal 4.7, Drupal 6 to Drupal 5, and gradually Drupal 7 to Drupal 6, purely as a teleological exercise in patting ourselves on the back? Of course not! And however close the something else might be to being Drupal, there'll be some slight difference, which will inevitably provide an opportunity for hairsplitting. Maybe we could call it fruitsplitting instead, because that difference in variety of fruit can be used as an excuse, if not a reason, to dismiss your broader motivations in making the comparison.

"X isn't a CMS." "Y isn't in PHP." "Z isn't aspect-oriented programming." "P is aspect-oriented programming, but it's intended to be purer than Drupal, with pointcuts." "Q doesn't have a genial tousle-headed giant as its benevolent dictator."

Apples aren't oranges, but then some apples aren't the same as other apples, either. Apples come in all sorts of varieties. So you can even compare apples with apples, if you like, and someone will come along and protest. Except they won't so often these days. Want to know why? Well, here's a story about apples, from the ever-readable George Monbiot.

Briefly: there used to be a huge market in different apple varieties. Hundreds and hundreds of varieties: Belle de Boskoop, Michaelmas Red, Brown Cockle. And then the supermarkets came along, and they decided that they could essentially compel their customers to standardize on a handful of apple types: Royal Gala, Jazz, Cox's. They did it, because the customer didn't really mind what type of fruit he was eating.

And that was essentially the end of the line for most types of apples. "Extinct, extinct, extinct." Most of them just gone. The free market effectively wiped out those varieties, ruthlessly and ignorantly. It reduced the number of breeds to a tiny fraction of what it was. People compared apples with other, different apples, and they just picked... apples. Nobody will fruitsplit between apple varieties now, because they're just all apples.

Drupal already has plenty of greengrocers, fruiterers of the programming world, people who rightfully and meticulously care about, and tend with love to, our apples and our oranges. But the prize, the broad user base, the real success story... that all lies in attracting non-greengrocers. And they'll just think: "Apples. Oranges. Other apples. Whatever." They probably won't care about different types of fruit; they've been told that their website has to have its vitamin C for the day, so they'll get the apple that's easier to get into, and to hell with your awkward-to-peel oranges. If your business model depends on selling individually wrapped fruit to other greengrocers, then good luck with that. I'm off to take some coals to Newcastle.

Who's going to tell the customers?

The blogpost suggests that:

Instead of comparing a toolset and a product, there are other, appropriate comparisons that businesses and developers should be making...

Well, it's wonderful that I know that now. But who's going to tell everyone else to change their ways? Is there going to be some sort of government-funded outreach programme? Will we all be making some sort of world tour? I try to picture a random drupal.org user appearing, like a superhero in a flash, in offices around the globe. "Hark! I hear someone in Mumbai making comparisons between Wordpress and Drupal that appear reasonably valid to them based on their expectations derived from: Drupal websites, Wordpress websites, drupal.org and wordpress.org. Yet I must intervene, swiftly! To the nearest train station!"

Anyone who decides that the solution is to tell businesses and developers what comparisons are appropriate will end up like Wowbagger the Infinitely Prolonged, travelling in time so that they can tackle simultaneous disparagements of Drupal. We can't rely on that: Drupal ultimately has to be able to say this for itself: it should be obvious to these businesses and developers what Drupal should be compared to. Otherwise these businesses and developers will continue to make comparisons based on the (admittedly incomplete and sometimes wrong) information they have available to them. 

Saying what comparisons end users ought to be making is a lot like that other canard, "educating the user." Unless you're talking about a site's administrative user base, people at a client who you could count on one hand, that's a pretty mammoth task. Who gets to ensure that such universal education about the vagaries of, say, module weights, or the vagaries of CCK field display, eradicates doubt in the same way that we once got rid of smallpox? Similarly, if Drupal's success against Wordpress depends on people only ever making the comparisons we want them to make, we're in trouble.

There's also tendency to call Drupal a CMS, right up to the point where someone complains it can't do what a CMS does out of the box. Then it's called something else. A toolset. A content management framework. A management framework toolkit. A content toolkit framework management system tool. It might deflect debate, but ultimately the jargon just puts people off. You might have won the battle with potential new users, but the war goes to whichever CMS with limitations that accepts from the outset that it's a CMS with limitations, and tackles those limitations---in Drupal's case, most notabbly user experience and getting started with it if you've never heard of Drupal before---head on.

The documentation on Drupal.org is pretty impenetrable to the average newbie, but if you can figure it out then you get the impression that Drupal is basically a CMS, a bit like Wordpress only with other (waves hands) stuff. So it must have a WYSIWYG editor, only somehow more so, right...? And the user experience of Drupal 7 is a great improvement, much like improvements that have already happened in Wordpress; but, despite the fantastic news that we're moving to beta releases, only greengrocers are using that right now. If we want non-Drupal users to make the right comparisons about Drupal, today, will we really fix it by arguing about distributions; products; toolsets; downloads; projects; modules; features...?

The technology will save us, of course

Here's a handy tip. Technology alone will probably never save you. You only have to have sat through Jen's talk, and to have read about Hagen's similar Wordpress-Drupal-Joomla walkthroughs in the unconference on DrupalCon Monday (I blogged about Hagen's marvellously excruciating walkthroughs on the g.d.o usability group) to know that the technology won't save us. Or rather, specific bits won't save us. Aegir won't save us. Products won't save us. Distributions won't save us. The drupal.org redesign probably won't save us either, because that's nearly finished and yet we're still denying the very usability and expectation problems that are still in plain sight.

Don't get me wrong. All of these things are great tech--really fantastic, mindblowing tech---and they solve specific problems that developers come across. I think drush make is one of the most exciting bits of Drupal I've ever used. But I'm a developer! Of course I will think that! Not only do I know how to set a Drupal site up in 15 minutes, but I also know from experience how to avoid the many, many ways in which it will take you two days. These tools  don't fix the fact that Wordpress is easy to use. Wordpress just works. Drupal needs tools to help you install it, and command-line fu before you can even make those damn upgrade errors go away, go away, please just go away.

You can't wait for technology to solve these things. Distributions won't change the fact that you can click around the drupal.org website for ten minutes and still not be completely sure what it is, or how to use it. The learning curve is still too large; and I'm just talking about how you use drupal.org, not how you use Drupal. Until everyone in the world is re-educated to know, and care, about what a distribution is, and how it's subtly different from just getting the blasted thing to work, then distributions won't save us.

What will save us is usability. User experience reviews. Jen Lampton's talk. Hagen Graf's talk. Watching users try to get to grips with this thing we love, when they just don't love it so much, won't excuse it as much. Feeling the cringe when a new user falls into the same trap over and over again, and knowing you won't be able to appear on their shoulder to help them. Then, though: this is key. You can't just say, "well, we'll let the themers fix that," or "maybe the forums can discuss it," or even: "when users ask for the wrong thing it is rarely, if ever, the right answer to humor them." Instead, you have to accept the application has a usability problem; and work out a plan fix it, right there and then. Developers, deciding to fixing usability problems above functionality problems. Again and again and again. Test, observe, cringe, fix, repeat.

It's a slog. But it could work where technology won't, because ultimately end-user functionality with serious usability problems will end up massively underused, and as far as the greater course of Drupal is concerned it might as well not be written.

Does this matter?

I feel like I've gone on a bit, and if you feel like that too then I apologise. After all, the usability community in Drupal is healthy and growing. People are starting to take usability seriously. But I feel like there's still no UX standards to point to, with the same weight and depth as the coding standards. Talk is silver; code is gold; UX is presumably 24-carat meh. There are still no easy ways of sharing usable interface patterns as easily as one might share patches. Usability is still a teenager, and it's easy to freeze it out of the conversation it in favour of adults talking about established technical preferences. Usability needs cultivating, and the user's behaviour needs to be king, whatever comparisons that user might make. We're right to worry about Wordpress, but that's a good sign! It means that Drupal is doing something right. It's worrying about the user.

Maybe, returning to the original blogpost, "the time is right for Drupal products." I'm happy to agree with that. Featurization and ease of deployment certainly suggest that productization will swiftly follow. But that has nothing whatsoever to do with the usability talks. It really won't solve the fundamental problems that Jen's talk tried to address.

One thing she said really stuck with me; as a developer, I took note. Well, I took lots of notes, but here's what stood out for me:

"Wordpress is behind us, but they can move fast, and they're looking at us."

With version 3.0, Wordpress quietly turned itself into a CMS. Maybe they saw fields were working well for Drupal, and thought: we'll have that. "It's simple but it'll do: let's ship!" Bang. Instant easy CMS. Usable too.

That's the point, in the end. Usability is not a nice-to-have. It's the canary in the cage, the indicator species: when usability suffers, it's telling you about lots of other attitudes that lead to the user being made unhappy. Whereas Wordpress emphasizes usability; it's friendly to the user out of the box; with things rich-text editing that the user wants to have without any issues; with straightforward media management; and with upgrade methods so simple they're frightening.

Drupal? Drupal's a brilliant, smart, well-oiled, massively functional framework (it's far more fun to develop with than Wordpress.) It's a CMS, except when it's not (but when it's not, it's still a rich seam for developers to mine.) It's still tricky for newbies to install (but developers learn the tricks.) Image handling is odd, and if you pick the wrong method early on you're in for a lot of pain later (but developers know which one to pick.) Upgrading modules is not a one-click experience (unless you're a developer and you've played with drush.)

Yet with all that in mind, here's a question. If you'd never heard of Drupal or Wordpress before, and you were 90% of the internet, rather than a developer; if you were the same sort of user as a client's marketing guy, who's never written a line of PHP in his life; based on the experience of trying to get each of them up and running yourself, which would you choose? Apple or orange?

It's already been over two months since the last Oxford Geek Night. Because everyone was away for holidays and then for the conference season, and if you also add a dash of minor illness into the mixture, we've been holding off organising the next OGN until we were ready to get back into the swing of it.

Now, the wait is over. Oxford Geek Nights #19 will be on Wednesday, 1 December 2010. Put it in your diaries now! (We're also planning OGN20 for some time in late January or early February 2011: exact date to be confirmed soon.)

Because we've had chance to catch our breath, two major things have happened. The first is that we've already got two brilliant keynote talks confirmed for OGN19. Leila Johnston, self-styled punk broadcaster, co-presenter of the Shift Run Stop podcast and published author, will be talking about Making things fast. We also have David Caruana and Florian Müller from Alfresco to talk about the OASIS standard on making content management systems interoperable. That means an international standard on how CMS-authored sites can talk to each other.

The second major change to Oxford Geek Nights is that Wes West and Jonny Grum are joining me as co-planners and helping to share the burden. That should mean that OGN tech will be more reliable and OGN planning more robust, and each night itself should hang together that little bit more, because we can all pitch in where necessary. Thanks to Wes and Jonny for joining the existing team of Nick Burch (wifi), Neal Todd (video) and me.

Incidentally, as always: we need microslot volunteers! Do you think you could speak to a roomful of geeks for five minutes on some topic close to your heart? If so, submit your microslot proposal at http://bit.ly/ogn-microslot . See? We've even got a new dedicated microslot URL. We're so technically advanced these days that we're practically robots from the future.

Incidentally, we'd like to thank everyone who submitted feedback recently: we got an unprecedented response, with dozens and dozens of intelligent responses. Just what you'd expect from Oxford's smart, engaged geek crowd. But because of time pressures we've not yet been able to plough through all of that data; so we've decided to prioritize planning OGN19, but hope to incorporate some of your thoughts into the OGNs soon.

OGN19, then. December 1. Leave your chocolate advent calendars at home and come along to the Jericho Tavern.

My Drupal module for editing nodes inline EditInline is at version ɑ-0.4. Just to summarize, the module lets you edit either the current node (or any other node where the title comes from Views or node template rendering) in a lightbox overlay. That means you don't always have to navigate to (or even know how to navigate to) a piece of content in order to edit it, making editing more accessible and intuitive.

Now you can also edit nodes in nodereference fields, while you're on the page to edit the current node! That means you can be on the edit page for e.g. a publication, but edit the author biography node attached to it by a CCK nodereference field. There's little edit buttons to the side of nodereference autocompletes which . Also, once you've edited the node in the lightbox overlay and it's closed, any title edits are also changed in situ to help you envisage how the page will look without having to refresh.

I did some of the work---mostly that leading from ɑ-0.2 to ɑ-0.3---during handy gaps between talks at Drupal Camp UK, held at BBC Manchester a couple of weeks ago. I wish I'd caught the wave of blogging about it at the time, as it was tremendous fun. The talks were all of a very high standard, but what felt more important to me was meeting people in the UK's Drupal community, and realising at first hand that the fun-loving, Drupal-interested, hard-drinking weirdos (that I'd always hoped were hiding here and there on the IRC channels and forums) really do exist.

EditInline was first discussed here. It's a Drupal module that provides your site with handy editing links, inline with each node title, which rather than taking you to a separate editing page use a lightbox overlay on the current page to provide an inline editing interface.

It's currently in alpha but available under GPL on the Torchbox public subversion repository. I've recently prepared another alpha subversion release, so if you want to have a look at EditInline ɑ-0.2 then feel free to download and let me know what you think.

(The main improvement from ɑ-0.1 is a dedicated form workflow for editing inline, which results in submission of the form leading to the lightbox overlay being automatically closed. Future releases should include CSS hooks into the lightbox content and other usability improvements.)

David Yelvington mentioned back in December 2008 that his Drupal site had over 30 content types:

Why on earth so many content types? It's easy to see good reasons for news items to be structurally more complex than a simple blog post. But we also have some types of content you probably wouldn't think about at first. Wire stories are an interesting case.... Promos are another.... Other content includes special types for various video players, feeds from other technology and content partners, items aggregated from websites in the community, podcasts, cartoons, Soundslides shows, and Tweets.... Drupal also creates content types for internal purposes, such as representing user groups, webforms, etc.

To be honest, thirty seems about right for a medium-sized site, so my first reaction wasn't one of surprise at all. David's explained briefly what a content type is in his own post, so I'll not repeat that here. Safe to say that what makes a job advert on a site distinguishable---and capable of holding different information---from a publication or organizational event is that each is derived from a different content type. Some CMSes call these "templates", as does Torchbox's proprietary alternative.

Really, really big sites (especially multi-domain sites, sites with organic groups, sites with microsites, sites with just a lot of transitory projects going on) need a lot of types of content. Even a medium-sized site can easily have two dozen content types, just to satisfy things like news, PR, departmentalization, events, products, staff, directories.... The most recent Drupal builds I've been involved in have all had over twenty content types, and Torchbox's biggest non-Drupal site has literally hundreds of "templates", serving many tens of subdomains and several years of legacy content for many different projects.

What Drupal's content-type maintenance (especially in Drupal 5) highlights is that implicit in Drupal's interface design has been a small number of content types: or at any rate sufficiently few to be listed without much scrolling of your browser window. I'd hate to see an unfortunate user maintaining a Drupal site containing two hundred content types. Yet again (yawn), we're working on a module---currently only for Drupal 5---to categorize content types. It currently only improves the tabular content-type admin page by grouping similar content types into separate tables, but the hooks should then be available in order to have more segmented views of content types.

You can never predict where usability (as opposed to programmatic) scalability will bite you. At least Drupal's modular nature---rich in overrides and workflow interrupts---more often than not allows you to solve some of these problems in hindsight.

It's heartwarming, really encouraging to see that Drupal 7 is undergoing a usability review. Drupal's a massively functional CMS, but all the functionality in the world won't help you when the average (for which read: can't write HTML, let alone PHP) CMS user can't discover it. There's a common misconception that usability is the finishing touches you add to an application if you've got time, the icing on the cake; but if your application lays any claim to maturity then its usability is the cake, and all that functionality you were so proud of is, without usability, just eggs and flour.

One of the main usability improvements suggested by the usability team---and largely shouted down by the technical team---is the ability to edit inline on the page: that is, to log in as an admin, then have any bit of the page "active", so that if you click on it then it becomes an edit box with the text inside. Flickr does this especially well, letting you edit title and description on photo pages and lists of photos by just clicking on the apparently uneditable text. But Flickr has the advantage that there's very little form on top of its content: it's a delivery mechanism for the raw metadata about photos, and the photo itself.

The other end of the spectrum---which complex CMS sites have every right to sit on---is a rich and complicated mapping between the storage of a node's content in the database and the eventual display of it in the browser. take a page from a recent Torchbox project at random, how would you expect areas of this page from the Joseph Rowntree Foundation's website to behave when you clicked on them? If you have to hardcode print statements in your PHP templates, what do you print? How do you get editing inline to work? What happens when content is brought in from other, related nodes, and mixed in with the other content before display.

I can appreciate both sides to this story of user experience versus technical practicality, although it's not sufficient to expect the usability team to discard the idea merely because there's no correspondence between page content and database content: that's only an argument for why Drupal doesn't currently have edit-on-page. The usability project is moving forwards rapidly, and while there's clearly a tension between usability for the CMS user and feasible technical limitations---usability for the developer, if you like---it will need to be resolved soon for this marvellous work, and a great opportunity, not to end up wasted. And resolving that conflict will involve some sort of compromise, for both sides.

One possible compromise would be to offer edit links, when Drupal can spot a sort-of 1-to-1 correspondence between a fragment of page content and the node that supports it. Page templates and views---specifically hook_preprocess_node and hook_views_pre_render---know full well that what they're processing is a node. And they generally know what field the node title will be in. So let Drupal rewrite the title, to add an "edit inline" link. If anyone clicks on this link, then pop the node-edit form up in a lightbox for editing.

Here's some screenshots of what I've been working on, in an attempt to get people interested (click for bigger.) Firstly, here's what the anonymous site visitor sees:

Next, here's what happens when a user has just logged in. Note that the brilliant Admin menu module kicks in, giving the user a black navigation bar across the top. But, more pertinently, each node title also now has an "[edit inline]" link beside it:

If the logged-in user clicks on one of these new links, then our edit-inline module kicks in and, using the equally brilliant Drupal Thickbox wrapper module, provides a stripped-down version of the node-edit page in a Thickbox overlay, both speeding up node editing using AJAX calls and also letting the user cancel the node-edit procedure and return to the webpage they were on quickly:

To reiterate, you don't have to be on a node's page to edit it. All that matters is that the title of the node you want to edit passes through onee of the supported pre-render hooks. Currently, clicking on save/preview/cancel takes you elsewhere rather than being trapped within the Thickbox, and we're also wrestling with getting CSS and Javascript into the Thickbox overlay to support the nattier bits of node editing, but it's functional and, I hope, gives you some idea of how it would all work given a few more hours of bashing away at keyboards.

Anyway, there it is. A possible compromise. I've mentioned it in a comment on the d7ux blog but I fear I might have been eaten by a spamtrap. If anyone's interested in the project then email me, jp.stacey, either at gmail.com or torchbox.com, and say hello.

A New Year's present from Dries Buytaert:

It didn't take long for us to realize that people wanted more than Acquia Drupal: they wanted support for everything Drupal 6.x -- all modules, themes and custom code. The good news is that Acquia is a nimble company so the last weeks we worked on changing our support model to address customer demands. Starting tomorrow, we will support everything Drupal 6.x -- not just Acquia Drupal but all modules and themes available on drupal.org as well as custom code. I'm still a firm believer in Drupal distributions so Acquia Drupal still has a role as a packaged on-ramp for people getting started with Drupal. However, anyone will be able to connect any Drupal 6.x site to the Acquia Network.

If you want someone to build you a website, don't let them build you a bespoke CMS to help you manage it. I've fallen prey to this very temptation, although in my defence it was as much an investigation into technology and the structure of my own content as a solution to the problem of managing said content. But after having spent two years struggling in vain---completely and utterly, to the point of not merely writing zero new code but also writing much less content---I've moved to Drupal. Since doing so I've been playing with blocked-out chunks of reusable code and content, and little related-content lists, and automatically generated RSS feeds, and a free-text search that just works. Beat that, my own programming skills!

This sort of slip-up, though---asking someone to build you a thing, be it website, web application, or offline electronic service, and letting them instead build you the tools to build it with---is tremendously common, and I can see why. You want to think that your particular site is the unique snowflake, that your way of working only fits a certain publishing workflow, or moderation structure. Of course you do: to suggest that your notions could be implemented using off-the-shelf tools is to suggest that they too are off the shelf.

But however innovative the idea, eighty percent of its implementation is, if not the same, then of the same form. How many newly-invented white goods couldn't be fitted with a standard wrench, and how many plumbers got customers to pay for them to invent a new, never-before-seen custom tool to fit them? It's not a flattering comparison, but so it is with new ideas for using the web. Every publishing system needs ways of filtering, searching, and unpublishing content; every website with dynamic content needs to address cross-site scripting, error catching and logging, and formatting raw content; and every successful site needs to consider cacheing, spooling, and load balancing or throttling.

And while web development companies can and do solve all of these problems (you didn't necessarily ask, but Torchbox does it quite nicely, thank you very much), they have to justify to you as a client why they're better placed to solve them than people whose core business is to solve them. The same goes for application frameworks: if the company's meant to be building you an application, but they're not recommending a framework like Ruby on Rails or Django, then you should ask why. And they should be able to tell you.

Maybe the system you're end up with won't quite let you moderate content the way you're used to, or the way you're expecting to. There may well be good reasons for that---and the framework or CMS has just stopped you making a very silly mistake---but if it was just a case of it being a reasonable tradeoff of functionality and developer time in the original framework, then that's the point where your web company of choice can start to extend and build on the framework. By that time, that eighty percent is already there, and secure, and the bespoke twenty percent that every site needs can sit on a solid, reliable base.

I can't tell you how happy I've been since moving from my homegrown system---much as I loved its slickness and elegance---to Drupal---much as you can always argue about the quality of other people's code, essentially just whining that it's not quite how you would have done it. Content, after all, is born free; yet it is everywhere in custom-built chains.

Drupal 6.0 released. The smoothness of D6’s interaction with both user and developer is really breathtaking these days: as close to one-click installation as you’re likely to get on shared hosting; modules to help you port your own modules over from D5; and even automatically downloaded updates to (unhacked!) core. I had a look at the release candidates but owing to other responsibilities I haven’t had a chance to sit down and play with the actual release.

(With any luck D6 still contains my three characters of contribution fixing OpenID autodiscovery.)

Coming to the end of the Drupal project on which I’m currently working, I spotted someone else’s brand new site on drupal.org: TeamSugar.

The hallmark of a good frameworked site is that it’s not easy to guess which framework was used, and TeamSugar manages that admirably. While I can’t really comment on the design—I find most networking sites pretty busy, and this is no exception—it certainly feels like a lot of hard work is distancing the user experience from the limitations of the framework, and that’s admirable from a usability perspective. The fewer visitors jumping through hoops to indulge the whims of your CMS the better.

There are a couple of interesting observations in that thread, mostly because they’re guarded criticism coming from an otherwise happy user of the framework:

… We have four app servers now, I believe, and a dedicated database server. We have also extensively edited the code. The architecture of drupal, unfortunately, lends itself to doing things like issuing one query per module per node on a page. For our 8 content sites this isn’t too bad because they’re easily cached and don’t make use of many modules. For TeamSugar it’s much worse because each feature generally requires at least one module. We cache where we can and refactor code elsewhere…. [link to 1971521]

… When you’re creating web applications you’re typically going for one of three things: speed/scalability, flexibility, or maintainability. Drupal is high on flexibility, average on maintainability, and poor on speed, in my opinion. If your priority is maintainability then I’d go for one of the RAD environments like Rails or CakePHP. If speed is your priority then I’d write your own lightweight framework, or whatever, and do it yourself…. [link to 198497]