Design « Greg's Head

Archive for the ‘Design’ Category

Apple’s Tablet, Slate, Canvas, Taplet

Jan 10

Tablet style computing has been one of the most failed technologies ever. History is full of examples of similar devices that have crashed and burned.

1950’s Styalator electronic tablet, 1960’s RAND Tablet and Dynabook. Various generations of Apple Newton devices, Microsoft Slate’s and Windows for Pen based computers. Even the Kindle that has sold about 1.5 million units total could be viewed as a failure when compared to numbers like 40-60 million iPhone’s and iPod Touch devices.

Why have so many companies tried and so many failed? Perhaps more importantly what does Apple think it can do to succeed? Here’s what I predict:

Best overall device for consuming content. Books, Magazines, Music, DVD’s.
Devices of the past focused on creating content (usually with a pen) only the Kindle was good at reading content and only book form at that.
Best mobile web-browser. Sure you can pinch and zoom on your phone but if you really want to surf you need something larger. This middle ground is great for a tablet sized device. You can finally read a website on a bus or train without trying to balance a laptop or looking too conspicuous.
Interface based on the iPhone. Clearly Apple has nailed the iPhone UI. They will take this base and extend it to a larger device. Not as big as a laptop but somewhere in between. The touch based interface will be enhanced with a two hand multi-touch predictive keyboard. Everyone will hate it at first. Three months later everyone will call it brilliant.
It’ll look like a flat iPhone. 90% screen, a little edge. Thin as hell. It’ll be priced so that people perceive it as being expensive and premium compared to everything else. $799, maybe more. Expect people to say… Why would I get that when I can get a Kindle for $259. That sort of thing just makes people desire it even more.
App developers will flock to it.
Magazines will be the killer content.
Social games will be the killer app.

Tags: Apple, Canvas, Iphone, Slate, Tablet, Taplet
Posted in Apple, Design, Prediction | 2 Comments »

Mobile Ergonomics for those with two thumbs

Nov 09

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.

I 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: Design, Egonomics, Iphone, mobile
Posted in Design, Telephone, User Interface, mobile | 1 Comment »

Quick Calendar UI Review – Google

Nov 09

This is a simple UI critique of a simple feature burried in Google Calendar. Here’s the 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:

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: Calendar, Google, Review, UI
Posted in Design, Google, Review, User Interface | 1 Comment »

5 Email Problems not Solved by Google Wave

Nov 09

Google wave is an interesting new technology for communication. In concept it’s supposed to fix many of the issues associated with email. While it solved some of the back & forth in traditional email threads it fails to solve a number key email issues and instead introduces it’s own set of problems by radicly changing how people work.

It’s still not possible to easily tell if your message was received, read or even opened. Just like email you will never know if the important proposal made it.
Information overload. The problem is finding what’s important. New things move to the top regardless of how important they are. Compare this to how you organize papers on your desk, important things move to the top.
If you say something stupid you can’t take it back. Just like email once it’s out there you’re done. Even if the other person hasn’t seen it yet. They will now play it back in it’s full glory.
Privacy. You can’t send something and keep the recipient from forwarding it on.
Transfer of large files or collections. You can still attach things but if you want to share 50 wedding photos or a large home movie Wave won’t help you much. It’s a communication pipe but files are secondary citizens.
Bonus #6. Spam. You’ll can still get it and you’ll still be expected to flag it. So there will be false positives. An extensive social network reputation doesn’t help. A lack of a social network doesn’t keep you from sending 1000’s of messages. It’s still early so there is little spam but this will change if this catches on.

Tags: Email, Google, wave
Posted in Design, Email, Google | No Comments »

Free iPhone Designer Icons

Oct 09

Designing icons is hard. Designing quality icons is harder. That’s why it’s great when a free resource pops up that provides over 100 free icons for your use in iPhone application designs. These icons are perfect for tab bars or toolbar use.

Often times we don’t use these icons verbetam but they provide a valuable design language and starting point that offers some level of predictability and consistency across apps.

Get them over at http://www.glyphish.com/

Tags: Design, Glyph, Icons, Iphone
Posted in Apple, Design | 1 Comment »

Interface List Design – Drupal

Oct 09

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:

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

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: CMS, Design, Drupal, Interface, Lists, Web
Posted in Design, Development, HTML/CSS, Usability, User Interface | No Comments »

Why the Chrome OS Matters

Jul 09

Two years ago I stood at Goolge’s mountain view campus in front of about 100 Linux desktop architects. The message I delivered was simple. Linux would never take off in it’s current form. A new strategy was needed and the core of this strategy was the web.

The arguments for Linux on the consumer desktop were not working:

The main argument of Linux was that it’s a free alternative, however most people get PC’s with an OS pre-installed. From this perspective ‘free’ doesn’t matter because it’s built into the price.
The second argument of Linux is ‘it’s open source.’ This argument carries some weight with businesses but a typical consumer doesn’t understand or care about open source.
The third argument is speed. Not a bad argument but when most people only care about web-browsing and email the bottleneck is usually the dial-up connection, not the x86.
Beyond that the argument isn’t very compelling. Linux provides the same abilities to launch basic apps, configure settings and has the same or often times worse compatibility issues with drivers.

The future OS is will be based on the web

Current operating systems where all developed at their core before the web was invented. We know a lot about what users do on websites and we haven’t made any of that easier in the desktop OS.
Files can show up on the desktop but live in the cloud
Everything is backed up
Web sites (apps) work online and offline
When I double click on a file in the future it should be able to open in a web-based editor and that web-based editor should be able to save that file back to my desktop.
I should not need to worry about installing and uninstalling stuff. I should just use the tools I need when I need them.

All these things are part of the Google portfolio and plan

Google Chrome – the browser and it’s integration into Google Gears can be the foundation of very complex and rich desktop class apps.
Google Docs is a web based editing suite that is obviously going after Office. The ability to click a file from your desktop and have it open online is too obvious not to happen.
Google has said that it will target the OS toward ‘netbooks.’ If you haven’t realized it all laptops are becoming netbooks as you spend more and more of your time online.

An operating system based around the web is a really interesting proposition. It’s not about ‘Linux’ it’s about a better web experience. This is what consumers are doing understand and this is why this OS matters while Linux still does not.

When I gave my talk many of the Linux architects had good comments and discussion but quickly retuned to bickering about KDE vs. Gnome. It was the Google guys, lurking perhaps, that have taken the message to heart and are building a true OS with the web at it’s heart.

Tags: Browsers, Chrome, Google, Linux, OS
Posted in Browsers, Design, Google | 4 Comments »

Going Mobile – Giving users the finger

Apr 09

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: Design, mobile, Talk, UPA
Posted in Apple, Design, Misc., Telephone, User Interface | 2 Comments »

Boston iPhone Developer Meetup

Mar 09

I’m hosting a small local meet up for iPhone developers in the Boston area. If you’re a Boston based company developing, designing or building iPhone applications we invite you to join us for a meet up on Monday March 30th.

Bring your iPhone and join us for a beer. We hope you can make it.

Additional details, directions and free tickets while they last are here:
http://bostoniphonedevs.eventbrite.com/

- Greg

Tags: iphone boston meetup
Posted in Apple, Design, Experience | No Comments »

A better iPhone tip Calculator

Jan 09

One of the very first things I did when the iPhone came out was to write a little free web based tip calculator. This was mostly a tool to learn about the web-capabilities of the iPhone while writing a simple tool. We decided we could do much better with a native application. Our new version is available today.

For this application we really wanted to do a scenario based design. We had three core scenarios in mind:

1) I go to lunch or dinner and figure out a tip

2) I go to dinner with friends and split the check with a tip

3) I go to dinner with friends and one person just gets a salad and everyone else gets a full meal with drink.

Most tip calculators get you to Scenario 1 or 2. Scenario 1 is pretty easy we need the bill total and the tip percentage and we can quickly compute the tip amount.

Scenario 2 was a little more complex but not much. We perform the original calculation and then just divide the total bill and the tip line up between the number of people.

Scenario 3 was when it got a little more interesting and I think this is a unique feature I haven’t seen anywhere else. We allow the user to go into the details of the bill and manually adjust each dinners check.

If one person had an extra drink you use the slider or plus/minus arrows to adjust their price and everyone price adjusts automatically. This can also be used as people are putting money into a pile. You can quickly see who has put in how much and what amount is left. If you adjust a slider it stays fixed allowing you to move to the next diner.

Tip Calculator for the iPhone

Our calculator allows you to see if you have an underpayment or an overpayment. This makes it easier to ask everyone to chip in another buck or two as needed.

The visual design of the application is styled to look like a restaurant napkin. While this doesn’t impact the functionality it makes for a fun and attractive design that we hope people will enjoy sharing and using with their friends.

We learned an interesting usability lesson in building this applicatoin. It turns out that it’s critical to test on actual hardware and not just on a simulator. For most of our basic development we built the application and tested it in the iPhone simulator software. It was only when we got it on an actual device that we discovered that the slider bars can be a little tricky to adjust at a fine granularity. If you had a $90 bill the slider can go from 0 to 90 and making fine level adjustments with your finger can be quite difficult. After usability testing this we decided to add the plus and minus icons to make fine grain control a little easier. We also made it possible to just hold down the plus/minus and allow the button to repeat as an added way to help peeople get the price right.

There’s a lot of subteltly in building applications for mobile devices. We hope you like this one.

Download our new tip calculator from the App Store for $0.99

Tags: Apple, Application, Calculator, Iphone, Raizlabs, Tip
Posted in Apple, Design, Development | 10 Comments »

Archive for the ‘Design’ Category

Info

Categories

Archive

Comments