Monthly Archives: September 2006

Wii Will Not Be Disappointed

Good ol’ Billeh Berghammer over at GameInformer has penned an article expressing his apprehensiveness about the Wii’s launch. An excerpt:

“…the future is made up of many of the same promises and hopes I had when the N64 and GameCube were announced. I just hope I don’t end up being disappointed once again.”

Granted, I had similar concerns about the last Nintendo home console. I also had the same concerns about the DS. I mean, come on, a touch screen? How can *that* be fun?

Continue reading

Google Holding Back Automotive Tech

Google’s forming a new for-profit charity. That’s good.

One of their first projects is a 100MPG plug-in hybrid vehicle. That’s bad.

The word “hybrid” is rapidly becoming associated with half-measures that really don’t solve the fundamental problems which thet address. Hybrid hard drives… where’s my fully solid-state MRAM drive? And hybrid vehicles… I demand cars powered by hydrogen fuel-cells! We need to stop scaling back and doing the easy things, simply because we can bring them to market quickly.

Companies need to focus, take the hit to revenue and resources, and take the time to do the hard thing, because it is the right thing to do. GM has been doing it for nearly a decade now, and their efforts are closer than ever to paying off.

Continue reading

IDBUX: Radio Menu Items

Windows Radio Menu  Mac Radio Menu

What happens when I select “List”?

Here’s a truly rare bird: a UI heuristic where most GUI toolkits get it right, but Apple (Cocoa) goes horribly wrong.  In the above example, what will happen when “List” is selected?  On the Mac (right), It’s not clear, is it?  Will “List” also become checked, or will “Large Icons” become unchecked?

In virtually all pull-down menu implementations across all platforms, there are basically three types of functionality for any menu item (which does not have a submenu, and is not a separator):

Continue reading

IDBUX: Make Use of Application Roles in Finder

Editor / Viewer

Respect These Roles!

When developing a Mac OS X application, you can specify what extensions your app can open.  Furthermore, you can specify, for each document type, whether your app is able to open that document for editing, or just as a viewer.

So why is it that I can not utilize this differentiation in the Finder?  For any given “.jpg” file, why can I not choose to view it (using Preview.app), or edit it (Adobe Photoshop CS2.app)?

The experience could be simple enough:  double-click to view, triple-click to edit.  Command-O to view, Option-Command-O to edit.  Think of the time you would save that is otherwise spent tediously dragging an image to an icon in the Dock.

With the capabilities now built into the core of Mac OS X, the “Open” command just doesn’t cut it.  I Demand Better User Experience.

Yeah, yeah…

Damn... hair.

This man also neglected his blog.

So it’s been a while since I blogged.  Big deal.  You wanna fight about it?  Things have been busy, and they still are.  I recently realized, however, how many ideas and observations I have backed up, soooo…

I’m firing up the computar blog machein again, and to kick it off, I’m introducing a new recurring category.  It’s a rant about big gaping omissions from good interface design.  I call it “I Demand Better User Experience,” or IDBUX for short.

Enjoy, you ungrateful wenches.  ^_^