Category: IA

Clickwrap UI mini-rant

When I am ruler of the universe, this will be my first edict:

Any clickwrap license which:
(a) is longer than 1000 words, OR
(b) is longer than ten (10) times the height of the text box it is enclosed in, OR
(c) is displayed in a text box that uses less than 5% of the total display area and cannot be resized by the user for easier reading, OR
(d) cannot be selected for copying and pasting into another document, OR
(e) cannot be read before purchase,
IS AUTOMATICALLY NULL AND VOID.

Inspiration abounds, but today it’s the Firefox 3 clickwrap license window’s that fails (c) and probably also (a) and (b) which reminded me of this common UI issue.

J2ME: Write Once, Be Disappointed Everywhere

We developers and other nerdy folk are used to using strange and klunky applications that do something special, and we’re used to that trade-off.

Eclipse is an IDE so it’s hard to imagine it not being baroque and difficult to use, requiring weeks of effort to become productive. JBidWatcher has saved me a lot of money on eBay so I could probably put a dollar value on how much it’s worth to endure its bizarre UI. Azureus is fairly fugly also but it does a very good job and has a deep, sophisticated UI that’s fairly easy to understand, so despite the eyesore, it’s at least fairly clear. The common thread among all of these is that they are all written in Java, and that they are so valuable that it’s worthwhile to overlook the ugly UIs.

Now imagine those sorts of trade-offs, but on already difficult to use mobile devices, and aimed at consumers. Are you making a strategically wise choice by sacrificing usability and control over the user interface, and probably access to platform-specific features such as dialing the phone, in order to save money on development? Adam Breindel talks about this in When Building a Smartphone App, Resist the Siren Song of J2ME.
Continue reading “J2ME: Write Once, Be Disappointed Everywhere”

HTML Wireframes vs. Wireframe Drawings

Related to Rapid Application Development vs. Big Design Up Front is the question of what exact format the UI design work should be done in.

This is more important than user stories vs. use cases, class diagrams vs. ERDs and other such decisions, because UI design artifacts are the most user-accessible artifacts. That means they’re probably the only ones you’re actually going to be able to get users to look at. Try emailing a CFO a 100-page Word doc full of use cases sometime, if you don’t believe me. Then sit that same CFO down in front of Excel and ask for a rundown of their least favorite Excel features. Big difference!
Continue reading “HTML Wireframes vs. Wireframe Drawings”

Rapid Application Development vs. Big Design Up Front

I’m working on a new project which I regard as medium-large in scope, and I’ve decided to use BDUF instead of RAD on it. This is of course heresy in light of the effect XP and Ruby on Rails have had on the web startup zeitgeist. (“Isn’t it all about RAD these days?”) But I still think I’m making the right call here.
Continue reading “Rapid Application Development vs. Big Design Up Front”

OmniGraffle Pro and Subversion

I’m working on wireframes for a startup company, and I’m using the excellent OmniGraffle Pro to do it. Of course I’m keeping all my artifacts in Subversion. But there’s a problem: OmniGraffle sometimes changes a file’s format from a single flat file to a “bundle”, which is a directory that Mac OS X pretends is a single entity (as is seen with all the .app bundles in the /Applications directory). OmniGraffle bundles contain a file with a hideously awful filename, which I’ve seen in the old Classic MacOS if I remember correctly: Icon^M. Like, 5 characters, 5th is a carriage return. Subversion can’t check it in, svn:ignore can’t ignore it. Ugh. Here’s the fix: Using OmniGraffle with Subversion without Sadness