 | |
|
|
|
A look and feel design represents the visual appearance and behavior of a graphical user interface (GUI) component set. The "look" is based on the visual design characteristics shared with the GUI component set. The "feel" is based on the input mechanisms that the GUI component set provides for the user to interact. Look and feel designs vary according to the needs of the underlying product and the target user. Forcing consistency across radically different products results in unusable products.
This document focuses on the Touchable look and feel, a specific look and feel designed for touch screen based consumer products, including retail kiosks, personal digital assistants (PDAs), and screen phones. The main objectives of the Touchable look and feel are twofold: (1) to provide developers with a good starting point for a touch screen based consumer product look and feel, and (2) to provide a look and feel that is usable for consumers.
This document discusses the advantages of using the Touchable look and feel on touch screen based consumer products. The first section focuses on the experience and expectations of the target user. The next section details the nature of the target products and how these products differ significantly from traditional desktop computers. The final section describes some of the design approaches and extensive usability evaluations conducted in producing the Touchable look and feel, along with some of the lessons learned from the process.
For a more detailed discussion on designing human interfaces for consumer products, refer to the forthcoming Consumer Products User Experience Style Guide.
|
When developing a product, it is important to keep in mind both the experience and expectations of the target user. The target user for the Touchable look and feel is the consumer. Consumers include people without any experience with personal computers. These users probably have experience with consumer electronics devices and they expect software-enabled consumer electronics devices to operate and behave consistently with their solid-state predecessors. Even people with computer experience have very different expectations when dealing with a consumer product than they do when dealing with a computer at work.
Statistics for the United States show that around 50-60% of households do not have a personal computer. The number of households with a personal computer is rising, but it will be a number of years before most households have a personal computer. Interestingly, the number of households with personal computers has remained fairly stable for the last few years. The belief is that it is more likely that consumer products, such as screen phones or internet-enhanced televisions, will appear in the remaining households before a personal computer does.
Of those consumers who do have a personal computer at home, the applications used most frequently are word processors and personal finance applications (e.g., Quicken). In addition, compared to business or enterprise computer users, consumers typically performless complex tasks on the computer, use the computer less hours per day, and know fewer applications well.
While it is true that children are being increasingly exposed to personal computers in school, this does not always translate to the same kind of computer applications or tasks as used by business or enterprise users. Many schools employ software designed specifically for children, which is less complex than typical productivity applications.
The implications of these characteristics are many. It can be assumed that most consumers have used a telephone, the younger ones may have used a game machine like a Nintendo or Playstation, and most have watched television, used a remote control, and probably used a VCR. Some consumers may even have programmed a VCR, though this is more common in the younger part of the population. These users have also used control panels on microwaves, answering machines, and stereos.
Not surprisingly, consumers who are unfamiliar with desktop computers may feel uncomfortable dealing with anything they consider to be too "high tech" and tend to be unwilling to learn complex interaction models. Those consumers who do have computer experience often have very different expectations when dealing with a consumer product than they do when dealing with a computer at work. Business users who regularly use a cell phone expect to be able to pick up the phone and dial a call in seconds. When has a personal computer ever booted up in seconds? Additionally, people who have participated in some of our consumer studies have voiced the sentiment that even if they are fairly computer literate, they do not want to take the "lingo" from the office to the home.
Furthermore, within the consumer domain itself, expectations differ depending upon the user's generation, sex, class, and education. All of these types of factors should be considered during the development of the product.
While electronic appliances such as televisions, VCRs, telephones, and microwave ovens are common today, widespread acceptance is hardfought. Eight out of ten consumer products fail in the marketplace, often because consumers find them too difficult to use. Modern consumers have little patience for learning how to operate new products. They expect the interfaces to be self-evident. Most consumers simply will not buy a product if they believe it might be hard to use.
In short, consumers expect products to be easy to figure out and fun to use. Such expectations affect response time, the complexity of applications, the plastic of the product, the choice of colors, and many other aspects of a consumer product. The result? A marketplace where success is equated to simple, slick design. Design that inspires consumers to pick up the product and play with it. Products that come in all shapes and sizes and colors, for children, teenagers, and adults alike.
|
This section details some of the main considerations that affected the development of the Touchable look and feel, and how these considerations differ for a look and feel targeted for touch screen based consumer products compared to typical desktop look and feel designs. It is important to keep in mind that there are similar differences, though maybe not as radical, within the consumer product area itself.
Consumer products are tightly integrated and reflect a careful balance between several competing design criteria. Specifically, the level of integration between the software and the hardware (i.e., the actual plastic) must be very high. The color of the physical components (e.g., plastics, buttons, bezels, etc.) must be coordinated with the colors on the display. The shape of the physical buttons on the plastic should be integrated with the shape of the buttons on the screen.
The Touchable look and feel is a reference design only. It represents a framework from which a variety of derivative look and feel designs are possible. A main consideration in the development of the Touchable look and feel was to ensure that it can easily be modified to support the product identity or product design needs of device manufacturers. For a more detailed discussion of how to modify the Touchable look and feel, refer to the Truffle Customization Guide.
The Touchable look and feel is targeted for products containing a variety of different display sizes. For example, the display size on a retail kiosk is likely to be larger than the display size on a screen phone, which in turn is likely to be larger than the display size on a PDA. As a result, the look and feel is designed to scale gracefully. This is in direct contrast with desktop look and feel designs, where there is less variance in display size, and therefore scalability is not as important.
The Touchable look and feel started with a working target of a640"x480", 100 dots per inch (dpi), color touch LCD. Finger input was used as the starting point because, compared to stylus input, finger input requires more adjustments to the look and feel due mostly to target size issues. Figure 1 shows an example of some of the Touchable look and feel widgets in the context of an email application. Figures 2 and3 show the same widgets scaled down to 75% and 50%, respectively.
Figure 1: A 640" x 480", 100 dpi, full scale sample of the list, choice menu, and button widgets from the Touchable look and feel in the context of an email application.
Figure 2: A sample of some of the widgets from the Touchable look and feel in the context of an email application, scaled down to 75%.
Figure 3: A sample of some of the widgets from the Touchable look and feel in the context of an email application, scaled down to 50% and rotated to vertical. Notice the modified button shape and placement of the scroll buttons.
The color schemes are different in the Touchable look and feel than they are in a typical desktop look and feel. In general, consumers dislike gray scale. In user studies, color schemes that resembled desktop computer look and feel designs received the lowest ratings from the participants (see Figure 4).Instead, consumers prefer bright, cheerful colors.Figure 5 shows the color scheme that received the highest ratings from the participants in the user study.
Note: Only a sense of the color schemes can be gathered from thefigures included in this section. The colors appear extremely different on an LCD display.
Figure 4: This predominantly gray scale color scheme received low ratings from consumers.
Figure 5: This yellow/blue color scheme received the highest ratings from consumers.
Additionally, participants in the user study desired the ability to set the color scheme on the product. Color schemes should be targeted to age groups: what works for a child will not work for an adult. Color preference also differs according to sex: what works for a 7-year old boy may not work for a 7-year old girl; likewise a female adult prefers different color schemes than a male adult. The Touchable look and feel provides alternate color palettes from which to choose.
As discussed, the Touchable look and feel is targeted for use on touch screen based consumer products. On such products, typically a finger or a stylus is used for input, resulting in the following implications for the look and feel:
The pointer/cursor model of graphical user interface has become common in computer desktops. It was originally developed to provide a mechanism for allowing a user to control graphical elements in a computer display (e.g., pressing a button on the interface by moving the mouse over the button and pressing the physical button on the mouse).
This model is not necessary in a touch screen based look and feel for two reasons: (1) the touch screen hardware allows a user to directly manipulate an object on the display, and (2) a mouse adds bulk and complexity. The arrow pointer used on desktop computer systems is out of place on a touch screen. Users try to make the arrow move to the right place instead of just touching an element. Paying attention to the arrow pointer makes the entire system seem much harder to use than it really is. The pointer is unnecessary because the direct interaction model simply does not require it. The current position is wherever the user places his/her finger.
(Note: The only exception to this in the Touchable look and feel is the text insertion point, which is not a cursor.)
Many desktop computers use a focus highlight graphic to indicate which human interface element has keyboard focus. The graphic is usually displayed as a rectangle drawn around an element. This rectangle can be very distracting to a consumer user and is unneeded on most touch input consumer devices.
(Note: The Touchable look and feel does include focus highlight, however the default is to have it turned off.)
It is actually quite hard to tap twice in the same spot with a finger. Fingers inherently jitter. Given the error-prone nature of fingers and touch input with regard to tapping, double-tapping should be avoided.
In general, most human interface components, like button or choice menu, will show a state change upon finger-down. The state change may be a simple highlight. Upon finger-up, the operation associated with the component is executed. For example, upon finger-down a choice menu button will highlight and upon finger-up, the choice menu will be displayed.
Additionally, an input is only registered if the user lets his/her finger up over the original target (i.e., the same target as the one the finger went down on). If the user touches (i.e., finger-down) on a target and then drags his/her finger out of a target then the target returns to a neutral state. That is, finger-up outside of the original target serves as a cancel, even if the finger is dragged over another legal target.
A finger is neither small nor accurate. If the user is expected to use a finger as the input device, then all of the user interface elements must be large enough to accommodate this. The size of desktop computer elements is far too small. For example, on displays with a resolution of ~100 dpi, the minimum height of a button should be no smaller than 36 pixels in order to accommodate the full range of adult sized fingers.
Compared to desktop computers, the lower resolution and smaller displays of consumer products also have several implications for the look and feel, including:
The color LCD has a big effect on the Touchable look and feel design because of the differences in how color is displayed. Not only is color displayed differently on a color LCD compared to a CRT, but color is affected by the specific LCD as well. For example, on some LCDs the saturation level of red is much lower than expected, resulting in the inability to show certain colors, such as violet. Furthermore, subtle color differences may not be apparent to the eye on LCDs, thereby limiting the available shades of gray and requiring the use of high contrast colors. As a result, there is a limit on the variety of color palettes provided with the Touchable look and feel. Viewing the palettes on a typical personal computer display is not a good idea. (Note: The actual LCD on which the look and feel is displayed will directly affect how the colors are displayed. The color palettes included with the Touchable look and feel were tuned for a specific type ! ! of LCD. Developers are encouraged to tune the colors for their own LCDs.)(For a more detailed discussion on this topic, refer to the Design Language section in the forthcoming Consumer Products User Experience Style Guide.)
Given the small size of the display and the performance typical of these products, the human interface elements on the screen have to take rendering time into consideration when they are designed. The Touchable look and feel is deliberately a simple look with few outlines or other excess graphic bits. This is advantageous because the look is both fast to render and simple, and therefore less intimidating to consumers.
The style of typeface recommended to work with the Touchable look and feel is a sans-serif condensed typeface. The recommended size for a 640" x 480", 100 dpi display is 24 point for finger input of adults (see Figure 1). A sans-serif condensed typeface is recommended because of space considerations on small displays.
The first release of the Touchable look and feel includes the minimum required set of AWT components from the PersonalJava technology API specification. Components such as overlapping windows, modeless dialogs, hierarchical menus, and scroll bars are considered optional in the PersonalJava API specification and are not supported at this time, though future releases may support some of these components. Many of the unsupported components and their related concepts have been shown to be hard to learn, difficult to understand, and generally too complex for consumer products.
A few examples of desktop concepts that typically cause problems for consumers are included below. For a more detailed discussion ofthe Desktop Concepts: Do's and Don'ts refer to the forthcoming Consumer Products User Experience Style Guide.
Multiple overlapping windows are very confusing to consumers with no desktop computer experience and require a much steeper learning curve than is appropriate for most consumer products. They assume the presence of a windowing system and a method for the user to manipulate or manage windows, neither of which is common or necessary in consumer products. In addition, the display size of consumer products is typically much smaller than that of a personal computer display, leading to insufficient space for multiple overlapping windows.
The basic human interface problem with multiple overlapping windows is cognitive load on the user. Multiple overlapping windows require users to learn and then use various interaction methods to resize, move, scroll, and so on. The collection of extra knowledge that the user must learn and use puts a cognitive burden on the user that is inappropriate given the simple specialized nature of most consumer products.
In addition to having to learn how to manage windows, the inherent reason a computer system has multiple windows is so that multiple applications can be running simultaneously. Ignoring the fact that many consumer products do not have the memory to support multiple applications, forcing a user to interact with multiple applications at a time places another cognitive load on the user. While the operating system and other system infrastructure may need to support multi-tasking, users should not be exposed to it in the personal computer sense.
Double clicking an icon on a personal computer is a shortcut for selecting the icon and choosing the Open command from the File menu to open the icon. It should never be used as a primary method for an operation even on a desktop computer. Most consumer products do not have a mouse or any device that provides for double clicking. Even when consumer products do have a pointing device, it may inadvertently move between clicks causing the system to interpret the double click as two single clicks. Moreover, users with common medical conditions like arthritis or Repetitive Stress Syndrome (RSI) may be even less tolerant of double clicking in a consumer environment than in a desktop environment.
Double tapping on a touch screen presents further problems because people do not consistently hit the same spot on the screen twice in rapid succession. What the user meant as a double tap may get parsed by the input handler as two discrete single taps, and then the user sees the software do the wrong thing twice instead of the right thing once.
Scroll bars were originally designed for viewing documents on a personal computer; the bar gave an indication of how much of the document was visible. The document model is one of the main concepts of the personal computer human interface as creating and editing documents are two of the main tasks on personal computers. Consumer products rarely allow users to do more than create and send an email or fill in an address book entry. Users do not typically view either of these items as a document in the personal computer sense.
The bar portion of the scroll bar is very confusing to people with no computer experience. Because they usually have little experience with the concept of documents on a personal computer, they do not readily understand what the bar represents. In addition, the thumb, or elevator, in a scroll bar can be very difficult to manipulate with the limited input devices available on consumer products.
|
This section describes some of the design approaches and lessons learned from the extensive usability evaluations conducted in developing the Touchable look and feel.
It can be argued that an iterative design and evaluation process is even more crucial when designing products for novice computer users than it is when designing for more experienced computer users. In no way should such a statement insinuate that iterative design and evaluation should not play a central role in the desktop computer market. However, when designing for computer users, assumptions can be made regarding their behavior based on their knowledge of the conventions used in the desktop world. On the other hand, consumers include novice computer users who may have had little, if any, exposure to computer conventions, and consequently few assumptions can be made with regard to how they will behave. Once a good intuitive model for what a user expects and how a user behaves is obtained, the designer can develop designs more directly, with less iteration.
The needs and expectations of consumers were taken into account throughout the development process of the Touchable look and feel. At the same time, the goal was to understand the needs and requirements of developers. A fair amount of time was spent working closely with software engineers, learning about their business, and evaluating existing products on the market.
The development process for the Touchable look and feel involved several design iterations. The process began with the creation of the basic elements or building blocks from which other more complex components could be built. The next step was to iterate the designs of the components until patterns started to emerge. Two sets of design rules emerged during the design process: (1) rules that had to do with how elements were laid out, internally within a component as well as with regard to other components, and (2) rules dealing with how color was used, how many colors, and what color mapped onto in the elements.
Other tools that were used during the design process included a demo that mimicked possible screen phone applications and made use of all of the Touchable look and feel components, as well as a set of tests created to display the widgets and test out edge cases. Additionally, the designer working on the Touchable look and feel created sample application screens based on the consumer application work of the other designers in the company, and held regular design reviews with peers.
The first release of the Touchable look and feel went through five rounds of user testing with consumers who had little or no personal computer experience. Although the intended user population for the Touchable look and feel varies broadly with regard to their level of computer experience, the focus during the user evaluations was predominantly on those users with less experience in order to ensure that the design accommodated their needs. The data from the user testing was tightly integrated into the look and feel design. Touch monitors and a color touch LCD were used throughout the design and evaluation process.
During the user evaluations, valuable feedback was collected regarding the usability of the components. Some of the lessons learned through the many hours of user testing are shared below:
Users are very inconsistent with regard to which finger they use. Many times they will change the finger or even the hand being used to tap on the screen. Users also do not tap with a consistent area of the finger. They tap with the tip or the side of their finger, roll their finger, place their finger sideways or straight up, and just about every other possible contortion. Long fingernails are another source of trouble, as users can inadvertently tap on two items if the nail is too long: one item with the pad of their finger and the second as the finger is raised and the nail contacts the screen. In addition, a finger inherently jitters and can accidentally produce double clicks. When users are frustrated with something on the screen they will sometimes tap repeatedly and very quickly on an element.
Furthermore, it was commonly observed that users touch lower on an element than they would with a mouse pointer. This is most likely due to the fact that the finger obscures the thing the user is touching. Consequently, users touch lower to make sure they are touching the correct element. This effect is more pronounced with finger input as compared to stylus input. These observations directly impacted the design of the widgets. Specifically, the following guideline was adhered to for each of the widgets: Once the appropriate width constraints are met, the height of the element becomes critical to ensure error-free operation by users.
Active Labels
Another observation from the user evaluations was that when using checkboxes, radio buttons or text fields, users touched on either the actual object (i.e., checkbox, radio button, or text field) or on the object's label and expected both to operate the component. When using finger input, being able to select the object and its label makes the target area that much larger, which is a distinct advantage.
Labels are usually part of the checkbox and radio button components in toolkits. Text fields do not have labels as part of the component. The additional work to tie the label and text field together makes the operation of the product less error prone and more user friendly.
For reasons already discussed, the Touchable look and feel does not contain a scroll bar widget. However, the issue remains that users need feedback to tell them if there is more information to scroll to or not, and if they are at the top or the bottom of a list or text area.
In developing the Touchable look and feel, visual cues to replace the feedback that a scroll bar would give a user were iteratively explored, implemented, and tested. The resulting design incorporates redundant feedback in the form of scroll arrows, clipping of items,and blank spaces at the top and bottom of a list to provide feedback as to whether the user is at the top, bottom, or middle of a list or text area.
When the scrolling list is at the top (seeFigure 6), there is a half-space left blank to tell users they are at the top. If there is more information to scroll to, then the last item is shown clipped in half. In addition, the scroll buttons are enabled or disabled appropriately for each state. When the list is somewhere in the middle (seeFigure 7), the text is shown clipped on the top and the bottom of the visible list. When the list is at the bottom (see Figure 8), the half space is at the bottom and the upper item is clipped.
Figure 6: Scrolling list at the top. Half-space left blank at the top of the list. Bottom item is clipped. Scroll-up button is disabled.
Figure 7: Scrolling list in the middle. Items at the top and bottom are clipped. Both scroll buttons are enabled.
Figure 8: Scrolling list at the bottom. Half-space left blank at the bottom of the list. Top item is clipped. Scroll-down button is disabled.
The scrolling feedback within the list and text area widgets proved extremely successful during the user evaluations. So successful, in fact, that it was applied to scrolling in the choice menu widget as well.
A general lesson that can be learned from the design of the scrolling feedback is to build redundancy into the interface. Each of the visual cues by themselves may or may not have been enough of a cue to signal the scroll state of the list or text area. However, taken together, the cues succeeded in signaling the state to practically all of the participants in the user evaluations.
One of the components that was extremely difficult to design, and that went through a series of redesign phases, was the choice menu. This is a component that is very dynamic. The size of the component is dependent upon what items are in it. Where it pops up and whether it is scrollable is dependent upon the screen real estate around it. This component can be confusing to a user who has never seen one. The goal was to make the component as easy to understand as possible given the constraints.
A choice menu has two parts. One part is the menu button which is the element from which the menu originates. The other part is the menu itself. There are three states the menu button can have: enabled, disabled, and selected. The menu supports scrolling if there is not enough room to display all of the items. Figure 9 shows one of the original designs of the choice menu.
Figure 9: One of the original designs of the choice menu.
One thing the original design of the widget had not taken completely into account was the situation in which there was a group of menu buttons and one of them had a menu popped up. During the user evaluations, the demo application displayed a set of four choice popup menus which were used to set the label for an associated text field. It became clear that not all of the users could tell what" popped up" menu went with what menu button. Given our users had very little if any desktop user interface experience, the confusion was not surprising.
The design of the choice menu was revised such that the selected menu button and its menu were visually tied together with a colored outline (see Figure 10). In user testing, the new design did seem to alleviate most of the confusion.
Figure 10: Revised design of the choice menu.
A remaining problem with the widget was that users did not seem to easily pick up on the scrolling state of the menu. In the next user test, the clipping feedback from the scrolling list was added to the menu as an extra visual cue for users that the menu was scrollable(see Figure 11). This extra bit of visual feedback fixed the scrolling problem successfully.
Figure 11: Final design of the choice menu.
The choice menu is another widget that demonstrates the strength of building redundancy into the interface. The choice menu can be closed in three different ways. The user can touch an item in the menu to select that item and close the menu. The user can touch the arrow on the menu button or simply touch outside the menu to dismiss the menu. The last two methods do not change the selection. The choice to have the widget behave this way was based on observation ofthe varying behaviors of the participants in the user studies. Afterall, no two users are exactly alike. When possible, the Touchable look and feel attempts to accommodate the varying behaviors of theusers.
Text fields and text areas differ in their visual appearance from the typical box one sees on a desktop system. In designing the text field and text area widgets in the Touchable look and feel, it became painfully obvious that consumers did not automatically know to touch a text field or text area to enter text into it. After several iterations of the design, the final design of these widgets incorporates a lightly shaded background with a small vertical affordance on the left edge of a text field and area. This affordance leverages the manner in which color is used by employing the button color. Figure 12 provides an example of the text field and text area widgets in the context of an address book application.
Figure 12: Example of the text field and text area widgets in the context of an address book application.
Another observation made during the user studies was that consumers expect to be able to simply tap on an empty line (i.e., below the last line of text) in a text area and have the insertion point appear on that line so they can enter text. In addition, users expect the down arrow on the keyboard, physical and on-screen versions, to move the insertion point down to a empty line. Though not supported in the desktop market, this behavior is the default behavior in the final design of the text areas in the Touchable look and feel.
The behavior of the insertion point in the text field and text area widgets was also the result of the data from the user studies. In the final design of the Touchable look and feel, when the user taps on a field, the word they tap on is selected. Upon second tap, the insertion point is set at the tap point. This model of selecting a word upon tap, lessens usability errors when the finger is used for input. When a pen or stylus is used for input, the model recommended in the Touchable look and feel is to place the insertion point at the tap point. The selection mode is a property that can be easily altered.
|
Designing for consumer products requires a different perspective than designing for desktop computers. Memory and input device limitations, as well as user expectations, have direct implications on the look and feel for consumer products.
The Touchable look and feel is a reference look and feel design. Device manufacturers are expected to modify the look and feel to make it suitable for their product. The Touchable look and feel provides the building blocks for creating a good user experience for touchscreen based consumer products. Although it contributes to good design, the Touchable look and feel does not guarantee good design in and of itself. The device manufacturer should consider the overall behavior of their product and how customers will use it in order to produce well-designed applications.
The Touchable look and feel is intended to be the first in a series of look and feels created for the consumer product market. The goal of producing such look and feels is for Sun Microsystems Inc. to continue creating products and technologies that make our customers successful by helping them get to market sooner. Indeed, one of the key selling points of our look and feel technology is the ability to easily alter and customize it, thereby being able to tailor it to specific needs. Our products and technologies, including the Touchable look and feel, reflect our commitment to understand and address the differing needs of the consumer product market.
|
|
Oracle is reviewing the Sun product roadmap and will provide guidance to customers in accordance with Oracle's standard product communication policies. Any resulting features and timing of release of such features as determined by Oracle's review of roadmaps, are at the sole discretion of Oracle. All product roadmap information, whether communicated by Sun Microsystems or by Oracle, does not represent a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. It is intended for information purposes only, and may not be incorporated into any contract.
| ||||||||||||
Print-friendly Version
