With few exceptions, intuitive user interfaces really don't exist. Familiar interfaces do, however. But does that mean developers need to be locked into the same old design patterns? There's no reason why they should.
What do customers want from our software and documentation? They want to accomplish tasks, and to obtain information about tasks, as quickly and painlessly as possible. Do they also expect to be entertained along the way? No, not when there is work to be done. Years of usability analysis in the software industry indicates very clearly that clarity and ease-of-use is topmost on the minds of software users.
The sky is falling. It has been falling for about a year now, and it feels like it won’t stop falling until every business associated with the Internet is dead, dead, dead. What is happening now happens with every new explosion of technology. When the sky has finished falling, it will leave behind an industry with far fewer, but much healthier players. And then things will get better than they ever were.
Dan Harrelson, design technologist at Adaptive Path, recently spoke with Jensen Harris, Group Program Manager of Microsoft’s Office User Experience team. Jensen was one of the key designers behind the new Ribbon user interface introduced in Office 2007. Dan and Jensen chatted about Office’s redesign and the techniques he uses to keep the focus on user needs within an organization the size of Microsoft.
This style guide is designed to help software developers with the language aspects of screen design. It is not comprehensive, but it does cover the most common problems. For comprehensive style guidelines for documentation see the Microsoft Manual of Style for Technical Publications. TechScribe is based in the UK, and although we produce documentation for both the US and the UK markets, we have used British English in this guide. The document can be printed on both US Letter and A4 size paper.
The concept of direct manipulation is usually viewed as a single characteristic of a class of interaction styles. Here, direct manipulation is analyzed according to a detailed layered interaction model, showing that it has quite different effects on the dialogue on the different levels. In particular, the "no errors" claim may be true at the syntax level but not at several of the levels above or below that level. Furthermore, a unified framework is presented for conceptualizing Direct Manipulation, What You See Is What You Get (WYSIWYG), Transparency, Immediate Command Specification, Arcticulatory Directness, and Computational Appliances according to a layered interaction view.
If you’ve been reading ProfHacker for a while, you probably know that one of our primary goals is to talk about those things in academia that people simply don’t talk about. If you’re here–so the logic goes–you must already understand
Users have goals when they use software applications. Their goal is NOT to 'use' the application. Their goal is to complete an activity or task using the application. Performance support is defined as providing users what they need to be successful in completing their activity or task when they need it – at the point of need. Technical communicators can benefit from incorporating performance support elements into their work, even if they are not creating a performance support system.
Adobe has been using one of the most effective contemporary goal-oriented interactive mechanisms for years, and a lot of product designers should have been paying attention. It is, of course, the 'Variations' tool.
Look around the computer screen on which you're viewing this document. Do you see a keyboard and mouse a short distance away? These two traditional input devices have become so deeply entrenched as the established human-computer interface that they are inseparable from our notion of the 'computing experience.' Yet in many ways, keyboards and mice only make our experiences with computers more unnatural, forcing us into modes of interaction that we would never use with other people. In other words, they make humans interact with machines, rather than machines with humans.
Personal computing is in an awkward adolescence right now. On one hand, we are rapidly moving into ubiquitous computing environments that let people constantly interact with the omnipresent network; on the other, the devices and interfaces we are using to enter these new frontiers provide woefully inadequate user experiences. Let's take a look at one of the key technologies that will take mobile user experiences to the next level: holography.
When delivering your product in foreign languages, it is important to consider how the user interface will appear to users around the world. While there are no hard-fast rules, the following suggestions provide some guidance in facilitating localization in regard to your user interface.
The process of localizing digital games can be significantly different from the process of localizing productivity software.
There has been a growing tidal wave of flat designs on the web, and recent trend reports have confirmed that they're only increasing in popularity. Of course it's easy to dismiss flat design as yet another fleeting aesthetic trend. But further investigation into this new philosophy reveals that flat design is a lot more than "just for looks."
As a Graphical User Interface (GUI) programmer, I have many interface development tools to choose from. Over the years, my development environment changes to accommodate my needs. This often includes learning new languages and the tools that go with them.
This document describes the additions and changes to Macintosh Human Interface Guidelines related to the release of Mac OS 8. Specifically, it presents guidelines for taking advantage of the Mac OS platinum appearance and the Appearance Manager. This document does not replace Macintosh Human Interface Guidelines.
This document, which covers features up to Mac OS X version 10.2, describes what you need to do to design your application for Aqua. Primarily intended for Carbon and Cocoa developers who want their applications to look right and behave correctly in Mac OS X, these guidelines provide examples of how to use Aqua interface elements. Java application developers will also find these guidelines useful.
Efforts to understand user requirements commonly focus on the functionality and features of a product. However, it is important to analyze other product attributes, such as usability. A product may meet all of its functional requirements, but can fail if it has an interface that is difficult to navigate and learn. To address this problem, it is important to get feedback from users as early in the development life cycle as possible. A common technique is to develop a prototype or mockup of a product's interface to present to users.
Technical communicators strive to provide high-quality content to users when and where they need it. With responsive design it is now possible to create content that automatically adjusts to the device.
Users loathe reading the operating manuals that accompany new equipment. Manuals often sit unused on a shelf, far from their targeted audience, while the costs of technical support soar. This article promotes integrating information traditionally found in printed manuals into the product itself and reports the experience of a design team in developing an easy-to-use product requiring minimal printed documentation. As part of design teams, technical communicators can advocate both reducing the amount of information required to operate a product and making the information immediately available when needed. These strategies can produce increased customer satisfaction and lower post-sales support costs.
Working with long lists of information over a network, like web email, can be problematic. If a user needs to hunt for something, she’s going to need access to other pages, and this article is about how those controls should look and behave.
This paper focuses on managing constraints in a way that enables developers to create an accessible and usable user interface (UI). The constraining processes presented in this paper comprise of a language to describe a logical web page in an application, a basic bottom-up repository management system and the processing required for compiling pages.
At Microsoft we have full-time employees, called usability engineers, who are trained to help product teams understand what the user's needs are, and analyze how well our product user interfaces match those needs. They do a great deal of work, and understand the discipline of UI design and data collection really well. They are critical to the success of our products. As I've learned from the e-mail I've been getting at email@example.com, most developers don't have the luxury of this kind of support, and are on their own to make good interface design decisions. This issue will introduce a basic development process that helps good UI make it into products. Word of warning: There is no magic recipe for good UI, or for writing good code, and I can't guarantee improved interfaces without some extra effort.