jamesladdcode.com

What I hear, I forget.

What I say, I remember,

What I do, I understand.

- Lao Tse

Recently I have been reading a lot of books about interaction design, prototyping and negotiations and one book in particular Designing Interactions, by Bill Moggridge is a absorbing read, especially if you want to read about the pioneers of User Interfaces and devices as well as the various techniques they use. You name a pivotal person in the field of Computer interaction and the book covers them and their crowning achievements. There are also a lot of places where Smalltalk is mentioned. Oh how much we owe to that time and that language.

To give you a taste I’ll quote the section that interviews Bill Verplank who drove interaction design to new levels during his work at Xerox from 1978 to 1986 on the Xerox Star graphical user interface. I like this section in particular because it draws out what an interaction designer is all about. Even if you have a passing interest in interaction design, I think this book is worth getting.

From the book:

Bill says that the interaction designer has three questions to answer; they are all “How do you…?” questions.

1. “How do you do?”

How do you affect the world? A human, a person that we are designing for, does something, and we provide affordances. We either present handles that they can continuously control, or we give them buttons for discrete control, pressing the button and giving up control to the machine. When you are designing the way people act, there is a choice between handles and buttons. You can grab hold of a handle and manipulate it, keeping control as you do it. Alternatively you can push a button, or click one, delegating control to the machine.

2. “How do you feel?”

How do you get feedback? McLuhan made the distinction between what he called “fuzzy,” or “cool,” media and “distinct,” or “hot,” media. Early TV was a cool medium, with its fuzzy images. Cool media draw you in. A book with careful printing or a gravestone with carved lettering is hot, or immutable–you cannot touch or change it. We design the way that the machine, or system, gives feedback to the user, or the book looks to the user, or the sign communicates. That’s where a lot of feelings come from; a lot of our emotions about the world come from sensory qualities of those media that we present things with.

3. “How do you know?”

As we design products with computers in them, it is very difficult for a user to know exactly what they are going to do. A map gives the knowledge that you may need if you are designing complex systems. A path offers a kind of understanding that is more about skill and doing the right thing at the right moment. It is the responsibility if the designer to help people understand what is happening by showing them a map or a path. The map shows the user an overview of how everything works, and the path shows them what to do, what they need to know moment by moment.

This section continues to build upon this by talking about Interaction Design Paradigms and Process and ends with a good example of applying these.

This is just one of many inspiring sections that let you get into the mind of the people who created the tools and interfaces we use today.

Would you like to come and work with me on a green-fields Java, Web 2.0, Social Network application using frameworks like Seam and using Agile and TDD techniques? If yes, then please apply through this Seek advertisement. Updated advertisement.

Dynamic Languages Strike Back - another long but fantastic rant from Steve that is well worth a read.

I have very vivid dreams and I remember them rather well and in detail. Last night I had a dream and it involved Steve Jobs, let me explain …

A group of people and I were traveling on a bus through a nice forest like country side high on a hill when we came to a very large waterfall. The bus went near the edge of the water fall on top of a large sheet of glass, enabling the bus to get close to the edge and for all the passengers to enjoy the view. The bus started to slide on the glass and it plunged off the edge of the falls and lodged between some trees and a cliff with the front of the bus in the air and the back of the bus closer to the ground. No one was hurt but we had to get out quickly because the trees holding the bus were creaking and we felt the bus could plunge further any minute. Everyone got off the bus including me or so we thought, until a few faint squeals came from a boy in front of the bus too scared to move. I went back onto the bus and grabbed him and took him to safety.

We mustered together and walked through the forest for a while and came upon a large house with nice grounds and a tranquil feel. There were seats on the ground and in front of them a banquet and we all sat down and started to eat. In front of me only a meter away was a separate seat and to my amazement sitting at it was Steve Jobs and his wife. Steve stood up and said he would rather sit with all the other people and he came and sat opposite me. I was rather excited by this.

I asked Steve what he was doing in this place and he said he was searching for someone to help him build the next big thing at Apple. I then asked how he would know when he found that person and he looked at me calmly and said, “they will have a white ball”. I have always been excited at the prospect of meeting and working with Steve Jobs and Apple and looked around me quickly to see if I could find a white ball. To my amazement I was sitting amongst thousands of them which I had previously thought were lotus leaves, so I picked one up and handed it to Steve, who looked back at me with a confirming grin. A tear came to my eye.

I was hired.

I’m at a loss to say what this means and if you have any ideas, please let me know.

User Interfaces, Design and interaction interests me and I stumbled across this web site http://www.dontclick.it/ where they experiment with an interface that removes the need to click a mouse button.

Very interesting indeed.

I can’t wait for Java closures because they will make our code simpler and cleaner. For example, we can replace

FileInputStream input = new FileInputStream(fileName);
try {
    // use input
} finally {
    try {
        input.close();
    } catch (IOException ex) {
        logger.log(Level.SEVERE, ex.getMessage(), ex);
    }
}

with this

with (FileInputStream input : new FileInputStream(fileName)) {
    // use input
}

AWESOME !

(The example above was taken from Neal Gafter’s Blog.)

Closures would have made the code in my East example more clear too.

So what interfaces do users really want and what do they really like ?

Over at Fully Personal Interface they are finding out with a verify interesting survey on different aspects of ‘interface’ and you can see a report on them. Please take a moment to take the survey.

When I visited the site I was survey participant 2010.

Also check out this good eZine on making your life easier and your interfaces, called Smashing Magazine.

For a short while I have been looking into JBoss Seam and working through the examples and coding my own project.

My last few projects were Spring/Spring MVC based and architected with distinct layers to keep the code clean and focused, and I wondered how Seam supported this approach. Initially I thought I could just get Seam to inject the items I needed to form different layers and it does, but this isnt idiomatic Seam.

I think it is important to understand the idioms of a framework so you understand how it is intended to be used and therefore get the most out of it. So I posted a question about layering to the Seam Forums.

There were a couple of responses but one in particular from Andy Gibson spelt it all out so clearly that I had to post it here, since it applies to a wider audience than just Seam users.

Hey James,

Shane is right, it really depends on the application context. Another important factor (I think) is whether code is going to be re-used later on, either from another point in the same application, or from another client elsewhere.

These things can always be refactored out later but if you know about it ahead of time, it can impact design decisions earlier.

The first major layering decision though is whether to mix business logic and view logic in the same session bean. A lot of times we’ll see code to handle button clicks in the same bean as the code to perform actions on entities. If we want to perform the same actions from other places in the code or even other applications, we may want to separate that out which is fine.

You can further demarcate the layers based on state and function. The ‘backing bean’ session beans can hold the view state and logic, but any general functional code can be placed into stateless beans which have state passed in to them.

The obvious benefits are that we put the method in one place and always use it to perform that action so if we decide to change it, or always send an email to someone when that action is performed, we can just put it in that one method.

This is probably obvious to many as it is just good OO principles, but Spring always seemed to to put as many layers in as possible because of the (overstated IMO) need to change any layer at any given point in time. We started with MVC, and then Spring threw in service layers, repositories, Daos and so on.

Seam is a little different, especially since it is based around a stack that probably 80% of people are going to use anyway, hence no need to swap out layers. With Seam you can just put layers where they are logical, or it is prudent to do so.

Cheers,

Andy Gibson

Seam handles the weaving (I had to get in a sowing term) of web and services so well that the need for heavying layering is removed, at least for the immediate development. However, I am still a little weary of putting EntityManager interaction logic across more than one class and still choose to put this into a Repository object that is in turn injected into the Action/Service.

Happy seaming !

I was reading a post on the blog by Simon Harris about a suggested RESTful way of requesting information in ranges, and I wondered why we don’t use the OPTIONS keyword more, since we appear to be right at home with GET, PUT, POST and DELETE?

There is no standard for REST that I am aware of and maybe this is the reason and maybe we need someone to champion a draft or suggested ’standard’ for using REST and REST-enabling web sites.

I’d like to propose that sites use OPTIONS to enable a method of discovering what resources a site exposes. For example, an OPTIONS request to www.acme.co may respond with an XML representation like this (this is rough but I’m sure you can follow it):

<resources>

<services>

    <service name="consulting" uri="/consulting"/>

    <service name="support" uri="/support"/>

</services>

<products>

   <product name="acme torch"  uri="/product/torch"/>

   <product name="acme battery" uri="/product/battery"/>

</products>

<gateways>

    <gateway name="shopping cart" uri="/cart"/>

</gateways>

</resources>

From this the whole offering of the site is discoverable in a reasonably uniform way. Further OPTIONS request would make possible finer inquiry into the supported options and functionality.

This approach would keep the HEADers free to do what they do in regards the client to server conversation and the supported representations of resources.

If we all took this approach then clients could become smarter and provide more automated and regular features on top of the human readable site. Imagine asking your browser to find the cheapest iPod and it going through your bookmarks or google search results and interrogating each site for the best price, heck, it could even make the purchase too.

Want to work more on this, then drop me a line.