GUI patterns

There are standard GUI patterns. For example: Do not overlap windows. Why? Because information is hidden (assuming that the information is in a window because it is useful and meaningful in the first place). Yet both Windows and MacIntosh do not follow this because screens are so small.

Maybe in 10 years screen will be of 48 inches, but right now, having overlapping windows is still useful.

Another GUI pattern that is corollary of the first one is: Do not scroll. This is a very important pattern in web, since most websites seem to follow that, except the point of entry to the internet: Google. So I guess they think it is not that important. I mean if you are searchign a document it will probably be in the first 3 links, so you won't scroll anyway.

A much more important GUI pattern, in my humble opinion, is direct manipulation, that is, being able to modify (or manipulate) directly what you are seeing on the screen (provided that you have the right privileges). Which also makes me remember of 2001 when I was discussing with a bunch of XPers about XP and how you couldn't keep track of bugs using a Wiki (because I assumed that since the Wiki was so open to direct manipulation, you couldn't control what people put in it). Also I assumed Wikis did not store any history, so you could not rescue an old page, or fire an alarm everytime a page was modified. Needless to say I was wrong! Wrong! WRONG!

First of all, adding permissions to a page (or to any resource) is just a matter of adding a proxy. Adding a proxy in Java is like 3 minutes of work if you are lazy AND dumb. If you are not lazy, but you are dumb, it is like 2 minutes. If you are lazy, but not dumb, it is like a 30 seconds of configuration. And if you not lazy nor dumb, it has already been done.

So direct manipulation is a very important pattern, especially when it goes hand in hand with Wysiwyg (What You See Is What You Get).

Most sites can be implemented as Wikis and I see no need to hire expensive web developers.

Most projects I've worked on have required half the people to work on the presentation layer and the presentation layer is never finished quite right. The customer is never satisfied with how the site looks, but he doesn't care at all about SOA, ESB, EJB, Spring, Hibernate, SQL, etc. All your techinical details are just meaningless words to him. All he cares about is how the site looks and what the site does when you press a button or do something else with the user interface.

So the user interface is like an open problem to him, while we IT professionals couldn't care less. We concentrate on the hard stuff, that is the internals. And I guess that is correct from our point of view or the screen will just be a mockup.

But guess what. After 15 years dealing with the internals, it becomes repetitive and simple. Eventually there are no secrets to discover, no problems to resolve, and we begin to realize that the only reason a project can be late is because we didn't understand what the customer wanted. So we need to concentrate on the user interface. At least from my point of view, once you get the user interface right, the rest is a piece of cake (I'm not saying it will be done a minute, in an hour, or a day, I'm just saying that it is already wel defined), just in case....