I most enjoyed getting to meet a number of java.net bloggers such as Kirill Grouchnikov, the author of the Substance look and feel, and members of the Sun Swing team including Shannon Hickey, Chet Haase, Hans Muller, and Richard Bair. Of particular interest to me was the chance to meet people behind independent open source frameworks such as Wolf Paulus, the author of SwixML. It's also always a pleasure to revisit with old friends Ben Galbraith, Dion Almaer, and Scott Delap, whom I know from speaking tours with NFJS (no fluff just stuff).

What I value most about such conferences is the chance to connect with the community, the people who were drawn to this conference, speakers and attendees alike, because of their involvement with desktop technologies in some respect. They came to share and discuss. This was not a dead audience. Talks were interactive, and Ben made sure to heckle speakers that didn't get their fair share of questions.

Personally, I was very humbled by the feedback I received about my talk. There's nothing more encouraging to one's work than getting positive feedback so personally.

I enjoyed informal conversations with fellow speaker Kai Toedter of Siemens, and Etienne Studer who delivered two presentations: the first on the ULC product from Canoo (which imho rocks), and the second on IntelliJ IDEA's GUI designer where Etienne's facility in the environment made me reconsider my own intimacy with the product. It was also an honor to get to meet and listen to the people behind JIDE. David Qiao gave a great talk.

So, now that DM is over, and now that I'm home, I can finally say that I feel like I know at least a few members of my community, and it's a good feeling.

The conference is organized such that it has a single track, which I very much like. As much as it's nice to have a choice of talks to attend, I believe there's more value in everyone being in on what goes on, in sharing a common experience. It's not unlike how TV used to be. I recall a place and time where there was only a single national television station. If a movie was on, everyone watched it, and there's something nice about that.

Personally, I will be attending the conference as a speaker: I will be showing off my project: JMatter. It's been a little over six months since I announced the project as open-source. Our mailing list has grown to over 100 users and the feedback has been extremely positive. Some of my favorites are: "you should be speaking about this at JavaPolis" and "the documentation is outstanding." Speaking of the documentation, I have recently expanded it and it now stands at roughly 200 pages. The manual is now available in print as a self-published book from lulu.com.

I am looking forward to meeting the members of the rich client community at Desktop Matters. Sometimes as developers we overlook the importance of attending a conference. Listening to a talk or speaking with a colleague can be a catalyst for new ideas, and reinvigorates us when we get back to coding. Perhaps I'll see you there.

I recall clearly a period of activity on java.net where many (including me) voiced their desire to see Java open-sourced.

Now that this has happened I'm amazed at the correlation of this event with my own experiences. In my career I've open-sourced two projects: ashkelon and JMatter.

Each time the process of letting go and embracing open source was very difficult, even arduous. I took what felt like forever to arrive at the decision. Surprisingly after the decision was made, the feeling was very positive, very rewarding: that I'd shared my work with the community. The same thoughts reverberate: "why did it take me so long to do this?" I believe the reward is of equal or greater magnitude to the effort; that is, it's worth doing.

With my first project, I hadn't yet read Eric Raymond's Cathedral and the Bazaar. I was a novice when it came to managing an open source project. I still regret that I wasn't able to make the project flourish, though I don't regret for a moment open-sourcing the project. Many used my code and some sent me improvements. There was also at the time an obstacle to this project: the fact that one could not legally publish online javadocs for Java's APIs.

Another correlating fact was my choice of license. Both my projects are available under the GPL. So it's a great feeling of validation to see that Sun has also chosen this license.

One odd way to describe how I feel about Sun open-sourcing Java is that the positive feeling is of equal magnitude to the negative feeling I had when hearing the news of the Novell ship sinking. It gives me hope for the future.

In my mind the parallels that exist between the events that play out in real life: the battle being waged between the forces of open and close code, and between the Star Wars saga are striking. I don't mean to sound cheesy here, but we see time and again how sometimes organizations exert their force by proxy, sometimes anonymously (as in the case of SCO).

One item I've been ranting about to friends (and on this site) for too long is how companies can get away for charging people for software they don't use. Each time I purchase a notebook computer and quickly wipe the disk clean to install Ubuntu, I pay the famous "microsoft tax" for a license of windows I did not ask for.

I would like publicly thank Sun Microsystems for choosing to side with its community, to side with the open-source community on Java. I sincerely hope that a few years from now Sun will be able to say: "we made a good decision; and it has paid off handsomely."

Here are some of these new frameworks:

• NextApp's Echo2
• WingS
• Google's GWT

It's also worth mentioning that Canoo ULC also provides a Swing-like API, but they're trying to leap-frog AJAX altogether: they deploy Swing thin clients.

Even though this model is new and not yet "fully" proven, I find it very promising. Up until now, web developers have had to master multiple different technologies including Java, Servlets, JavaScript, HTML, HTTP, session management and cookies, and the idiosynchracies of various web browsers on a multitude of platforms.

These frameworks promise to collapse all of these layers down to one. That's tremendous.

So I was thinking, if what is essentially a Swing-like API can be used to build rich web applications, would it be possible to extend Swing in such a way that a deployment switch controls whether we produce a web application or a ... Swing application?

I suppose we could think of this in reverse: can an HTML look and feel be constructed for Swing?

The end result would be the same: we'd write a single application, using The Swing API (not a Swing-like API) and we'd be able to target the web without any extra effort.

So, my message in this blog is: I think Swing should venture in that direction.

So it was not until maybe a few months ago that I got a great big laugh watching the classic Monty Python Spam episode, wherein everything on the menu has Spam in it.

Earlier this week I proudly announced that I'd finally open sourced JMatter, a framework that I've been developing for a good while, for developing rich client applications at very high productivity levels.

I never really blogged about it, feeling it was not appropriate to promote code that was proprietary. For some reason, even now I have a little difficulty with this. So I thought why not try to do it with a little humour? That usually makes the SPAM go down a little easier. :-)

On a more serious note, I've been delighted at the response to my announcement. We already have a thriving mailing list, terrific discussions, and I've had the good fortune that a few fellow developers have blogged most favourably on JMatter.

If you have a little time, I invite you to check it out!

What does Swing have? SwingSet2? Not really. There are indeed thousands of rich Swing applications that exercise Swing. NetBeans being a very serious one developed by Sun, the same organization that develops Swing. One could also say, "look SWT doesn't have a desktop either, they just have Eclipse." So, you are right, it's not fair to make such a comparison. Nevertheless, it does not mean that it would be a bad idea to have such a project drive the evolution of Swing going forward.

There's nothing like a full-fledged desktop system used by thousands of people daily to serve as a complete harness for a robust GUI API. A desktop system probably exercises all facets of such a toolkit:

• Does the toolkit provide a complete suite of widgets that can support a very dynamic user interface?
• Are the widgets rich enough? Are they flexible enough?
• Is the performance of the toolkit's components being put to the test on a regular basis?
• How well do the components interact with each other?

I see an interesting development going forward. I recall reading that someone has ported most of GTK to MacOSX. That is, very soon, Apple users will be able to run GTK apps alongside their Cocoa apps. It is my understanding that GTK also works on Windows. Swing has been in a unique position for a while of being able to run multiple platforms. Others are catching up. And they do have some advantages, having multiple language bindings possibly being one such advantage.

In all fairness, I should mention an excellent project out of France whose goal is to create a desktop system for Java written in Swing: JDistro. What I'm really interested in is a stronger coupling, a stronger feedback loop between two teams: one developing a Swing Desktop System, and another supporting its development by making improvements in the Swing toolkit.

1. Revisiting things you already know: you will likely see them from a new point of view. This will usually happen because time has passed. You've changed, you're not exactly the same person you were when you originally studied the material. That's what happened to me as I prepared to give my set of talks at NFJS last weekend.

2. Attend talks given by others. It's very likely that the same topic will be presented from a different angle, a different point of view.

3. Get together with other developers. A NFJS conference might do the trick. JavaOne is coming up. Maybe your local JUG meeting.

4. Even if a topic is not related to the work that you're currently doing, you might be surprised to find once in a while that a situation is discussed that is analogous to yours, albeit in a different domain, a different context.

5. Provoke thoughts in others. That has the tendency to amplify the thought process. You might not be prepared for an avalanche of feedback, ideas triggered by your original provocation. That happened to me recently after I demo'd some software I was working on to a couple of friends / colleagues.

6. A few friends recently decided to get together for Friday lunch meetings. It's been a great opportunity to discuss what each of us are working on, articles or books we came across that grabbed our attention or interest. We always have more to talk about than time available, which is a positive sign.

The idea of logic leaks applies to other aspects of development, not just the client tier. For example, the Hibernate project is very concerned about not leaking persistence issues to other application tiers.

As I was thinking about this notion of business logic leakage, a very interesting thought came to me. Say for example that we define a business object, maybe a Customer. Furthermore, let's say we define a number of fields on this object: name, date of birth, etc.. The minute we put down in our text editor the lines:

<caption>Name:</caption>
<input type="text" name="name" />

..is the minute we've crossed the line; we have violated the DRY principle. We have just leaked business logic into our view. From now on, if we rename the field, we must do it in two places: in the model and in the view.

Now, imagine being in the process of developing an application consisting of a dozen business objects, each with a half dozen fields. Model changes are going to occur. They're going to imply making changes in more than one place.

Given this, it's no wonder that resistance to change grows as a project gets larger. Yet business change is inevitable. People talk about the high cost of building software. It's no wonder the cost is high if we have to manually make each change twice. Not only is it more work but also error-prone. The essence of DRY is eliminating that duplication.

So, having provided a context, I can finally describe this small epiphany I have had in a short sentence:

If we're going to have a model-view-controller system without business logic leaking into the view, then we must construct generic views and controllers.

What does that mean? Take for example, the CRUD scaffold generators in Rails. The code duplication is still there but at least the duplication is automated. Admittedly not bad for a first pass.

The other interesting tidbit that sort of "falls out" of this small thought exercise is:

GUI is plumbing

I've been saying this for a couple of years now but it is still my hope that some day everyone will have good GUI plumbing for their software applications.

This past weekend I attended the Northern Virginia Software Symposium and was fortunate to have a little time to spend with my NFJS comrades. A most vivid comment that Justin Gehtland made during one discussion was how stoked he was about this software we were discussing.

It occurred to me on the plane ride back to Austin that the term "stoked" is normally used to describe the feeling one gets when surfing. Perhaps it's also applied in the context of extreme-sports related activity.

To my wonder, the term could be applied, and very aptly so, to moments that we, geek software developers, have in our work. That feeling arises when we do something that we think is extremely cool, that perhaps hasn't really been done in that particular way. For example, I sensed that feeling when reading a weblog I came across on java.net a while back, having to do with a very cool idea that occurred to one of the Wicket Framework developers. See Wicket + Swing == hmmm...interesting....

I believe that this feeling is the driving force behind the hordes of us out there, of any age, who spend their spare time coding, pursuing the creation of something that, to them, is so incredibly cool. So, just like surfers can't stop surfing and continually strive to be in that most special state of being stoked, so do software developers.

Oftentimes, we deal with scheduling activities and must develop or integrate calendars into our software applications. Inevitably, our customers will require a mechanism to produce reports. We will also supplement our user interfaces with wizards, by walking a user through a series of steps. We need to persist our objects to databases, we need an authorization mechanism. We need audit mechanisms to find out when information was edited, by who.

Many of these tasks are generic, orthogonal to the problem domain. Must we keep on constructing new implementations each time we start on a new project? Is it even feasible to produce implementations of these concerns (e.g. authentication, authorization, CRUD, a user interface, searching, reporting, wizards, etc..) that are completely decoupled from the business domain in question? Can we even entertain the thought?

To me, the NakedObjects framework is a proof of concept. It demonstrates that it is indeed feasible to implement many of the various concerns of application development generically. Usually the tradeoff is adherence to certain framework conventions, though others have shown that many of these conventions are not absolutely necessary.

Look at the scaffolding generators in Ruby on Rails. Trails is another project that embodies these same ideas. The idea is basically that a domain model can be constructed that is to a large extent ignorant of the context it runs in. This sounds like the Spring Framework and Dependency Injection. But it goes well beyond injecting transactional rules or turning JNDI on its head. Indeed, a long time NakedObjects proponent, Dan Haywood, is working on his own framework (see Essential), and is leveraging the Spring Framework for it. The Naked Objects folks have recently coined the term "The Naked Objects Architectural Pattern" to categorize frameworks that adhere to their architecture concepts and ideas.

In Ruby, one uses the piece of metadata :attr_reader to tag fields that one wants to expose with getter methods. In NakedObjects, there's a fieldOrder piece of metadata to relate how fields should be laid out on a form in a user interface. It is specified in a manner analogous to Ruby's :attr_reader. This manner of specifying metadata is also in line with the DRY (Don't Repeat Yourself) principles given to us by the pragmatic programmers. It expresses our intent succintly and without duplication.

Let's set aside the "can it be done" question for a moment and envision the rewards. What do we have to gain as an industry if we manage to develop a system that provides generic implementations for these generic aspects of business application development?

Imagine an ecosystem, similar to Eclipse, but not for tooling. Instead, this ecosystem would be a runtime infrastructure ecosystem, where providers supply competing implementations of these various concerns (this is what Rails is evolving towards by the way).

• developers would spend the vast majority of their time directly addressing customers' problems
• conversely, very little time would be spent building software infrastructure
• software infrastructure would become standardized
• development time and cost would decrease dramatically
• infrastructure components would be of higher quality
• the size of the code that pertains directly to a specific project would shrink dramatically
• our abilitly to read, understand, and extend other people's code would likewise improve
• we would have true decoupling of concerns
• the developer would simply plug in their object model (the data and behaviours) into a an infrastructure that would supply everything else
• we'd be able to pick which aspects we want to include in our application at deployment time (the true, original vision of J2EE by the way)
• our applications would inherit new features when infrastructure upgrades came along, without even altering a single line of code in our applications

I'm not even mentioning the benefits to developer-customer relations, the closer mapping between a user interface and its object model with direct benefits to customers' understanding of the logic behind a business application (hence the term "Naked Object").

Aside

Many people have been saying "Move over Java, Ruby is the new language in town." I do agree to some of the arguments but not all of them. How much of this is a language issue? I do admit that maybe implementing such a system is easier and simpler in Ruby. But that does not mean that it cannot be done in Java. Java has reflection. Java does not have mixins. Java has AOP. So there are tradeoffs. I suppose if you really want to do it from scratch, Ruby might be a better choice, from a certain point of view. If you're building a rich client that needs to run cross-platform with a minimum of fuss, I'd say that Java is the better choice. Smalltalk could be just as good a choice, perhaps a better one. Paul Graham says it's LISP and I know he's got some very good reasons.

My contention is that the debate has been focusing disproportionately on the language as the root enabler of frameworks such as Rails. The ecosystem I dream of can be constructed in Java. We would reap serious savings in development time, development cost, similar to the time and cost savings that are being boasted about by the Rails community.

I have developed my own framework that embodies these ideas. At this time, this framework addresses only workgroup business applications. It does not tackle the important issue of transport. I have recently employed this framework to construct a small solution for a customer. The numbers are in line with my expectations. On this particular job, I spent under two weeks implementing the solution when the original estimate had been in the order of two months. So how much does this have to do with language?

[Footnote: blog entry cross-posted on Eitan's personal weblog]

1. From an Annotation, one should be able to navigate back to the programming element that it annotates.

   For example, a method annotation clearly marked with a Target of ElementType.METHOD cannot say getAnnotatedElement().getName(),

   There are two problems here. The first is the lack of the getAnnotatedElement() method The second is the fact that an AnnotatedElement is too primitive of an interface. You cannot actually invoke getName() on an annotated element. I feel that there should exist a basic ProgrammingElement implemented by or extended by all annotated elements.

2. The default value for an annotated element should not be restricted to a constant expression. Instead, the value should be a code block.

   For example, let's assume that I want to annotate methods to give them a caption. By default, the caption should be some kind of derivation from the method name it is bound to.

   That is,

   class MyClass
   {
     @MyMethodAt(caption="The X Method")
     public void method x()
     {
       // ..
     }
   }
   
   
   and
   
   
   @Retention(RetentionPolicy.RUNTIME)
   @Target(ElementType.METHOD)
   public @interface MyMethodAt
   {
     public String caption() 
        default
        {
          return getAnnotatedElement().name();  // see [1]
        }
   }
   

   As far as I know, this is currently not possible.

Many debates surrounding Java 5 annotations also are related to this issue: many have argued that they don't want to have to recompile their code to revise the value for a piece of metadata. Fair enough.

How many times have you heard or read of a selling point for a software framework or product or solution being "and you can make changes to the system without having to recompile the code." I must admit I'm sure I used that line more than once before (in my early days programming :-)).

So here's what I find interesting: instead of coming up with all kinds of schemes to get around the problem, why don't we just deal with the root cause? I think it's staring at us in the face: why don't we simply program in an interpreted environment?

I think we all must admit that it's much nicer to be able to make a change to a web page or a template or a piece of code and very quickly turn around and test the change without having to recompile. Compare that to the way a jsp works: compile the jsp into a servlet and compile the servlet into bytecode. It's true that servlet containers are easily configured to 'autoreload' jsps. So in this case, it's really no big deal.

But that's not what I'm talking about here. What I'm talking about is if we need the equivalent of a config file, we don't have to go out-of-band and step out of the Java environment and start our new metalanguage in a properties or XML file like James Duncan Davidson did with Ant or like we do every day. We would simply write source code. An entire thick layer of nonsense design decisions would simply disappear. No more debates about put this code here or there depending on whether we want to incur the cost of a recompile.

This essentially is the argument for internal domain specific languages (DSLs). So Rake files are not written in XML like Ant is but instead they're interpreted by Ruby, the same interpreter that you use to write your Rails app (note: ruby and rake and rails are discussed here as means to provide an illustration. this entry is _not_ about 'ruby is better than java' but rather about the more general idea that 'interpreted might be better than compiled, from this point of view anyway').

More and more these days I'm coming to think that a single or unified underlying model for interpreting stuff would be a good, pleasing thing. I like this kind of simplification. We end up with a more uniform system, and spend less time reinventing the wheel.

I find it most interesting that for some reason, discussions around this basic issue never seem to come up. What comes up are people talking about or trying to solve the symptoms of the root cause, but the root cause seems to evade us.

Note: this entry is cross-posted on my personal weblog

Overall, it's been a terrific experience, and it's looking like I've come here to settle down.

So I thought I'd summarize my experiences, from my perspective as a Java software developer, and as a computer user in general.

The Good

Here are a few things I really like in Ubuntu / Linux:

• The Gnome Epiphany Web Browser: my favorite browser. See my blog entry on the subject.

• Edutainment + kids games: On linux, one can download a number of games for children that are of high quality from the point of view of the material they cover. Sure, some games like supertux, are just plain fun 'mario brothers' style games. But many can be powerful tools that can hone the brain power of children. Here are some of them:

  • kturtle (logo programming)
  • gcompris
  • tuxmath / tuxtyping

  My kids and I also very much like supertux, tuxracer, and tuxkart. I'm particularly proud of my 3 year-old who is now a supertux champion and has mastered the arrow keys, the enter key, the control key, and spacebar.

• Quality open source desktop applications. Who said that open source can't produce desktop apps of higher quality than their commercial counterparts. If you thought the adobe had the best vector graphics editing application, take a look a inkscape. For pictures, check out the beauty of f-spot. For spreadsheets, I think gnumeric is terrific.

• Authoring tools. A number of different technologies can be used to write books or articles. Docbook is one and docbook support in the form of toolkits, documentation, utilities and more is the strongest on linux. Many love LaTex.

  I particularly appreciate lyx, a wonderful wysiwym editor that does all the heavy lifting for you. If you're about to write a book and don't have in-depth knowledge of docbook or latex, then I believe lyx is the right choice.

• Strong pdf support. One can easily produce a pdf version of a document, translate a postscript file to PDF. I recently printed a web page to a postscript file and then translated it to PDF.

• editors galores. Lots of editors to choose from. gedit, kedit, kate, jedit, and many more besides.

• apt-get and the amazing synaptic package manager. Want an app? Just wish it and a few seconds later it's completely installed on your system, along with all its dependencies. That's the magic of the synaptic package manager. apt is the technology that makes it happen and the synatpic front-end gives you no reason to ever fall back to the command line.

• strong printer support

  • lj3200 which i'd given up on entirely with my mac (hp did not make apple drivers for this specific version), worked like a charm with linux, without having to install drivers
  • doing duplex printing with my brother 5150D at the office
  • doing network printing to an hp inkjet printer

• wifi worked for me out of the box.

• the sleep feature works just fine but does not conserve the battery charge nearly as well as my powerbook did. hibernate then is the alternative, which has worked great for me for many months, up until a recent kernel update.

• strong device support in general: plugged in my camera and automatically started downloaded photos, without even having to download anything.

• amazing endless suite of kde apps. from kontact to koffice, kde is simply an amazing source of seemingly boundless energy.

• kde and gnome apps can run side by side

• terrific support forums

• java:

  • unlike the last OS i worked on, there are no issues regarding obtaining the latest java udpates on time
  • all the java ides work with it: intellij, eclipse, and netbeans
  • have the option of building java applications that use the gtk toolkit

• latest firefox

• endless supply of artwork for customizing background image, login manager, login splash, window decorations, icons, and themes

• freedom!

• no viruses, no symantec, no mcaffee

• complete desktop customization features, especially with kde, although in the end i prefer gnome; i find myself forever tinkering on kde, and more productive on gnome. each has their strengths and together they make for an even better distribution: a wider array of choices; sometimes you get this feeling though that the velocity on the kde projects is just so amazing..

• i love the ability to assign keyboard shortcuts to anything i rarely touch the mouse and am in complete control

• ruby. if you're doing ruby development, installing the toolstack, including rails is a snap.

• cost. i don't have to pay for additional apps. my notebook cost me approximately 1/3 the price of my last one.

The Bad

• projector support is not really there like it is on a mac
• sleep does not conserve battery well
• had some hickups with hibernate after a kernel update
• have some weird totem/video problems at the moment, though there's no lack of video players for gnome or kde, this one happens to be the default and for some reason hangs when attempting video playback

Summary

The main reason I switched to ubuntu is that I can now compile and launch my java apps in 1/2 to 1/3 the time it used to take me on my last laptop. I used to run a 1GHz powerbook G4. Now I run a 1.7GHz intel centrino (same amount of ram on both). That's a serious advantage.

Finally, contrary the general perception, I don't compile my gnome apps or kernel. I download and install precompiled binary distributions of all my apps.

I'm very satisfied with Ubuntu and in the event that you're looking for the right home, I hope this short review was helpful.

In a similar vein, I recently (maybe two-three months ago) came across Epiphany..and i'm in love.

Epiphany is to Gnome what Camino is to MacOSX: a web browser that uses Gecko but its UI uses the Gnome and GTK APIs for a user interface. Epiphany was designed to fit in on a Gnome desktop. Indeed, it is the endorsed web browser for Gnome.

But that's not the reason I so love Epiphany. Epiphany's philosophy appears to be along the lines of stay out of the user's way and less is more.

So, beside the fact that Epiphany has the following favorable traits:

1. it just works
2. it has a simple, minimal menu structure
3. it supports tabbed browsing
4. it highlights bits of strings on a page when doing incremental find's

the feature that really speaks to me is the design of its bookmark system and the way in which you can customize the browser with actions for URL handling without having to write any code.

This is subtle but a most wonderful feature. Allow me to illustrate.

When you launch Epiphany, you won't find two text fields at the top edge of the window: one for the URL address and another for doing the Google search. Instead you'll find a single text field where the URL address is entered.

How then does one perform a Google search without having to first visit google.com? By writing a plugin. Here's how:

1. visit google.com
2. enter a search string, for example: testing
3. bookmark the search results: name the bookmark "Google this"
4. edit the bookmark: in the url string, replace the word "testing" with "%s". You've just parametrized the URL. save the bookmark.

Now, open a new browser window and type "java" in the URL field. You'll notice that a pull down menu will appear containing the option "Google this." Selecting that option will automatically visit the google search URL, replacing that "%s" in that bookmarked url with the search string you entered in the url field. It's a dynamic bookmark.

How wonderful! In my browser, I've configured four such dynamic bookmarks: google search, wikipedia search, dictionary search, and ashkelon search. So now when I'm coding I can just type in the url field: "String*" and select the 'ashkelon search' option from the Epiphany context menu, et voila: i get my ashkelon (javadoc) search results.

In addition to this cool search feature, if you type a substring of the name of a bookmark in that magic url field, that bookmark will show up in the context menu as well.

If you do use Gnome, I highly encourage you to give Epiphany a try. It's a stable and robust browser. But just as importantly it's well-designed. If you don't use Gnome but would like to give it a whirl, I strongly recommend the ubuntu distribution. Last note: Epiphany also works on KDE.

So today I came across this specific entry discussing "humane" interfaces:

http://www.cafeaulait.org/oldnews/news2005December7.html

Here is a snippet from elharo's blog entry:

"More buttons/methods does not make an object more powerful or more humane, quite the opposite in fact. Simplicity is a virtue. Smaller is better."

Hearing stuff like this makes my blood boil. I am a disciple of Jef Raskin (z"l), the person who designed the first Macintosh, the author of the book "The Humane Interface" (THI).

My goal in this entry is very simple: to prevent the perversion of the meaning of the word "Humane", to set the record straight.

I read Raskin's THI a number of years ago, and don't have it in front of me at the moment.

The claim made by elharo is simple:

that an apple iPod user interface, or the imac's new remote control, with its 4-5 buttons is better or superior to the 100-button remotes from hp and gateway.

That's absolute nonsense.

The 100-button remotes are infinitely better. The ipod has serious usability issues. The problem was easily illustrated to me one day when I tried to teach my poor daughter to use the ipod's interface a year or two ago (she was 4 or 5 years old).

The poor girl was getting so frustrated that pushing the sequence of buttons I instructed her to push did not have the desired outcome. Instead of scrolling a song list, the volume would go up!

Why?? The ipod only has three or four buttons. That's not enough to express 100 different operations. So the buttons must be overloaded; they must be made modal. That is, the same button does different things in different contexts. This is precisely what you want to _avoid_ when designing a _humane_ interface. With the 100-button remote, there's no ambiguity, no context, no modality.

With the 100-button remote, you don't have to remember to press a sequence of buttons in a specific order, with specific time intervals between the button presses. With the 100-button remote, the operation boils down to pressing a single button.

Even better: once you've performed an operation once or twice, you've formed the habit. Doing the same operation again later would take you no time, because you now know that the second button from the left on the top row is the one you want.

I have nothing against the apple ipod. it just has an in-humane interface, that's all.

Why am I talking about iPods on a Java weblog? Because the same principle behind designing the interface for a remote control applies to designing humane interfaces in our software applications. elharo brought up remotes as an analogy in the context of designing interfaces for List or Array objects, stating that such a class should have a minimum of methods, and that its design was consequently better.

We're all in one way or another responsible for designing interfaces. Let's make sure they're humane. If you haven't already read THI, I highly recommend you do. Here's the link:

http://www.amazon.com/gp/product/0201379376/104-7232126-4081541