Portfolio: Interactive & Transactional Systems

Rich Media

'Rich media' is a broad phrase, with different meanings to different people. The key idea behind anything that might be called a 'rich medium' or 'rich media' is dynamic motion or noticeable change that occurs on the screen of a website, client-server application or 'client side' (just runs on one computer) application. Hypermedia links are a simple form of rich media...clicking on a link causes a new page or window to display.

Hypermedia links have been around for so long that we don't usually think of them as rich media. Rich media today typically involve interactive presentation files embedded in a web page. These media contain every possible permutation of text, audio, static images and photos, video, visual screen effects and so forth.

By far, the most well-known and commonly used rich media tools today are are:  RealPlayer, Microsoft Media Player, Apple QuickTime, Macromedia Flash/Shockwave and AJAX (stands for asynchronous JavaScript and XML). This portfolio itself makes extensive use of Flash/Shockwave to display videos that actually reside on another video server somewhere, generally one of  YouTube's (YouTube is covered as part of  'Social Media' section of the portfolio.).

All use of rich media embellish a website or interactive application. Only well-designed usage enhances the value of a website or application. Poorly used or gratuitous rich media usage either adds no value or may even detract from a website's or application's perceived and actual value.

Rich Media Usage Demonstrations

Use the video player below to select any of the 6 examples of rich media usage, all from projects in which Don Rickert was significantly involved.

Internationalization-Globalization and Localization

Introduction

While hardly an expert on the deep technological aspects of Internationalization (often referred to as I18N) and the related topic of Localization (L10N), I have been responsible at the executive level for Internationalization/Globalization standards for transactional (financial) applications, as well as a contributor on Internationalization/Globalization issues in many of my consulting engagements.

The Main Issues for Internationalization and Localization of Websites and Web-based Transactional Applications (Summary)

Example: On the right of the screen is a thumbnail of a website that is Internationalized and Localized for German and English. It happens to be the website for a tool (AttrakDiff) that we use extensively for online 'card-sorting' studies related to naming and categorization of website commands into a good navigation structure. (note: Many are surprised that many modern German technical terms are "borrowed" from English)

• Internationalization:

• Internationalization refers to the overarching framework or architecture of an application to support multiple languages, multi-byte characters, different sorting orders and ease of Localization; which is described under Localization below.

• An Internationalization framework includes multi-language, multi-format (date/time/address), and, for eCommerce applications, multi-currency capability. Specifically, we are talking about error, warning and informational messages, labels on screen controls and elements, online help, dates, time/time zones, numbers, currency, phone numbers, personal titles (Mr., Dr., Mrs., etc.) and postal addresses.

• Localization:

• Localization (L10N) is when an entity (group, company, engineer, third party, partner, etc.) converts the current language application to another language.

• An application must be easy to Localize by separating all user viewable messages into one “area.”  Someone who is converting the application from one language to another need only look in one area to convert/translate the messages, as opposed to searching throughout the entire application looking for and hoping they find all the messages/text that could be displayed to a user and, thus, need to be converted.

Critical Internationalization (and Localization) Requirements, by Category

• General

Documentation defining the process to Internationalize / Localize the application is always necessary. 

• Language & locale

• User selectable language within a website or system

This requires that more than one language be supportable by a single instance of the system (rather than running a separate system for each language)

• Ability to switch from one language to another within a session (i.e. “on-the-fly”)

This is only required for certain kinds of websites, but it should be kept in mind as an issue for anyone developing a truly Internationalized site.

• Messages (error, alerts, informational) should be in the language chosen by the user.

A fall back strategy is that messages are displayed in the language of the localized version of the site.

• Formatting/presentation

• Support for the ISO/IEC 10646 Unicode universal character encoding standard used for representation of text for computer processing

• Applies to characters, numerals, special characters, and diacriticals
• Supports left-to-right AND right-to-left AND vertical input and reading
• ‘BIDI’ (Bi-Directional) support:
  
  • Middle Eastern languages such as Hebrew and Arabic are written predominantly right-to-left.
  • Numbers are written with the most significant digit left-most, just as in European or other left-to-right text.
  • So the complete document is bi-directional in nature, a mix of both right-to-left (RTL) and left-to-right (LTR) writing. Text written in the Hebrew and Arabic languages is often referred to a bi-directional, or ‘bidi’ for short.

• Cultural sensitivity to use of color, graphics, and symbols

• Observe that many colors, graphics, symbols, and words that are suitable for the western culture may have different meanings and may even confuse users from other cultures.
  • For example, the red color indicates stop in the US but it might not be the case for other cultures.
  • An envelope graphic may replace the mailbox graphic that is used as indication for "email". The envelope is easier to recognize for users from other cultures than the mailbox.
• Many Western languages are written from left to right, but Arabic and Hebrew are written right to left, and this orientation can affect the interpretation of visual cues and icons. For example, an arrow pointing to the right can mean "continue" in the United States but just the opposite in countries where Arabic is spoken.

• Sensitivity to etiquette, policies, tone, formality and metaphors

An excellent example to illustrate this point is the example of AttrakDiff, used at the beginning of this posting. Great effort was taken by the AttrakDiff team, including extensive ethnography, online surveys, interviews and so forth to ensure that the German was well-translated for English speakers. Literally translated German can seem gruff and overly formal in tone to many  English speakers.

• Support for Arabic lunar calendar

• Currency & exchange rate (for eCommerce applications)

• By default, the system must support all currencies as by ISO 4217 standard.

• Currency should be displayed using common currency codes (e.g. USD, EUR, GBP) or currency symbols (e.g. $,€,£).
• Transactions/monetary amounts should always be stored with a currency attached.
• All screens displaying summary account information will allow for the ability to display amounts in user-selected currencies.
• Monetary values must have a precision of 18,3 digits
• Some countries have multiple interchangeable currencies so we would need to support these. For example, Argentina permits the Peso & the US dollar (1:1), Belize permits the Belize dollar & the US dollar (2:1)

• Many other issues with banking systems…

There are issues such as International identification of banks and accounts, but that is beyond the scope of this summary.

Enterprise Teller System

S1 Teller provides a base set of transactions and core services necessary for fulfilling the rigorous requirements of today’s teller environment, including host communications, sharing and storing of information, cumulative totals, electronic journal, transaction security and approval, and balancing aids.

UX Design Research and Key Insights

Under my leadership of UX at S1, Enterprise Teller received the benefit of extensive ethnographic study of bank branch culture, including many depth interviews of Tellers and bank branch management. A number of banks, in different regions of the U.S. participated in these studies. Enterprise Teller also went through numerous iterations of prototyping, usability testing and design.

The "Master" Insight: The work of a teller requires effective interaction in a work environment that differs significantly from the work performed by users of consumer-oriented financial systems (e.g., web-based Personal Banking).  Some of the key aspects of Teller's unique needs are:

• "Mouseless" and keypad-oriented interaction: Optimized for "mouseless" operation (keyboard-only operation has been shown over time to be optimal for use by tellers in a busy branch environment)
• "Heads-up" operation: Tellers can easily operate without having to look at a screen
• Discrete task-specific screens: Each screen gives Tellers all the information they need for a specific task...densely populated screens are essential rather than a detriment in the world of Teller.
• The system MUST work transparently when off-line: This means that when communication with host computers is "down", the system must continue to work as if nothing is wrong...Tellers cannot tell customers that "the computers are down."
• Efficiency is a critical factor for teller systems: Efficiency is used here both in terms of transaction speed (the time it takes for a teller to get the results of an action he or she takes) and extreme ease of learning (e.g., 'walk up and use' ), which will ensure the shortest end user training effort as possible.
• Consistency with current work practices, such as...
  • Entry of numeric amounts should be "like a calculator" rather than like a web-based application.
  • Compatibility with existing special purpose output devices, such as check printers, etc.
  • No special input devices (e.g., special keyboards)
  • No additional special hardware, such as higher-end computers.

The only part of Enterprise Teller that I can show is the screen shot shown here, as there is no demo available for public viewing (a policy decision of S1).

Click on the image for a larger view.

Customization of Personal Online Banking: Regions Bank

S1 Personal Banking provides self-service capability to customers of banks for basic functionality such as account balance lookup and online bill payment.

The general "look and feel" of S1 Personal Banking can be seen in the standard Balances screen shot shown below:

Click on the image for a larger view.

The names of commands, navigation structure, layout and so forth were refined through many iterations of observation, depth interviews, terminology/categorization studies and usability evaluation (ranging from Expert Reviews to full lab-based Usability Testing with large numbers of participants).

This extensive UX work notwithstanding, many banks want S1's Personal Banking system to be branded according to their own internal standards. For this reason, the ability to customize was built into the technical architecture of most S1 products, including Personal Banking.

One of the first banks to apply a radically different appearance to S1's Personal Banking system was Regions Bank. Their re-design was so good that it was adopted as an example in the official S1 Design Pattern for Navigation. An early version of this customization is shown in the screen shots below:

Click either  image for a larger view.

          

Regions Bank has gone through a total corporate re-branding and they have refreshed their version of S1 Personal Banking accordingly. To get an idea of the current state of Regions Personal Banking, click here.

 

Patterns Approach to Documenting UI Standards and Guidelines

Patterns are formal descriptions of best practices within a given design domain. They capture common solutions to design tensions (usually called "forces" in the pattern literature).

The idea of patterns actually started in the field of architecture (as in physical buildings). The first book (in the 1970s) on patterns and pattern languages (collections of related patterns) was Christopher Alexander's A Pattern Language. The “Alexandrian” format for documenting patterns is still very popular today. Patterns were introduced to the field of commercial software engineering in the mid-1990s by the publication of Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.

In recent years, patterns have taken hold in the field of Human-Computer Interaction (HCI). A very good introduction to UI patterns is Common Ground: A Pattern Language for Human-Computer Interface Design (http://www.mit.edu/~jtidwell/interaction_patterns.html) by Jennifer Tidwell at MIT. There is a growing body of literature on the topic, as well as a number of peer-reviewed UI pattern websites, such as—

• UI Patterns and Techniques (http://time-tripper.com/uipatterns/index.php)
• Interaction Design Patterns (http://www.welie.com/patterns/)

UI design patterns do not separate system behavior from “look”. The traditional approach to “Information Architecture” views visual identity as decoration for functional behaviors. A pattern, on the other hand, describes an entire solution to a task (e.g. choose an account from a list), including the way it should look and feel. A pattern can optionally describe the best way to code the solution (Coding best practices can also be written as separate patterns cross-referenced to the behavioral and/or visual appearance patterns.). In other words, UI architecture standards and style guide can ultimately be combined in the same document in an easy to understand format.

Patterns:

• Are observed through either formal user research or experience.
• Are typically written in a structured format
• Are reusable artifacts (i.e. prevent “reinventing the wheel”).
• Exist at different levels of abstraction (e.g., structural patterns vs. behavioral patterns).
• Undergo continuous improvement.
• Communicate design and best practices.
• Can be used together to solve a larger problem.