techno.blog("Dion")

David Temkin has written about The lost art of user interface programming.

I wrote a little bit about this earlier, and agree with a lot that David has to say.

Building good user interfaces is hard work. Very hard work. When I used to work in that area I was always amazed at how screwed up people were (this means: they didn’t think and act like me in front of a computer).

In general open sourcer’s aren’t going to put in the time to do user experience tests and the like, but this may change in the future. Open source software is also normally more:

a) aimed at other geeks [so you can get away with more]
b) heavy on backend code, versus “products”

I hope people take a step back with the new rich interfaces, get back to basics, use the KISS principal, just test real user experience… not their own! You know your app a lot better than John Doe does!

Judy is an open source project that is trying to bring together Jini and Web Services.

Judy consists of:

• Jini Client->Web Service
• Web Service Client -> Jini
• UDDI integration

Description

Web services hold a great deal of promise for facilitating automatic, Internet-wide distributed application execution. The strengths are in it’s use of the defacto Internet standards such as XML for protocol encoding and HTTP for protocol transmission — this allows any operating system, programming language, and network wire protocol to be used by any client or server. In addition, it utilizes a service-oriented architecture whereby an intermediary facilitates the communication between clients and servers. The downside is that web service protocols are moving quickly toward over-specification and over- complication, yet still incorrectly assume:

- the network is reliable
- latency is zero
- bandwidth is infinite
- the network is secure
- topology doesn’t change
- there is one administrator
- transport cost is zero

Jini is a Java-based solution that was developed to deal with these problems (also using service-oriented architecture concepts) but does not carry the baggage of over-specification. In fact, combining the best of these two technologies would provide an excellent distributed computing solution.

Cool stuff.

UPDATE: Talip has written an interesting entry on JINI in which he looks to other blogs for a state of the union.

I went to a talk at the Cambridge Forum where Elizabeth Warden talked about her book The Two Income Trap. I saw her on Bill Moyers NOW on PBS, and was really impressed.

A lot of these problems come down to education. When are we going to have a revolution in the way we “do” education.

We do not have public education. It is all private. You just “pay” for a good school by buying a house in a good location, OR you send your kid to a private school. This isn’t an equal education for all.

Imagine a world where all kids are highly educated. I know it scares the old white men, but it would create an amazing world.

Sam Pullara has written about how Eclipse needs to switch to Swing before SWT really gets out of hand.

I totally agree with Sam here. Once upon a time Swing/AWT really sucked. It was painful to work with, looked awful, and ran dog slow.

That time has passed. It is really hard to change peoples minds on this matter… so if you fall under that camp and YOU THINK SWING IS SLOW then please take some time to try it out again and you will be impressed.

Just talk to the IntelliJ guys if you want more proof.

Kris Thompson asks ‘So why do I want Rich Interface Applications?’.

I was on a conference call with the Flex folks, in which I watched them put together a typical Shopping Cart system. The demo was very slick (as it should be) and the user experience was so nice. You could drag and drop, change views, and all of the “rich” things that you are used too on the desktop.

My only concern with some of these rich clients is the lack of a uniform UI. This has long been an issue with Flash-enabled websites. Every designer tries to do something “cool” and inheritely un-usable.

I used to study usability in a past life, and always found it amazing that even if you came up with an amazing “ne way” users still didn’t grok it like the old “ugly way”.

I wonder if there is an effort to create usability guidelines a la Apple Guidelines for these Rich applications. That would be fantastic.

Awhile ago I wrote how EJB is still good at TX processing.

When it comes to choosing a “J2EE” solution with EJB and all…. I contend that there is a place for it, but it is for high scale REAL “enterprise” solutions. These are few and far between. Some sectors tend to these scenarios: Large banks, telco, government, etc. However, most apps are smaller, departmental, small business, or toy applications. There is no need for everything that a full J2EE stack has to offer in these situations, and there are other solutions out there to handle these.

So if I am working on one of these large scale systems… what am I excited about in the J2EE stack?

• Solid JTA/JTS
• Solid JMS
• Maybe solid caching and fail-over/clustering

If you want these features where are you going to look? BEA? IBM? I don’t think JBoss would be on the list in its current form (I am not saying that they can’t catch up, but I don’t hear many people saying “Man I love the JMS system that JBoss has”).

So when would you choose JBoss? I bet the majority of applications that use JBoss fit into the categories of:

• Using EJB. Don’t need them really
• Using “JBoss” but am only using servlets… (I have also seen this at places who have spent a lot of $$$ for WebLogic and only use their servlet engine on small projects… er….)

JBoss needs more value add. You could argue that they are getting there via JBossAOP, their clustering, JBoss Hibernate ;). They need to keep growing these services to give you a reason to use them, or they need to come up with a top quality MQ / JTA implementation.

What do you think? I would love to hear of some use cases where it made sense to go with an open source solution such as JBoss.

Dynamator 1.5 has been released.

Dynamator is a simple tool that can be used with any page generation technology to completely separate HTML from server code. Dynamator transforms HTML or XML files into server pages or programs. It can generate JSP, XSL, Velocity, and even plain Java.

Dynamator 1.5 features major performance improvements, syntax validation, a documentation refresh, and a large number of minor enhancements and bug fixes.

It looks similar to XMLC. I am always a fan of technologies which leave the HTML as HTML. This way designers can dink around, viewing something that looks like the real thing without having to go through a round-trip.

Using the id=”x” approach definitely gives you this ability (like XMLC, and Tapestry with its jwcid=”x”).

It is also interesting that you can use Dynamator with many page generation technologies and it is “build-time”.

It is always tough to know when some news is real or not when you are around April Fools. “If it is April 1 somewhere in the world does that count?”.

However, today we hear that Sun announces peace with Microsoft: Legal and technical.

This is great news for everyone concerned. The industry needs competition (IBM vs. Sun vs. Microsoft …) but competition doesn’t have to be “nasty”.

Next we will hear that there will no longer be any negative ads from the Republican presidential campaign!

We are proud to have Java.Blogs in our ranks :)

I really like the added touch of having /index.aspx :)

After reading that Google is creating an email service, Gmail I started to think about what I wanted in my email client.

• MetaEverything: I want to be able to right-click on a mail message and tag it with meta data. This meta data will allow me to search/filter my mail.
• Multiple Folders: A message should be able to live in multiple folders. Folder heirachies are great until you realise that an entity wants to live in multiple paths
• Filter up: I want virtual folders which show all messages from sub-folders. E.g. if I click on Email Lists/Java it shows me messages from all of the lists (Email Lists/Java/JDO and Email Lists/Java/Groovy and …)
• Security: This isn’t just a client thing… but I wish everyone had digital keys and we were seemlessly using them in our email.