Windows User Interfaces and Web User Interfaces: Convergence and Confusion in Online Experiences

Transcription

1 Windows User Interfaces and Web User Interfaces: Convergence and Confusion in Online Experiences Liza Potts Rensselaer Polytechnic Institute Abstract This paper discusses a case study underlining the differences between Windows and Web interfaces currently being implemented online. Findings are reported from a recent examination of DotNetNuke, a web portal system based on Microsoft technologies. Keywords: user experience, user interface, standards, patterns, windows, web Introduction Windows and Web User Interfaces Today s Web is entering a new phase where technologies such as rich internet applications are allowing communicators to devise new user interface mechanisms. On sites such as Flickr, users are able to interact with the Web in real-time, in many cases without having to wait for the page to refresh, due to new AJAX technology. There are also new frameworks such as.net, where developers are able to use Windows-like interface affordances to create Web-based user experiences. While this does leverage a user s understanding of how Windows applications work, it also leads to applications that create unexpected user experiences on the Web. Online, the freedom to experiment with user interface design can often lead to unbridled experimentation. For example, the inconsistent use of buttons and links can result in user confusion. Am I sending information or linking to a new page? These links can also be inadvertently hidden by using the same color as the body text, not using underlines in links, or both. This paper will describe the differences between these two user experiences, discuss the advantages of leveraging this new paradigm for Web interactions, and give specific details on how we as communicators can best address the needs of our users and communicate these needs to Windows developers who are making the transition to the Web. As surprising as it may seem, these issues are still prevalent online and further discussion is needed to help improve these experiences and leverage the new paradigm that technologies such as AJAX and.net will afford us. Case Study: User Experience of DotNetNuke The examples in this paper come from a web application called DotNetNuke. About DotNetNuke DotNetNuke (DNN) is billed as an open source web portal system that runs on Windows with other Microsoft applications. History of DotNetNuke DNN is based on the IBuySpy Portal Solution Kit, a free example distributed by Microsoft.[1] The founder of DNN then modified this free offering, turning it into DNN and releasing it as an open source framework based on Microsoft technologies. DNN now boasts over 200,000 [2] users in multiple countries. DotNetNuke Developers The majority of DNN community developers work part-time on various modules. They are typically more familiar with the Microsoft framework [3] for software development and less familiar with other Web-based frameworks such as PHP.

2 Differences in Affordances This paper will discuss specific examples of the differences between Windows and Web-based user experiences. Traditional Windows-based user interfaces are object driven, while most modern Web-based user interfaces are task driven. While most Windows user interfaces are bound by Microsoft standards and conventions, Web interfaces are more flexible and faster to evolve, depending on the conventions followed. Sites such as Yahoo, Flickr, and numerous start-ups are creating novel affordances based on ideas collectively known as Web2.0. Technologies that can employ RIA (Rich Internet Applications) and AJAX (Asynchronous JavaScript and XML) provide a method for web pages to be more interactive and avoid page refreshes, allowing the user to see immediate feedback based on their actions. These new affordances leverage technologies to allow for client-side interactions to create a more task-based and highly interactive experience. DotNetNuke s Use of Affordances Because of DNN s early work connected to the Microsoft solution kit, much of the user interface affordances had strong leanings towards a Windowslike implementation. The original IBuySpy Portal was built as an example application, without the intention of becoming a full-fledged product. Regardless, the user experience of DotNetNuke is neither Windows nor Web. Instead, it is a conglomeration of these two styles, leading to a confusing user experience because of the lack of leveraging of these understood affordances. Looking at the product as a whole, there are a number of issues regarding the use of these affordances. The following sections will discuss these in brief detail. Fonts Although most of these issues are examples concerning how DNN deviates from the normal web experience, this example is more critical of offline and online reading styles. Figure 1. Numerous fonts are implemented. Many developers were unaware of how many different fonts they were employing in their applications. It was explained that each and every iteration of font size, color, family, bold, italics, etc. constituted a different font type to the user. Such cues to the user could set-up expectations that each different font had a different purpose, although this was not the developer s intention. Another issue for these developers was the use of serif and sans-serif fonts. In documentation writing, it is understood that serif fonts are best used for reading, as the serifs create invisible boundary lines to help readers follow lines of text across a page, whereas sans-serif fonts are preferred for online use [4], as they help readers scan; the lack of the serif allows the user to jump from section to section, unbound by the boundaries serifs can create. Buttons vs. Links A major issue for DNN is the ambiguous nature of links. The understood convention for Web-based user experiences is to use links as a navigational tool. If a user clicks on a link for Home, they are then sent to the home page. Figure 2. Links used to navigate and submit information. However, DNN uses links to submit information back to the server, such as updating forms and deleting items. On the Web, buttons are used to indicate to the user that they are submitting information. This push-button affordance lets users know that they are actively sending information. Breadcrumbs Breadcrumbs orient the user to the linear hierarchy of a page by listing the names of previous pages within the site structure. The first item is typically the home page, followed by any intermediary pages, and ending with the current

3 page. To signal that the user is currently on this page and does not need to navigate elsewhere, the current page is not a link. Symbols such as arrows, slashes, etc. direct the user s attention and explain the linear hierarchy. Figure 3. Breadcrumbs. A pervasive issue in DNN is the multiplicity of breadcrumbs. Often, both the portal itself and the module within it use different breadcrumb systems, causing navigational confusion for site users. Figure 5. Modal dialogue in DNN. However, on the web, unless the modal comes in the form of a pop-up, the user can typically avoid the modal window by employing their back button, opening a new browser window, or navigating elsewhere. The modal pop-up serves to disrupt the user s task flow [5]. Therefore, it is critical to only use modal pop-ups when a critical event will be triggered. One example would be the deletion of any items that would cause serious stress for the user, such as deleting a photo album that would then cause all of the photos contained within it to also be deleted. Figure 4. Breadcrumbs and Breadcrumbs. Another issue involves the links of these breadcrumbs. Often, different design skins do not provide for affordances to let the users know that the breadcrumbs are indeed links (i.e. different colors, underlining, etc.). The typical web convention for the last item in a breadcrumb list is that it not be a link. This signals to the user that they are currently on that page and they do not need to navigate elsewhere. Modal and Non-Modal A modal interaction ensures that the user cannot proceed further in an application without first answering this dialog box. In Windows interfaces, the modal interaction is typically used in wizards and pop-up windows. The classic Do you want to delete this file? Ok/Cancel is an example of a modal interface. DNN typically uses these windows whenever any item is being deleted, moved, or otherwise altered. Icons In Windows, icons are a constant. They help increase our speed of use, but such icons are only affective when the user spends a lot of time using such interfaces. An example here would be the print icon in Microsoft Word. The icon s ubiquitous appearance provides for such understanding. Figure 6. SimpleGallery, a module available for DNN, provides multiple implementations of icons. It is even in popular use on the web. However, most icons on the web are coupled with text. This helps indoctrinate the user to the icon s purpose, while at the same time cueing more advanced users to the

4 affordance. Icons should be descriptive, lend themselves to being localized, and provide specific ALT text for accessibility. Status In Windows, status is often a mystery What changed? Did that work? Typically, indicators in Wizards such as Step 2 of 4, progress bars, etc. are used to describe status. However, these often fall short in their ability to notify and inform users. The web, and in particular RIA and AJAX technologies, gives us more freedom to add status inline and give better visual cues to our users. Highlighting gives the user a visual cue that something has changed. Animation can further emphasize the change, though this can cause issues for accessibility. Such interactivity can encourage users to be more active in their use of such systems. reviews, and similar programs are being deployed. It is hoped that such improvements will rectify the current gulf between internet user expectations and the current Windows-like implementation implemented by DNN. Conclusion This paper discussed the current state of a typical web portal system, DNN, as an example of the confusion over mixing Windows and Web user experience affordances. This case study pinpointed specific issues found in this implementation. This work can serve as an example on how to alleviate this user confusion by addressing these issues as part of improving the overall user experience. References [1] DotNetNuke, What is the history of DotNetNuke? [Online]. Available: [2] DotNetNuke, What is DotNetNuke? [Online]. Available: WhatIsDotNetNuke/tabid/777/Default.aspx. Figure 7. Flickr s highlighting gives visual cues. Developing an Initiative for Change When this information was first presented to DNN developers, it was well received. Their consensus was that most of these examples were easy to understand and obvious to them, once they were presented. Such feedback is important for understanding the development community: they understood what the issues were and are now eager to improve their work. The community is now beginning to improve the user experience of DNN. Such initiatives as style guides, Visual Studio component libraries, usability [3] DotNetNuke. (2005, Dec.). Newsletter Survey, vol. 1, no. 2. [Online]. Available: [4] K. Shriver, Dynamics in Document Design: Creating Text for Readers. New York, NY: Wiley, [5] A. Cooper and R. M. Reimann, About Face 2.0: The Essentials of Interaction Design. Indianapolis, IN: Wiley, About the Author Liza Potts (pottsl@rpi.edu) is a doctoral candidate in communication at RPI. She has worked as a manager, user experience architect, and technical communicator in the software and internet industries,

5 authoring corporate guidelines for user interface and documentation design. She conducts research on social software and user experience.