Archiv der Kategorie ‘Interface Design‘

 
 

Losing functionality with each new release

So this is a rant about the AppleTV and the new version of iTunes.

First AppleTV, the new software release that came out yesterday (2.1) has some bugs in it, one notable one is that new podcasts are not immediately designated with the blue dot if the podcasts section were selected on the AppleTV, which is annoying.

Second, iTunes loses more and more selection context with each new release. In the previous release when you had an artist selected, they remains selected and you only saw their albums when you went back to the music library after looking at the Apple music store for example (or podcasts). Now that is no longer the case, you get to see all the music in your library. And in the early days the scroll bars were not reset when you moved off a pane which they are now.

So what is it with losing functionality with each new release?

From: http://wordpress.com/tag/user-interface-design/feed/
Go to Source

7 Components for a Successful Web Site Redesign

Lately, we’ve had a flurry of clients contacting us about their latest redesign project, wanting to know what advice we can give them. We talk to them, discussing their team’s needs and what is driving the redesign effort.

In many cases, we discover the team is thinking only in the short term. Of course, because they have immediate deadlines and resources to manage, they need to focus on what’s happening right now. The short term, after all, is where we all live day-to-day.

We’ve spent the last five years studying teams involved in major redesign efforts. Some teams regularly produce innovative, user-satisfying enhancements to their sites. Other teams work hard, but their efforts result in expensive changes that, after all is said and done, don’t really enhance the user’s experience or help the business.

As we analyze the difference between these two types of teams, we’ve noticed a pattern: teams who focus on the long term are far more likely to create designs that really pay off for the organization. Short-term thinking gets the design done, but the team ends up doing it all over again months down the road. Long-term thinking deals with the inevitability of changes and turns the site into a living, breathing entity that grows with the organization’s needs.

In our research, we’ve uncovered seven essential long-term components to reach a successful redesign project.

1. Make Sure You Have A Vision

We suggest clients look five or ten years into the future and ask the question, “What will using our site be like on that date? What experience will the user have?” Team members from the best organizations can answer this question. They have a consistent, clear idea what the user’s experience will be like in the future. Having a clear vision lets the team chart a direction for their design, helping identify if any design idea is moving them closer to the vision or farther away.

It’s critical the vision not focus on future technology but instead on future experience. What are the steps in today’s process that makes things cumbersome or frustrating? How could the experience become more delightful?

One of our financial services clients constructed a vision where banking clients easily manage all their money and credit from a single screen, or can simply check their financial forecast from their mobile phone when, say, deciding if they can afford that new car, while simultaneously getting competitive quotes for insurances and car loans from their primary institution. While it would be impossible to do this with today’s legacy infrastructure, it’s possible to see something like this 10 years from now. The design team, using this vision, can then work in baby steps to getting as close to it today as the technology will allow. As the technology improves, they can get even closer.

2. Spend Time With Your Users

To successfully redesign, you need to know who is using your site and what they are doing with it. You need to know what is currently working well and what is broken.

The number of established web sites embarking on a major redesign, whose designers have never watched any users actually work with their current design, constantly surprises us. Add that to the number of relaunched sites we see where the designers are surprised by the negative reaction of their users. What you get is a group of organizations that need to spend more time with their users.

When preparing for a redesign of their site, many teams have no trouble spending hours in meetings to talk about what the new design should do. Our recommendation is those teams make sure they spend the same amount of time sitting with users watching them work with the existing design. Teams that do this produce substantially better results.

3. Reduce Risk By Working In Little Bits

Some teams struggle to make significant changes to their sites, while other teams regularly push out enhancements with ease. Probably the most striking difference is how big the projects are.

The most successful teams know to keep their projects small. They don’t attempt to redesign everything about the site in a single launch; instead, they work on one small section at a time.

When the team tackles a large project, they end up with complexity at all angles: the scope of functionality is larger, the number of stakeholders is larger (each with their own concerns), the number of personas the team is designing for is larger, and the risk is much higher. If things don’t go as planned, it’s a huge problem for everyone, often with more visibility in the organization than the team would like.

Teams that only focus on a small portion of the site at a time reduce the number of stakeholders, thereby making it easy to satisfy their needs. They reduce the number of personas, thereby giving them the time to ensure they’ve covered the edge conditions — those details that make or break a design. And, they substantially reduce the risk — if things don’t go well (and they frequently don’t), it’s easier to roll back to the previous design.

Reducing scope has another advantage for these teams: they see results faster. New designs can pop up in just a few weeks, giving immediate feedback on what works and what still needs effort. The team immediately applies what they just learned into the next little bit, making each part of the overall redesign smarter and better with every new portion.

4. Have the Right Skills Internally

Another striking difference we see in our research results: the best teams are less likely to hire outsiders to do their designs. Instead, they work hard to ensure they have the right skills in-house.

It may sound great to hire a top-notch design firm, but what happens once the project is done? Will they continue to make the millions of little changes required to keep a production site working? Who will make the inevitable changes, updates, and enhancements?

It’s usually too expensive to keep using outsiders for the continual care and feeding a quality web site requires. Yet, the unsuccessful teams typically don’t have internal resources to help with making changes and enhancements. In the long run, the site begins to decay and becomes a liability to the organization — something everyone is embarrassed to send customers to.

In a strange irony, the pattern we see from the struggling organizations is their solution to a decaying web site is to repeat the process all over, doing exactly what they did last time, hoping it will be different this time. The successful teams look to their long-term needs and invest the same money into having the skills on site, giving them the flexibility to constantly update the site as the business grows. They only use outside firms as an extra set of hands, to make the larger changes faster.

5. Think ‘Standards’

The CSS and xHTML standards are the successful teams’ best friends. Careful application of the standards can dramatically shorten the time it takes to make changes down the road, because radical design enhancements can happen by only tweaking the definitions of the styles.

Even if a site didn’t start out as standard-compliant, it’s worth the effort of slowly converting it. As areas are redesigned (in little bits, remember), changing them over to be standards-compliant is an effective approach. Every new redesigned area helps improve the team’s skills in using standards, thereby making the next area even easier to convert over.

6. Have a Plan for Change

Most teams we talk to have an internal plan for changing to the new design. They think about what servers will need updating, which internal processes will change, and how they’ll break it down into a manageable launch process.

However, we’ve found only the successful teams give as much thought (or more) to how the users will experience the change. Will they just log in one day to find an entire new experience or will the change slowly happen over time, almost imperceptibly?

Yahoo! Finance, for example, has been slowly converting users over to their new chart functionality. The new charts are greatly enhanced and users love them. Yet, many existing users, visiting the site multiple times a day and busy with their goals, can’t easily stop and learn the new charts. For them, they can continue to use the old functionality for a while. In time, Yahoo! can assess the risk of changing the functionality out from under these users versus the cost of supporting both interfaces.

7. Understand the Internal Processes

In a conversation we recently had with Gerry McGovern, he talked about his experience working with many teams in the redesign process, which matched our research results. He noticed many teams approach the redesign process much like they’d approach the design of a brochure.

Designing a brochure has the advantage that, at some point, it is printed and delivered. Once that happens, it can’t be changed — it’s done. The only thing is to start over with a new brochure.

Gerry noticed in his travels this attitude, when applied to web sites, is what got many teams into trouble. They thought they could think about a new design, implement it, then pay attention to other business, not giving the site any further attention.

Unfortunately, both Gerry’s experience and our research show that strategy won’t work. The most successful teams know it. Those teams consider, in the planning stages of the project, what the long-term internal processes will be for updating the site after the design changes. How will they add new content? When do they remove outdated content? Who will edit content before it goes live? Who will review changes? Who will decide about changes to the user’s experience?

Understanding how the organization will handle the continual site changes shortens the time it takes to make improvements, reducing the need for a risky major relaunches.

Thinking in the Right Terms

All the evidence points to the simple fact: Careful consideration of long-term factors dramatically increases the odds a team will produce ongoing results that have considerable business impact. Teams ignoring these long-term components may get a new design launched, but will likely find themselves reliving the difficult experience again in just a few months.

From: http://wordpress.com/tag/user-interface-design/feed/
Go to Source

Good User Interface Design Tips

General application user interface guidelines :

  • Always use cute icons, buttons, and graphics. Everyone loves big red hearts, pink bunnies, and yellow smily faces.
  • Don’t be afraid to experiment with colors!
  • Your application should play fun sounds while operating to keep the users entertained.
  • Never, ever, under any circumstance use the OS-native graphical controls or widgets. Users get bored of the same old buttons, text boxes, and stuff.
  • When possible, disable window management and use unusual, oddly placed graphics for the windowing functions such as the window close option.
  • When writing your own controls or widgets, make absolutely sure they look and feel nothing like the OS-native widgets or anything else the user might expect. Otherwise you might accidentally make the user think that your application is actually designed for their OS.
  • Use your own creative ideas on how a “save as” dialog should look and work. Built in ones are always too limiting.
  • It is important that the user should never be able to tell the difference between a checked and unchecked check box or option box.
  • Always use obscure or poorly drawn graphics for your tool bar buttons, and never put text on them.
  • Avoid including a preferences or options dialog. Instead, let the user use the standard OS provided text editor or an editor of their choosing to edit text configuration files. .
  • Users need time to think about what they are doing and get coffee. Your application should always take at least 5 minutes to load even on the fastest available computer.
  • Make sure an accidental double-click on a single-click item does something really nasty or unexpected.
  • Tool tips are the perfect way to display critical information.
  • To get the most screen space, force your application to always run maximized.
  • Always make the default positions of floating properties windows cover something important.
  • Use the most exotic fonts you can find.
  • Your application’s user interface should be flexible and customizable to the point where if the user accidentally sneezes on the mouse or keyboard they will have to spend the next half an hour setting things back.
  • Let a 5-year old draw your graphics, including your corporate logo.
  • File browsing dialogs are not needed, users can easily remember and type in long file paths.
  • Design your application so it requires the user to set their tiny monitor to 10512*7430.
  • Always crash at a critical step and then display a fake apology to the user.
  • It is a mistake to make use of application hooks in the native desktop environment such as new file templates, file associations, or program menu icons.
  • The exception to the above is placing icons in the system tray. Place as many icons as you can in the system tray and make sure that the user can not remove them.
  • If your program implements keyboard shortcuts be original and make them completely different from any other applications.
  • Rent extra UI space in your application out for advertising. Advertising benefits the users and your wallet.
  • Never underestimate the power of nudity.
  • Don’t forget to embed a hidden video game as an “easter egg”.

Application Help: How to make a help system that is impervious to usefulness.

  • There is no need to include a manual with software. These days users are smart enough to figure out this kind of thing on their own.
  • If you do include documentation, there is no need for printed manuals. Users love staring in to a 17 inch light bulb all day.
  • Always put your installation instructions on the CD-rom rather than in a printed manual to save paper. The instructions should be installed with the rest of the program so they are not accessible until it is installed.
  • Keep help files simple. Only state the bleeding obvious about any given topic.
  • There is no need to use consistent terminology.
  • For program error, warning, question, and information messages, explain what is going on to the user in the most technical terms. They really need to know and learn this stuff because it is important. As part of the message dialog include a help button that opens the help file and displays exactly what the message just said.
  • Display as many information and question messages as possible in as many different places as possible. Except before critical irreversible operations such as wiping the hard drive.
  • It is acceptable to use “Engrish” throughout your application. All your help file are belong to us.

Making the web do things it has never done before

(and should never do again).

  • Always build a web browser in to your application. For best results make your own web browser.
  • Always hard code hyperlinks in to your application. Then make sure that the links don’t work two months after the application is deployed.
  • When you launch a web browser, never use the user’s default browser. Always launch the crappiest one available (I.E.: IE) (See above, you should write your own).
  • Always use hyperlinks instead of buttons. Hyperlinks are cool.
  • Be sure to include a throbber graphic in every window of your application.
  • Applications should look like web pages because the web is the embodiment of usability.
  • All modern applications are required to automatically sign users up for spam.

OS Specific tips

  • For a great first impression during your OS setup, never set the video to a refresh rate that works with user’s monitor.
  • In fact, your OS should never, ever set the proper refresh rate for the monitor. Eye strain is good. In fact, whenever possible set it to a refresh rate that the monitor can’t handle at all. If the user does manage to set a higher refresh rate, make sure it is non-standard so they have to fiddle with the monitor sizing and positioning. Bonus points for finding a refresh rate that makes the monitor blow up.
  • When packaging a GUI or operating system make sure the same functionality is available in at least a dozen different places in unrelated programs.
  • Include three of every kind of application program. (four or more if possible).
  • Install all possible advanced utilities and mindless junk that the typical user will never use.
  • Uninstallation options are out of style, don’t include any. If you do need to include them make sure they always choke on dependencies.
  • It doesn’t matter if your file manager / desktop shell is slow and sluggish. Go ahead and integrate it with your web browser. In fact, integrate it with several web browses while you are at it.

Application design for the ultimate user experience (in hell)

  • Begin coding the guts of the program immediately. Designing the UI can come later in the development process.
  • Don’t waste time writing efficient code. GUIs don’t need to be responsive and it is easy to make users upgrade to the latest 10,000,000 terahertz CPU and who doesn’t need another zillion gigabytes of ram?
  • You can implement features half way. Your users will forgive you. (And if they don’t, screw them anyway). Or you can always make them upgrade to the next version.
  • You don’t even need to finish your software, if someone else has a problem with it they can fix it themselves.
  • It is safe to ignore the overall purpose of the application you are writing. Just make it do what you want.
  • There is no need to do any kind of user testing or research. Programmers always know the best way to design a user interface.
  • Let the users dictate design and implementation decisions, after all they know what they need.
  • If this is a corporate environment, always design the user interface the way the boss wants it. After all, that degree in user interface design he has is how he got to be the boss right?
  • When porting your application to another OS platform, there is no need at all to modify the way your application looks or behaves.
  • Always hard code all references to the file path your application must run in. The user will never have a need to install anywhere else and you will never run in to naming conflicts.
  • Sue anyone who makes a UI even remotely like yours. That’s what the legal system is there for right?
  • Always use bizarre, scary sounding code names for the name of your application. For best results it should be an acronym for something that doesn’t make any sense, and the acronym should be recursive.
  • Never remove old, obsolete, buggy, or nonsensical features from your application.
  • Pre-load your (now huge) application at system startup. It doesn’t matter if it slows down the rest of the system, it is important that your application, which most users only use only occasionally, start the fastest. .
  • Add all possible features to your application. Even those that already exist in the OS. In fact, your application should eventually become an OS.

From: http://wordpress.com/tag/user-interface-design/feed/
Go to Source

PicLens

Sometimes you need to know about new software right now. This is one of those moments.

PicLens from Cooliris is an immersive, full screen environment that displays content (images and Flash video) as a dynamic wall of thumbnails. The wall can be manipulated with the click of a mouse to scroll and zoom, and you can switch to a “playlist-like” view of the folder contents with a single click.

This is better explained by seeing it in action. Have a look

http://www.piclens.com/

And then

“The PicLens Plugin for WordPress makes it easy for you to provide your readers with an immersive slideshow experience. Visitors simply click a “start slideshow” link (see example) to activate PicLens Lite, a slick filmstrip-style presentation console. From there, they can play or pause your slideshow, or better yet dive into a full-screen mode.”

http://piclens.com/lite/wordpress.php

This plug-in is for server installation only. Not available for WordPress hosted blogs.

You can also add a gallery to your website. Full instructions here.

http://piclens.com/lite/webmasterguide.php

From: http://wordpress.com/tag/user-interface-design/feed/
Go to Source

Mapping, GIS, disease

“A system of electronic mapping which allows many different types of data to be layered onto a single image is being used to improve healthcare across Rwanda.

The digital maps, called Geographic Information Systems (GIS), are designed to compile information from numerous databases and use it to both track and predict outbreaks of disease.

This can then be used to help developing countries best utilise their limited resources. For example, GIS is used to organise data on clusters of disease and the availability of drinking water.”

BBC technology

See also, data mapping, point maps, John Snow, cholera, London 1854

Wikipedia link

From: http://wordpress.com/tag/user-interface-design/feed/
Go to Source

‘usability trainwreck’

Video comparing usability of the Open Moko mobile phone operating system with the iPhone. Unfavourably.

Comments point out that it will get better. True, and Open Source success stories like Firefox took a long time before achieving stability and widespread adoption.

Question is, how long are you prepared to wait?

Open Moko usability trainwreck

More like this

“So, we installed another possible frontend for the FreeRunner, the Qtopia phone frontend. In general it’s better, but really doesn’t solve any of the deeper problems with this phone. It’s still sluggish, still has horrible input methods, and still is not a valid substitute for an iPhone. Anyone who recommends you the FreeRunner as a substitute for the iPhone is attempting to play a cruel joke on you and should be treated as such.”

Qtopia video

From: http://wordpress.com/tag/user-interface-design/feed/
Go to Source

5 reasons to avoid iPhone 3G

From the Free Software Foundation

The 5 real reasons to avoid iPhone 3G:

  • iPhone completely blocks free software. Developers must pay a tax to Apple, who becomes the sole authority over what can and can’t be on everyone’s phones.
  • iPhone endorses and supports Digital Restrictions Management (DRM) technology.
  • iPhone exposes your whereabouts and provides ways for others to track you without your knowledge.
  • iPhone won’t play patent- and DRM-free formats like Ogg Vorbis and Theora.
  • iPhone is not the only option. There are better alternatives on the horizon that respect your freedom, don’t spy on you, play free media formats, and let you use free software — like the FreeRunner.

From: http://wordpress.com/tag/user-interface-design/feed/
Go to Source

Free software usability

Matthew Paul Thomas has a piece which tries to get to grips with the causes of poor usability in Free and Open Source Software (FOSS). He doesn’t dodge the problems and their origin in FOSS development methods and the rewards for participating in FOSS. He also has proposals for tackling the problems.

Free software usability

Back in 2004 John Gruber wrote an influential piece called Ronco spray-on usability. Here’s an extract:

“UI development is the hard part. And it’s not the last step, it’s the first step. In my estimation, the difference between:

  • software that performs function X; and
  • software that performs function X, with an intuitive well-designed user interface

isn’t just a little bit of extra work. It’s not even twice the work. It’s an entire order of magnitude more work. Developing software with a good UI requires both aptitude and a lot of hard work.”
Den ganzen Beitrag lesen…

How Long Before Your Computer Asks "How Do You Feel?"

Find out how Jonathan Harris has used some great visualisation techniques to uncover the world of human emotion…

http://www.ted.com/index.php/talks/jonathan_harris_tells_the_web_s_secret_stories.html

The video shows impressive ways of visualising large amounts of evolving information, making that information reasonably easy to understand and spontaneous to interact with.  Information seems to increasingly be depicted in a cognitive way, with clusters conceptually working in a similar way as your brain’s synapses create clustered relationships around things (subjects, tasks, interests) you are interested in.  This ability to cluster and interact with information in way that is spontaneous and direct, rather than passing through structured hierarchies, suggests that digital communication must be moving rapidly towards artificially intelligent systems that can respond to emotional inputs?  If the clustering of information can emulate the way in which the human brain stores and recalls information, and both verbal and non-verbal communication can be described and captured by digital systems, it won’t be long before computers can respond to human inputs that don’t need to be well organised, allowing a more spontaneous response by digital technology to human inputs.

All these ideas are somewhat whimsicle and non-scientific, just verbalising my thoughts.

Find out more about non-verbal communication here: http://en.wikipedia.org/wiki/Nonverbal_communication

And see how your computer can respond in an equally human way…
http://technology.timesonline.co.uk/tol/news/tech_and_web/article4557935.ece 

From: http://wordpress.com/tag/user-interface-design/feed/
Go to Source

iPhone NDA, patents, innovation

Extract

“At my company, our lawyers advised us to keep what we considered more-or-less public software under NDA for a very long time because demoing software to someone under NDA, no matter how many people it is, avoids “publishing” the software and any inventions contained therein.  We know Apple’s been building up a patent strategy around multi-touch; maybe their lawyers believe there are patentable inventions described in the iPhone SDK and they are telling Apple to keep everything under NDA until they know provisional patents can be filed within a reasonable amount of time (you get a year after publishing in the US, but in the EU, I think you forfeit any patent claims once your invention is “published”).”

continues at Daring Fireball

Multi-touch, patents, lawyers: plausible.
Den ganzen Beitrag lesen…