Showing posts with label Usability. Show all posts
Showing posts with label Usability. Show all posts

Tuesday, December 08, 2015

Ruminating on the UX Design Process

Centerline has published a neat infographic illustrating the UX design process. While there are a  lot of UX related infographics on the net, I liked the simplicity and clear thought process of this one :)

When we create compelling user experiences for our customers, we follow a similar process.

  1. Gain a deeper understanding of the customer and the industry segment the customer operates in. Who are their end-customers? What is the market positioning of their product? 
  2. Based on customer segmentation, create personas and user journey maps. 
  3. Create a high level information architecture
  4. Create low fidelity prototypes (mockups) using Visio, PowerPoint, etc.
  5. After review, create high fidelity dynamic prototypes using tools such as iRise, Axure, etc. Work with Visual/Graphic Designers during this phase. 
  6. Once the application is developed, do a usability test using tools such as TechSmith Morae. Create a feedback loop for UX changes that gets incorporated in the next agile release. 
  7. Make sure that your UX team and Web/Mobile Analytics teams are working in tandem to resolve all UX concerns and improve the customer experience. 



Tuesday, June 16, 2015

Ruminating on Section 508 Accessibility standards

In the UX world, you would often come across the phrases such as "compliance with Section 508". So what exactly is Section 508 and how does it relate to User Experience?

"Section 508" is actually an amendment to the Workforce Rehabilitation Act of 1973 and was signed into a law in 1998. This law mandates that all IT assets developed by or purchased by the Federal Agencies be accessible by people with disabilities. The law has stated web guidelines that should be followed while designing and developing websites.

It is important to note that Section 508 does not directly apply to private sector web sites or to public sites which are not U.S. Federal agency sites. But there are other forces at play, that may force a organization to make their websites accessible. The ADA (Americans with Disabilities Act) that was passed way back in 1990 prohibits any organization to discriminate on the basis of disability.
The following link reveals examples of law suites filed for violation of ADA - http://www.law360.com/articles/513033/doj-focuses-on-ada-compliance-in-the-digital-age

Beyond the legal regulations, there are also open initiatives aimed at improving the accessibility of websites. W3C has an initiative named "Web Accessibility Initiative (WAI)" that lays down standards and guidelines for accessibility. There is also a standard for content authoring called - "Web Content Accessibility Guidelines (WCAG)".

The following sites provide good reading material on Accessibility -


Jotting down the high level guidelines that should be followed for accessibility.

  1. A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).
  2. Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation. For e.g.  synchronized captions.
  3. Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup. Color is not used solely to convey important information. Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. 
  4. Documents shall be organized so they are readable without requiring an associated style sheet. If style-sheets are turned off, the document should still be readable. 
  5. Client-side image maps are used instead of server-side image maps. Appropriate alternative text is provided for the image as well as each hot spot area.
  6. Data tables have column and/or row headers appropriately identified (using the element).
  7. Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz. No element on the page flashes at a rate of 2 to 55 cycles per second, thus reducing the risk of optically-induced seizures.
  8. When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
  9. When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

Wednesday, January 29, 2014

A/B testing vs. Multivariate testing

The following articles give us a good overview of the differences between A/B testing and multivariate testing.

http://visualwebsiteoptimizer.com/split-testing-blog/difference-ab-testing-multivariate-testing/
http://searchengineland.com/landing-page-testing-choosing-between-ab-or-multivariate-approaches-27195

Snippets from the articles:

A/B testing consists of creating alternative pages for a specific page and showing each of them to a certain percentage of visitors. For example, if you create 4 different variations of a landing page, 20% of visitors to the website will see each version (4 variations + original). Cookies are used to maintain a consistent user experience—if a visitor sees one version, they will see it again and again when visiting the website as long as the cookies are not deleted.

Rather than testing different versions of web pages, as we do with A/B tests, Multivariate tests experiment with elements inside one specific page. Basically, we define elements inside a page (e.g. a picture, a text or a button) and provide different alternatives of each element. The testing tool will show each element combined with all other elements to visitors. The resulting combinations are derived from the number of elements multiplied by the number of element variations. Just as with A/B testing, however, each visitor sees only one particular combination of elements regardless of how many times they view a page. 

Hence A/B testing is best for testing radically different ideas for conversion rate optimization. Multivariate testing is more granular and is best for optimizing and refining an existing landing page or homepage without doing significant investment in redesign. 

Tuesday, January 28, 2014

Ruminating on Information Architecture

Information Architecture is both an art and science of organizing and structuring your content in such a way that it is very intuitive for the end-user to navigate. As such, Information Architecture is a subset of the User Experience Design field.

The output of Information Architecture is typically a set of wire-frames that depicts that design. It may also define a taxonomy to classify information (e.g. content, products), using a tree-structure hierarchy.
Other outputs for IA include site maps, annotated page layouts, page templates, personas, storyboards.

To put it in other words, IA answers the following questions:
  • How do you categorize and structure information?
  • How do you label information? e.g.  'Contact Us' label would hold all details on contact info.
  • How users navigate through information?
  • How users search for information?
And content cannot be structured in isolation, but depends on the 'users' and 'context', as depicted in this Venn diagram in the famous book by Rosenfeld and Morville.


Jotting down a few links on IA that are worth a perusal.

http://www.theguardian.com/help/insideguardian/2010/feb/02/what-is-information-architecture
http://boxesandarrows.com/category/design-principles/
http://docstore.mik.ua/orelly/web2/infoarch/index.htm
http://www.steptwo.com.au/papers/kmc_whatisinfoarch

Friday, November 02, 2012

UI Framework Classification

Today there are a plethora of frameworks and technologies available for create RIAs. Our customers often ask us to advice them on the best fit technology framework for their needs.

To help our customers, we have classified UI frameworks into the following broad categories:

1. Action based frameworks: These frameworks rely on the HTTP request-response paradigm and are designed around it. Many popular frameworks such as Struts, Spring MVC, ASP.NET MVC belong to this category. These frameworks typically implement the MVC design pattern and are light-weight in nature. They also have a easy learning curve for developers familiar with HTTP semantics.

2. Server Side UI component frameworks: These frameworks abstract away the HTTP protocol semantics and allow developers to work with UI components. The developer drags-n-drops UI controls on the page and writes event handling code for the components. Thus the paradigm is similar to thick client programming (e.g. VB, Power Builder). The most popular server side UI frameworks are JSF based open source projects such as ICEFaces, PrimeFaces, etc. Also classic ASP.NET is server side component based. These frameworks emit JavaScript and AJAX code during the rendering process.

3. Client Side UI component frameworks: In this category, the entire client is downloaded into the browser during the first request and then-after communication with the server is through AJAX requests. Either JSON or XML is the preferred data format for the payload. Examples of these frameworks are Flex/Flash, Ext-JS, MS Silverlight, etc.

Monday, August 13, 2012

Ruminating on JSF

In the past, I always hated JSF, the same way I hated EJB 2.x. But of-late, I am seeing a renewed interest in JSF, especially since a lot of pain areas were resolved in the JSF 2.0 specification.

Over the last couple of days, I have been evaluating PrimeFaces - an opensource implementation of JSF 2.0 and I would say that I am pretty impressed. Going through the sample demo pages, I was mighty pleased with the neat and clean code on both the XHTML file and the POJO beans Java code.

Also PrimeFaces has a plethora of components that should suffice for 90-95% of all basic web application requirements.

In general, if you do not require heavy UI customization and can hence sacrifice absolute control over the generated HTML, CSS and JS, then I would say that using PrimeFaces would greatly increase the productivity of an average development team. IMHO, the productivity gain could be as high as 50% over doing the conventional plumbing using MVC frameworks and JQuery.

But if there is a special requirement that cannot be sufficed by the standard UI components provided by PrimeFaces, then you are in trouble. You would then need deeper expertise to write your own JSF component or customize existing ones.

Based on my study and the common challenges we faced, I am jotting down some FAQ's that should be useful for folks embarking on using PrimeFaces.

Q) How to manipulate JSF components on the client side using plain JS or JQuery? How to use JQuery JS API or any other JS library on the client side with JSF?

Q) How to include JS file or inline JS code in a JSF XHTML page?
A) There are 3 ways to handle this.
  • Escape all special chars like 'greater than' or 'lesser than'
  • Use <![CDATA[ ... ]]> to hold your JavaScript code
  • Put the JavaScript code in a separate .js file, and use in the JSF page  
http://www.mkyong.com/jsf2/how-to-include-javascript-file-in-jsf/
Q) How do I output HTML text in JSF? Do I need to use the 'verbatim' tag?
A) <h:outputtext escape="false" value="#{daBean.markedUpString}"></h:outputtext>

Q) Can I mix HTML tags with JSF tags?
A) You can. It is not as much as a pain as in JSF 1.x, but you need to be aware of issues.
http://stackoverflow.com/questions/5474178/jsf-facelets-why-is-it-not-a-good-idea-to-mix-jsf-facelets-with-html-tags

Tuesday, July 10, 2012

UIaaS - UI as a Service

Some time back, Salesforce popularized the term - UIaaS (UI as a Service), when they launched VisualForce.

UIaaS essentially means the ability to create new user interfaces using pre-built components. UI components could be pages, controls, static resources, etc. So the concept is to not start from scratch, but use off-the-shelf UI widgets. Typically UI designers are web-based and allow for in-browser UI design.

The underlying technologies for creating UIaaS are –
Server Side: JSF, Portlets, .NET WebParts
Client Side: Dojo controls, JQuery controls, Ext-JS controls, etc.

IMHO, the term is just old wine in new bottle. We used to have concepts of UI Widget Factory that encompasses creating reusable widgets and storing them (with meta-data) in a repository. Application developers would then pick and choose their widgets and design new pages. The reusable widgets could be technical widgets such as a "tab-bar","menu-bar","calendar", etc. or business widgets such as "Healthcare Provider Search", "Google Maps Overlay", etc.

Friday, April 20, 2012

JavaScript coding guidelines

With RIA applications becoming the norm, developers have to deal with a lot of JavaScript code. It is important to have proper coding conventions for JS too. Was glad to see a good document posted by Google on JavaScript coding conventions.

http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml

Also, there are tools available to check the code quality of JavaScript code. Here are a few examples available:

http://docs.codehaus.org/display/SONAR/JavaScript+Plugin

http://jslint.com/


 

Monday, March 26, 2012

Techniques for website design on all devices

Today, there is a growing demand to create websites that can render across multiple devices such as desktop browsers, tables and smart phones. New standards such as HTML5 help in this regard.

But it's important to apply proper design principles when we develop web pages that can reder across a wide array of devices. Found this cool article that describes a few techniques that can be used. The author of this blog 'Ethan Marcotte' has also written a book on this called "Responsive Web Design".

The core philosophy is how can we use CSS3/HTML5 to enable our application to detect the capabilities (size, resolution, JS support, etc.) of the browser and adapt the layout of the page accordingly.