http://www.iht.com/articles/2007/05/20/news/proto21.php
Rave adapts a variety of gaming techniques. For instance, you can build dossiers of your clients and sales prospects that include photographs and lists of their likes, dislikes and buying interests, much like the character descriptions in many video games.
From IHT:
There's a name for this: user interface design, or UI for short. Its goal is to ensure that all of us can use digital devices simply and intuitively, regardless of how techno- savvy we are. As we're spending more and more time with digital products, UI is becoming one of the most important areas of design, but it's also one of the trickiest to judge.
This posting is meant to serve as a practical follow-up to the more reflective, academic article I recently published on boxesandarrows about designing for a rich user experience.
This is a "crib sheet" summarizes the main points of that article, with links to resources to help the dedicated UI designer who strives to craft a richer quality of engagement with digital media (web, mobile, desktop apps). Of course, richness transcends the digital, towards immersive games, environments, and performances; yet this set of tips is focused on pixel-based encounters for brevity. More later on non-digital rich encounters...
High-Level Issues
+ Re-perceive the design as a talk or presentation to an audience, persuading them this product is best for meeting their goals, as demonstrated in the navigation, functionality, content, and style.
+ Consider how to enhance that communication at the level of structure, behavior, and/or style by using a) good visual and interaction design and b) emerging technologies like Flash, CSS, AJAX, etc.
+ Make sure such enhancements improve the user's efficiency, confidence, desire or other stated goals and not for the sake of technical hype or coolness.
Detail Design Tips
+ Use in-place editing of labels, names, and other data, whether inside a form or table grid
+ Present immediate feedback and error validation with in-place visual cues, rather than a dialog box or separately loaded page
+ Use desktop-inspired interactions like drag-and-drop, floating palettes, keyboarding shortcuts, as the web and desktop become blurred
+ Use collapsible panels and panes of information; through usability ascertain the default states
+ Apply visual embellishments to emphasize key pieces of information and functionality, like tabs or buttons or messages, or to add stylistic flair in moderation
+ Remember to sustain the underlying grid layout and visual balance of elements
References
+ Designing Visual Interfaces by Mullet/SanoSimply saying "it doesn't feel right" isn't sufficient feedback when reviewing a design with a manager or prototyper or engineer (much less so for other peer designers). It's just a recipe for communication breakdown, with misinterpretation and ambiguity creating problems of what was really meant.
Gotta be specific--is it the spacing, the layout, the color, the type, the behavior, etc. Get it down to the specific design signals/variables that is the source of the problem or difficulty--then a productive conversation and more importantly, action, can follow that helps everyone get on the same page and towards resolution.
Else, team breakdowns can result, all over a simple misunderstanding that causes people to try to fix other things that cause breakages to occur in the design, etc.
Surprisingly this is something that is not clear for most designers, although the concepts have been around since late 80's/early 90's and often bandied about in professional tones of mastery--Only to be humbled by realizing the fallacies! Also this is not something exactly taught in design school (ahem). However, here's the basic breakdown of what these concepts mean and why they are confusing...
MDI: Multiple Document Interface, meaning you have many document windows, with the menus, tool bars, palettes all separated out into their own windowed objects, all within the application container, or environment
SDI: Single Document Interface, meaning the document is consolidated into just one window that has the menu, tools, tabs, etc. all compacted into that windowed object (ie, the application container = the window object, with all functionality self-contained)
So what does all that mean, regarding Mac and WinXP?
1. Pseudo-MDI: On WinXP, each application's document has a window but there is a general application level menu bar, tool bar, etc. On WinXP, closing the last window exits the app. However, on the Macintosh, because the application menu bar is shared with the Finder menu bar, there's some confusion. You can have multiple document windows open but only one set of menu, toolbar, palettes that contextual update based upon which document is in focus.
2. True SDI: IE is pretty much the exemplar, with each IE window being self-contained, with its own menu, toolbar, history panel, etc.
3. True MDI: X Windows and NEXT, in which even the menu or document navigator is its own window floating with the document windows.
From IHT:
The numbers seem nutty. There are 6.5 billion people on this planet, 90 percent of whom can't afford basic products and services. Half of them, nearly three billion people, don't have regular access to food, shelter or clean water. Yet whenever we think, or talk, about design, it's invariably about something that's intended to be sold to one of the privileged minority - the richest 10 percent.
From IHT:
The odd thing is that no one sets out to design something that's mediocre. So why does design go wrong so often? Let's set aside the rational reasons why projects can fail - like budgetary constraints, deadline pressure and lack of talent - to concentrate on the scenarios that should be easily avoidable, but crop up again and again, with predictably dire results.
[placeholder]
This is what separates the pros from the amateurs--making design decisions by really understanding the construction aspects (ie, code issues), rather than purely aesthetic or other factors. That way, you're helping to avoid unnecessary re-work, empathizing with the coder's POV, mindful of the level of work involved, and just smarter all around. Doesn't happen by itself or magically. Better know-how of the technical issues can also make for better arguments, so you don't sound "wishy-washy" but firm when talking with Engineers.
[placeholder]
Functional details can really matter and add up to either a horribly frustrating experience or one that is fluid, productive, sensible. For example, keyboard shortcuts for a date picker or in-field auto completion (similar to Google Suggest). Coding for CTRL + A, Arrow UP/DOWN, HOME/END buttons, etc. all add up big time for those power users who are data entry experts, 8 hrs a day, 40 hrs a week. They increase productivity and keep the data entry pro humming along swimmingly well, minimizing errors, and maximizing output.
Yes, it's tedious, but working out the interaction details like tab, shift, control, spacebar, etc. can have huge dividends for your user cranking away at her job someplace...
[placeholder]
Sure it may not be the most visible item on the screen or necessarily the most usable (discoverable, functional) but small flourishes like an elegantly crafted branding area (what I like to call the "credenza" for some reason), can add that extra "something" to give a degree of polish, sophistication, and yes beauty to an otherwise rote, dry, spartan interface. Think of the New Beetle's flower vase next to the dashboard. Adds small delight without obscuring or being grandiose.
[placeholder]
Related to earlier posting about too many systems. Process is nothing bad or evil in itself; it's just the risk of process becoming a burden that sucks out the "life" (ie, nimbleness, fluidity, momentum, passion) of a team and project overall. Also other things related to that, at a psycho/perceptual level: a feeling of "on-demand" or "on-call", that the work just becomes tedious administrative tasks, a sense of "another thing I gotta do", the pressure of "gotta please the manager", etc. Rather than spending the actual hours/effort getting the real design work done, that speed along the necessary progress of getting a good product out the door.
[placeholder]
One of the biggest challenges when designing a new product (or significant revision to existing product) is to get everyone else in the company behind you and the project. A sure way to do that is to build out (in prototype form) the most visible, core functional areas that are ever-present in the product, like the main navigation and branded panels (ie, the chrome) to make it really seem like it's coming alive. PM's, VP's, Directors, Leads from other departments can connect to that easily. Else it's just pretty pictures all disconnected from separate prototype pages/components that lack coherence, too random, not congealing...gotta make it "real" as THE THING TO BE for all to look upon and point to.
[placeholder]
As a team evolves its own internal user experience competency within the overall corporate machine, a hi-risk danger arises when the "informal" becomes the "formal" , with the introduction of processes, systems, protocols for everyone to follow. The team gains more people, more tasks to do, the workload increases and schedules shorten. Tempting to clamp down and insert some ways to regulate and control, but need to remember the balance/moderation ideal. And don't kill the great momentum from the earlier informal days when the team first started...
