on User Experience design

Opinions on a subject close to one's heart can be quite difficult to express. UX certainly is one I've procrastinated on for a long time and probably will never be able to capture in a short neat post. However, I feel compelled to start boiling it down hoping that in time a well distilled elixir of love will emerge. When unable to precisely define a notion of what one stands for, it is always best to eliminate the superfluous and the opposites from the spectrum of likely candidates for core interests and beliefs.

Rather than the “look and feel” of landing pages or navigation issues, which appear to dominate many UX debates, these days, transitions of interactive devices and mechanisms in user workflows e.g. content authoring tasks, are of particular interest to me. The nature of users' dialogue with the contraptions facilitating task oriented actions within the system is an increasingly important aspect, especially when we consider their impact on the extent of engagement in creating content.

Not intending to discount the significance of navigation, wayfinding and landing page design, I'll focus on the wizards enabling authoring, ongoing maintenance and organisation in ad-hock created content on the web from a user perspective. A few issues immediately come to mind and given time I'll attempt to attribute those to aspects of success and failure in context of user adoption and capability to evolve with changing needs. The cumbersome authoring process of this system (blogspot.com) and blogging systems at large, should provide ample opportunity to discuss failed workflows in contrast with later generation of Social Media sites.

I suspect that much of the failing User Experience can be directly attributed to system design based on code engineering tasks as opposed to usability principles and User Centred Design process in particular. This leads me to the role and the general fit of UX practice in business culture and an interesting paper by Zafer Bilda on this very subject. The report comprises of a number of propositions Bilda presented to a group of 15 UX practitioners in order to solicit their views. I felt motivated enough to respond to the issues raised myself and in part to address the answers he obtained from the group. Read the original paper and my comments on “Chris Khalil’s Musings” blog.

agile or fragile software development

Agile methodology is widely accepted and has been adapted to many specific applications. The motivation to develop “lightweight” processes for accelerated production of software, lead to the formulation of the very ambitious Agile Manifesto in 2001. 1999 was a low point for the software development community, not only did revisiting old code to hunt for Y2K bugs seem like punishment at the peak of the .com boom, but more critically – the process exposed fundamental weaknesses of the documentation heavy processes in the past. It was time for a disruptive change; the pragmatism behind a general reluctance to adopt new approaches evidently failed us.

The appeal of Agile was by no means a discovery of new techniques, we've seen or done it all before, but this time a methodology was elegantly distilled into a few pages rather than a book. The Agile Manifesto offered a convincing vision of preferred values and principles focusing on collaboration, responsiveness, the individuals and their roles instead of a rigid processes and documentation. Other benefits ascribed to Agile include: satisfaction through rapid delivery and high ROI (return on investment).

______________________

more agile

The informal and often cuddly nature of the face-to-face workflow has at times been vulnerable to parody in its less successful applications, but the wide acceptance speaks for itself. The long emphasised focus on the user and the problem domain is finally an integral part of the process and not an 11th hour contractual necessity. From a design point of view, this aspect alone opens up the scope for exploration of truly creative solutions. Shifting from the closed shop research of the problem space towards stakeholder interaction, enables the developers to go beyond delivering 'what the client asked for' to gain the insights which increase the likelihood of discovering innovative and disruptive outcomes.

______________________

but still fragile

But isn't all this bonding and hugging amongst stakeholders just as fragile as other partnerships we form in everyday life. Well, yes it is and either party may shoulder the blame. On the developer side, the integrity of the routine daily progress/problem updates can be compromised for various reasons, including the reliance on interpersonal relationships. However, the client representative role is far more vulnerable to failure. The mantra and reality of the partnership and the sense of engagement will inevitably lead to emphatic attachment to the notion of validity and value in the project without the safety net of ongoing checks and balances from the peers. Further, the client-side stakeholder isn't necessarily representative of the end-user or worse - the prospective user may for now be just a speculative 'persona' profile.

The methodology falls short of full coverage in a number of key scenarios of the product development lifecycle and delivery situations. The Agile stereotype of client – developer relationships, typical of the last century e.g. building business process software, are not universal. The above-mentioned vendor as a commissioning party and the direct to public deployment paradigms are increasingly common in today's market yet neither seems to fit the magical stakeholder interaction scheme. My deliberations on those two examples revealed the most glaring omission. The inherent rush to produce application code, due to the value placed on software as a primary measure of progress, appears to overlook the need to integrate the critical early stages of the process; research, idea generation, design exploration and prototyping.

______________________

what about design?

It is one thing to declare catchy principles like openness to changing requirements and regular adaptation to changing circumstances and yet it is an absolute mistake to embark on code without a design and prototype validation. Under those circumstances, the unexpected manifestation of changes and the necessary adaptations are almost guaranteed and consequentially would compromise the expected delivery timeline, ROI and ultimately result in poorly designed and unmaintainable code. Yes, the core aspect of Agile – iterations and the prescribed code re-factoring may address the latter problem to some degree, but surely not without further compromises of the primary objectives.

I'd like to entertain the notion that Agile methodology can be readily mapped to the design and prototyping stages, just as it has been adapted to other processes. However, besides the strong appeal of the core values and user-centric principles, I fail to see further complementary features. Perhaps it is time for the early stages of development to be specified as additional steps extending the Agile iteration methodology at a cost of diminished elegance and simplicity.

______________________

is there a fix?

Many designers agree that, the correct way to accommodate design in Agile is to define “an initial phase zero that takes a long-term and holistic view of the project needs before moving into agile process” [Bernard C. Summers S., Dynamic Prototyping with Sketchflow in Expression Blend]. A common approach, in real-life application, is to embellish Agile with attributes of a familiar or industry recognised process, for example, see “Kanban Development Oversimplified” or “How Scrum Induced Sub-Optimization Kills Productivity (And How To Fix It With Kanban)”. However, none of those exaples cover the User Centric Design model. Unfortunately, all attempts at pimping up Agile with 'process' simply water down and often compromise its core principles and create a patchwork of less appealing prescriptions rather than a crisp well defined methodology.

to app or not to app, that is the smartphone question

______________________

cool code in the cold

At present, there seems to be a lot of dispute about the appropriate technology to implement smartphone oriented RIAs (rich internet applications). The debate is especially valid in terms of the 'me too' rush to develop iPhone and iPad apps instead of mobile device optimised websites. This picture is muddy indeed when we consider decisionmaking behind the tendency to favour the native app paradigm and especially the iOS platform. Lets look at a similar credibility dilemma in the recent past - the emphasis on deploying Flash websites, against the better judgement of many internet programmers.

In the days when the 'suits' had no idea of what internet technology objectives were and many felt quite proud of this since they had secretaries to type and print emails, decisions were all too often left to the young 'propeller heads' with little experience and even less expertise. The technologists aware of the big picture in terms of network applications or User Experience seemed just too hard to delegate, especially when requested to “show something by Friday”.

The cool “look and feel” designers stepped in without hesitation. Many had Macromedia Director skills and felt quite comfortable with applications that didn't print and broke the fundamental interactive UI event behaviours. And so, the user got the 'look' in the form of “Wait.. loading Flash” and 'feel' trying to work out how to scroll the information clipped in a tiny fixed size box.

Luckily, by the time the legacy Netscape was buried and the browsers imitating IE DOM provided a nearly uniform client-side scripting environment, the industry had begun to exploit the dynamic possibilities of HTML in combination with HttpRequest object. The 'suits' got a new phoney moniker to talk about; “Web2” and the web became a hub of Social Networks. The ECMA Script committee was shaken up by Microsoft, Google and Yahoo developers who intended to adhere to a deliverable standard, forcing the committee to abandon the ES4 utopia and accept a more realistic roadmap of critical revisions to ES3, which bore the ES5 release in 2009.

The final nail in the coffin for Flash is being hammered in by Steve Jobs. The 'special' relationship between Apple and Adobe (now the owner of Flash) reached a high point when Jobs expressed the commitment not to support Flash on iOS.

______________________

ecosystems deja vu

For a while it seemed that we had the future direction mapped out. But suddenly, the suits began to notice the outstanding growth figures as Apple introduced the new status symbol on the block. The techs lamented – a PDA with GSM not even 3G, UI designers cried – the icons all have the same shape, women frowned – the fingernails get in the way and the calls drop. And yet, the iPhone boosted street credibility in a prolific way and at the same time proved to be the most disruptive technology in a long time.

Tempted by Apple's market success (despite of or more likely due to the device's high cost) and the hefty 30% margin on third party app sales and subscription revenues, the manufacturers are busy clambering up the greasy pole building their own ecosystems. Quite apart from my semantic objections to using the term ecosystem (the original meaning is a topic more alive now than ever before), the concept of proprietary device or system oriented marketplaces for digital products bluntly contradicts the principles of User Centric Design. The notion that consumer choice and their needs are the primary objectives simply falls by the wayside when you lock them to a proprietary procurement and service channel.

The choice between native apps and cell phone optimised websites (web apps) should be based on technical requirements and user tasks, but in reality it is anything but. For one, when a company director or CEO asks for an iPhone app, very few employees have the guts to ask if the decision was purely influenced by the 12 years old technology guru at home. A truly 'smart' phone screen could be a combination of 'gadgets' for live data feeds and links to commonly used web URLs, not unlike a fusion of iGoogle and the Chrome opening page. However, since the phone manufacturers suffer from amnesia when it comes to failures of locked-in online environments e.g. Apple's eWorld or the Microsoft Network, we have to re-learn the lessons of 1995. Thank God that Steve Jobs is on-board this time, even if his health isn't quite what it was in 1996 when he returned to Apple and scrapped the Newton MessagePad.

I realise that statements like this are very controversial and deserve a lot more than an off-the-cuff post. However, in the interest of brevity I want to limit it to a just few key points. So beside the “customer is king” argument, what is the major ecosystem problem?

The business culture relating to Intellectual Property law. Just look at Apple; with 250,000 apps on offer it is apparent that some of them may violate registered patents and Apple is in no position to verify the legitimacy of every offering it sells. So far, when an app becomes a subject of an IP claim Apple pulls the app from the store and in many cases seeks to be admitted as intervenor in the legal case. There are countless reasons for Apple to be involved considering the business size and immaturity of many developers behind these apps. The question is, can and should Apple's (Google and Microsoft are in the same boat) IP people deal with the growth in patent assertions by licensing companies and patent trolls? My guess is obvious I hope.

______________________

the silver lining behind proprietary technology

The native app development environments aim to streamline the implementation and delivery, as well as enhance UI presentation on the respective platform. These intentions are very worthy, but are they effective considering the need to deploy three or more app versions and engage multiple vendors? Microsoft is the last to join the Apple, Google and Nokia ecosystems and back-end clouds. The Windows Phone could become more important now that Nokia adopted it for their products. Even if this choice was strongly influenced by monetary benefits of the partnership, its technical advantages, if any, will constitute the difference the user may experience. Perhaps sharing a few thoughts about WP7 technology will help to illustrate my point.

Personally, I don’t believe that the new focus on the phone as an entertainment device, in preference to the earlier emphases on business/enterprise communications, is anythig but an iPhone panic. The new architecture appears to be aimed at single user games and trivial commerce apps. The Windows Phone 7 platform is based on Silverlight and xna for applications requiring 3D support. These two development paths 2D or 3D are quite distinct and don't allow for mid-stream migration. The single-tasking runtime environment (tombstoned when user switches to another app) is also limited to self-contained executables sand-boxed (exclusive memory and local storage of persistent data) aiming to enhance security and stability, but as a result severely crippled in scope. In plain English, this paradigm hardly looks capable of enabling the next big thing beyond Web2.

Further, just like the Apple, Google and Nokia ecosystems, Windows Phone is totally reliant on the Microsoft controlled delivery channel via the Windows Azure back-end cloud. At large, I dismiss the commonly expressed 'big brother' fears regarding cloud services, however the platform locked user experience objections expressed above remain.

______________________

clouds on the horizon

The cloud paradigm will no doubt be the basis for the next generation of RIAs and provide ample opportunities for new innovative network applications beyond Social Networking and spanning across all forms of devices we happen to have on hand. I believe that in the near term future, HTML5 will become the favoured technology for mobile oriented RIAs over deployment of multiple native apps. For now, the wish list priority focuses on wider HTML5 and SVG support.

As far as the more mature cloud application candidates for the smartphone boom - Microsoft Windows Live or Gmail and Google Apps/Docs hold a lot of promise and yet in business settings I’m still a little dubious at best. As expected, Microsoft manages to meet some formidable design objectives, e.g. 'simplicity' - least effort in adoption since that is the scarcest resource and yes the 'price' is right. But Google services provide a better example for a number of reasons; the claimed high adoption rate, more complete functionality and above all, a business model that doesn't compete with a core legacy revenue source. However, the monetisation model based on advertising isn't free from hindrances when one considers the targeting mechanism. Using context derived from seemingly private content constitutes an obvious problem for anyone with Intellectual Property concerns (clients’ or one's own).

Commercial contract based cloud computing (SaS) is another story, especially for companies culturally struggling with IT departments presenting a mind-field of 'yes men' too afraid to raise an issue or too lazy to address problems.

The recently introduced (June 28 2011) replacement for Business Productivity Online Suite (communication and collaboration tools for MS Office) – the Office 365, which now includes Office Web Apps allowing for online document viewing (including smartphones) and editing (albeit limited), at a reasonable price. This package will be a more attractive option for business startups than companies with legacy in-house data stores, which will no doubt find the migration a daunting task. Moving the data from office servers to the cloud provides countless management shortcuts; however, the process implies a substantial shift in the IT culture and of course requires 'big decision' to commit to that change. Further, there are additional costs and effort accompanying the deployment e.g. business process related manuals, documentation and training.

To be fair, all these meta issues are equally relevant to Google Apps/Docs, in addition to some basic user skill quirks. So far, the feature-set of the Google platform constitutes a superior candidate for a replacement of local desktop apps. But, for many users, the close coupling of local MS Office Applications with Web Apps may provide the 'least pain' path in moving towards the cloud paradigm, e.g. supporting teleworking from home.

The collaborative capability of the two offerings are very hard to compare. The MS check-in / check-out workflow model is easier to adopt and understand through an analogy with the 'track changes' function in regular apps and yet, Google provides real-time editing by multiple users – a more powerful feature; however, in many cases it may take some time to capitalise on these strengths. My experience with Google Wave (same capability) proved that exposing users to tools which are far removed from their familiar ground, introduces hard to overcome barriers and often a sense of dis-empowerment, resulting in a reluctance to learn.

We will see the future before long.

For those interested in the technicalities discussed here Anthony Franco's blog posts “Mass Confusion: The hysteria over Flash, Silverlight, HTML 5, Java FX, and Objective C” and “Mobile Strategy Best Practices“ are well worth a read. Also see mobiThinking article “Mobile applications: native v Web apps – what are the pros and cons?” or these slide presentations (both are on slideshare.net so you can read text outlines instead of flicking slides) on platform specific HTML Apps by Davy Jones "HTML5 is the Future of Mobile, PhoneGap Takes You There Today", Mikko Ohtamaa Building HTML based mobile phone applications and a general Mobile RIA overview by Myles Eftos Smart phone development. A year passed since writing this post and finally I found a programmer's view on this dilemma which is very well expressed in a slide presentation and an article describing a concept of TransMedia Applications by Martin Fowler of ThoughtWorks.