Posts Tagged ‘design’
Ribbon Hero uses game design principles to help users learn Microsoft Office
Kathy Sierra, design and usability advocate, is famous for saying, “If you want people to RTFM, make a better FM.” In 2007, Danc, a game designer and author of the Lost Garden blog, claimed that any user activity that can be learned, measured, and returned as feedback can be made into a game.
An alternative to Minesweeper?
Some folks on Microsoft’s Office Labs team took up the challenge. They’ve released a game called Ribbon Hero, which helps users master the Microsoft Office “ribbon” toolbar.
Danc discusses the design philosophy behind Ribbon Hero and shares his thoughts on turning a traditional application design into one that incorporates learning, fun, and a sense of accomplishment.
I’ve always thought that computer games have a lot to teach the rest of the software industry about design and usability. It’s fascinating to see software developers putting those ideas into practice.
Whoa! Look at the Colors, Man!
Color makes an impact. It’s one of the strongest visual cues you can use.
When we started Infovark, we knew we wanted to make something different. Gordon and I had just come from the enterprise software arena. We were tired of boring press releases and the battleship gray applications.
And then we stumbled upon the name Infovark. And our lovable mascot. Suddenly, we not only had an idea for a software company, we had a way to express it.
One of the things that caused us to reach out to Amy Hoy for help with our user interface design was her bold use of color, which you can see on Slash 7, her principal blog, and also on her projects twistori and freckle.
One of her first questions to us was about the adjectives we wanted associated with the project. What sort of impression did we want to make? In addition to “new and different,” we provided answers like helpful, friendly, enthusiastic, accessible, earthy, natural, and intuitive. Clearly, our approach to creating software, the company name, and the critter all had an influence.
We had already taken one pass at the user interface for our application, but it still retained too much of the drab, corporate look so common in applications today. Even paragons of design like Apple and Adobe use neutral tones like brushed metal and charcoal gray. Microsoft is noted for Windows’ blue and white scheme. Amy’s advice:
My suggestion for fixing the aesthetic problems can be summed up in two words: Be bolder. Ditch the color waffling: go bold. Ditch the lighter shades, commit to the bright ones. Kill the grey. Get rid of borders and boxes. Get rid of gradients. Ditch the icons, unless you can get bold, iconic ones that can do the job with just one color.
You can see that advice at work in the new look of this blog and the Infovark Underground. And we hope you’ll see it in our user interface, too. The screens aren’t ready for primetime yet, but you can see our color palette below.
The Infovark color palette
These are not the exact colors you’ll see in our application, but it’s provided the inspiration for our scheme.
But what does it all mean?
Have I mentioned that I’m the son of an interior designer? I may sling code all day, but I appreciate good design. And for me, these colors have meaning. I won’t bore you with color theory, but if you’re at all interested in color, marketing, and branding, it’s worth looking at the Usability Post’s Guide to Choosing Colors for Your Brand and Smashing Magazine’s Colors in Corporate Branding and Design. Both provide insight, advice, and lots of examples of how color influences our impressions of companies and products.
Lipstick on an Aardvark
After our first round of product testing, we decided to make big changes in the look of our Infovark product. This is the first of an occasional series of posts about the design of the Infovark Beta.
We use the Infovark mascot — we call him “the Vark” — to represent our company. We use his head for our avatar in twitter and as the favorite icon for web bookmarks.
I like the simplicity and abstract look of the icon. It has a certain Scott McCloud less-is-more aesthetic to it. As Scott explained in his book Understanding Comics, the less detailed an illustration is, the more it invites the viewer to use their imagination to fill in the gaps. The more detailed a drawing, the more it represents a particular thing. We wanted Infovark to be about you, the knowledge worker, and not about us, Gordon and Dean, two guys making software.
We also chose an animal mascot for a reason. The Infovark name was partly an accident, but it stuck because it was a useful metaphor for us. Infovark does a lot of work in the background for you. It watches files, catalogs email, indexes content, and other useful things automatically. We liked the image of an animal digging through your information, trying to find interesting items and making associations between files, contacts, and email. It made our software feel friendly and helpful, like an enthusiastic pet you’ve taught to do neat tricks.
For round two of our product design, we wanted to try giving the Infovark just a little more personality. But not too much personality. Ever since Microsoft introduced Clippy to the world — and to much popular scorn — software developers are mindful about overeager assistants. Does anyone remember these guys? It’s a fine line that we’re walking here…
So after much consultation, this is our attempt at something a little cuter, with a touch more detail.
What do you think? We’ll use this new character on our redesigned blog theme, and possibly in the product itself. Leave a comment and let us know your thoughts!
Ideas and Forms
Here’s a philosophical topic to start the week. Information Aesthetics, a blog about design and data visualization, posted two videos from Maya Design. The first discusses the term information, the second architecture. As a software developer, these are terms I use all the time, but I often have a hard time defining precisely what they mean.
It’s a bit of a challenge for our marketing and communications strategy. The core API for Infovark, our product, is fundamentally nothing more than an information architecture. We use this core to create solutions that help knowledge workers get stuff done. But if information and architecture are tricky to define, you can imagine the confusion involved in combining the two! But where was I?
The two videos do a great job describing the terms information and architecture from the classical point of view.
- Information is the essential message being communicated. It is separate from the form the communication takes.
- A design is a plan for making a thing. An architecture is a design for making plans.
These definitions are classical in the sense that they rely on Plato’s concept of an idea being separate from a particular physical representation. There are other approaches. For example, Marshall McLuhan believed that “the medium is the message” — that you can’t separate the meaning from the representation that conveys it.
Did I mention this was going to be a philosophical post? I did warn you…
Getting real
Even though the topic is a bit academic, there are real-world debates going on about representations and forms right now.
How many differrent representations of you can be found on the web? There’s your LinkedIn profile, your Facebook page, your StackOverflow account…
Much of the buzz surrounding the open stack technologies is due to there being a way to finally associate a person with all the stuff about that person on the web. Wikipedians talk about having “canonical URIs” — a web page address that points to the master record for an article, rather than a particular translation of an article. And if you support or build software that uses the REST pattern, you’ll face this issue. What is the base address for this web page? How do I get to the HTML version, the XML version, the PDF version, or the MP3 audio version of the page?
There’s not a “right” answer to any of these questions, but we usually adopt certain conventions for dealing with them. Libraries had to figure out whether to keep Braille editions of books together with the print editions, for example. After all, they’re the same book — they contain the same message — but the format is different.
We’re working out those same conventions on the Internet right now with regard to privacy, data portability, text translations, podcasts vs. screencasts vs. print, etc.
