OK, so maybe I was a little hasty with my earlier post. We are emphatically not all developers now. The hyperbole ran away with me, and I apologise for that. But there was a nugget of truth in there.

If the Rails-revolution (and that includes all those things which perform similar functions to Rails, even if they themselves are not rails) has a real-world analogue, it’s that of the far eastern bespoke tailors. You see their ads in the papers; they fly over to London for fittings in hotels, and then make a bespoke suit for you in their workshops back in Hong Kong. You end up paying the price of a decent off-the-peg suit (about £200) for something tailored to you. Of course, it’s not quite Saville Row, but it’s still a darn sight better than a generic off-the-peg model.

And this is what the rapid-development-frameworks give to small businesses.

A small business wanting to serve the global market might consider, say, an online shop as part of its web presence. A small, local web-development firm are contracted to build one. A long while ago, said web shop built a fairly substantial (and customizable) online store. They now use this work as a basis for future stores – pull another copy off the shelf, add a few tweaks, and serve to client. To create something uniquely tailored to the client’s needs would take a lot of time – and the client, being a small business, can’t afford the time a bespoke product takes.

So they receive delivery of a store that works, but has quirks that they could do without, features they don’t need, and might even lack features that could save them time; instead, they implement workflow-based workarounds to those missing features.

What the new frameworks do is put bespoke products (especially small bespoke products) within reach of small businesses. A small web-development firm isn’t going to be overworked, or take too long, to start from scratch and create a product that is 100% suitable for the client. The client will be more productive as a result. It’ll probably be a better product, too, as the product will always be built to current standards (instead of being last year’s model, dolled up).

Of course, in this new bespoke-economy, there will still be successful web-development firms who continue to serve up the old, 90%-suitable, off-the-shelf product. They might get away with this for a while, but not forever, because the bespoke economy serves everyone better – developers get the chance to constantly be creating new things; clients get the product they’ve always wanted.

So we’re not all developers, we’re just all in a position to get bespoke development at off-the-peg prices (or less). I mentioned ‘software scaling down to a userbase of one’. It’s not that this is possible – it always has been – that makes these new development frameworks exciting, but that it’s suddenly become very, very viable.

Self-promotion again: over at Pixelsurgeon, a review of the latest Castlevania game, Dawn of Sorrow. This time round, the series moves onto the Nintendo DS. It comes with a huge recommendation for me – the review will explain more, but basically, it’s invariably fun to play, has lots of longevity (and some killer bonuses I didn’t have space to write about), and harks back to a slightly bygone era. Fun to write, too. I’m really looking forward to having the chance to write more about games. Up until now, I’ve mainly been biting people’s ears off about them, so this new outlet will no doubt please those unfortunate enough to have listened to me droning on.

The big question around Rails: does it scale?

I say: forget that. Ask this instead: why should it scale?

Rails empowers the lowliest user or homesteader to create applications faster, at a lower cost than ever before. You may have an application that does 75% of what I want to do – but given that Rails puts t even closer to 0 it’s probably be faster for me to start from scratch than it is to try and adapt yours. That way, you have a perfect personalised solution, and so do I. If we looked at our code, they might even resemble each other a little. That’s survival of the fittest, isn’t it?

More and more users will become programmers as the tools, the middleware, the software-to-make-software gets better. Ning is the beginning of this. Users don’t need a generic solution; they’ll all be rolling their own. Software will become more discrete – hell, it’s going to become discerning. The tools we use are very personal; in an ideal world, they’d all scale to a userbase of one.

I guess that we’re all developers now.

Matt addresses the issue of the philosophers of Lagado, with regards to Don Norman’s take on the “simplicity” of Google:

“it would be more convenient for all men to carry about them such things as were necessary to express a particular business they are to discourse on”

I refer to it as the “map of the world the size of the world” problem, but I forget where I obtained that concept – it might have been Gulliver, too. The most perfect map of anything is a 1:1 representation of it – you end up making a copy. The trade-off in any navigation aid – menu, sitemap, chart – is accuracy of representation versus accuracy of content (I think). You need a perfect representation – an outline – but you don’t need a perfect rendering of content, because you’ll get that at the destination.

I face this problem a lot in design and IA; you come up with a solution that will work with the current content – and then “current content” grows. And for a while, things scale, but then they stop scaling, and you end up cramming it all in at the top because, well, all the content is competing with one another. And so you end up with a map of the world the size of the world.

The next step is to stop, refactor, and start again – if you have that luxury. Google, by contrast, never let things grow: it’s still practically the same homepage they started with. They avoided the feature-bloat by never letting it happen, and instead, launched their other product by and large, seperately. They may have occasionally integrated them into the results screen, but never the home page. So then usability comes down to intuition (and why shouldn’t it? Even Norman argues that objects should be intuitively usable). mail.google.com – what do you know, it works. maps.google.com – it works. And in making people guess the subdomains, you’re creating better users – users who work out what they’re really looking for quicker. That makes them more adept at your product – because Google’s product is find, after all – and more adept consumers of the internet.

The map-of-the-world problem stems from that horrid, oh-so-web-1.0 site archetype: the portal. We tread a fine line now – at one extreme, a single search box as a gateway to content; at the other, comprehensive indexes and subindexes, homepages of horrendous complexity. I don’t think the “single search box” approach is valid for many, but people are moving that way, and it’s good – away from horrendous taxonomies and indexes and subpages and sitemaps and towards a more organic, find-orientated paradigm.

Don Norman doesn’t believe in find. He likes devices to be “their own instruction manual”, remember – you shouldn’t need to read the book, it should just be obvious. This leads to his crazy telephones with millions of discrete buttons for each function. He’s kind-of right, but he doesn’t like a middle-ground of adaptability, multi-purpose interfaces. Google riles him not because it’s the middle ground in his way of thinking, but the polar opposite.