The Cafes

David Chapelle writes that

To anybody who’s paying attention and who’s not a hopeless partisan, the war between REST and WS-* is over. The war ended in a truce rather than crushing victory for one side–it’s Korea, not World War II. The now-obvious truth is that both technologies have value, and both will be used going forward.

That’s a nice analogy. Take it one step further though. WS-* is North Korea and REST is South Korea. While REST will go on to become an economic powerhouse with steadily increasing standards of living for all its citizens, WS-* is doomed to sixty+ years of starvation, poverty, tyranny, and defections until it eventually collapses from its own fundamental inadequacies and is absorbed into the more sensible policies of its neighbor to the South.
Read the rest of this entry »

Yes, it’s the coolest phone yet designed, but smart techies are going to wait on this one. It’s a little expensive at $599 and $60 a month for service other companies charge $40 a month for, but that’s not why you shouldn’t buy one. The two-year lock-in to a poor network is an even bigger reason to stay away, but that’s still not why you shouldn’t buy one. The real reason is that the iPhone won’t be ready.

Do you remember the first iPod? the first Newton? the first Mac? These were also very cool Apple devices that leapt beyond what anyone else had done, and consequently didn’t work quite right. It took a few iterations not only to work out the bugs, but more importantly to work out the design flaws that inevitably arose when inventing radically new product categories and user interfaces. The iPhone is no exception.
Read the rest of this entry »

Yet another hideous idea from the closures camp: removing checked exceptions from the language. Now they want to remove one of the features from Java that actually works to support their pet obfuscation.

According to Neal Gafter:

We did a Google search to see how many people have written in support of checked exceptions and how many people don’t like them. The discussion seems to be lopsided against checked exceptions, but on the other hand that may be due to the fact that checked exceptions are the status quo.

For his next Google search, let me just say, I like checked exceptions and I want to keep them. The people who object to checked exceptions mostly seem not to know the difference between checked and unchecked. Most importantly, they seem not to know when to use checked exceptions and when to use unchecked exceptions. A few libraries such as the Java USB API even get this exactly backwards. And I will admit, if you don’t know this crucial piece of information, then checked exceptions seem ugly and confusing.
Read the rest of this entry »

There’s a common but mistaken belief that proper user interface design requires lots of pictures and icons. In fact, it doesn’t. Many concepts and actions can be fully and best conveyed by text. While standard icons for directories and disks and the like can be helpful, custom icons for an application’s unique actions rarely are. The fact is, most icons are not self-explanatory; and if they’re not common enough to be standardized, they’re not common enough to be learned easily.

Nonetheless, many applications persist in creating pointless, incomprehensible toolbars. Icon design is hard. It is not something that just any art school graduate with mad Photoshop skills can accomplish. Icon design is about conveying an idea with pictures. not merely making a 32×32 bitmap look pretty. It’s hard enough coming up with a good icon for basic actions like cut and paste. Now try imagining one for “Analyze Module Dependencies” or “View Breakpoints”. There’s a reason Susan Kare gets the big bucks.

Lately, this trend seems to have seeped into menus, where text used to rule supreme. For instance, look at this File menu from IntelliJ IDEA 6.0:

Not only do the icons add nothing to the menu items. They actually make the menu harder to scan and read because the items are no longer left aligned.
Read the rest of this entry »

IBM’s Bill Higgins takes a very unusual way of explaining why Mac apps should look like Mac apps and Windows apps should look like Windows apps. It also explains why desktop Java failed.

I’m not sure his analogy really holds, but I’m not sure it doesn’t. His conclusions are correct, even if his reasoning and/or evidence turns out to be faulty.

He makes a good argument that SWT is the right way to design a cross-platform GUI, and Swing is the wrong way. The problem here is that empirically Swing delivers more native cross-platform apps than SWT does. When theory clashes with experience, either the theory is wrong or there are factors not accounted for in the theory. I suspect the latter here.