Design Technology at the Intersection of Art and Science
Dear software tools vendors – please check your defaults. Please increase the effort necessary to create visually abrasive applications – in most cases, it is far too easy right now. I am asking that you make it more difficult to create ugly UI. Please know I don’t rest the blame for these atrocities solely on your shoulders – we technologists need to up our game as well.
I’ve been working with both Eclipse (with the Android SDK), and xCode (with the iPhone SDK), working on a mobile-focused program. It struck me how difficult it is to make a bad UI within xCode. If you do nothing more than create a new iPhone app, add a single button, and compile and run, the result looks nice. Now do the same within Eclipse. Oh my. Eclipse needs a “Do No Harm” option that is enabled by default.
This is not a mobile platform debate – this is a request to help people create more elegant applications. And this is not limited to mobile platforms. Back in the “olden days”, Visual Basic 3 was quite the tool. Unfortunately, it was too easy to create ugly applications. Anyone remember the “embossed font” craze?
How ‘bout the blue text on red background fad (a combination that the human eye cannot physically focus on simultaneously)? It would have been great to have a feature available that would limit my choices to only those that were actually readable on a screen – the other options could be disabled by default, with an option to ignore common sense available via the CTRL key or something similarly obscure. On the Apple side, there was HyperCard. I’ll classify it as similar since it did include HyperTalk. Using just the defaults, the applications didn’t look too bad. That was certainly a step in the right direction. Unfortunately, HyperCard was silo’ed far too quickly, and didn’t really have the opportunity to impact other tools’ the way it could have, given more time and attention.
When the Internet, and RIA’s, became the fad, an opportunity to stem the tide of ugliness was ignored, or at the very least deprioritized below the cut list. How else can you explain the existence of (and support of in most HTML tools of the time) the <blink> tag? Why not choose to not enable its use? The Web would have been a kinder place for all of us. I applaud Yahoo’s efforts to raise the bar when they released their YUI libraries. Unfortunately, I haven’t found any tools vendors who enabled the use of YUI by default.
So, tool vendors, here’s a fun exercise, and a great moment to take a bold stand. HTML5 is predicted to solve all known programming, display, and media playback issues. Well, most of them anyway. It may not block the creation of dancing hamster web sites. But! It gives everyone an opportunity to update their tools, so please take this opportunity, and create great defaults. So here’s the challenge - create an application with your tool, using nothing but the defaults – don’t change a thing. Click OK as quickly as possible. What do you think of the results? Now do the same with your top competitors’ product. Which looks better?
Fellow technologists – work with me here. You will make your designer compatriots beam with pride when you proclaim, “There needs to be better affordance hints expressed in this tool!”, or “I don’t understand why visual dissonance isn’t flagged as a bigger issue in this tool!” Together we can end the tyranny of visual abuse. Together we can build a better (albeit augmented-reality based) world.
most of these images were lifted from the wonderful Interface Hall of Shame. Thanks for the laughs…