I'm just back from Adobe's partner conference in Amsterdam, where George Neill, Lead Experience Architect at Adobe Consulting, shows us this great slide depicting a woman processing mortgage applications. She has a PC on her desk which is running her organisation's app for managing mortgage applications. However, around here desk are multiple signs of usability failure. On her left, a paper calendar with names and phone numbers handwritten onto deadline days. On her right, an old-fashioned paper roll calculator. In front of her, a pile of paper forms colour coded with post-it notes. The app, Neill notes, should be handling all these tasks, but one glance at the user's working process is sufficient to expose its poor design.
All good stuff. The next thing we see is a nice application built with an Adobe Flex front-end and an Adobe LiveCycle back-end, with the not-so-subtle implication that these user-experience (UX) focused tools will help us create applications that fix this kind of design failure. There's also talk here at Adobe's partner conference of a new era in software built on customer experience, and how consumer technology from iPhone to Facebook and Twitter is raising expectations when it comes to business applications. There are even a few digs at developers, the people who, it is alleged, hate it when requirements change and who develop software geared towards the IT system which which it integrates, rather than towards users.
There is truth in all of this, but I'm cautious. It is easy to find a poor application and poke fun at it, but the idea of observing users and creating applications that improve their productivity is not a new one, and it is not necessary to use Adobe's stuff in order to do good software design. There are even times when it gets in the way. I recall spending time looking for a campsite on the web, for a holiday, and how it was in general the simple HTML sites rather than the "rich" Flash-driven ones that were easier to navigate. Admittedly the average campsite does not create web applications to Enterprise standard, but the underlying point is that there is a case for simple as well as a case for rich. Never forget "skip the intro".
The key question here: how do we define excellence in user experience? Let me state the obvious for the moment.
Applications that have functional deficiencies will not be rescued by any amount of eye candy or beautiful state transitions; and if the user is surrounded by post-it notes and antique calculators I'd suggest that this is not primarily a UX issue, unless we strip all meaning from the term and use it for every aspect of software design, features and performance.
Second, software can deliver a good UX without necessarily having gorgeous graphics and multimedia. As a business software user, I value applications that let me accomplish tasks quickly and easily. Question: think of a web application that changed the world, partly thanks to superb UX? Answer: Google search. Question: how much PhotoShop and Flash was used in designing the fantastic Google home page?
The case for user-centric software design is irrefutable; but we need rigour when it comes to working out what that means and how to achieve it. I like this comment which I found in an 2004 paper by Larry Constantine:
User-centered design is a good idea in need of improvement. The needed improvement is found in practices that put uses rather than users at the center of design and in changing the prime objective from enhancing user experience to enhancing user performance.
UP rather than UX resonates with me. It also reminds me of Kathy Sierra's mantra: creating passionate users. If the current rush towards UX puts the focus there, I am all in favour. If it means newly empowered designers imposing some sort of visual or multimedia experience on us whether we like it or not, count me out.
The iPad has just launched in the UK, queues are long, stock is short, and it is yet another successful new product from Apple. The iPad has frustrations, like no Adobe Flash support for web browsing, no Java, no printing, and the general sense that you do things the Apple way or not at all. Still, users love it and are willing to pay for it, and in the end that is what matters.
Does this shiny gadget have any relevance to the more humdrum world of business IT? I think it does, especially when taken together with other factors. Here's a remark from Apple CEO Steve Jobs from an informal email conversation with Ryan Tate:
The times they are a changin', and some traditional PC folks feel like their world is slipping away. It is.
Yes, it's a Bob Dylan reference; read the entire thread to see why. Jobs is marketing his company's stuff, of course, but a few days later the stock market put some solid evidence behind his claim. Apple's market capitalisation surpassed that of Microsoft for the first time since 1989. Microsoft remains more profitable; but the figures reflect the market's judgment that Apple has better prospects for growth.
Another sign of change comes from one of Microsoft's most important partners, HP. At the end of April it acquired Palm, and with it the WebOS operating system for mobile devices. Whether HP can make a success of WebOS is uncertain; it will not be easy going up against Apple and Google Android. What is more significant is the implication that HP has finally lost faith in Microsoft's ability to get it right in mobile.
Despite some positive buzz around Windows Phone 7, Microsoft did not help its case when it announced a major reshuffle in its Entertainment and Devices division on May 25th. This follows the bewildering launch of the Kin phone - bewildering because it seems right out on its own in terms of strategy - complete with typical Microsoft flaws according to this thoughtful review:
But the obtuseness of this user experience doesn't stop with the Spot -- it permeates the entire interface as though decisions about how things should work were made almost arbitrarily, without anyone stopping to test them in the real world. The Twitter implementation is a great example of that. You can add your Twitter account to the phone and see updates from people you follow, and you can update your status from the top of the Loop... but that's all you can do. You can't retweet something, you can't send a direct message, you can't go to single person's feed to see all their updates, and you can't even open a link in a Twitter message from the Loop!
Windows Phone 7 will have to be much, much better if Microsoft is to claw back any ground in mobile.
I digress. All that matters is that the world is changing, and looking less Microsoft-shaped with each passing day.
In saying that, I don't mean to diminish the excellent work which I see coming out of some parts of Microsoft - Visual Studio 2010, for example - or to ignore the continuing dominance of the company in many areas of business IT. Many companies still standardise on Windows, and Microsoft Office remains the only productivity suite I come across in work.
All true, but the two great IT trends of today are not centred on Windows and Office. One is mobile, the other is cloud computing; and of course there is synergy between them. Apple's iPad is a further advance for mobile, and will drive increasing mobile data usage and increasing demand both for iPad/iPhone applications and for web applications that work well on those devices.
I'm at Microsoft's MIX conference in Las Vegas, where the big news has been the unveiling of the Windows Phone 7 development platform, and the platform preview of Internet Explorer 9 with extensive HTML 5 support.
There is more to say about both topics; but one thing I want to highlight is that IE9 will not work on Windows XP, the venerable release that will not die.
It is not only that XP remains in use on existing PCs; there are also new machines on sale with this old version of Windows. I've just purchased a netbook, and when making my selection I noticed that many of them still come with XP, usually the Home edition. Some companies still specify XP when buying new PCs, to avoid the compatibility hassles that come with a move to Vista or Windows 7. There's also doubt over the benefits of upgrading. A friend said to me recently, "I really like XP, it does everything I need. What is the point of moving?"
Here's what IE General Manager Dean Hachamovitch told me:
Building a modern browser requires a modern operating system. There are facilities in Windows Vista and Windows 7 around security, for example the integrity level work that gave us protected mode, there are performance improvements that enable a variety of things in the browser, there is graphics infrastructure to take advantage of the GPU, that doesn’t exist in previous operating systems.
A measure of scepticism about such comments is reasonable. Microsoft wants users to buy its latest stuff; there's no surprise there.
Nevertheless, Hachamovitch is right. Windows 7 is more secure and more powerful. Personally I find it easier to use as well, partly thanks to Microsoft's design work on the user interface, and partly because desktop composition in Windows Aero enables richer preview of minimised applications and other good things.
Microsoft is also making a statement with IE9, to the effect that XP users can no longer expect to be included in major product releases. Office 2010 does support Windows XP; but you can bet that the next one will not.
The long life of XP is a side-effect of one specific thing, which is the failure (relatively speaking) of Windows Vista. I used Vista from its first release and regard it as better than its reputation suggests; but nevertheless, it was greedy for hardware resources, prone to annoying slow-downs, and less polished overall that it should have been.
There is also a real issue with application compatibility, introduced with Windows Vista, mainly thanks to User Account Control. This feature protects access to system locations such as the Windows and Progam Files folders, and parts of the Windows Registry, causing problems for some applications that expect full access.
These factors extended the life of Windows XP, resulting in the situation we have today: an operating system coming up to nine years old still in widespread use.
Very often the continuing use of XP is not something we can control. Rather, it is something we have to live with. Nevertheless, it is becoming a liability. Windows 7 improves on XP in every way that I can think of; and we even have XP Mode and Med-V to assist with migration, by running obstinate apps in virtual instances of XP.
Windows XP is something we have to live with, but no longer something to recommend.
Postscript: arriving at the gate for my flight from Las Vegas, I could not resist snapping what seemed the perfect illustration: Windows XP with a sad little error message.
I'm at the QCon conference in London, one that I particularly value for its vendor-neutrality and strong content. Yesterday we heard from Robert Martin, founder of Object Mentor, on the subject of software craftmanship, or how to avoid bad code. One of Martin's points is that having code that works is not enough. He makes an analogy with a machine. It's not enough that your car works; when you open the bonnet you want to see good engineering, not a tangle of pipes, wires and belts that somehow hangs together.
Software is vulnerable to poor craftsmanship because code is often well hidden from customers and end-users. Still, the programmer knows whether they are putting together something that just about works, or crafting something excellent that will be understandable and maintainable long into the future.
Martin's talk turned out to be a practical one. There was nothing really new; but plenty to think about. Here are a few of his tips:
You may not agree with all of these; but I like the underlying objective, which is to code to a high standard rather than just fixing bugs until it runs.
Agree? You can sign the Manifesto for Software Craftsmanship.
I've written positively about Microsoft's forthcoming Visual Studio 2010, both here and more recently in a review on The Register. I was interested to see a kind-of follow up from Jeff Vroom, making the case for doing without an IDE at all, at least some of the time:
Emacs, Vim, and other editors have basic syntax highlighting and code navigation for an even broader set of formats despite the fact that they lag behind IDEs in features. Though IDEs offer impressive plug-in capabilities, traditional script and config files seem easier to learn and use and ultimately more flexible.
Command line workflows offer a more flexible, less integrated and less guided approach to development. You learn how to use them one tool at a time. Development and adoption of new tools is usually easier as you are not tightly coupling tools into one complex user interface. Admins, analysts, and designers use command line tools, making it easier for them to work with developers when the IDE is not front and center.
I don't see a lot of designers using command-line tools; but even so I agree that there is a case for a programmer's editor with command-line compilation, rather than a huge IDE. The two things I like most about the bare metal approach are speed and transparency. Speed, because a little editor like Notepad++ starts in a blink, handles large files with ease, and does not get in your way. It is odd that performance still matters so much in an era of multi-processor machines with each core running at more then 2 GHz; but it does. Sometimes I am caught out when a monster like Adobe Dreamweaver grabs a file association for something like HTML or PHP. I double-click a document, and wait impatiently while it loads all sorts of stuff that I do not need, when I only want to make a small text edit to the code.
Transparency is an even bigger issue. If you work with simple editors and build from the command line, you are forced to be aware of what files are in your project, what tools you are using for the build, and what arguments you are passing to them. If something goes wrong, you know where to look. By contrast, IDEs hide things from you, supposedly for ease of use. In the worst case, something like a Visual Studio solution can get corrupted and leave you not knowing how to fix it, other than to create a new one and add back the files as best you can.
A similar problem comes with wizards that generate code. It is lovely to have the IDE generate all that boring data-binding code for your forms, until there is some weird bug, the results are not as expected, and you end up tracing the SQL and puzzling over why it is wrong.
Valid points; but I am still going to come down mostly on the side of the IDE. It is simple: there are so many genuinely useful tools in something like Visual Studio that productivity is better. Things I don't want to do without include IntelliSense and code completion, debugging tools with things like mouse-hover variable values and watch windows, visual design tools that generate a ton of code I don't have to write, various refactoring utilities, and build tools that save having to think about make or Ant. Visual Studio takes ages to load, but once it is up and running you can always press Shift-Alt-Enter and pretend it is a text editor.
I am still wary of wizards though; and I value knowing how to do without the IDE, even if most of the time I end up using it. As one of the comments to Vroom's piece notes, if it gets to the point where your programming skills are really IDE skills, you should worry about being so deeply tied to a single platform and way of working.
I attended a round table to discuss the use of open source software in government, with Red Hat, Ingres, Alfresco, and on the government side representatives from the Office of National Statistics and Islington Council.
It is a fascinating topic on several levels - and not just for government. The two big questions: first, what is the rationale for prefering open source; and second, if you are convinced of its desirability how on earth do you get a huge, diversified entity like the UK government to increase its adoption?
There is clearly some kind of disconnect. The government already has a policy which stops short of mandating open source, but does say:
Where there is no significant overall cost difference between open and non-open source products, open source will be selected on the basis of its additional inherent flexibility.
In other words, given two otherwise equal proposals, open source is favoured - yet in practice we were told that 95% of software in use in the UK government remains proprietary.
So why is that? There are dozens of reasons. It's the available skills, with armies of experts in Microsoft, Oracle, IBM, and so on, compared with only a few willing to specify open source technologies. It's the culture, with countless existing supplier relationships and a well-trodden procurement path with the usual suspects. It's the existing envirnonment: if you start from a point where the servers are Windows, say, and the desktops all have Microsoft Office, it feels more comfortable to continue down that path. It's the lock-in, especially when it comes to things like proprietay SQL extensions and stored procedure languages, that simply do not port easily to new database managers. And it's canny vendors, who go for site licences with the widest possible scope, so that if a small group decides to break the mould and use something different, it looks more like a cost than a saving - because they are already licenced for the proprietary stuff.
These are tough obstacles to overcome. Put another way, the rationale for adoption has to be exceptionally strong to overcome the inertia; and it was here that I found the round table unconvincing. The open source companies gave diverse reasons for the benefits. Lower cost was mentioned frequently. By contrast, John Powell, President and CEO of Alfresco, talked intensely about how the UK was somehow handing over its soul to silicon valley, by not building up local skills in open source software. Someone else said how nice it was that open source software was free so that everyone in an organization could use it; another gently observed that since most open source companies make their money from support agreements that are per user, this is often not the case.
The most persuasive rationale is that open source software tends to support open standards and therefore avoids lock-in. This lowers long-term costs, by ensuring that the customer always has freedom to switch.
The snag with all these arguments is that the proprietary companies can counter them easily. They will reel off all the open standards they support. They will draw graphs showing how much money you save by using their stuff. They will point out that those with skills in their technology can easily market them worldwide. The outcome is that nothing changes.
I don't doubt that leading vendors make excessive profits on software that should be commoditised and cheap, or that vendors follow strategies designed as much to keep us hooked on their stuff, as to advance technology for our benefit. It's a cycle that needs to change.
At the same time, the open source vendors have to recognize - and to be fair, I reckon they often do - that most of us will not switch for ideological reasons. We want to get our work done. The best open source projects, things like the Apache web server (if there is anything like it) succeed on sheer quality and reliability, not merely through being open source.
The tough question: does the open source ecosystem have sufficient resources to deliver that quality, against proprietary vendors with huge profits to pour into research and development? There are plenty of decent open source products; the number that are truly best of breed is more limited. Currently it is the big proprietary vendors that have the advantage.
I left the table with more questions than answers. Should governments introduce more draconian legislation, to counterbalance the industry bias towards the status quo? Will the move towards cloud computing break the pattern? Should legislation be focused on mandating standards support, or even that applications should be proven to work on two different platforms, rather than the matter of open versus closed source? If today's MySQL is tomorrow's Oracle, is there really any difference? Isn't there too much to worry about already, solving problems and delivering successful projects?
If pressed, I would always incline towards the best technical solution, rather than one which ticks boxes, even open source boxes. That said, we are all susceptible to being bamboozled, not even looking at open source alternatives if we already know a proprietary tool or component or platform that will do the job. Even for individual developers, it makes sense to choose the open source solution in cases where other things are equal; and to think twice before building vendor lock-in into the applications we create.
Tech media pundits talk incessantly about migration to the cloud, but it is always interesting to get reports from the trenches. Two recents ones interested me. The first is from Patrick McKenzie, who sells a niche Java application. He's just posted a detailed and entertaining blog entitled Why I'm Done making Desktop Applications. His application exists in both desktop and online versions, and he says he was a staunch defender of the advantages of desktop apps - "You can keep your Google Docs, Excel is superior in almost every way." Then he made an online version of his app with if anything fewer features, and tracked the statistics. He discovered the following:
His conclusion:
The next major release will almost certainly be its last. The webapp, and my future webapps, seem to be much better investments.
Does any of this apply to corporate development? It's true that life is easier in some ways if you do not have to make a sale; and there are still some things that desktop applications do better, like integrating with Microsoft Office through COM automation, or continuing to work offline on the train or plane - though see Rails creator David Heinemeier Hansson's You're not on a plane for a contrary view.
Still, many of the other factors do apply. Lower support requests, zero installation, accurate usage monitoring - all these things have immediate financial benefit.
It is no longer web application developers who have to justify their case, but rather those who still advocate desktop development.
If you need any further persuading, take a look at this survey of 1400 Microsoft's small business customers by Accredited Supplier. Apparently 62% prefer business applications that work through a browser, and only 18% prefer desktop applications. The more chilling news for Microsoft is that 13% actively intend to switch to Google Apps - with all that implies for sales of Windows server, Exchange, and Office - while only 36% are sure that they are not switching.
All that cloud talk is translating rapidly into business decisions. I'm not sure whether the future of the business application client lies more with AJAX and HTML 5, Microsoft Silverlight, Adobe Flex, or something else; but for sure it is not a desktop technology.
The Apple Mac's OS X is a gorgeous operating system, beloved by its users, but outside the niche world of designers and musicians it is generally not the one used in business. It's an odd situation that puts pressure on system administrators to accommodate Macs into their systems, either from the aforementioned designers, or from eager home Mac users who want to enjoy it at work as well.
Last week Apple released OS X Snow Leopard, also known as OS 10.6. I was at Apple's flagship store in Regent St, London following a press briefing, and watching throngs of people line up to purchase their upgrades left me in no doubt about the Mac's continuing success. Nevertheless, because of its high price and lack of business penetration the Mac remains a minority choice. The figures are slippery, but it may be around 10% of the US market by units, 20% by value (the difference showing how expensive they are), while worldwide it is much smaller.
Now Apple has introduced native support for Exchange as a key feature of Snow Leopard, apparently giving admins one less reason to deny would-be corporate Mac users. Is it enough?
Unfortunately the Exchange support still falls short. I've spent several days working almost exclusively in the new OS, and explored the new Exchange support in Snow Leopard. Although there is a lot to like, such as deep integration with Mail, iCal and tasks, there are snags. For a start, you need Exchange 2007 SP1, and earlier versions remain common. Even if that is in place, Snow Leopard's Exchange support still falls short of Outlook on Windows. The new feature is based on Exchange Web Services (EWS), which do not expose all the features of Exchange.
I found myself missing features like the ability to send on behalf of another user, and access to public folders. Another practical problem is that unless Exchange is configured with EWS in mind, it might not work at all, especially when trying to connect over the public internet. Outlook has its problems, but its ability to use RPC over HTTP, avoiding the need for a VPN connection, is a brilliant feature. It is also strong at seamless online/offline support, stronger than Apple Mail. I'm also not convinced that Mail's new Exchange support is quite done, as evidenced by several crashes like this one:
The real issues are broader than this. Macs still fit awkwardly into Windows-based networks. System administrators like standardisation: standard application deployments, standard operating system builds that can be zapped and re-imaged; standard configurations that can be enforced using Windows group policy. The presence of Macs adds unwelcome complication.
There's also the matter of application compatibility. If your business depends on some little application written in Visual Basic 6 or Microsoft Access, for example, you have to figure out a way for Mac users to run it, by emulation, or terminal services, or some other route.
In the short term then, Snow Leopard will not transform Enterprise Mac adoption. Nevertheless, the Mac is a huge influence, beyond what its market share implies. Further, if a significant number of users are using Windows grudgingly, wishing they were not, that is not good for productivity.
Here's three suggestions. The first is to think cross-platform. The past is the past; but for new applications it is short-sighted to target only Windows. I suspect this lesson has largely been learned, but it still bears repeating. Have a cross-platform client - Silverlight may help for .NET developers, or there is Adobe Flash/Flex, or Java, or pure Web applications, to mention a few solutions.
Second, learn from Apple. Microsoft is doing so, and Windows 7 is the evidence. An interview I did with Bill Buxton last year gives further background.
Third, is it really so hard to accommodate Macs? Yes, there are still issues, and different factors apply in every organization, but few problems are insurmountable.
Incidentally, I am no Mac Zealot. I actually like Windows, and although I'm currently immersed in OS 10.6, I intend to go back to using a PC most of the time. Some things are better on the Mac, some things are not, and most things are more expensive. It does pay though to have users working in the environment they prefer; and where that is possible, it makes sense to allow it.
Question: which is best for cross-platform, managed code using a runtime such as Java, .NET, or Flash, or is it native code? When Java arrived in 1996, Sun promoted write-once-run-everywhere as one of its key benefits. The arrival of just-in-time compilers for all the runtimes mentioned above removes many performance concerns. So is managed code the best solution?
My assumptions about this were challenged when I spoke to Embarcadero's CEO Wayne Williams last week. His company is the one that now owns Delphi and C++ Builder, the RAD software development tools, after acquiring Borland's Codegear division last year. Williams told me that taking Delphi and C++ Builder cross-platform is now the top priority for the team working on those products. Concerning native code, he said: "It's crystal clear. If you want a small, fast, GUI-rich application, and you want to target the popular platforms, there's only one game in town." That means at least x86 code for Windows, Mac and Linux, and he added, "there's no reason mobile devices shouldn't be on that roadmap as well."
What's wrong with Java then? "There's always been two approaches to target multiple platforms. One is interpreted, where you shield the code the developer is writing from those differences. The Virtual Machine is responsible for that, and if you want to add another platform, it's all centralised. It's easier, but the result is poor, it's a least common denominator approach.
"It's a bigger investment and it's more difficult to cross-compile, where you natively target these platforms, but the end result is much better. You're running true native code with full access to whatever hardware there is on that platform."
It was like going back in time: I recall similar arguments about Java back in the nineties. Since then, we've had not only JIT compilers but also huge increases in hardware performance. Is Williams living in the past?
Before dismissing what he says, it's worth noting that native code has never gone away. I use cross-platform native code applications all the time, from the SQLite database engine to the Audacity sound editor, and I enjoy their small size and fast performance. Over at Google, the Chrome team is hard at work delivering a new web browser, and it is mostly written in C++. Most of Windows is written in C++, despite Microsoft's commitment to .NET; and Java is an afterthought in Apple's OS X.
Although hardware performance has improved, the increasing numbers of mobile devices with constrained resources is a counter-balance to the idea that hardware takes care of inefficient code; and although managed code is fine for many business applications, it's hard to quibble with Williams' contention above that "If you want a small, fast, GUI-rich application, and you want to target the popular platforms, there's only one game in town."
There is another argument for managed code, which is that applications are quicker to write and safer to run when they are under the control of a runtime virtual machine. That is generally true as well. Still, Delphi does a great job of hiding the complexity of native code development. It may be just a little anachronistic, but if Embarcadero successfully deliver a cross-platform Delphi compiler, I think there will be plenty of take-up.
Williams says we may see cross-platform Delphi as soon as next year.
