This video is from a talk I did on mobile design and user experience. The talk was given at 360iDev in Denver.
Designing for Thumbs and Fingers from Greg Raiz on Vimeo.
Designing for Thumbs and Fingers
Reply
Tag Archives: User Experience
9 Things I didn’t know about the iPad
- The keyboard design isn’t as slick as the iPhone keyboard design
It’s not quite a MacBook keyboard layout and it’s not an iPhone keyboard layout either. Commit actions like, done, go, search aren’t colored like on the iPhone. The dashes, dots, commas are hard to distinguish. On the iPhone a typewriter like key pops out so you can visually confirm that you hit the right key. On the iPad there is no feature to deal with occlusion. - How you hold the device really alters the user experience and how apps should be designed.
On the iPhone the design is done in such a way to accommodate the way you hold the device. For example in mobile Safari and in email the command buttons are along the bottom of the screen. This puts many buttons in thumbs reach. On the iPad key buttons in both email and Safari are across the top. This means that if you’re holding the device along the bottom you can’t reach many of the buttons without moving your hands. Since the home button tends to be along the bottom there’s no comfortable rest-state. - About my laptop
It starts out with just email and some web-browsing but pretty soon you realize that most of the things you do can be done on an iPad. Not all, and this gap is closing. In particular heavy typing tasks (blogging for me) and heavy editing, especially visual and graphics editing is still better with a laptop. That being said I am much happier bringing a light iPad to a meeting then a heavy laptop. - You don’t use this device like a giant iPod.
I’ve never read a book or a magazine before on either my laptop or iPod. I’ve never played a four person multi-touch game on either of these devices. The experience is different and fun. In a new way. Magazines and books are key here. This is the future of digital content. - Certain people could use this as a replacement computer but I can’t.
Email and web browsing without compromise. (Well maybe the Flash thing) Other then that you have a pretty nice device for doing the core things my mom uses her computer to do. For technical users the iPad doesn’t do enough to replace their laptop. - Screen orientation is flipping me out
When you hold the screen in vertical orientation you get 4 icons across and 5 icons down. When you flip the screen you get 5 across and 4 down. The annoying part is that the icons re-positions so you can’t use spacial memory to find an icon. Was that icon on the top right? Ohh, sorry now it’s in the middle left. - The web is not ready for the iPad (yet).
There are still plenty of sites with embedded video/flash and when I hit these sites I am likely to move on. I almost never stop what I’m doing to go grab my laptop. As the iPad sails past the 1M mark the tech-savvy sites will transition over to H264 video. The issue is primarily video although other flash goodness will still be missing.
Flash sucks but HTML5 is worse then Flash on many things, more on that in another post.
Subscribe to this blog to hear more on that.
- The battery lasts a freakishly long time
It’s nothing like a Kindle but compared to other bright-screen electronics. Wow. That’s all I have to say about that.
- A different user experience is fundamental to touch computing
I remember a program manager from Microsoft talking about the Tablet PC back in 2000. He said, in the history of computing there has never been a product category that has failed as often as tablet based computing. From the Alan Kay to the Apple Newton and even Windows for Pen Computing. The history books are filled with these ‘slate’ computers that have failed. He then went on to explain how the Tablet PC would be different because it focused on the input experience.The truth is that the tablet/slate experiences of the past were not that different. It was Windows with a great input editor. It’s too early to tell if the iPad will succeed or fail but the iPad user experience is so different in a fundamental way that it will change how people interact with computers.
How do I know? My two year old is now reached out and trying to scroll the screen on my laptop. If that’s not the future I don’t know what is.
Drupal User Experience
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.
Twitter Scalability – Performance is user experience
This is not another post about how bad performance is on twitter. There are planty of other people talking about that. Instead this is a post on how you can define performance expectations in terms of the user experience.
For example:
- When I open a file that’s very large I have a different performance expectation from when I open a small file.
- When I send a large package by mail I expect that it may take longer then a postcard or a letter (unless I pay more).
- When I travel I expect it’ll take longer to get somewhere if it’s further away.
These expectations are defined by the task at hand. Consider how the Twitter service is trying to scale and provide performance expectations.
- A person that is tracking 10 friends has the same user experience performance as a person that is tracking 10,000.
- A person that is being tracked by 10 friends has the perception that their messages are delivered as quickly as a person being tracked by 10,000
- My stream of data is updated in real time regardless of if I visit the site once a year or once an hour.
Basically the way the user experience is ‘unfair’ in it’s balance of resources. Regular users of the site are punished by the super users. If you think of the site as a utility then each person using the site should be entitled to a somewhat equal share of the site resources.
The Twitter status blog makes no secret that they believe they should be architected as a messaging system. Each time a person posts a message it’s ‘sent’ to the followers of that person. So each time a popular users posts a message it may be sent to 20,000 ‘inboxes’ this can result in a mass ammount of back-end servrver requests to process the messages.
Consider how the performance expectations could be set through a simple user interface change:
By simply telling users that updates for that user are being sent and a percentage of those updates is complete it begins to set expectations for how the performance of the service will scale. For a user with 50-100 followers the sending performance will continue to be relativly quick but for users with tens of thousands of followers there is the expectation that it could take several minutes to get all updates out.
If you define the user experience you want to achieve you can architect your system with this in mind. The above implies that each user would have their own outgoing message queue. This is similar to an outbox in email. A collection of worker machines could then cycle through all the users and process a certain number of operations per user.
- If the user has messages in their outbox process X messages and deliver them to the appropriate end-points, sending to the most popular people first when possible.
- If the user has no messages in their outbox process Y people that they are following and pull messages from those peoples message queues.
The above is a fairly simple system that is similar to how a CPU kernel will perform process time-slicing allocating a consistent amount of time to each system process. Similarly each person is allocated an equal slice of the sending/fetching pie. The above process has the following nice characteristics:
- If you follow few and few follow you you’ll have a very responsive experience.
- If you follow few and many follow you most of your time is spent sending updates.
- If you follow many and few follow you most of your time is spent fetching updates.
- If you follow many and many follow you your updates don’t slow down the system they just get added to the queue. Additionally people with lots of followers are able to carry on conversations with other popular people. (The Techcrunch chatting with Scooble problem)
The systems would scale in a more linear way. Certain users would experience slow sending durring peak times but this would be more isolated and a problem that is easier to solve with more worker machines. The key thing is that by setting the user experience expectations of performance with an outbox or a sending status the users of the system can visually see the health and performance of the system.