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.