Archive for October, 2006

Electronic Voting Machines – Usability

Oct 06
30

Recently the voting machines down in Florida seemed to be causing some problems. Last year I had the opportunity as part of World Usability Day to play around with two of these DieBold voting machines. These machines had some major problems in the UI design. These problems alone could easily cause someone to be confused and inadvertently vote for the wrong person but the issue that really stood out was the touchscreen.

The issue with the touchscreen was that it required to be calibrated. If the system was calibrated correctly the location of your touch would match the location pressed on screen. But if the screen was not calibrated you could be way off. This was a known issue two years ago, I’m really surprised it hasn’t been fixed.

Unlike a traditional mouse the touchscreen doesn’t display any-visual feedback of where the computer believes your finger is. The result is that the computer cursor can be far from the actual physical location.

This is a great example of why real world testing and usability is needed. Given a simple task 50 people who are asked to vote for A and 50 people who are asked to vote for B you should have a task success rate of 99% or higher and you should be able to verify that 100% of the results are correct.

Although it’s possible that there is a voting conspiracy I believe it’s far more likely that the voting machines have bad UI and even worse touch screens.

PDA With Dynamic Keyboard

Oct 06
30

I’ve always enjoyed playing with consumer electronic devices but I’ve yet to design an interface for one. I worked on a touch-screen system for the New York Stock Exchange but never a consumer product. Recently I was toying with some concepts for a PDA/Phone with a dynamic keyboard display.

The idea is fairly simple but powerful. Rather then have a screen and keyboard you instead extend the screen bellow what would normally be the keyboard and use soft transparent buttons as the keys. To the user it still appears to be a plain old screen and keyboard but the advantage is you can dynamically change the keys.

This allows you to alter the face of the keyboard based on the mode that the user is in. In this example when the user is entering text they get a primarily text based input keys but if they are entering a telephone number they can either dial the number, choose a photo of one of their friends or spell out the number if needed (1800-flowers for example).

Advantages

  • Hard buttons provide tactile feedback (no touchscreen keyboards please)
  • Buttons are in-sync with the UI so you know what options and buttons are available
  • The same hardware can be used in multiple locals so you don’t have to have region specific keyboards
  • Type feedback – as you type the letters that are unlikely to create words can be dimmed out.
  • Richer UI for application development, Calendar, Contacts and other apps could be enhanced. (Think Nintendo-DS ideas in a phone)
  • Larger keys in a smaller space. Because the keys are dynamic you can use larger keys without all the extra text. This makes the keyboard easier to read and use.

The idea was partly inspired by the Optimus keyboard concept. Although the design intent, platform and implementation would be very different the idea of dynamic keys is fairly powerful regardless of the platform.

Rosie – Segway Style Concept

Oct 06
24

Rosie – Segway Style Concept


Rosie started out as a concept in the summer of 2003. It was loosely based on the idea of creating a more radical and more fun version of a Segway.It was designed as a single wheel portable device that could be ridden like a BMX bike but without the skill.

Rosie was affectionately named after Rosie in the Jetsons cartoon.

Device Goal: The goal of the device was to be light weight, fun, portable and in-conspicuous. The last part is important because people are afraid to buy something that is too futuristic. The device needed to look somewhat familiar, like an elegant bicycle, to gain acceptance. We wanted to specifically avoid a visual association with the Segway and instead create an association with a bicycle. (Hence the spokes)

The conceptual drawing was made from a picture of a unicycle. The idea was to create a small motor that would either be part of the handle-bar or alternatively an in-wheel motor.

Research

We researched the concept and found that there was no existing device that did exactly what we where trying to build but we did find some interesting devices:

We found a motorized unicycle that as far as we could tell is balanced by the driver manually adjusting the throttle. We found one other reference to a motorized unicycle. Both of these have been gas powered and could only go forward. The driver would make small adjustments to the throttle and his weight to keep the device balanced. This is similar to a bicycle or motorcycle doing a wheelie.

We also found a fairly old invention called a mono-cycle or mono-wheel. This is where the driver is on the inside of the wheel and is balanced by gravity pulling him down to the bottom of the wheel. Many monowheels exist and there are enthusiasts today who still build them with large motorcycle engines. Their large size generally makes them somewhat unwieldy and the wheel generally blocks the field of vision.

Around 2003 Bombardier came out with a concept design that came the closest with a single wheel futuristic motorcycle design. This concept however was never actually built to function.

Again our device was supposed to be a bicycle-style device not a motorcycle.

Technical Research

The problem of balancing a device was actually solved long before the Segway. The problem is generally known as an “inverted pendulum” problem. I refer to this as the broom balancing on my finger problem. Explained simply remember that Force equals Mass times Acceleration. You calculate the force of a falling body on a pivot point (in this case your finger), use gravity as your acceleration, and then apply the opposite force to your finger to keep the broom balanced. If you are able to compute how fast the broom is actually falling you can make adjustments to keep perfectly balanced. This technique is used in helicopters, walking robots and even skyscrapers to minimize the effects of wind.

There are two devices that we choose to use to measure our rate of falling, an accelerometer and a gyroscope. A gyroscope will tell you how much your angle of rotation changes over time. An accelerometer tells you which way is down. Together the two can act like a compass that always points straight down.

Building a Model

We needed to build a model to learn how to use our gyroscopes and control boards effectively. Our model used Lego as a simple building block material. Controlling the apparatus was a PIC board that is essentially a small chip that can be programmed from a computer.

Onboard our model had a gyroscope that sent signals to our PIC board. As the device started falling in one direction the gyroscope would send signals to the processor and the motors would reverse to keep the device balancing.

Using the model we where able to get the device to balance for several seconds. Because the model did not have an accelerometer after a few seconds the device would accumulate gyroscope drift. This drift is caused by slight inaccuracies in the gyroscope angel causing the device to fall over.

Building a real prototype
The actual Rosie prototype was built to be low cost. We tried to use as many off the shelf parts as possible and had a goal of creating the initial prototype for under $1000 in total parts. We constructed the bulk of the prototype but never complete the final design.

Current status
We put Rosie on the back-burner in 2004. It turned out that Segway has a patent on a similar idea. We also felt that if Segway couldn’t build a thriving business from a two-wheel product it would be difficult to do the same on a much smaller budget.

Hopefully this post sparks some ideas and helps others as they pursue their own ideas. Any companies interested in more details on the Rosie concept can contact Raizlabs for additional technical documents and related information.

Special thanks to Matt Malchano and Blake who designed and programmed the initial prototype.

Links:

User Interface Design for Software Developers – Update

Oct 06
11

User Interface Design for Software Developers – Update

For anyone in the Boston area I will be speaking tomorrow at MIT on user interface design for software developers.

The meeting will be held in a classroom in MIT’s Stata Center, Bldg. 32 Room 144, onThursday, October 19th. Catered food from Anna’s Taqueria will be provided. Yumm.

Networking at 6:30 and the talk at 7:00pm. Please RSVP



Many interface designs aren’t created by designers but rather by developers.
So why do so many developers create hard to use software?

One of the reasons is that developers approach problems in a very different way.

A developer will typically take a problem and deconstruct it down to the functional components that can solve the problem. This may sometimes be a list of features, functions, objects or components. The interface tends to be data and object driven. The interface is a mechanism to test out the functional aspects of the application.

Users on the other hand don’t think of the application construct or the inner workings. Users rarely construct a mental model of the application. Instead they simply know what they want in terms of a task and they try to identify appropriate features to complete that task.

Developers build software by solving problems using “Object Oriented Thinking”
Users solve problems using “Task or Goal Oriented Thinking.”

Fullscreen Google Video and YouTube

Oct 06
4

One of the drawbacks of Google Video, YouTube and many other online video sites is that the video can’t be played full screen from a flash player. Well it looks like Adobe thought the same thing as they just introduced fullscreen playback in Flash 9.

One concern of full-screen mode is that it could be used to trick people into typing passwords into fake login screens. Those clever folks at Adobe thought of this scenario and prevent keyboard input while in full-screen mode.

The flash 9 player seems to be in beta but I expect that before the holidays all the main video playback sites will be sporting full-screen video playback.

More on the CSS sucking

Oct 06
2

More on the CSS sucking

A couple weeks ago I managed to get a bunch of people upset by saying that CSS sucks. The comments were A) I don’t know CSS B) The web and CSS isn’t about design. C) Don’t blame the CSS blame the browser and D) Back-up your claim by proposing something better.

In short I’ll point out that A is not an argument, B used to be true perhaps in 1994 but is no-longer true. People who suggested that I should blame the browser and not CSS should take a close look at the actual CSS spec. I’m not at all surprised that browsers interpret the standard differently and have mistakes in how they render HTML & CSS. Specifications and standards can be overly and unnecessarily complex. CSS has a lot of good concepts but the fact that no two browsers are able to nail the spec it is a huge problem.
Ok. Enough complaining. To propose solutions.

The flash format is actually a fairly large step toward a better overall web-design tool.
It’s much more consistent across browsers and platforms. It handles graphics, design and animation with precision. Flash isn’t ideal for flowing large amounts of content and it doesn’t integrate with the navigation of a page. The largest obstacle to flash is that you can’t link between pages of content. Multiple pages of Flash content is treated as a single page within the browser. Adding a navigation element to Flash could allow sites to substitute HTML pages with Flash based pages. This would also allow Google and other search engines to parse and link to specific content.

Ok, idea #2… Beyond the flash story how could you address the CSS issues within HTML?
I’ll break that problem into two parts. Part A is the things that have to be done within the browser. There’s no easy hack around these things and it’ not something that can be fixed in a blog post. These are intrinsic things that should be available in the core HTML rendering platform:

  1. JavaScript drawing primitives (boxes, lines, gradients, canvas objects, etc)
  2. Font control and font embedding (Mozilla & Apple don’t have this and perhaps a better implementation for IE is in order)
  3. Anti-aliasing control on fonts/text/images
  4. Rendering effects via JavaScript (Rotation, reflection, scale, animate)

I put these in this order because #1 will allow you to do almost anything you want in terms of layout and design as I will discuss later. #2,#3 will help accessibility by pulling fonts out of images. #4 is optional and would help performance for real-time rendering and effects.

Part B is the styling attributes, look and feel and layout. There are two possible solutions. The first possible solution is to start from scratch. While this is desirable it’s perhaps too far reaching. Instead I’ll propose a solution to style pages that that:
- Doesn’t involve CSS in the traditional sense
- Is accessible – for screen readers or alternative devices
- Allows for semantic markup
- Is optimized for tools
- Is cross browser

Before I get into my proposal a bit of history. Back in 1998 as part of my college senior project I designed a cross-browser HTML editing and animation tool. At the time Microsoft had just introduced DHTML and Netscape had recently made layers possible. Although the two technologies were different they made it possible to position elements on the screen in somewhat predictable ways. The program created layers and absolutely positioned elements and allowed the user to both position and animate objects across the screen.

The editor tool created a library array of objects and then set the position of those objects on the screen using a JavaScript timer. The key thing about this method was that the browser didn’t manage the layout of the screen. It was up-to the designer at design-time to decide where objects would go. At run-time the position of the objects was simply a result of the JavaScript execution.

Back in 1998 the problems with layout sounded similar. Thee were incompatibilities in using tables and transparent pixels to create web-pages. There were all sorts of browser hacks to try to get things to line up right.

The solution I used back then and the solution I propose now is to use JavaScript to render the layout instead of having the browser position screen elements. You still use CSS classes to style fonts & colors but you don’t allow the position to be specified in CSS. Instead you position and size elements in the design tool and allow these properties to be set at runtime via JavaScript (or even AJAX if you’re so bold).

There are many nice things that happen when you use CSS just for fonts and JavaScript to control the layout.

  • The page loads fast. Since all elements are absolutely positioned and you’re not cascading the browser doesn’t have to wait long to render.
  • The styles are deterministic and predictable.
  • The placement, margins and positions are easily editable (assuming you’re using a tool)
  • You can have consistent sizes that are re-used across the layout.
  • Your layout can be parameterizes so elements line up and stick together as designed even when the browser resizes and content flows.
  • You can specify alternate element positions for smaller sizes making it possible to use the same content for mobile applications. Since the position is set in JavaScript it happens at runtime and adjusts to the device it’s running on.
  • You fight less with the browser because you only use a few primitives. In addition any browser hacks or tricks are done by the JavaScript compiler and not by the page designer. The page just works.
  • You can re-order the content tags anyway you like so that accessible browsers read the tags in the order you specify. This level of control is often impossible with CSS.
  • The approach is future friendly. As new browser features are exposed the script can progressively and safely expose these features.
  • You can mix traditional HTML/CSS with this new approach
  • You can think outside the box-model.

In many ways you design the page and then compile it down to the appropriate JavaScript that would render the content. This is similar to how PDF/PostScript documents are created. The postscript file is actually a programing language and your document is represented as a series of function calls, loops and procedures.

The concept address many of my own complaints but there are some drawbacks to this approach.

  • Hand coding page layout in JavaScript is slower then writing CSS. To do this properly you need a tool. My college project wouldn’t cut it although a similar approach could be used to create a rich-tool. In theory if you had the items #1,2,3 &4 you could even write a printer driver that would convert any document into a web-page.
  • View source won’t tell the whole story. This is because in some sense the page is pre-compiled from the editor tool into the JavaScript representation. The compiler may optimize the layout or code and may even discard certain editor specific meta-data that doesn’t need to pushed into the web-page. For people who insist on hand coding this may be a drawback.
  • Different tools could produce pages that don’t necessarily transition well from one tool to another. This is because the pre-compilation step and the resulting JavaScript file would vary between tools.

These are two possible approaches to the problem. I’m sure there are many others. It’s easy to poke holes in these ideas but I’d rather hear your concepts.