Recently I read a discussion highlighted by Herb Sutter on his weblog, Sutter’s Mill. Herb is a well-known and respected leader in development and C++. In his article, he covered many of the misconceptions that seem to exist around user interfaces for Internet-based applications. The question is: Are developers and product managers thinking too rigidly when they approach a SaaS application? Do “Web 2.0″ and Rich Internet Applications (RIA) have value in SaaS and On-Demand applications?
To answer this question, you need a sense of the context. There is a school of thought that basically says user expectations and learned usage patters should dictate the approach. For designers with this basic belief, a desktop application has a particular “look and feel” and users have set of learned behaviors that should be exploited. More than that, a Mac application should adhere strongly to Mac interface standards and a Windows application should adhere to Windows standards. The same school of thinking recognizes HTML, CSS and REST as the classic approach to web-based applications and the browser as the common user agent. For this school of thinking, developing applications that do not respect these built-in user expectations as de facto standards is at least risking user confusion and probably creating something that will lower acceptance and raise the time it takes users to achieve full productivity.
There is a second school of thought however, that comes from using languages and technologies that are not bound by the classic paradigm of “the page” as classic HTML approaches it. These same approaches tend to flatten platform issues by existing outside of the strict interpretation of a browser interface or a vendor-led interface standard. This school generally includes developers using JAVA, Flash, Flex, Silverlight, Python, AJAX and similar interpreted languages and environments. These technologies can live in a browser-based paradigm very well, but the point is – they don’t have to. They can exist on the web or off. They can provide a local client interface for a remote data source and/or a local one. They can be the whole application with parts local and remote. They can develop their own user experience and keep it across versions implemented in many different configuration.
For members of the first school – a web-based application that is not bound by a page-based interpretation is wrong. If it is based in Flash or Silverlight and does not have ways for users to share views of information contextually (the URL links we pass back and forth on the Web), ways to highlight, copy and paste information in the page context into other applications without resorting to workarounds, it is crippled. If it cannot resize text and adapt to different platforms (like a desktop and a mobile device) without multiple code bases – it is wasting resources and probably risking code forks that will create user islands.
For the second school, the page-based paradigm simply doesn’t need to exist in every application. What’s more – they question why the entire data view shown to the user should have to be updated to represent the change of only a few items in the user’s view? And, who should decide when the data is updated? If the application has an updated bit of data, why should it wait until a page is requested or refreshed to show it? We’ve seen more of this philosophy since the advent of AJAX, but in the JAVA and Flash worlds, data concurrency has never been bound by a page-based representation – inside or out of a browser. While to some this seems more like desktop application behavior – it is in truth available to any application with the right tools.
In many ways – SaaS applications represent the “third school.” The technology is new – or at least considered to be new by most people. There is no “established user paradigm” and I don’t believe we should be in a rush to build one. By its nature, a SaaS application is not bound by desktop or the Internet. The user experience needs to be completely contextual and it can be. Where it misses the mark – when workarounds and new interaction patterns are required – innovation is needed and developers either need to step up and make it happen or advocate for others to take on the challenge. There are SaaS apps which are not intended to be used much of a users day or even every day. Those are probably better left to more classic web methods where possible. There are others that users will be on for most of the day or will greatly enhance user productivity. For those there are strong opportunities for new thinking and re-engineering.
Consider: Real time updates (push instead of the classic user pull of page refresh) are more efficient when they leverage an interface that doesn’t require a full page refresh. If the user can depend on the application to update the data view when it is relevant they are freed from the impatient – “is it done yet?” – syndrome or worse – a double submit during a transaction.
If it makes sense to build a client outside of the browser (again, how much time will the user spend with the application?) there are some additional bonuses. The application is freed from the browser update cycle and needing to render correctly in several browsers on multiple platforms. Updates to the client can happen transparently – if planned correctly. The client can be locally resident in a way that allows it to integrate with local and network applications inside the firewall. In some cases, it may be necessary to use the client when network connectivity is non-existent or slow. The client can be designed to work with the remote data set in a loosely-coupled way that allows updates when the network is available.
Finally – Designers should be challenged to re-engineer the user experience and process without considering the constraints of the browser or if a browser is the best choice, to blend the page-bound paradigm with useful tools from their tool kit. And there are cases, such as when the SaaS application is an online presence of a regular desktop application like Microsoft Outlook for instance, that you don’t want to change the desktop process and learned behaviors with the web version if users will continue to use both. In this case, current technologies and user skills can be leveraged to duplicate the desktop application and user experience very closely. It is important in these situations to develop the application for browsers agnostically. Saying “we support browser XYZ and so should you” – is just short sighted. The development time saved will never pay for the lost users in a SaaS application – where customer retention really counts. For SaaS ISVs, developing the “target user experience” up front should be as much a part of the design process as deciding on the stack – and in fact must proceed the stack in importance if the application is to realize its potential.
Useful? Copy, paste and Tweet it!
RIA and SaaS – Opportunity or Hype? http://bit.ly/10Cdy
Recent Comments