Archive for the ‘User Interface’ Category

« Older Entries

Visual TrackPad of tomorrow

Jul 10
27

What Apple Should have released for a desktop trackpad

Apple released a product that was decidedly un-magical when it released the Magic Trackpad. Despite the use of the word “Magic” the device was really just a big trackpad with nothing to amaze or delight the end-user.  The battery charger that comes with it was more impressive.

The true trackpad of tomorrow would have the following characteristics:

  • Control the computer pointer with touch gestures (duh)
  • Provide application  specific touch interface enhancements
  • Web browser specific controls at your fingertips
  • Formatting tools from your word processor at your fingertips
  • Crop and resize photos with your fingers visually.
  • When typing a number show a calculator keypad
  • Many of the interface enhancments that are taking place on the iPad could be transposed to desktop apps.

A huge efficiency is in minimizing the number of times your hand has to move from the keyboard to the mouse and back. This is why there are so many keyboard shortcuts for things that can be done with a mouse. The mouse/trackpad can evolve to present visual ways to process input in a way that would be more efficient then either the keyboard or a mouse.

There’s an opportunity to create a true visual and magical input device that combines the best aspects of a trackpad the iPad and the mouse.

Tags: , , , ,
Posted in Apple, Ideas, Prediction, User Interface | No Comments »

Mobile Ergonomics for those with two thumbs

Nov 09
23

Mobile Ergonomics

You can’t easily tap every region of the phone with equal ease. Your hand isn’t designed for this.  Yes your thumb is opposable but unless it’s double jointed there will still be parts of your phone that will be harder to tap.

When designing an application consider how it’s going to be held.  In one hand, sometimes in the other, perhaps in your pocket?  That’s why it’s so important to get the app out of the simulator and actually into your hand. The mechanics of how you hold your phone make it much harder to grip the device in certain orientations. It makes it particularly difficult to reach the lower corners by your thumb.

Consider the built in Camera application that Apple provides. The application is simple and attractive but the buttons for the application are in exactly the wrong place. To take a proper picture you need to hold the phone perfectly vertical (unless you’re taking a picture of the floor.)  The slippery edges of the phone require you to either grip the phone firmly with your hand making it difficult to tap the camera or alternatively balance the camera precariously on your pinkie finger.

iPhone Camera Interface Tap TargetsI have dropped my phone at least twice attempting this and know of at least one person who has smashed their phone into little bits because of this.

There’s a principal called “Fitts’s law” that describes how clickable items are on screen. Said simply:

Items that are larger and closer to the mouse cursor are easier to click.

The mathematical details then explain that traditional screen edges are infinitely click-able since they have a virtually unlimited size.   On a mobile device the same assumptions don’t hold true. The mechanics of your hand play a significant role.  Not only do items have to be larger to be easier to click but they have to be easily reachable when holding a phone in one hand.

Tags: , , ,
Posted in Design, Telephone, User Interface, mobile | 1 Comment »

Quick Calendar UI Review – Google

Nov 09
19

This is a simple UI critique of a simple feature burried in Google Calendar.  Here’s the original:

Google Calendar Original

It’s a relatively simple form.  It’s certainly not bad but I think it could be better. Here’s a quick mock up:

Google Calendar Concept

Here are the key design points:

  • The body of the form has “What, When, Where”  but doesn’t have “Who” if you’re having a meeting it stands to reason that the people attending are pretty important. I always felt that having guests hidden in the right didn’t make sense.
  • The majority of meetings are measured in duration. 30 min, 45 min, 1 hour, 2 hour, all day, etc. It’s much easier to pick a common duration and allow “custom end time.” as a fall-back rather then making users select end times.
  • Most meetings don’t repeat. Logically this is a secondary consideration. This can be moved to the secondary area on the right.
  • Checking availability should be a secondary area action as well. Plus over on the right there’s more space to present availability in-line.
  • It should be really easy to preview a location with a map.
  • The current UI makes it difficult to add people to a meeting without the system automatically emailing them. You have to place names into the description area. Having a simple checkbox to email guests could solve this.
  • There are a lot of simple UI 101 alignment things that can make the UI look cleaner and simpler just by lining fields up.
  • The right hand side could be extensible with new modules, plug-ins, ala Google Labs.

Tags: , , ,
Posted in Design, Google, Review, User Interface | 1 Comment »

Interface List Design – Drupal

Oct 09
1

This is a quick UI critique on a list design pattern that’s in a proposed stages for Drupal7. The UI being critiqued is not final, as such the feedback is meant to be helpful to both the Drupal team and anyone else designing list based design patterns.

Before:

drupal_content_list

Example image from drupal 7 content list

Key points with this screen:

  • The title areas don’t tell you what you’re supposed to do on this screen. In fact there are at least three competing title areas. “Content” as a title, “Content” as a tab, “Add new content” as a secondary title and two group boxes that cover filtering and updating. The actual title of the screen doesn’t reflect the modal nature of dialog. You’re actually adding content to something else and it’s not clear what that is.
  • The information is presented in the wrong reading order.  The content table should be first.  You first have to read the list to see what you’re dealing with before you decide to either filter it or update it.
  • An empty list is a dead-end. It tells you there is no content but doesn’t direct you on how or where you should go to create some.
  • The X in the upper doesn’t make it clear what it would close. The tab? The dialog? A simple cancel button or a standard cancel button or a close button in the upper right would be more obvious.

After

drupal content list updated

Key points

  • Title should say what you’re doing.
  • Filters should sit above column headers whenever possible. No additional button action should be needed and multiple filters can be applied at the same time.
  • It should be easy to reset the filters and hide them. Hidden should be the default.  The filters should give you a clue as to the number of items in each filter bucket:  Articles (3)  Posts (120). This makes it easier to select the right filters.
  • If the table is empty it should be easy to get to a content creation page.
  • Buttons along the bottom of a dialog provide clear ways to exit or complete the task.
  • Things that don’t map to the core task should be hidden.  In the original mockup there were options to update the status of content from published to unpublished. This type of functionality belongs in a management section, not when you’re “adding content.” It should be removed or hidden in a similar way that filters can be hidden.

Tags: , , , , ,
Posted in Design, Development, HTML/CSS, Usability, User Interface | No Comments »

Drupal User Experience

Aug 09
8

Over the summer we overhauled the Raizlabs website. It was originally developed in 2001 using Frontpage (yeah, I know). The site had accumulated a number of HTML files, a collection of ASP files, a number of blogs for personal and company use, some newsletters and assorted client scripts.

In re-designing the site I knew I wanted a content system. We evaluated Joomla, Drupal, WordPress and custom solutions.  Joomla and Drupal looked promising. WordPress was a good blog system but not designed for larger site structures. We started implementing a Joomla site and were perhaps a week into the process when we decided to change paths and go with Drupal.

The Joomla front-end experience is easier to get started with but makes it difficult to setup and interact with content quickly. The Joomla system had a lot of out of the box features but it required too many steps to do simple things.

The Drupal user experience was by contrast amazingly stark. After downloading Drupal I couldn’t figure out how you could possibly build a site using it.  It later became clear that the real value of Drupal was with it’s module system.

Critical flaw: Make sure things work out of the box. Batteries should be included.

While Drupal is truly a powerful system this is easy to overlook. The default install that you get from Drupal.org has nothing included. It’s like getting a car engine without the seats.

Dries: Oh, you want seats in your car? There’s a module for that.

There are more complete solutions and downloads available from providers like Acquia but this is not obvious. The modules are the most critical part of Drupal and if you’re not familiar with modules it’s not clear what modules you need.  They have many names that are also not obvious: CCK, Views, ImageCache, AdvancedHelp, Devel, Mollom, TaxonomyMenu.

Too much flexibility can cause problems.

Everything in Drupal is customizable. Not only can you customize your content but the system also makes it very easy to customize the admin structure, menus and commands however you want. It’s so easy to customize the administrative interface that it’s easy to get into a state where nothing works.

The admin interface should be designed to be quick and efficient for creating and editing content.  Some amount of customization is great but the system as it stands is overly abstract making it easy to get into trouble.

Be good at certain things. Don’t try to be good at everything.

When evaluating Drupal it seemed that it has support for blogs, forums, discussions, groups and pretty much everything else. It was only later that we decided that even though Drupal could do these things it couldn’t do them well.  For instance Drupal has a blog module but it’s so much harder to use then WordPress that there’s really no reason to fight Drupal to do what you want, it’s easier to integrate WordPress. Same story for PHPBB and the Drupal Advanced Forum module.  As a content system Drupal should make it easier to integrate these external products. Instead they try to re-invent these components and it doesn’t work.  Drupal is a good content system but it’s not a good blog and it’s not a great forum.

More then anything I wish Drupal would be a better cross product citizen for other PHP projects.  For example: Gallery, PHPBB, WordPress, ZenCart, etc. Plugging in other stuff that’s not part of Drupal should be encouraged.  The attitude that it has to be Drupal for everything is simply not practical.

Views and CCK

Views and CCK allow you to create all sorts of queries onto your content and allow you to customize the fields of content that you collect. It’s basically like creating your own database columns for your content.  The problem is that you can’t just take someone elses database you have to build them yourself. If I want to setup a bunch of content and views to create a little client database I have to start from scratch. It would be so much easier to take a good solution as a starting point and customize it to specific needs.

There should be a number of popular and useful views that should be included. I shouldn’t have to create my own “random post of the day” or “most popular articles” these should be canned views.

Modules and Blocks

A module encompasses a portion of functionality. It’s actually not ‘modular’ in that sense of the word. It’s more like a plug-in that extends the functionality. A block is a component that gets shown on a page.

The block model assumes that you have one core site template and that blocks are either shown or hidden on each page. As your site grows you have to have rather complex rules for when certain blocks are shown and when they are hidden. The UI to customize this show/hide functionality is rather broken. Rather then having page tempaltes with visual drag-drop interfaces for multiple pages you have to manually specify all your blocks and pages within one block template page.

I wish I could define a site structure then drag/drop content and widgets to each page in the site structure.

Terminology

With any content system there’s a certain amount of learning that has to happen. For some reason content systems don’t use terminology that is used when designing a website. They use their own abstract terms: Page, Story, Book.  If you take these terms literally you may expect that stories compose a book and a page is one page of a longer story. This isn’t how it works.

Drupal uses the term “Menu” for everything. Even if certain things are tabs, other things are trees and still others are actually menus.

Making things practical, not just possible.

Drupal has the ability to do a lot of things but in many cases these things are possible, not practical. Solutions for certain tasks are not ‘turn-key’ they involve a lot of customization and configuration. As a simple example I wanted to create a special “clients only” section on my site. Reading the docs and forums there were at least 10 different approahes for how to solve this problem. Some solutions suggested advanced permission modules, others suggested Organic Groups, still others suggested a CCK/Views approach. This seems like such a basic security scenario that there should be a simple solution to make this work (there was not).

I’m sure this problem has been solved many times over using Drupal however there is no current way for people to share these “solution recipes” in a way that I can download them and have things just work.

Long term experience

I think Drupal’s user experience has a lot of potential and I’m encouraged by the efforts I’ve read about for the Druapl 7 release.  Focus on the user experience is really the thing that’s going to make this not just a powerful system but a practical one.  I’m looking forward to it.

Tags: , , , ,
Posted in Experience, Review, Usability, User Interface | 15 Comments »

Going Mobile – Giving users the finger

Apr 09
29

Last month I gave a talk for UPA Boston, this is a summary of that talk.

Over the last five years we’ve seen a shift in mobile applications.  For about 30 years people thought of mobile phones as an extension of traditional phones. They would make calls and that was the primary use. Over the last 10 years we’ve added features like voice mail, texting and even basic web browsing. It wasn’t until just the last 4-5 years that the next wave of mobile has taken off.

Mobile today

Mobile phones today are dominated by three classes of devices, 16 button, 60 button keyboard and new touch devices. There are about 1Billion 16 button phones, 50-100 million keyboard phones and about 20-40 million touchscreen phones. I’m mostly talking about this last category of emerging phones though some principals apply to both keyboard phones and 16 button phones.

The key difference between the phones of yesterday and the phones of today are a combined set of capabilities and technologies that fundamentally change the user experience. These include:

  • Always connected – email/web/etc
  • Adaptive input screen (control every pixel)
  • Geo-location
  • Touch/Gesture interface
  • Accelerometer
  • Apps you can download

A lot of these technologies existed either in isolation or in awkward implementations. Together they allow for a much richer application experience. This has become a platform that is fun, exciting and profitable for application developers.

Design for existing behaviors

When designing an application it’s key to keep scenarios in mind. A scenario is the basic story of how a person may use the application. The important thing when thinking about scenarios is that actions tend to stay the same but the way you complete those actions changes.  Behavioral changes are difficult and rare. It’s much easier to design tools that encourage and support existing behaviors. Similarly it’s much easier for end-users to adopt your application or tool into their existing behaviors rather then changing established patterns.

Designing for Mobile

When designing for mobile remember that people are out in the real world. Your application needs to be a good alternative to the desktop/laptop. The factors for this type of design should include:

  • Input methods – make it easy and minimal to get information into the device.
  • Form Factor – Design for a smaller screen size and make it easy to read and get information back out of the device.
  • Location – Take location into account
  • Efficiency – A mobile application should be quick and efficient
Input Considerations
You can’t always expect that the user has both hands free. People are often holding something else in their hand, coffee, bags, railings, doors, etc.  You should design your application to be usable with one hand. Consider scenarios where the user may have both hands occupied, driving, running, etc.
Opposable thumbs are great but they aren’t perfect. There are spots on the phone that are particularly hard to hit with one hand. Certain apps aren’t designed well for single handed use. Fitts law doesn’t work on mobile devices. Because of the mechanics of the human hand certain zones are easier to hit and this has little relation to the screen edge.
Output Data
Use large presentation size fonts, 14-18pt fonts are typical. Use large finger tip sized targets, 30-40px are easy to tap.  Small targets are particularly hard to hit. Examples: Info buttons are tiny and sliders tend to be particularly hard to tap.
Touch Screen Language
The user interface language is being defined now. The desktop conventions of click, double click, right click. These conventions don’t always hold on a mobile device. A whole new interface language is being developed in rather an ad-hoc way. Certain conventions are becoming more popular:
  • Tap – most similar to click
  • Tap & Hold – magnify, copy/paste, selection/make dragable
  • Swipe – scroll, secondary action/delete option
  • Pinch – Zoom
  • Shake – Undo/Refresh/Clear
Basic guidelines
1) Each screen should do one thing (well)
2) Minimize on-screen elements (quantity, not size)
3) Make things easy to tap
4) Avoid preferences
5) Design for the 80% case
The session covered other topics including Mobile Wireframe Design, Mobile Web Design. Mobile Usability, and Mobile Gaming. The variation of the talk will be given at this years Mini-UPA, an event put-on by Boston UPA.  If your company or organization is interested in hearing it first hand contact me for additional info.

Tags: , , ,
Posted in Apple, Design, Misc., Telephone, User Interface | 2 Comments »

Iphone wireframe and interface toolkit

Nov 08
9

A wireframe is a design tool used to easily communicate ideas, and allow for quick iteration. Wireframes can be created easily by anyone with or without technical know-how to discuss ideas. 

Often when I work on projects with CEO’s and high-level executives there is a problem communicating design, concepts and intent. People may cite the lack of design or drawing skills. A wireframe levels the playing field allowing anyone with even basic Powerpoint skills to create basic screen designs.  I posted my original wireframe for web-applications here.  I’m now back with an iPhone based version. 

Why iPhone? Well first off I’ve been doing a number of iPhone related projects including Runkeeper and GPSTwit among others. Secondly the iPhone provides a unique interface language and set of reusable design patterns that can be easily incorporated into new applications. While the basic wireframe components can be used to conceptualize any mobile device the iPhone interface makes it uniquly different. 

The primary design pattern used on the phone is the list pattern. There are many examples of the list pattern but the basic idea is that it allows you to add/edit/remove/view sets of items.  The second design pattern is the table pattern usually used for forms, input and settings. Combined these two elements form the foundation of the platform. 

The wireframe provides a number of examples of how these patterns can be used, modified or altered.

Tags: , , , , , , , ,
Posted in Apple, Design, User Interface | 2 Comments »

Scrollbar UI and Search Results

Sep 08
17

File this under awsome. A while back I posted an idea about having an ABC or Heatmap scrollbar. The idea was that you could show suplimentary information in the scrollbar area.  Turns out that the recently launched Google Chrome uses a similar UI in their “Find” UI.

As you search you can see the matching occurances of the keyword in your document. I love it and hope there is a way to extend this so after visiting a search engine I can see the matching words on the resulting page.

Tags: , , , ,
Posted in Browsers, Design, User Interface | 6 Comments »

Google Chrome Browser Review

Sep 08
3

Google surprised everyone when it recently released a web-browser named Chrome. The surprise was primarily due to the fact that Firefox seemed to be the Google darling for many years. As Google has grown, the dependency on browser technology has also grown.

As a search engine Google primarily displays HTML with some minimal JavaScript. But as an email, calendar, ad-network, blogging platform, news-reader and more, the dependencies on the browser have grown. To alleviate this Google has used projects like Google Gears, Google Toolbar, Google Web Toolkit and more to fill the gaps of the browser. Now it seems the stop-gap solutions are not enough.

First off… Google Chrome is not for everyone. In fact I may even say it’s not yet for anyone. It’s a Version 1 and it does a lot of things well but it’s not perfect and there are still a number of issues that need to get worked out. It also only works on Windows. That said it’s a pretty good V1.

Google stands on the shoulders of both Mozilla’s Firefox and Apple’s WebKit for many pieces of the browser. This could not have happened without open-source software. The primary rendering of pages seems quick and crisp and all pages in my initial testing seemed to work without a problem.

The key areas where the Chrome browser is different:

  • Opening a new tab
  • Auto-completing a URL
  • Overall look and feel
  • Incognito
  • What’s missing – Plug-ins, spellcheck, etc.
Opening a new tab
Opening a new tab in Chrome brings up a page with the top sites you visit and allows you to quickly pick either an existing site or browse to a new site. This is a great idea. Reasearch shows that users re-visit the same 5-7 sites over and over again and often they type the website name each time. Firefox 3 keeps track of your recent sites but this takes it to the next leval and allows you quickly and visually identify and open a site. I love it and expect to see this in other browsers very soon.

Auto-completing a URL

When you start typing a URL into the address bar Google chrome automatically starts searching your history, your bookmarks and Google itself via Google Suggest. As anyone who’s done reasearch on search knows that one of the most common things typed into any search engine is a URL. By combining search and URL’s you have one stop shoping for typing a site name, a bookmark or a search. I wouldn’t say it’s better or worse then Firefox it’s just a little different. Some users may appreciate the change while others may find it annoying.

Overall Look and Feel

The overall look is very clean and minimal. It reminds me a lot of Safari on the Mac. The buttons are minimal, there are no draggable toolbars, no hidden menus when you hold Alt, no bookmark manager, no spinning logo, no toolbar customization. The browser does it’s best to stay out of your way.

  • The find on page dialog floats cleanly within the window
  • The download page doesn’t get lost in a secondary window
  • The status areas comes and goes as you hover over links never stealing space from your overall browser.
Showing IE, FF and Chrome displaying 1px of vertical content you can see that Chrome is much thinner:
In general this means that more space is given to your content and less to the ‘chrome’.

Incognito

In Safari it’s called “Private Browsing” in Mozilla there’s an extension called ‘Distrust’ in IE the often talked about but never implemented ‘promiscuous mode.’ In Chrome the feature is called Incognito aka ‘porn mode’ creates a seperate window that is free from the browser cache, history or other identifiable data.

I’ll just say it’s an interesting feature to include considering the other features that have not been included.

What’s missing

As I said previously I don’t consider Chrome to be a complete browser. There is no bookmark managment, no visible support for plug-ins, no spellchecker, no way to set a home-pages, etc. etc. Some of the tools you depend on may not be available. For some people this isn’t a big deal for others it’ll be a show-stopper.

The big deal is performance

In initial testing Chrome seems to be significantly faster at rendering complex pages then both IE and Firefox. The difference is visually noticable as pages pop and complex interactive sites like Gmail load with new found speed.

This performance is undoutably one of the key reasons that Google decided to invest in it’s own browser. The engine driving Chrome’s Javascript is a new peice of technology that does for JavaScript what Java had promissed to do years ago.

The added performance does come as some cost in terms of memory:

Sure it’s faster but look at all the memory it’s using. 80 megs for a browser is about 4 times what firefox and Internet explorer use. On modern computers memory performance tends to be cheap. Of course you want fast and minimal memory but if you had to choose one I’ll take the performance.

Other details

  • Chrome has a feature to turn a page into a desktop appication. This is simlar to the Prism concept from Mozilla. This is the future. I was very happy to finally see this in a shipping product.
  • There is a development mode that’s preety slick. It’s not quite Firebug but it’s pretty good.
  • View Source formats and displays a good looking source page
  • Browser settings, bookmarks and other data import nicely
  • Spell Check. I miss you.
  • Tabs can be ‘torn’ off similar to Safari to create a new window, tabs can also be re-ordered by dragging.
  • The browser passes the Acid-test 2 and does OK on acid test 3 (77/100)
  • Accessibility and keyboard shortcuts seem to work well
Overall a good V1. It’ll eat away market share from Internet Explorer and Firefox in limited places but for the most part I see this as a technology preview. The power of Firefox is still it’s extensive plug-in and customizations. The power of IE is it’s enterprise deployments and OEM’s. In the short term Chrome doesn’t change that but longer terms it’s certainly a large peice in this puzzle. Either way the Google browser will help push the state-of-the-art in open source web browser development.

Tags: , , , , ,
Posted in Apple, Browsers, Design, Google, Microsoft, Review, User Interface | 5 Comments »

Iphone Clipboard Concept for Cut, Copy, Paste

Jul 08
26

One of the current drawback of certain touch devices (Iphone) is it’s lack of copy/paste functionality. The difficultly in creating this functionality on a mobile device is that the interaction technique has to be non-intrucive to the core interface. 

Unlike a desktop application where you can toss commands into a menu the interaction model on a phone has to be more direct and gestural.  The copy/paste model I’m proposing tries to address some of these issues. 

When a user is viewing a core text area:

  1. They can scroll (tap + drag ).
  2. They can move the insertion pointer (tap)
  3. They can use the magnifier loupe to position the insertion pointer (tap+hold)
In my illustration you could activate additional copy/paste gestures:
  1. You can bring up the copy/paste pallet ( tap+tap near the insertion pointer)
  2. Once the panel is open you can mark a selection (tap+dragging) from the insertion point creates a selection. Similarly you could create a selection with two fingers marking both corners..
  3. When in copy/paste mode the keyboard is replaced by your recently cut/copied blocks of text or images.  You can tap a piece of text to insert it into your document 
Note: The tap+tap gesture is sometimes used in application to zoom however it is never used to zoom while editing text or viewing read-only text such as in emails or contact lists. 
Unfortunately at this point it’s not possible for third party application developers to write an extension such as this so it’s a concept sketch only at this point. 
P.S. Did you know we’re now developing and designing mobile apps?  Check out our latest design work for a new fitness startup focused on running. 

Tags: , , , ,
Posted in Apple, Development, Telephone, User Interface | 1 Comment »

« Older Entries