RIA Blog Posts

Undoubtedly you have heard about the great RIA war raging between Apple and Adobe. Apple claims that HTML5 is all you need for web applications and Flash has no future. Adobe shoots back that Flash is the best choice today and claims (not entirely convincingly) that it will remain relevant 5-10 years from now. So how do we make sense of this brouhaha as it relates to our own work designing SaaS and Rich Internet Applications for the Enterprise?

The enterprise desktop of 2010 relies on non-HTML5 desktop browsers

Regardless of what the future will hold, the reality is that in 2010, there is an enormous installed base of IE 6, IE 7, and IE 8 on the desktop - particularly in the Enterprise (with governments typically frozen on IE6!).

Consequently, for Rich Internet Application design work intended for Enterprise desktop web browsers, it is a non-starter to design solutions that don't run on IE7 at the very least. For this RIA market, HTML5-related technologies (see below) are simply not yet viable.

RIAs designed with Flex for the desktop user

For Enterprise web and SaaS applications, by far the majority of RIA work that we do is in Flex (Adobe's RIA platform based on Flash). It is predictable, has a good development environment, is scalable, and provides good performance.

What about Silverlight?

I should also note that we do a growing amount of work in Silverlight 4, particularly for desktop/surfaces/large display multi-touch and gesture applications.

RIAs on the mobile devices of 2010 = HTML5

But when it comes to mobile devices, it is a completely different story. On mobile devices over 90% of the smartphone and tablet market in the US (Apple, Android, WebOS, Rim soon) use the HTML5-savvy WebKit framework for the browser. Consequently our RIA and UI design work for mobile (smartphones and tablets) is increasingly HTML5 and associated technologies.

Key Features of HTML5 and associated technologies

For those who are interested, I just want to quickly note some of the most compelling aspects of HTML5 and the collection of technologies that almost always go with it (Note: I'm not breaking out which are core HTML5 vs associated tech). This list is not at all complete - it just references some of the things I think have intuitive appeal to both technical and non-technical audiences.

• Semantic Tags - for more meaningful markup that is great for search, accessibility and coders
• Audio and Video Tags - for plug-in-less audio and video with native controls
• 2D Canvas and Animations - for rich dynamic Flash-like graphics, animations and effects
• Geolocation/Location Awareness - makes the mobile device's geographic location available to a web application
• Offline Application Caching - cache an entire Web application for offline use so mobile users can access and interact with a Web app even outside of a coverage area
• Web Storage - allows information to pass between pages in a session or even across sessions
• Web Workers - enable developers to parallelize web application tasks for multi-core processors (mutli-core are not yet the standard for mobile devices but probably will be within a year or so)

Android, iPad, iPhone and Beyond

As a rule, Catalyst is technology agnostic. We design applications and UI for our clients using the technology that is optimal for their market and that is manageable by the organization's development team. For web applications intended for desktop users in 2010, this typically means Java, Flex or Silverlight. For applications and web applications intended for mobile users on the iPhone, iPad, Android devices, WebOS, and soon Rim and Nokia, this typically means HTML5 ( with fallback content adaptation for other mobile devices).

I recently attended an event on social media and application design. I got into a conversation with another attendee and asked him what he did for a living.  He paused and then answered “I help good companies let others know how good they really are”.

It was an odd answer, so I asked more:  “How do you do that?”. He then went on to explain how he developed web sites, wrote content, optimized SEO, and did the whole social media thing.  It sounded like all of the mechanical things that so many other consultants and agencies say they do. But his initial description intrigued me because his description gave me his purpose for what he did, the ‘why’ rather than the ‘what and how’.

It started me thinking about Catalyst Resources and the way that we describe what we do.  Sure we design Rich Internet Applications and efficient, aesthetic interfaces. We even refine this further by specifying our focus on mission critical applications and modular, reusable UI.  But this ‘what and how’ is not the motivator that actually makes us wake up every morning and go to work.  It is not the ‘why’ we do what we do.  It is not the essence of our DNA as a company.

Why we do what we do at Catalyst Resources is because we believe that we can fundamentally improve the efficiency and the “pleasurability” of any business activity.  The ‘what and how’ is by optimizing business processes, streamlining workflows, creating user-validated, high-performance, modular user interfaces and designing beautiful, intuitive and streamlined Rich Internet Applications.

When I am brought in on a new project I don’t immediately start thinking about what I am going to do from a UI or an application design perspective.  I think “what does this company need in order to be more successful”.  Coming up with this takes a lot more work and a lot more creativity then coming up with a well-designed set of UI elements.  But it is this goal that is the real inspiration behind every project that Catalyst undertakes.

Maybe we need to come up with a tag line: Catalyst Resources - we make the world better, one application at a time.  Kind of has a nice ring.

I often talk about how mission critical applications have unique requirements when it comes to RIA and user experience design. Broadly speaking mission critical applications require a combination high-performance, at-a-glance clarity, security, redundancy, scheduling, reporting and scalability.

I was explaining these characteristics to a client looking for an RIA front-end design for their green energy production system. I found that the easiest way to explain some of the real-time design requirements was to give examples from our own client work. I thought I would share a few of these from that conversation.

Example requirements for mission critical UI and application design

Scheduling - Trading systems
With most application, when you make a change to a preference of function, you save the change and the change is applied then and there. With international trading systems affecting large $$ trades/data, you need to be able to make changes and then precisely define triggers or schedule when these changes are applied.

Reporting and Tracking - Financial transaction processing
With mission critical applications there often needs to be an audit trail for changes to data, system settings and transactions. For example when changes are made to the interest rate on credit card there needs to be a non-alterable record that tracks who did it, when, and why.

Clear Conceptual Models - Flight planning
Complex or mission critical systems needs to designed it so that the user knows exactly what they're interacting with. In flight planning, the FAA uses a very particular type of document which is drilled into to every pilot or controller. The RIA interface for a flight planning application had to be modeled tightly around this existing model so it was immediately interpretable.

At-a-Glance Clarity - Telecommunications processing
Imagine a system with 200,000,000 transactions a day. The visualization and reporting system needs to be designed to represent mass volumes of things happening with automatic callouts and quick ways to drill down.

Privacy and Security - Medical diagnostic collaboration
While security is vital in every enterprise, security in medical records is a hot button item right now. Web-based medical records and collaboration applications need to have clear options to define roles, access levels, recurring re-validation requirements, and multiple layers of protection.

Redundancy and Validation - Emergency notification
For most web applications, it is standard to have simple error checking for things like entering an invalid email address. But advanced validation and redundancy become vital in mission critical applications. For emergency notification systems that trigger emergency first responders and can impact the physical well-being of many individuals, any alert messages need to have built in redundancy (i.e. you can't accidentally send out a notification without confirmation) and geospatial validation (you can't inadvertently send out a notice to residents in San Francisco about a threat occurring in Seattle).

Scalability - Insurance M&A
Scalability is desirable for any enterprise where there is an expectation for growth and change. But this was critical for an insurance carrier that grew rapidly due to acquisitions. The user base was to expand several orders of magnitude in the course of a very short time and the application would need to scale to accommodate the increased demands without requiring rework.

High Performance - Fuel management
Real-time reporting and high performance applies to virtually all mission critical applications. But when I was discussing this with the green energy company, rather than discussing our work in financial systems (i.e. where it is easy to see how even seconds of delay can translate to millions of dollars in impct), I instead referenced real-time remote monitoring, management and incident reporting of critical fuel supplies - such as in power plants, backup power systems, emergency fleets vehicles. As inventory drops or there is a change in the status of a critical fuel system, many actions need to quickly and automatically come into play to avert catastrophic failures.

Designing RIAs that address these mission critical requirements is not simple. In addition to the technical demands, it requires extensive user validation and testing as well as an understanding of the inner workings and organizational structures of large enterprises. Needless to say, it makes for very interesting and challenging work.

I just noticed that the Velocity Online Conference is coming up next week. This conference is focused on best practices in performance and operations for web applications to improve the user experience as well as a company's bottom line.

I've written previously about the importance of perceived performance in the design of a SaaS application. For SaaS, where customers can easily switch to another provider, user satisfaction is critically important. Low perceived performance can lead to low satisfaction and high customer churn. High perceived performance can result in high customer satisfaction and stability.

But what is the empirical evidence and how much of a change in perceived performance is necessary to have a significant impact? Well I just came across some hard data - metrics for page views, amount of interaction/use and online revenue presented at Velocity 2009 from some data-heavy players.

The empirical data on the impact of web application performance

Microsoft reported that with Bing, a 2 second slowdown in response time reduced the number of searches by 1.8% and reduced revenue/user by 4.3%. That a lot of money left on the table.

Google reported that as little as a 400 millisecond delay resulted in 0.59% fewer searches per user. But perhaps more interesting, even after the delay was removed, these users still had 0.21% fewer searches, indicating that a slower user experience affected long term behavior. While Google did not report revenue directly, fewer searches likely means fewer AdWord clicks.

Shopzilla had the most complete data on the impact of performance on the bottom line. A year-long performance redesign reduced response times by 5 seconds (from ~7 seconds to ~2 seconds). This resulted in a 7-12% increase in revenue.

But it's really perceived performance that matters

This empirical "bottom line" data becomes even more interesting when it is reviewed in the context of the study 'The Truth About Download Times. This study found that users do not rate the download speeds of Web pages based on the actual stopwatch-clocked download speeds. Perceived speed is dependent on how well "users successfully complete their tasks on a site."

In other words, it's not just page load time that matters. It is the time it takes for a user to successfully complete a task that has the real impact. In the case of the Velocity 2009 data, users couldn't interact with a page until it loaded. Those few milliseconds of additional time, prevented users from accomplishing their search tasks. That signficantly impacted the bottom line.

Designing RIAs for perceived performance

So how do you design a SaaS to enable the user to perform real work more productively - to feel fast, responsive and streamlined. Our RIA designers focus on a number of application flow and design areas.

• Determine the high value scenarios and then reduce the number of actions required to accomplish them
• Minimize the need for complete page refreshes and reloads - the waiting between screens creates serious friction with the user
• Incrementally add information and functionality to a page, based on an analysis of how users process the information (e.g. load a modular component only when needed or in the background based on predictive analysis)
• Progressively download data locally to avoid round-tripping to the database (HTML 5 is a great development here)
• Validate designs (visual, information, interaction and architectural) to determine where users perceive adequate performance vs. where they get slowed down and wait for the web application to catch up
• Enable queries or actions to be canceled - it gives the user a feeling of control and lets them move on to something else they consider more important than waiting
• Add reliable indicators of progress on activities (i.e. don't let users get frustrated in front of a screen not knowing how long something will take)

RIAs are about more than features, graphics and nice visuals. Optimizing perceived and actual performance has a real and quantifiable impact on the bottom line. The more productive an RIA/SaaS design, the more users interact with software.

Clients often ask which Rich Internet Application development tool they should choose - Flex, Silverlight, or an AJAX framework. Excitement over HTML 5 has been stirring up this question in the RIA community even more than usual.

At Catalyst we're in the business of delivering very sophisticated, responsive, interactive and graphically rich applications over the web, not pushing specific technologies. Sometimes Flex is a better option and sometimes AJAX is the better option and other times Silverlight or JavaFX is better. It all depends on the requirements, the team, and the application.

Each of these technologies have the same goal: enable delivery of a rich UI and immersive experiences with the interactivity and user engagement similar to desktop applications, but adding in the availability and interconnectivity of the web.

There are no hard and fast rules for selecting one technology over the other, however there are some rules of thumb.

AJAX - use for incremental, tactical improvements, SEO-friendliness, customizable footprint

If you are updating an existing application and want to implement rich functionality incrementally, with small, frequent updates then AJAX is a good choice. Or if you need to meet specific application footprints and performance requirements (e.g. fast initial page load time) AJAX development frameworks (e.g. jQuery, EXT JS) can be customized and tuned. Importantly you can also use Flash to fill in the gaps where you need richer behaviors, than are easy to create with AJAX (e.g. video players or real-timestock tickers).

Of course HTML 5 (supported in FireFox, Safari, Chrome and IE 8) will add to the allure of AJAX/HTML bringing local storage, multithreading, real-time data sharing, form validation, and more (e.g. 2D and 3D drawing).

See examples of our work in AJAX for Digital Advertising and Teleconferencing.

Flex - use for large-scale, more comprehensive user productivity applications

Like AJAX, Flex also can be used for gradual re-factoring of existing web applications via widgets, but the argument for Flex becomes particularly strong when an application is built from scratch, or has a high level of complexity and data processing. You get better performance (i.e. data sorting, search, display) and easier code maintainability. Also for large applications there is a definite plus with Flex in that you can avoid the necessity for testing and tweaking across browsers and OSs.

See examples of our work in Flex for Real Time Analytics and Media Advertising.

Silverlight - use if you are a .Net shop

Silverlight has many of the same arguments as Flex, except that it is geared for the community of .Net developers and offers seamless integration to .Net tools and components. Enterprises that work in .Net will find it easier to integrate interfaces and application designs created in Silverlight.

See examples of our work in WPF and SIlverlight for Financial Systems and Issue & Support Tracking.

So which technology do we choose?

We are agnostic about RIA technologies. Our developers are facile in all of the relevant options. So the general rule for us is to identify what problems our client needs to solve and then select the appropriate RIA technology. No one technology is inherently better than another. For each applications we look at the requirements for performance, interactivity, security, maintainability, scalability and in-house expertise, and then give our clients a recommendation as to the best technology or combination of technologies.

User experience designers all agree on the importance of user interface simplicity, consistency, and performance as keys to successful application design. This is particularly relevant for enterprise SaaS and RIA applications where expectations for "use without training" have been set high by consumer SaaS applications.

But one often overlooked attribute of good user experience design is perceived control. This is surprising because in many ways, a user's feeling of being in control is what defines their perception of simplicity, consistency, performance and even innovation.

Perceived control is a fundamental concept but rarely discussed and even more rarely do I see it implemented as a specific goal in SaaS application design. The basic idea is simple: the more a user feels in control of their software environment, the more satisfied they feel and the more likely they will become loyal repeat users. On the flip side, the more a user feels that they cannot control the software (because of a poorly designed or poorly validated UI), the more likely they will blame it on a "bad" application and seek alternatives.

Predictability, Simplicity, Performance, & Innovation

Designing for consistency is in large part just a way of creating predictability. Predictability is about controlling your environment. The user knows what will happen when they do something - even for the first time. It gives them a feeling of mastery and control, which is critically important to product use and loyalty.

Designing for simplicity is similarly about designing for control. Software feels simple, intuitive and easy to use when it matches a users conceptual model of the world.

Perceived performance is how responsive the computer feels to your actions. When an application forces you to wait for it to catch up (e.g. a spinning clock), you feel like you no longer have immediate control over the application and your environment. Low perceived performance can lead to low satisfaction and high customer churn, High perceived performance makes you feel in control and will result in high customer satisfaction and stability.

Innovation in UI is often in the form of discovering how to increase perceived control. Truly innovative software makes previously difficult tasks, easier to manage and complete.

Examples of applications/products that offer little perceived control: a Comcast digital remote control, Microsoft Word.
Examples of applications/products that offer high perceived control: the iPhone, Google search, many video games.

Design for Perceived Control from the Start

Levels of perceived control of course change as users gain experience with an application. But with SaaS, where it is easy for users to switch to a different service, a UI that creates the perception of control, right from the start, can reduce churn and keep customers coming back month after month.

At Catalyst we spend much of our initial design sprint developing and validating the right conceptual models that make software feel simple. We use RIAs in a way that we can optimize perceived performance. And as a company, we are uniquely focused on designing modular reusable UI which deliver consistency (as well as cutting development costs!). We recognize that perceived control is an essentail factor in user experience design and we regularly assess it in usability and user validation testing, quickly iterating to correct perceived "lack of control".

I've written a great deal about the intricacies of designing the user experience for an enterprise RIA or SaaS. These applications typically need to handle very large data sets, scale to service thousands of users, and address complex business logic that encompasses many functional elements and scores to hundreds of screens.

While many organizations attempt to develop their SaaS or RIA using their internal IT department, perhaps assisted by a web design or Flash creative firm, the end result will "feel" like it was built by an IT department. It may be functional, may even be visually pleasing, but it will not identify high value tasks, streamline business processes, increase user productivity, build the brand or drive adoption & use. To achieve this level of business value you need a UI engineering team of experts, each with a different focus, distinct skills and tight accountability.

Multi-disciplinary teams

Based on our experience designing over 270 pieces of software, the most successful projects follow a well-formulated process using a small, highly experienced, multi-disciplinary team comprised of an experience architect, experience designer and experience developer. This collaborative team then works with an organization's IT department to smoothly integrate the design with existing infrastructures and back-end systems.

Each of these primary team members needs to be facile in several different domains and take on different roles at different points in the project timeline. Below are brief explanations of some of these roles.

User Experience Architect

• Functional requirements definition - work with the product's stakeholder to define an initial set of key functionalities based on business drivers and value proposition
• User studies & ethnography - observe the actual users and usage environments in order to  refine functional requirements and document the actual user scenarios that will drive the User experience design
• Personas - create personas from the information collected during ethnographic studies. These represent typical users and help the design team keep a clear imagine for whom they are designing
• User validation - involve real users throughout the design process to enable testing the coherence of early mockups and ensure potential usability issues are identified early on
• Business process design - look for ways to organize complex business processes into simple logical structures that can be easily communicated
• UI architecture - design consistent behaviors that apply to the User Interface throughout the application. This enable the user to quickly understand, use and predict how the application will behave
• Conceptual models - define conceptual models that help users to naturally comprehend what they are trying to accomplish with the software, the kind of data they are manipulating, how the data is organized and their goals for interaction

User Experience Designer

• Information design - synthesize user requirements into interaction use cases that define a product's usage from a user's perspective
• User interface design - begin with fast, low-fidelity prototypes and iteratively develop into interactive, high-fidelity prototypes, incorporating feedback from user validations throughout to identify how "intuitive" the application is and the value it provides from extended use
• Interaction design - optimize and test navigation, control elements and messaging for user comprehension and efficient and effective use
• Branding and visual design - define the colors, graphics, fonts, motion, polish and fluidity that create the brand experience, always testing with users
• Documentation - provide screen functionality specifications  and visual design style guide

User Experience Developer

• Code clickable models - provide a full clickable model using dynamic data of exactly what that software will be like when it is released
• Presentation layer architecture - map out and validate proposed UI architecture so it is consistent with technical architecture, before writing any code
• Client side technologies - select and implement the UI using the optimal RIA for the users and IT infrastructure (e.g. AJAX, Flex, AIR, Silverlight, Java). Re-factor UI designs into a customized library of UI components, data, and actions
• Server-side technologies - translate what is going on in the back-end systems to communicate with the front-end user UI, requiring fluency in multiple languages and Web services
• Data and business logic implementation - rapidly iterate designs and systematically incorporate feedback to expose and validate that all data elements and UI components are matched to the database schema

Designing user experience for enterprise RIAs and SaaS is complex - no doubt about it. But compromises to the user experience will have a fundamental negative impact on the success of any application, so it is not something you can ignore or marginalize. To maximize business value, you should look for a multi-disciplinary team with diverse skills and tactical experience to design the application and augment the technical development work of your internal IT group.