It’s been a while since I regularly read Jakob Nielsen’s Alertbox: Current Issues in Web Usability. Imagine my surprise when I find no RSS … the largest change to web use since the browser itself, and all we can get access to is email alerts.
Archive for the ‘User-experience’ Category
The Emperor Has No Clothes: No RSS for Jakob Nielsen
Tuesday, March 11th, 2008Everything you know about scaling is wrong
Friday, August 3rd, 2007Scalability of the favourite argument topics of the technically inclined. Having developed some fantastic, all-singing, all-dancing, user-generated social networking Web 2.0 platform*, someone will invariably ask:
“Oh, you used {LANGUAGE X}”
“Will it scale?”
You have to imagine the slightly derisive tone for yourself.
Trouble is, languages don’t scale, systems do.
Assessing scalability on the basis of a particular programming language is like saying to someone who is writing an Encyclopedia: “English won’t scale”.
Systems scale.
If you wrote your Encyclopedia the same way you wrote your product brochure, it wouldn’t scale - small page format, lots of pictures, minimal text with plenty of whitespace. If you write an Encyclopedia, you need to develop a system for handling the information - table of contents, indexing, cross referencing, multiple volumes, alphabetical organisation, thin paper, multiple columns of text, readable fonts.
The language used to write the Encyclopedia or Brochure is secondary to the system that delivers it.
The same is true of Web Applications.
Languages are irrelevant to scale and frameworks (being very close to languages and essentially an extension) only have a minimal impact.
I moved to Ruby on Rails from PHP. The standard argument against Rails from PHP developers is that “Rails won’t scale”**. However, this focus misses the point entirely. I have seen arguments from PHP developers who suggest using single quote for strings ‘ rather than double quotes “, because single quotes parse faster in PHP. This thinking is radically broken.
Scalability has nothing to do with processing performance at the language level.
Scalability is about the system as a whole.
At some point as an application scales, it will invariably require multiple servers and multiple databases, and there is very little any language or framework can do to mitigate this requirement. These requirements are system level, not language level - your only real option is to be ready to build your system out accordingly as it grows. The only trouble you find is when you have made decisions early on that limit the way your application can grow out.
As a corrolary to the scaling issue, my final point is this:
You aren’t going to scale
Call me cynical, call me pessimistic, but lots of people build for scale prematurely.
The focus should always be on creating great user experience.
Unless you have the load to warrant a particular system decision you should not be creating that system (but always within the framework of sensible architectural decisions). Scaling issues are often unpredictable (you don’t know your load profile until you hit it, or are hit by it) but worrying about them before you have to wastes valuable developer resources on infrastructure rather than the interface.
In the Web 2.0 world, scaling problems are a sign of success, but the focus should be on the user, not the system.
* We don’t develop applications or, god forbid, sites anymore, we develop platforms.
** I am aware the argument is a bit confused here, because PHP is compared to Rails, when Rail is a framework based on the Ruby Language and should be compared to a PHP framework like CakePHP.
Dear Blogosphere: Shut up about the iPhone
Monday, July 2nd, 2007Dear Blogosphere,
Shut up about the iPhone.
I don’t want to hear it.
I am already totally over the iPhone, and won’t even see one until 2008, at the earliest. See, Dear Blogosphere, not all of us live in the US of A.
Not all of are effected by the apparent revolution caused by some people strapping a cell phone onto an iPod and hooking it up to a network that barely works.
======================
It does seem apparent that Apple is going to do to the mobile phone market what they did to the MP3 player market. If they can survive the telecommunications companies - all reports are saying that AT&T are really dropping the ball. In the music market, Apple could get traction without playing directly with the Record Companies, because people already had music collections. Once the iPod took-off, Apple had some leverage to play with. In the telecommunications world, things are very different … you can’t have an iPhone without the network, which means playing with the telcos. Australia’s equivalent of AT&T, Telstra, has a long history of customer abuse and mismanagement, but it’s the dominant player (read: only player in some areas of Australia) and Apple may be forced to deal with them.
Multimedia died for a reason
Thursday, June 28th, 2007The 37 Signals Blog has stirred up controversy again with a post about HTML, CSS, and JavaScript:
On the user experience side of things, we’re not even close to tapping out the potential of HTML. The majority of web sites and applications still suck.
Of course, the flame-war began immediately:
“Flex/Flash/Apollo is totally the future”
“No it isn’t”
I think that is definitely true that we have only scratched the surface of HTML. It’s only in the last couple of years that HTML, JavaScript and CSS have really become advanced, stable and widespread enough to be used for complex application development. Even features that have gained ubiquity, like auto-complete text fields that talk back to the server, are very recent additions to the developer’s toolkit.
Having worked with WebStart for several years now, the hardest problem to solve is the additional installation. Java makes this particularly hard, but when you use a runtime on-top of the browser, you will always have this additional barrier to adoption. Rather than prospective customers being able to use your application straight away, you are placing an extra hurdle in front of them.
The problem is not insurmountable, but it is there.
On top of all of this, most RIAs I have seen don’t really do much more than a “vanilla” Web 2.0 application anyway. I come from a Multimedia background (I did a lot of CD Authoring with Director in the 90s) and I’ve done far too much Swing, so I’ve seen many, many fantastically bad applications. There is a reason why software tends toward the a standard set of application principles - business applications don’t need much singing and dancing.
Auto-complete, edit-in-place, drag/drop, lists, options are all standard fare with HTML, CSS and JavaScript About the only piece that is really missing from the stack is the ability to zoom effectively.
Whichever side of the debate you come down on, you have to admit that it’s going to be an interesting few years.