User Interface design and the role of the programmer

Anyone who has had a conversation with me, over the past six months or so, about web programming will know that I am a firm advocate of the less-technical programmer. That phrase is heavily loaded and I will explain in a second, but I mean that creating applications, particularly web applications, is increasingly within the grasp of people unversed in the arts of software engineering.

This post, about the demo of “Thermo” at the Adobe MAX keynote yesterday, has captured my imagination. It is a tool for making it simpler to create web applications in Adobe Flex, to the point where you can do it without touching any code. So far, so much yawn – there are plenty of companies out there creating what are generally termed “mashup” editors – Yahoo! Pipes, Google Mashup Editor and Teqlo, for instance. Thermo is, to me at least, different; it is described as splitting the design of a user interface away from tying that interface to the programmed logic. Simply from a product design point-of-view, this is vitally important, as it puts the user and their interface at the start and the centre of the design process, something which my colleague Phil Whitehouse has been writing about here and here. But Thermo also recognises and supports different skillbases. For the “mashup editors” I mentioned, their problem is in the name – generally, they want to help novices pull together mashups with little or no programming, but this is just not interesting. There are only so many times you can re-combine RSS feeds and Google Maps before you really go off the whole business. I have yet to see a really compelling reason to use these tools to build my own applications, rather than just take what someone else has built. And because these tools focus on the building, they are not optimized for running the mashup, which means I’d probably be better off getting a php/perl/python-savvy friend to code it for me.

Back on these skillbases that Thermo supports, they have explicitly decided to support both user interface designers, as well as allowing programmers to come in and pull the threads together underneath the UI. In creating a single environment for that all to take place, they are able to push the skillsets closer to each other, where there exists a natural grey area.

This goes right back to my statement at the start that I am an advocate of the less-technical programmer. I am careful to avoid the phrase “non-programmer” here, because I don’t believe that pursuing the goal where granny knocks up the custom applications she needs is at all a reasonable goal. There are huge numbers of people who won’t ever create applications, but are perfectly happy to use and/or pay for other people’s applications. Plus, the popular idea that everyone wants a service customised to their own needs does not mean that they need to go right back to the construction of their application to accomplish this. The group of people that I’m much more interested in helping are the large numbers of people with a very smeared and ill-defined set of web development skills, anything from having an idea, creating a user interface or making digital graphics, through to editing HTML and JavaScript, even if it means they are putting someone else’s code down in notepad and cargo-culting that. This is why Thermo appeals most to me – it is going to allow the people who have the drive to create exciting web applications do so when they cannot today, and not pussyfoot around trying to persuade my mother to mash up her shopping list with the cost of groceries across local supermarkets.

Having said all that, I should point out Paul Downey sitting in FOWA2007 has just twittered this:

#FOWA Adobe AIR and Microsoft Sliverfish have a strong presence here. Rich Applications are NOT the Web Repeat after me LOCKIN LOCKIN LOCKIN