Lambda the Ultimate

hi. I've got a strange question: is squeak really an object oriented system or it only claims it is? the point of the question is that instead of working with objects, i work mostly with text.

I am sure everyone here understands why this is so funny, so I will resist the temptation and will not ruin the joke by trying to explain it.

But some [design techniques for more efficient, more understandable, less error-prone user interfaces] are incompatible with the auto-generation of the user interface that is part of our approach. Some commentators have been strongly critical of the Naked Objects framework for this reason.

Yet users continue to tell us that they really like the systems that have been built using the framework.

Maybe it would be more appropriate to measure if the users could achieve their goals as-well with these auto-generated UIs?

Maybe we should just stop letting programmers do interaction design?
About Face 2.0: The Essentials of Interaction Design

Which aspects of it specifically?

1. The user interacts with Java classes with special member variables - value objects. There are no additional layers. Programmers and users talk about the same thing.

2. Reflection is cleverly used by the framework to find methods for various tasks. No need for configuration files etc.

Maybe I've just been spoiled by always being able to inspect the state of Smalltalk objects?

Yeah, but I do not want my clients to have to deal with object inspectors, while I can certainly imagine exposing them to naked objects. Naked objects is far more than inspection. Values can be changed, and new associations can be made - and the changed objects are aware of these changes, and can also veto them.

The first four years of my career were spent developing custom applications that generally followed the pattern of "software that controlls some custom hardware, has a GUI, and is persistent to a relational database". The GUI nearly always was a very simple reflection of the underlying object structure. In that context, something like this would be useful in many ways. First it would allow delivery of a prototype very quickly, since the GUI code would be largely implicit. Second it would allow the customer to play around and see the software's potential for themselves. Third, in a released product, it could serve as a GUI-style scripting language that users could use if the "standard" GUI wasn't sufficient for some unanticipated task.

I'm ordering the book if only to see the effect such good looking books might have on my students (and myself of course).

The funny thing is that I am currently writing a GUI front-end to a database that I have made end-user configurable. I've done it this way to make my life easier when getting requests for changes from users, but all the basic manipulation is simple enough (I think) for any competent user to perform, and thus allows individual users to customise their setup to suit themselves.

Perhaps an idea whose time has come?

inspect objects at runtime without...
Most Smalltalk systems would allow you to inspect
and change objects at runtime without writing UIs.

I do not want my clients to have to deal with object inspectors
Me neither!
Nor do I want an inappropriate solution foisted upon them just because it can be generated from existing code!

The FAQ promotes Naked Objects for problem-solving exceptional situations. The FAQ acknowledges that there are plenty better solutions for the 95% (arbitrary %) of boring normality (but you need to seek out expertise in interaction design, as you would seek expertise in SQL Server query optimisation).

combine the claimed virtues of naked objects with those of their own discipline
They don't seem reconcilable. People like Constantine care about usability - "we think the user interface should accommodate to users rather than that users should accommodate to user interfaces".
Naked Objects cares about auto-generation - "well-established design principles... We have adopted some... But some are incompatible with the auto-generation of the user interface".

I'd like to be able to get to the papers on OOUI without buying the book ;-) Predictably I would like to see "the claimed virtues of naked objects" supported by something. But rather than N O providing the evidence it seems that the other guys are expected to go do the testing - maybe that's why they are cranky ;-)

See "Experiments with OVAL"

I implemented a large subset of the Naked Objects system using the SWT gui from Eclipse in well under 2000 lines of Jython.

The benefit is everything in a set of applications work in a similar way without writing any gui code whatsoever. If you want something to work somewhat differently you try to implement that in a way that can be automated as well.

What the OVAL system and my Jython subset provide that is not in Naked Objects for Java is the ability to build a good bit of an application by point and click. In Naked Objects for Java, the application is expected to be programmed completely by hand. A little more code and using a dynamic scripting language or just using the Java compiler API would enhance that to support point and click applications.

Thanks for the link to this thread. I apologize for the slow response, but between client work and organizing a major international conference (www.foruse.com/2003/), I just have not had time to monitor and regularly participate in such exchanges.

In response to the post from Darius Bacon that you forwarded, I should point out that, although placed in quotes by Bacon, none of the criticisms attributed to me are actually from my paper on Naked Objects. What I wrote was considerably more measured, precise, and qualified:

"The usability problems...under most conditions of use are too numerous to go into in detail...[but] will be fairly obvious to any competent usability professional. Among these are the fact that context menus are a form of hidden behavior whose contents change and must be perused on every use in order to pick an action. Both drag-and-drop and right-clicking are interaction idioms that a significant fraction of users find difficult to master. With everything in separate windows, window management can become a burdensome overhead. Naked Objects also force users always to pick an object, then an action, even when it might be easier or more natural to pick an action and then the object on which to perform it."

These are all rather subtle problems but ones whose collective impact on user performance can all too easily be grossly underestimated or missed altogether. Even more important, as the paper goes on to explain, Naked Objects fail in not "tailoring the presentation of information and the operation of the user interface to fit the unique aspects of the context, the application, and the user needs." It is such tailoring and attention to seeming minutiae of interaction style that can enable nurses to solve clinical management problems 50% faster or cut the steps in PLC programming in half or enable teachers to make efficient use of a sophisticated classroom information system with only a paragraph of instruction. When and where usability and user performance are critical, human creativity is needed to design a truly effective user interface.

All I can say is to read the paper. It is not at all "dismissive" but rather takes "naked objects" very seriously. Along with specific, concrete criticisms and reservations, it also acknowledges various strengths, particularly in modeling, collaboration with users, and in offering problem-solving flexibility and control to users. It even finishes by highlighting that the most important message implicit in Naked Objects is about user empowerment.

It is not at all surprising that the quick and easy answers of Naked Objects appeal to many programmers. For that matter, however, the basics of usability and user interface design are not that hard to master, either, and we have trained countless developers to be effective designers. We will be training still more at SD Best Practices in Boston (www.sdexpo.com) and forUSE 2003 in Portsmouth (www.foruse.com/2003).

--Larry Constantine
Chief Scientist, Constantine & Lockwood, Ltd.