JavaOne day three: Native looking swing UIs
Wednesday, June 30th, 2004Given my abysmal track record with regards to session attendance, I thought that today I’d make an effort to go to more than one. The first of these was the ‘how to make Swing look native and great’ session. So so much of this session resonated with me, and I ended up feeling very angry and bitter at all the developers out there who have such a callous disregard for such basic elements of UI design.
I mean really, it takes SO LITTLE to put yourself in the mind of your end user, and imagine what they feel when confronted with your UI. What are they trying to achieve? Are you helping or hindering? Are you wasting your time on hidden features that the UI does not advertise? Are you writing your UI to your code, or to your user’s needs? These mistakes are frightfully common. Just look at roller (granted, it’s a web UI, but the same principles apply). The whole thing seems to deliberately go out of its way to spite its users and deliver a painful and inconsiderate UI. The same thing applies to site after site after app after app.
One of the key take home lessons from the session too that all the assholes who demand 100% native looking/behaving apps with no effort on their part are ignorant asshats. Swing will do 80% of the work for you. The rest is up to you. Yes, amazingly, you DO need to know the UI guidelines of your target platform. Yes, you DO need to test using multiple platforms. If you don’t, you end up with shit like Eclipse, which, through the divine gift of obstinate fuckwittedness, behaves like a Windows application no matter what platform you run it on. If your UI is successful and usable, the best outcome is no feedback from your end users. They’ll be suffused with a happyhappy feeling and won’t quite know why. They’ll eagerly use your application and not cringe when they’re asked to do something with it.
On the downside, when you have a bad UI, very very few users will be able to pinpoint what is so bad about it. Instead, they’ll hate your application and feel an incoherent rage towards anyone insisting they use it. It’s not like web shit where there are a few million html monkeys and two ways of doing everything; with rich clients, there are thousands of ways of doing everything, and about 3 people who know the right way. Finding the sweet spot is a task far more daunting than farting out yet another silly web intranet app.
Conclusion? The user drives the UI and features, NOT the underlying code. It’s your responsibility as a developer to ensure that the mapping between your UI and your underlying functionality works well, and to acknowledge that such a mapping is necessary. Also, always always go that extra mile to ensure that your app is well behaved on all platforms, and be prepared to spend a lot of time and effort doing that with no feedback. No feedback that is beyond smiley gleeful users who are more often than not totally unable to attribute that sensual sense of satisfaction with anything you might have done.