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.

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.

Adam and I worked on a J2ME application and I totally agree with him about the disillusionment of trying to write a single app that would work across phones. Issues include:

• Complex and difficult application installation procedures for end-users: How do you install the JVM on the phone? How do you get the plain J2ME app packaged up so that the phone will accept it? Does the app require manual user configuration before use? Is there a different launching process from other apps?
• Lack of control of the user interface: hardware details such as how many buttons you have, whether there’s a stylus, etc. differ from phone to phone, and the API to let you code once and let J2ME handle the layout for each device leaves your code very disconnected from what’s actually happening on the screen.
• Not being able to use recent J2ME APIs because even the latest phones only support older, more minimal J2ME APIs
• Not being able to do things on a phone that would seem obvious, like dialing the phone, opening a hyperlink in the phone’s browser, sending an SMS, or making a network connection. Either these are entirely impossible or require phone-specific or JVM-specific tools and procedures to sign your application, or having the runtime nag the user to request permission to do something that they just asked the app to do for them.

For all the noise Sun is making about broad J2ME penetration, the developer experience is quite disappointing, and as a result, the user experience is also quite disappointing. You can look up J2ME features and APIs and get excited, but when you actually deploy your app to a handset, it won’t load, or runs terribly slowly, or looks awful, or simply doesn’t do the things that the API says will happen when you call it a certain way. Suddenly the strict J2SE and J2EE logo certification programs make sense, because the J2ME approach of making so much functionality specified but optional leaves developers high and dry. The phone supports J2ME version xyz, but write an app coded to that API that works on the emulator and deploy it to a handset and lo and behold, all those optional APIs turn out to be missing even though the handset is capable of that functionality, and some mandatory API functions are not working. Here be dragons.

Case in point: can’t dial the phone on a Treo 650 (at least, not as of a year ago). The J2ME API tells you how to do it. The PalmOS JVM (made by IBM) lets you make the API call, and returns a successful response. Nothing happens. IBM says they’re aware of this issue. The end. The docs say you can, the code you write says you did, the phone just doesn’t do it.

Case in point: Every time you start an application and it accesses the network for the first time on a Treo 650, the user is nagged for permission to access the network. Quit the app and start again, nagged again. IBM has a tool that you can use to sign the app, but you have to use their VisualAge Micro Edition IDE which costs hundreds of dollars to do that. Try and find and download the trial version. A year ago, it was not possible. So, making that persistent nag go away probably costs several hundred dollars. (I never verified that it actually works, just that IBM says the way to sign the app so that it’s trusted is to do that, and that there was no available free way to get that tool.)

These are minor issues, but they certainly interfere with the quick usage pattern of a mobile app, and make it annoying to use your app. Imagine what that would be like if you had a competitor with a native application for that phone, whose application probably cost them more, but their app is better and the user likes it a lot more.

The important distinction here is not cost, it’s ROI. It costs a lot to develop a similar application for each smartphone platform, using that platform’s native tools. It would seem to cost a lot less to develop a J2ME app. But that’s only if you assume that it’s OK to abandon features and settle for a horrid user experience in the course of development.

It’s likely that your goal as a development team is to develop an app that has a predefined feature set that you know the device can support, and a predefined UI design that your mobile-savvy UI people are sure will go over well with users accustomed to that particular kind of smartphone. In that case you will almost certainly fail to accomplish that goal using J2ME. You have to scale back your goal so that you’re satisfied that you got something kinda like what you wanted working on a bunch of phones, and determined users will probably be able to figure out how to install it and make it work.

I call that phenomenon “write once, be disappointed everywhere.”

Let’s continue talking about cost, though. The native apps may require (or suggest) different programming language skills for different devices. It might seem wise to just write everything in C, but I think that’s a false economy as well. The phone APIs will differ so much that you will really need a native developer for each platform, not a team of generic C developers who will figure out the individual phone stuff and be freely floating resources that you can assign to whatever app version needs their attention. Smartphones may run Linux, may run Windows Mobile, may run PalmOS, may run Symbian… these are different operating systems with very different ideas of how applications run and coexist. The platform specific knowledge (APIs, appropriate UI feel, device capabilities) is probably an order of magnitude harder to learn and maintain than the ability to get an application working in a given programming language.

How much of a great C programmer’s skill is really the C language, and how much of it is proficiency with the available libraries on the platform he or she is accustomed to? I think close to 90% of their professional skill set is platform and library familiarity, and 10% syntax and low-level understanding of how the language actually works.

In light of this (just using C doesn’t mean developers or code are portable across smartphones), consider that there are high level languages available for some smartphones. What if that 90% platform familiarity means they can use a language and/or development environment that makes them 5 or 10 times as productive, after spending just a few days or a couple of weeks learning the language syntax?

After our very disappointing J2ME-on-PalmOS port experience, Adam found Handheld Basic which initially appalled me (oh no, BASIC!) but turned out to be a great choice. It’s a flavor of BASIC, so learning the language didn’t take long, and the support happens to be quite good (lots of code samples) so picking up the library portion of that 90% didn’t take long at all. I imagine that C# on Windows Mobile is similar. As more and more phone start to use Linux as their OS (which will be a particularly huge improvement for PalmOS based phones), you’ll be able to use Python, Ruby, Mono, J2SE (a whole different animal from J2ME), TCL, or pretty much any other high level language available for Linux. At LinuxWorld 2006 I saw a development device running unmodified GNOME desktop apps running on a PalmOS device alongside PalmOS apps. There are more options appearing all the time, and with the exception of Handheld Basic, most of them are ports of familiar, mature, well understood desktop languages, with class libraries relevant to mobile devices.

So, I recommend that you work in whatever high level language lets you do all the platform specific stuff you want, and if that means a different language per phone, that’s actually going to be the least expensive way to get to the apps you actually wanted to build. A big chunk of the scary cost of developing native apps goes away, because native doesn’t necessarily mean abandoning Java for C. (In fact I found Handheld Basic to be a more productive environment for me after a couple of weeks than J2ME was, despite my ~8 years of full time Java experience before starting that project.)

That pretty much means no reuse for you. Sorry, but that’s the deal right now.

If that unique-app-per-platform cost is too scary, consider a few ways to save money:

• For networked apps (aren’t they all?) ask yourself if there’s some logic that could just as easily be done on the server as on the client. Is there some complicated parsing code on the client that could be simplified by changing the response format from the server to something that’s easier to parse?
• Can you remove or alter certain features from a subset of platforms you intend to support, so that your premium supported platforms get your ideal app, whereas a few less popular phones still get a nice app, but perhaps one that doesn’t have every feature available on your premium app. You might be reading this and thinking “but that’s what you said J2ME would force me to do! Why is this any better?” The distinction is that you are in control of the decision of what to leave out to save money, whereas with J2ME it’s the platform vendor who makes that decision for everyone using their platform. If you’re writing an address book, not being able to dial the phone is lethal; not writing the code to let the user attach a photo to the entries is not.
• Can you move some user-facing functionality to the server to make the client simpler? Maybe there are some rarely-used features that could be done via a desktop or mobile web browser, so you can focus on putting the ten-times-a-day features on the handset, and making those features fast and convenient. You probably already made that trade-off in general, but perhaps for some kinds of handset, you’ll move the dividing line a little further, so that for users of particularly rare phones, some moderately frequent features can’t be done on the phone. This could also be a good approach for new handset types: design a “lite” app and a “full” app version, build the “lite” app first on each platform, and let user demand tell you whether the full app is worth it. Your developers can tell you much more accurately how much the incremental functionality would cost, since they already have done the lite version. Maybe you’d provide a VoiceXML interface, or mobile web browser interface, for that feature so that the user can still do whatever the feature requires while they’re far from a desktop PC.

A final consideration: labor. Maybe you have some Java developers, or C developers, and don’t have developers good at Handheld Basic or C#, so you’re not inclined to fire them all and hire new developers to do native apps, you’re thinking maybe C on every handset, or J2ME, is still the right choice. I still say that you should probably use native apps in native high level languages on every smartphone platform. If you’re committed to a strategy of good apps on a bunch of different phones, I think I’ve made clear that native apps are the only way to currently get there; J2ME simply doesn’t let you make good apps. So what’s left is C code written by C developers vs. high level code written by C developers who have to retrain.

As I said above, I don’t see much chance that your developers or your code will be portable across different smartphones if you use C. Maybe you’ll get 5-10% savings that way (some code ported across phones, or some developer hours shuffled between platform teams). But you’d get a 5-10x cost saving from using something very modern and high-level instead of C, and the overhead of training for the language would be very very small as compared to the large and unavoidable overhead of having to learn what the handsets can do and how the APIs for the handset’s OS work.

I suppose that means that if you have a bunch of C developers who lack smartphone skills, you’re in a pickle, but that situation seems kind of unlikely to me (a mobile app company hires a bunch of Unix and Win32 C developers with no mobile phone skills?). More likely is that you’d find a mobile developer who is proficient with one or more handset OSs and the best tools for each one, and they may be of the opinion that C is the best choice since they can reuse skills and some code across platforms. I would say that in that case you need to convince them to (or more likely encourage them to do what they were already considering, which is to) go ahead and find a highly productive high level programming language/environment for each smartphone platform.

A final possibility if you have a ton of platforms to target and a pile of killer C programmers is to try and port something like Python across most of your target platforms, or to make a very high-level API or domain-specific language that runs inside your own custom C portability layer. You might be able to find an open source option that you can invest some developer hours in, so that the actual application-specific code that you write on each platform is minimized and portable. But I suspect that this would still be expensive and would result in some J2ME-like UI abstractions that ended up being very unsatisfying in the end.

Best of luck!

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!

Shockingly, users care about the user interface. They understand the functionality of the application through the model that the UI presents to the user.

So, if you want feedback, the easiest way to get users to give it is to put something in front of them that looks like the user interface of the application that you’re building. In fact, the highest-fidelity way to do this is to build the whole application, then let them use it and tell you what needs changing.

This is usually cost prohibitive, so there’s a trade off to be made: build something that looks kinda like the final application will look, but that takes nowhere as much time and effort to build, and hope that by the time you actually build the thing, it’ll be really close to what the users wanted.

No, scratch that. Users don’t know exactly what they want, generally speaking, so building what they wanted is impossible – they only know if they want it once it’s in front of them. They can’t just come out and design the whole system for you, in full detail, and hand you a spec. (I can picture a house I’d want to build if it were up to me, but I can’t tell you what brand and model of faucets to use, or what the roof should be made of. And I certainly wouldn’t know what to do to meet building codes.) That’s why people hire professionals – it doesn’t mean they’re stupid, it means they don’t want to have to deal with all the details themselves. That’s the designer’s job.

But users sure can tell you when a certain thing is all wrong, and what that thing should do instead, which is how you’ll have to get used to dealing with them. (I can tell someone that a faucet is ugly, or that I don’t like the shower faucets that hotels have that make you turn it all the way past cold to get to hot.)

So, hopefully by the time you build the thing, it’ll be minimally wrong, and won’t lack any essential features that everybody forgot about until just now.

Anyway, as I mentioned before in RAD vs. BDUF, you need to understand how inclusive you need to be of stakeholders outside of the core team, in order to build something that isn’t totally wildly wrong. At one end of the spectrum, you just can’t get any grasp of what the users are talking about, ever, and you can’t build anything because you just have no clue what to build. Time to find a different problem to try to solve. At the other extreme, you know what to do and you don’t need anybody’s advice. That’s often the case with writing small apps and scripts to serve personal needs.

In the middle are all the processes where you need to figure out a way to solicit user feedback. Do you need lots and lots of stages of feedback because you barely understand the domain? Or are you pretty sure of what needs to be done, but somebody else is paying so you have to make sure they get a chance to look at it and sign off before you proceed?

These are the questions you should answer so you know whether you want to start with cheap and low-fidelity wireframing tools, like paper prototyping (advocated by Jakob Nielsen and A List Apart), or if you should lean toward sophisticated, high fidelity tools like graphics wireframe drawings or, according to some, HTML wireframes.

Boxes and Arrows has an article entitled HTML Wireframes and Prototypes: All Gain and No Pain, which seems like a pretty bold claim to me. The article’s author basically argues that Dreamweaver is the ultimate prototyping tool, because it’s as easy or easier than all of the options, and it makes prototypes that look more like the end product will than any of the other options.

I disagree; I’ve used Dreamweaver and found it to be one of the slowest, clumsiest, most awkward applications I’ve ever used. But let’s assume that Dreamweaver could be replaced with a tool that was basically the designer’s favorite drawing program that they know and love, except that it saved in HTML format.

Now we’ve eliminated the new-tool vs. my-favorite-tool issue, so we’re left with the issue of a continuum of increasing levels of detail. Now, ask yourself this: do you really need to fill in all the details in your wireframe, or can some of them be left until later? This really depends on your confidence level in the accuracy of your initial design decisions, and whether the folks reviewing your wireframes will be able to look past the placeholders and focus on the stuff you’re asking them to review.

If your users can handle a whiteboard, then you can use that, and take digital camera pictures. I prefer that process instead of paper prototypes, partly because everyone understands that whiteboard drawings have a very constrained level of fidelity (no one will ask “but will the web site really be all purple?” just because you drew it in purple).

For later revisions, the argument that an HTML prototype will be so much cheaper because you’ll reuse it as the start of the real application is clearly invalid. After all, if it’s wrong and you need to change it, you wouldn’t use it anyway, so it only makes sense to work on wireframes in the tool that’s the easiest to use. I personally find that OmniGraffle is faster than a whiteboard, especially if I want to change something small, and typing is faster than writing with a big dry-erase marker, especially if I want to be able to read it.

It’s simply a matter of the cost to fill in all the low level details before you know if the high level details are right. It’s wasted work if you do it too early, and if you use HTML, the expectations of the reviewers will be higher, and your ability (and temptation) to over-tweak the look and feel and thus distract reviewers from the content and basic functionality you’re trying to focus on is high. Does it really matter if that’s a link, a standard button, or an image button, at this point? That’s the sort of thing that you don’t want to get bogged down on, but you will if you’re not very careful.

Toward the end of the design process, I agree that HTML is a format you’ll need to use, but only because at some point you have no choice but to write the HTML and CSS for the web site, and to make sure it works with all the appropriate browsers. But I strongly disagree with the argument that, say, tweaking the design in Photoshop first and then doing battle with IE 6’s interpretation of CSS is slower than doing it in Dreamweaver, and then cleaning up the HTML that Dreamweaver created when it’s time to make the app work cross-browser for real.

In other words, until somebody makes a WYSIWYG HTML tool that generates clean and maintainable, cross-browser compatible, standards based HTML and CSS, the step of making the full HTML and CSS mockup should be left until dead last. Maybe as Dreamweaver (or another similar tool) improves over time it’ll make more sense to use it earlier.

In the meantime, instead of building an overly pretty bunch of tentative wireframes, do some graphic comps and show users what the home page and a few subpages will look like. Then show them the home page comp and a low-fi home page wireframe, and say that for now they’ll be working with the low-fi versions that you can change super fast. They’ll very likely understand it.

If you have no choice, because the reviewers just don’t understand that the web site will look prettier than the wireframe, well then maybe Dreamweaver (or little stenciled HTML elements in your drawing program) are the right way to go. But don’t spin your wheels trying to get things to line up just right in Firefox and IE before you even know what the heck is supposed to go on that page. It won’t save you time.

My take on BDUF is not to implement RUP or FDD or TDD or any named process as is, or even customized according to the Official Tome of that specific process. I believe that the best process is the one invented by the software development process expert on your team, tailored to fit the specifics of your project. That would be me. Hopefully that guy has read quite a bit about named published Official Software Development Processes, which I have.

So, in my case a process that employs some BDUF is not filled with bureaucracy and boilerplate and meetings and signoffs. Really it just means that I’ve taken long detailed notes on feature ideas, and that I’m doing wireframes (a.k.a. page schematics) and use cases before coding. I plan to do a page schematic for every page and a use case for every darn thing in the system. If the page is simple, then hey, it shouldn’t take too long to do a wireframe for that page should it? If the use case is simple it should be trivial to write.

In thinking about this I’ve come to some general conclusions about RAD vs BDUF that I’d like to share for the good of all.

RAD is not the next step in evolution beyond BDUF. RAD is not stupid and lazy compared to BDUF. They both have their place. Here’s how to decide which you need to favor in your roll-your-own process:

1. Do you have a clear vision within your team for what the product will be?
2. Is there a very solid understanding of the problem domain, within your team?
3. Do you have stakeholders and/or investors outside the core team who demand to control the design of the product?
4. How much overlap is there between the software people and the domain expert people in your extended team?

RAD works really well if the answers to 1-2 are “no”, 3 is “yes”, and 4 is “not a lot”. It helps a lot to build something that you don’t fully understand if you have some realistic prototypes to let domain experts and stakeholders fiddle with as you build it.

The disadvantage of RAD can be that the amount of rewriting effort is high. That may be unavoidable but it might be better to do high-fidelity page schematics (basically, a large number of comps) or even an HTML mockup instead of wireframes, rather than actually trying to make it all work before your stakeholders and domain experts have had a few iterations to poke and prod at.

One middle-of-the-road technique I learned from former co-worker Mike Schierberl is to just start with an HTML-only prototype and just “grey out” the links, buttons, etc that don’t work yet, or the content on the page that’s hardcoded or comes from a canned stub function in the back-end. That allows a stakeholder to just poke around the application and see what works and what doesn’t, which is a lot more useful than a couple of bulleted lists of done/not done. That gives an indication of progress as well as letting you just do HTML before stakeholders look at and comment on your proposed design. As parts of the UI become better understood, you can code them, and the mockup and running code coexist in the same running instance. When the mockup is gone and it’s all working code, you have an approved prototype that you can clean up for launch.

BDUF works well if you have a pretty darn good idea of what you want and you have the talent within the team to make decisions about the stuff that hasn’t occurred to you yet. At some point you absolutely have to make decisions about the lowest level functional and UI details that you’d rather not have to deal with, but computers can’t fill in the gaps in your high level design. The point of BDUF is to have all those conversations and design sessions in the cheapest medium possible, which is usually some words in a word processor about what it will do, and some annotated low fidelity pictures that describe how it will look and feel.

The disadvantage of BDUF is that you can get pretty far down the wrong path with no feedback. Stakeholders get impatient when they see that you’re producing a bunch of requirements gibberish instead of writing code. Wireframes and comps can help somewhat but that depends largely on the level of imagination that the stakeholders have, and their trust in your good judgement about design, and their experience with software applications that you consider to be well designed. Non-software people who just hired you aren’t going to have much patience for a 4 month design phase on their nickel, especially if you keep emailing them 150 page .doc files full of use cases that they’re supposed to review.

In my case the answers to the 4 questions above are “yes”, “yes”, “no”, and “a lot”. Those are the opposite of the answers that point to RAD as the right choice, so I’m using BDUF this time.