Archive for December, 2005

Car Dashboard User Interface

Dec 05
29

Recently Mercedes showed the beginning of dynamic car interface design. In some respect cars have always had interface design only it’s been more mechanical and dashboard design and less of a dynamic computer based interface. In the next 5 years I expect most high end models to begin to incorporate dynamic interface.

Car Interface design represents one of the biggest challenges in terms of interaction models.

  • Hand and foot interactions – gas, break, turn signals and steering wheel
  • Real time interactions – Obviously the car is moving everything needs to happen real time
  • Multiple system integration- Mechanical systems, Climate control, Entertainment system, Navigation systems, Safety systems and Communication systems.
  • Multiple displays, gauges and outputs all competing for visual attention.
  • Alerts, notifications and distractions both on the screen and on the road.

Not only is the car a house on wheels but it’s also contains more technology and computer power then in the original space shuttle.

The current Mercedes design is certainly a step forward but it’s a got a long way to go. The current design is constrained and limited by the dashboard designs of the last 100 years. The advantages of a dynamic screen is that it can be used to display more complete and more detailed information with contextual detail at each level.

  • The advantage of a radial gauge is that the mechanics are simpler then a linear control. In terms of displaying this information on a computer screen there’s no reason to take up 50% of the screen with something that could be shown as a simple indicator. MPH is important but it’s readability could be improved more by using a nice elegant and attractive font then with a traditional dial.
  • R, N, D, S, P. Cars have for years used a single letter for key features and functions. It’s as if there is a tax on using a whole word. Sure I know that these are Reverse, Neutral, Drive, Sport and Park but in an on screen interface it’s ok to use the whole word.
  • That said, why are R, N, D & P even on the dash? Shouldn’t these be drawn on the shifter? Perhaps these are hidden when the car is being driven?
  • Icons with no explanation – Sure I may know that the red guy with a line through him is supposed to be an indication to buckle up but in an on-screen interface you can say it explicitly or even shown a picture indicating the exact buckle that is open.
  • Lack of visual design and color – I’m not suggesting that the interface should be splattered with color or over designed but the design of the dashboard should feel like it’s an extension of the car. The high end styling of Mercedes should be easily apparent in the visual design, icon design, fonts and visuals of the dashboard. The interior accent colors should be reflected in the accents in the UI. If I own a red car the accents should be tinted red.

A car is a visual extension of status, aesthetic and design over the next few years I expect the auto-makers to jump on this and make car interface designs simpler, friendlier and more customizable. The trend of themes and ring tones that you see for cell phones today will likely spawn a similar after-market for high-end dashboard upgrades. Your ride will be pimped both inside and out.

Email Folders vs. File Folder

Dec 05
27

Why are email folders so different from file folders?
Cut Copy Paste:
You can cut copy and paste email folders and file folders but you can’t move one to the other.

Search:
You can search email and you can search folders and files but unless you have a desktop search engine installed you can’t search both.

Share:
You can share folders between computers but unless you have some special email client and server you can’t share emails or folders of emails without actually forwarding the messages.

Control:
Every program can easily interface with the filesystem and enumerate folders, and items but if you want to control, export, or interface with email you need to know the specifics of the email client.

Attach a file to an email or save an email to the desktop and the concepts begin to merge. Both a file and an email are at their core very similar. Each one contains an idea, a thought or concept. Each one is created saved and retrieved for later viewing. What if all your files existed in your inbox? What if all your emails lived in the filesystem? Today the separation of these two worlds is artificial.

The Unified Store
Bill Gates has wanted a unified store for the last 10 years. A single architecture that can hold both emails and files. A single database file-system that can bring these two worlds together. This is a huge opportunity for anyone in the operating system business.

Advantages:
A more powerful file system as well as a more powerful email application. The advantage of combining the two is that you get the best of both worlds. Rich meta-data on files, sharing and searching on emails, unified backup, unified sharing, unified security, unified interactions.

Public information seems to indicate that Windows Vista is not going to include a unified store and that Outlook 12 will not undergo a radical face-lift. Looks like the door stays open for another five years. The question is will Microsoft, Apple, Google, or Linux get there first?

Richer Browser UI Thumbnails

Dec 05
22

I was playing around with a couple of FireFox extentions that add some interesting thumbnailing capabilities to the browser and it reminded me of a sketch I made of adding rich thumbnail capabilities into the browser back button.

The idea was to show richer previews when opening the “split-button” section of the browser back button. I had another similar design that showed your navigation history as a film-strip across the top of the browser as well. Both designs looked to make the browser more of a visual tool by helping you identify pages visually rather then just by their text descriptions.

Searchable User Interface

Dec 05
14

Assume for a minute that you had a product with 1,000,000 features. Each feature has a unique function and performs a specific unique task. As a UI designer how would you approach this design problem?

A quick look at today’s common UI metaphors would show that conventional tools won’t work. Menus can’t scale to 1000 items let alone a 1,000,000. Tabs don’t scale well past 10 items. You can’t hide the functionality in advanced buttons and secondary dialogs. Today’’s UI controls are oriented around basic browsing, and even these browsing controls quickly break down. What you need is a UI control that can scale to 1,000,000 items.

Search + Lists
A searchable list is the grand-daddy of scalability. Searchable lists can handle billions of items. The more precise your search the better the results. The reason we’ve never had searchable UI is that we have yet to really hit a brick wall with browsable UI metaphors. The other reason is that it takes a significant investment in search technology, indexing commands and creating results that are both meaningful and actionable.

Searching Help
When you think about searching for functionality a common place to explore is the help area of the interface. Why is it that ‘help’ isn’t very helpfull? Well for one thing ‘Help’ search technology isn’t very good. The search results are based on simple keywords and the content is limited to the content written by the developer. Thousands of useful articles are available to Google users but not to the actual user in the application searching for help. Help also isn’t actionable and it doesn’t understand context. If I have some text selected and I search for ‘italics’ the search results won’t allow me to perform the action, instead I have to follow a list of automated steps to complete the action. In addition if I search for more abstract meanings of ‘italics’ such as ‘emphasize text’ I’m unlikely to find my command.

One App Size Fits All
In larger applications most users tend to use just a small portion of the entire applications functionality. The problem is that this tiny portion varies greatly from person to person. Applications developers build-in and expose more and more features to ensure that your needs are satisfied. Unfortunately today’’s interface designs force users to pay a mental tax for all the features you don’’t use.

Imagine your favorite application void of cluttered toolbars, menus, floating pallets and dialogs. This approach can be applied to everything from document centric applications like PhotoShop and Excel to content centric applications like Itunes or Outlook. The application has just the bare functionality needed for basic operation, nothing more.

Now imagine having a search engine for your features. Instead of assuming that you need all 1,000,000 features we’’re going to assume you need next to none of them. As you search for features the results of the search will describe each feature, what it’’s used for and what types of tasks can be accomplished. As you scroll through results of functionality you can use the commands right away.

Such applications would allow you to spend less time playing with the features of the application and more time working on the content of your ideas. An application with everything you need and nothing you don’’t.

Learning
If you did have a searchable interface the next problem you need to think about is discovery. How would I know to search for functionality if I didn’t even know that it was possible? This brings us into another familiar area, scalable browsing. Also know as category navigation. Instead of navigating tabs and menus you can imagine navigating pages of content like in a Yahoo style directory structure:

Look and Feel > Text Appearance and Prsentation

Colors Font Faces Text Decoration
Backgrounds Document Themes Apply document styles

Put it together
The two techniques of rich browsing and functional searching will allow user interfaces to scale beyond their current design limitations. The most designs of the new Office are already hitting the wall with Menu’s and Toolbars and the recent ‘Ribbon’ design reflects a better approach to task centric browsing. Even though this is a much better approach it still won’t scale as more features are added in each subsequent version of Office. The next page in application design is the ability to search for UI. This will bring us closer to the 1,000,000 feature application that not only has a 1,000,000 features but is also user friendly.

The Linux Attitude

Dec 05
12

I had the extreme pleasure of being called a F***ing Idiot by Linus the original creator of Linux. It’s with such ferocity and conviction that he called me an idiot that has me concerned about a possible future and direction of Linux as a main-stream easy to use operating system.

The main concern is with user interface design, simplification, ease of use and usability. Rather then sway your opinion I’ll let you read the thread on your own.

To frame the discussion this was about how the printing dialog in Gnome was perhaps over-simplified and didn’t show all the capabilities of the printer.

Linus:

I personally just encourage people to switch to KDE.

This “users are idiots, and are confused by functionality” mentality of Gnome is a disease. If you think your users are idiots, only idiots will use it. I don’t use Gnome, because in striving to be simple, it has long since reached the point where it simply doesn’t do what I need it to do.

Please, just tell people to use KDE.

Linus

Greg:

Technical users often feel that a usable design can dumb down the interface.
If this is the case then it’s a poor design. A good design will be easy for a beginner and will also provide the tools, advanced buttons, options, right click menus and settings to satisfy technical users.

The majority of end-users want a simple printer dialog. In fact most people will just hit the Print button without changing any settings. These users are not ‘idiots’ they just have better things to do then futz around with printer settings. On the flip side I’m sure there are many pre-press publishers who want to tweak and change every setting. The two design goals do not have to be at odds with one another. A good design will satisfy both.

Linus:

No.

That’s not what I’m talking about at all.

When user interfaces means that something CANNOT BE DONE, it’s not about “usable design” any more. At that point, it’s about UNusable design.

Any Gnome people who argue that it’s about “usability” have their heads up their asses so far that it’s not funny. I’ve argued with them about this before, and I know others have too, and mostly given up.

“Usability” is an issue only if you can do something at all. But if you can’t do the thing at all, it’s pointless to talk about usability: the thing is BY DEFINITION not usable if it cannot be used for a specific task.

Then a person that claims that it’s usable for something else is a F***ING IDIOT.

And in that F***ING IDIOT vein:

> The majority of end-users want a simple printer dialog.

This is a great example of being a F.I.

There is no such thing as a “majority of end users” in general. For example, maybe _I_ am in what you _claim_ to be a majority, in that I want a simple printer dialog – because I have a simple printer, and even simpler printer needs.

So a simple printer dialog doesn’t bother me, and as such you can count me in your “majority”.

But I can guarantee you one thing: the _vast_ majority of people are part of a specific minority when it comes to something. This is somethign that the F.I. “interface designers” in the Gnome sense seems to continually overlook.

For example, maybe I don’t care about printers. But I _do_ care about my mouse. If I can’t control the left/middle/right button actions, I get really upset. Again, the “majority” of people may not care, so by your majority argument, the mouse setup should be so simple that the majority of people can never get confused. But I _do_ care.

In other words: your “majority” argument is total and utter BULLSHIT. It can be true for any particular feature, but it’s simply not true in general.

To put it in mathematical terms: “The Intersection of all Majorities is the empty set”, or its corollary: “The Union of even the smallest minorities is the universal set”.

It’s a total logical fallacy to think that the intersection of two majorities would still be a majority. It is pretty damn rare, in fact, because these things are absolutely not correlated.

And the technical term for somebody who claims to do user interface design and not understand this fact is a “F***ING IDIOT”.

And this has _nothing_ to do with “technical users”. Even totally non-technical users care about something. In fact, it might be their printer, and having a way to set the paper type and resolution by hand.

Another way of saying this: we’re _all_ “special” some way. We’re damn quirky, even the nontechnical among us.

But hey, just continue to remove all that confusing functionality from Gnome. I don’t care. I voted with my feet.

Linus

————-
It’s interesting that Linus goes off on a rant about the majority and minority since my example of a typical user and a pre-press publisher specifically talks to the minority/majority case. A good design will be optimized for one but should be usable by both. I’m not speaking to Gnome in particular just general design. (The entire ugly thread can be read here)

I’m curious to hear comments from other Linux contributors and users. Does Linus echo a general attitude in the community? If simplicity and ease of use come at the cost of removing certain features is this a worthy trade off or are interface designers “F.I.”s for trying to simplify things?

archived 11 Comments

Twas the night before meltdown

Dec 05
8

Twas a night such as this one and all through the office,
Not a creature was stirring, not even the bosses.

The servers were hung on the blue screen with care,
In hopes that the updates soon would be there.

The employees were nestled away from their cubes,
While strange infomercials danced on their tubes.

My desktop and Tivo, my laptop and Mac,
Had just powered down for a long winter’s nap.

When out on my hard drive there arose such a clatter,
I sprang from the bed to save the bits from the platter.

Away to the tower I flew like a flash,
Removed my peripherals and emptied my cache.

The drive sputtered down and as the smoke cleared,
My data was lost I hadn’t backed up in years.

When, what to my caffeine filled eyes should appear,
But a miniature thumb-drive, and a couple of beers.

With a little old driver, so lively and quick,
I knew in a moment it could just do the trick.

More rapid than Google the futility came,
I shouted and cursed as I called them by name.

Now, Windows! Now, Dell! Now, Intel and Segate!
For such a disaster I deserve quite a rebate

A stack of CD’s to the top of the wall!
Now crash away! crash away! crash away all!”

So on through the night the curses they flew,
I wish I had backed up a sector or two

And then, in a twinkling morning of day,
I found some of my data squirreled away.

I sprang from my desk to try to re-make,
The dashed broken bits of a hard-drive mistake.
And just as I finish you’ll hear me explain

Run your backups by night or suffer my pain.

- Happy Holidays from Greg “yes I crashed my hard drive” Raiz

Email 2.0

Dec 05
6

The initial version of email has a lot of problems that can not be addressed by making minor modification to the way that email is trasnsmitted. A new architecture needs to be developed to begin to replace our current email infrastructure.

Problems
- No guarantee or acknowledgement of delivery.
- No accountability for who sent the message (spam)
- No guarantee on latency or delivery
- No general security (email is sent as plain text)
- No standard messages for bounced, inactive accounts or full accounts

Our current system:

Greg -> Server1@host.com  <- net ->  Server2@host2.com <- Kathy

Today Greg sends a message addressed to Kathy@host2.com. Greg’s mail server releases the message onto the internet. The message is sent back and forth between servers untill it reaches host2 or untill the servers give up. Greg has no way of knowing if the message was delivered. Kathy has no way of knowing if the message recieved is legitimate.

Proposed solution :
Greg types his message and sends it to Host1. The host creates just an envelope consisting of an encrypted key for the message, Greg’s name and the address of Host1. This envelope is sent across the internet in a similar fashion to our current email system. If Host2 recieves the envelope it can connect back to Host1 and retrieve the message securly using the encrypted key provided in the envelope. If Host2 never recieves the envelope host1 can automatically resend the envelope.

Send just the envelope wrapper using Email 1.0

Greg -> Server1@host1.com  <- net ->  Server2@host2.com <- Kathy

Once Kathy’s server recieves the envelope it connects securly back to Greg’s host and downloads the body of the email.

Server1@host1.com  <- net  <- Kathy

This is better then the current system for several reasons

  1. This makes it much harder to spam. Currently after a message is sent the sender can disapear on the internet. The new system requires that the mail server holds outgoing mail and waits for it to be retrieved. This provides a greater level of accountability. Additionally it means that each message is recieved from the correct host. Since the reciever connects to the sender computer to retrieve the message it is no longer possible to forge email addresses unless you have control of the sending host computer.
  2. Once a message is sent it can be canceled or corrected before it is retrieved. Everyone who has used email has hit send and wished they could fix, correct or cancel their message. This new architecture would make it possible. When you hit send you are now just sending an empty envelope the message is only retrieved when the server wants to download it.
  3. The new approach allows you to tell when a message has been successfully delivered. Since each envelope is unique and has a unique key you could easily tell when the message was retrieved. This doesn’t prove that the message was ‘read’ but at least you know it didn’t get lost along the way.
  4. Initially the system could be made to be backward compatible with current email networks. Initially the envelope could also contain the body of the message as well as the secure key. Email software that is aware of the key could download the message securly to help authenticate the sender. Email software that is not aware of the security key would just see the message. There would be incentive to upgrade your email client since it helps ensure that messages sent are delivered. Recieving less spam would also be an insentive to upgrade. In addition many of the clients could be updated transparently by simply updating the backend server and still delivering mail to the client applications using traditional pop3 and imapi. Another way to grow adoption and still have backward compatibility is to format the message in a way that brings users to a secure location:

    You have recieved a secure message from: ‘Greg’ who is using Email2 for secure communication. It seems your server does not support email 2. You can read this message by installing email2 software or by clicking this link: https://host1.com/key/23232082959372

  5. Email communication would be more secure. Although there is no perfect way to secure email commuunications the new system would be more secure then the curent system.

Having a framework for developing a new email technology would allow for other advanced that are desperatly needed.

  • Standard subscribe / unsubscribe headers
  • Standard bounce messages
  • Standard threading and referenceing (rather then including messages in each mail)

I think a revision to the way Email is sent and recieved is long overdue. Even if this isn’t the exact solution we really need to rethink the way that Email should work.

Pondering in Portland

Dec 05
4

This week I was invited to Portland, OR to speak at the Open Source Development Labs (OSDL) architects meeting. The group assembed represented the majority players in the Linux community including major companies, individuals and contributors to desktop Linux.

A number of individuals representing both top companies and industry companies were present including Redhat, Suse, Ubuntu, Mozilla, OpenOffice, KDE, Gnome, FreeDesktop, IBM, Adobe, Real Networks, Linspire, One Laptop Per Child project and many others. Together more then 70 architects level people where present.

The Goal? To discuss adoption blockers, common goals and key problems and strategic next steps.

What was I doing there? A Windows veteran with only a couple months of Linux experience? I was providing a view of an outsider looking in. I presented a revised presentation based on my Linux Thoughts article.

Circulating through a room full of Linux developers is actually quite similar to talking to room full of Windows developers. The terminology and acronyms change but the substance and content of the conversations seemed strangely farmilar. I can’t tell you how many times I heard people say “It just works” in reference to Linux hardware support. This used to be a buzz phrase that was used when developing Windows XP.   Scary. I met a number of interesting people and I am thankful for the opportunity.

My talk covered four key areas. I hope to be posting the slides later in the week.
- Why people avoid change and what can be done to make it easier for people to change desktops.
- How to improve the quality and diversity of software applications by improving the development environment and ISV story.
- Improving end to end user experiences by improving hardware and software compatibility and installation.

Overall I was surprised how well the talk was received. Online I got a lot of critical comments from people on Slashdot but in person many Linux leaders came up to me after the talk to tell me how much they enjoyed the talk and how they found it enlightening.

After the talk the group collaborated in identifying core focus areas for the meeting. The key areas identified included:

Hard Technical Problems
- Need to fix developer and ISV confusion. The core issue here is that it’s not easy to develop cross distribution applications for Linux. Documentation, samples and recommended best practices are lacking. The two major interfaces of KDE and GNOME make it difficult for developers to understand how things ‘should’ be done rather then how they ‘could’ possibly do things.

- Need to fix the driver problems. This includes having true plug and play support, having consistency in hardware support across distributions. From a consumer standpoint hardware has to work without surprises and without complex driver hunting and configuration.

Hard Social Problems
- There seem to be a lot of groups working on similar problems but not cooperating and solving these problems together. This may be the nature of Open Source software but current desktops and distribution development is very fragmented causing confusion to both end users and developers.

There are a couple projects that are being developed as an outcome of the meeting. The first called ‘Project Portland’ will aim align some of the efforts between KDE and Gnome. It’s my personal hope that this will lead to a unified effort on Usability, Accessibility, Internationalization and User Experience. Only time will tell.

I expect to see a lot more about ‘Project Portland’ in the coming weeks. A reporter from Linux.com interviewed me for article.