Fog Creek Software
Discussion Board




Naked Objects

I'm interested in comments about Naked Objects - an open source java framework that automatically generates a "truly OO" user interface (with persistence) from business objects that descend from the NakedObject class.

It is thought-provoking, but is it practical?     

http://www.nakedobjects.org
Their book is not out yet but it is available at:
http://www.nakedobjects.org/book/content.html

Scott McKissock
Thursday, December 05, 2002

Scott,

Thanks for that.  Possibly the Holy Grail of development. 

I'm definately going to look into it.

Ged Byrne
Friday, December 06, 2002

What do you do about those business objects that it would make no sense to present to the user? Objects that don't exist in the real business but are necessary for the functioning of the system.

John Topley
Friday, December 06, 2002

I don't know exactly how this particular implementation works but possibly you could define some rules that state which business objects/relationships are visible to the end user.

Wayne Bloss
Saturday, December 07, 2002

You can add about clauses that define when an object is available, or what level of access to allow.

This makes it nice and easy to define objects that are not visible, or are only visible to an expert user or debugger.

Also, the whole framework is just a regular Java object model.  You can easily access non-naked objects.

Its all very impressive.  I'm planning to see how well it mixes with Jython some time this week.

Ged Byrne
Monday, December 09, 2002

I agree with Ged.

I downloaded it, and it makes a lot of sense.

A couple of days using it, and it becomes very intuitive.

One thing though, I do not like the way it lets you open 10 windows of the same object. The task bar gets really crowded very quickly. Very confusing for the not so computer literate.

I also do not like the way it does not automatically update windows of objects that are already open.

If these get fixed, then it really is a simple yet powerful way of running business apps.

tapiwa
Monday, December 09, 2002

tapiwa: Do you think is it intuitive for end-users though? For me as a programmer, it is beautiful as it gives me a direct correspondance between the UI and the objects I've coded. But is it that easy for non-developers who doesn't care one bit about objects?

I suppose there is a learning curve for end-users. One advantage is that different applications would get very similar user-interfaces, so once you've figured the UI out for one app it would be relatively easy to learn another.

I agree, all those windows get in the way.

Karl
Monday, December 09, 2002

I was bothered about the number of open objects, too. 

I can see this style of interface being good for users that have to interact with the system day in day out, such as in a call centre environment.  For phone use most systems have an interface that is far to restrictive, and the openess of this framework would be welcome.

However, I think something more inductive would be needed for more casual users.

I'm also wondering if there's a way of creating a JSP OVM so that these apps could be published straight onto the internet.

Ged Byrne
Monday, December 09, 2002

I like the idea.  But.

This strikes me as the sort of interface that would completely bewilder somebody who's unfamiliar with a lot of hard-core computer terminology.  I see references to words like "instances," "cases," and other technical terms that seem to be directly exposed to the user.  If a non-technical office user tried to use an application like this, I predict they'd be confused and unable to use a lot of the features.

As a user, I wouldn't want to use this sort of system.

As a developer, it's very convenient, but developers are solving user problems, not the other way around.

Brent P. Newhall
Monday, December 09, 2002

Yes, but remember that call centre staff get a lot of training in running the systems they're talking to: they have to know how to drive the functions it offers.

In the case of Naked Objects you just train them how to use Naked Objects and let them loose. Yes, there'll be a learning curve, but the thing here is that you're putting the domain knowledge in the hands of people who can use it, rather than in the hands of some interaction scripting people who are (just to give the example here) an hour's drive from the call centre where their users are.

Naive users don't just pick up an interface (N.O. or otherwise) and a headset and start talking to customers.

Katie Lucas
Tuesday, December 10, 2002

Damn I'm convinced, I have to go look at it at least.

Another damn framework, paradigmatic thingy.

Simon Lucy
Tuesday, December 10, 2002

When I was playing with the framework, I kept thinking that a properly designed app using this framework could be very powerful and easy to use. I really do think that it is fairly intuitive, even for new users. Microsoft Windows/Office really got Joe Average familiar with the concept of the concept of right clicking on words/pictures/thingies (objects). When I taught computer literacy at university, I always used to tell students... when in doubt, right click.

It is a lot easier to teach a user to right click on something to find out what they can do with it, than it is to have them remember some menu item/keystroke combination. More to the point, it is easier to upgrade. All the actions you can perform on an object are there in one place. With good descriptions as menu items, the system is self-teaching.

Sometimes it makes sense to expose these objects to users, in other cases it doesn't. I am looking to use this to develop a CRM type system. I particularly like the way you can define objects (e.g. correspondence event) and make it easy to associate them with other objects (eg contact(s). I must admit that this is the most intuitive interface I have seen.... drag and drop, that is this easy to develop in.

This is particularly so where you are doing many to many associations... many people can share one address. One person can have many addresses. Seeing everything as objects makes this concept a lot easier to understand to newbies.

There are a couple of changes I would make to the framework to make it even more newbie friendly

1. I don’t like the way the windows just exist on the desktop. If you have another application maximized in the background, it is very easy to inadvertently click on that window, bring it to the foreground, and 'lose' the entire objects system. An idea might be to have all the objects opening within one uber window.

2. I would rather have the system switch to an already open and update instance if a user tries to open an instance more than once. There really is no need to have the city instance Washington open more than once at the same time.

3. I agree with what Brent wrote. I haven't looked at the code extensively, just the examples (so I am not sure whether such functionality exists already), but I would prefer to give business names to windows/menu items, instead of calling them objects/instances/cases etc.

4. Save/Cancel/Close buttons on the instances windows would help. I know what UI experts have written on this, but most PC users like the option of cancelling actions, tend to expect to save changes and expect to click the little x on the top right of the window to close the app. Before the UI gurus lynch me, try the system. When you close an instance window, you close only that. When you close the objects window, you shut down the entire app.

tapiwa
Tuesday, December 10, 2002

Does anyone care about the fact that you still must make your objects Naked Objects-compliable, i.e. you must implement an interface for each class. Wouldn't it be possible to use reflection on already existing classes together with some form of policy files for determining which objects to show in the UI? That would make it possible to reuse already existing code without any modifications (but it would still require som extra work).

Also, maybe I should take a closer look at the framework before asking stupid questions... =)

Karl
Tuesday, December 10, 2002

Well, it's LGPL licensed... Why don't we get to fixing it (and porting it to C#!)

Neil E
Tuesday, December 10, 2002

It will be nice if the open source nature leads to the framework being developed.

However, the source isn't in CVS.  Changes have to be sent to the authors for consideration.

It would be a shame if over control prevented the framework from bloosoming.

I've started reading the book, and their is a puritan edge there that could spoil things.

Ged Byrne
Tuesday, December 10, 2002

Neil... can you use Visual Studio for GPL projects??

Ged... I agree. I remember that one of the ways that arsDigita alianated developers was that while the toolkit was 'opensource', they were not too receptive to outside contributions to the source.

Needless to say, I will be watching the project. Very interesting concept indeed.

tapiwa
Tuesday, December 10, 2002

small observations, probably show that I have never actually run a NakedObjects app...  but I'll add my opinion anyway:

it would be nice if:
* the object inspector windows were mdi children, so that you don't get taskbar bits for them and you can minimise the whole thing at once.
* if you can't open multiple instances of the same object
* if when a new window pops up there is a connecting arrow attaching it from it's references, so it is clear how it is connected.

Still, definitely a toolkit I'd like to play with


Tuesday, December 10, 2002

"However, the source isn't in CVS.  Changes have to be sent to the authors for consideration"

took five seconds to fnd the cvs on the website.. huh


Tuesday, December 10, 2002

--------------------------------------------------------------------
took five seconds to fnd the cvs on the website.. huh
--------------------------------------------------------------------

If you'd held out for that sixth second you'd realise it was read only.

Ged Byrne
Tuesday, December 10, 2002

------------------------------------------------------------------
The development process
This an open source project (released under the GNU LGPL) so you are free to look at, and change, the code. If you fix a problem or make changes or additions that you think others might be interested in then please forward them to us so that we can consider including them in the central distribution. As the CVS (see below) is read only you will need to send us the updated code, or a patch, so that it can be reviewed and incorporated. Please can you detail what you have done and specify what version the changes are based on.
------- http://www.nakedobjects.org/developers.html

To clarify what I was trying to say - they are obviously keeping a tight control on the development (although it is always possible to fork.)  This could be good, or could be bad.  Time will tell.

Ged Byrne
Tuesday, December 10, 2002

I hope that as co-originator of Naked Objects it's not out of place for me to comment.  I've enjoyed reading all this discussion so far.

First on the CVS being read-only.  We may relax that over time, but to begin with we are erring on the side of control.  It's well intentioned.  We have been working on the design of the framework for 3 years, and I've been working on the underlying ideas for 10 years.  Our experience is that it takes a long time to find simple elegant solutions to things and a short time to lose them again!  We've already had lots of good suggestions from users and would-be contributors, some of them above.  But we've also had lots of suggestions that if implemented would, IMHO, destroy the very essence of the naked object idea.  We certainly want third party contributions, but we most value them from people who are willing to really get to grips with the underlying philosophy and work at trying to find the best way to do something.  Most of our own ideas get rejected as well!

Of the criticisms raised in the discussion above, we would agree with most of them.  We don't like the fact that every object is currently a separate window, with an ugly generic title bar.  We want to see a whole new user interface where objects appear as native icons inside a workspace, which the user can also save, keep private arbirtary collections and so forth.  We have some ideas already, but there's so much else to do that we can't promise it soon, unless we get substantial offers of help.  I say 'we'  -  but it's Robert  is the framework author.  I'm just the 'puritan' in residence, Ged;-)

Opening multiple views of one object?  There are pro's and con's to this.  Bear in mind that you might want to open alternative representations of an object e.g. as a table, graph, or map.  Tapiwa said that other windows don't automatically update when an object is changed.  They should do.  Probably you've forgotten to include the objectChanged() call in your various set methods.  See  http://www.nakedobjects.org/book/section19.html

Thanks for your comments and moral support.

Richard Pawson
Wednesday, December 11, 2002

Richard,

Thanks for your comments, and for making the fruits of you labour available for all.

I'm very excited about Naked Objects, and look forward to spending some time with them.

The books an interesting read.  It was good to read a fresh perspective on Objects - your criticism of MVC is spot on.

Ged Byrne
Wednesday, December 11, 2002

Richard ... my bad (sort of).

I had not tried to develop an app yet. All I had done was play with the examples you have.

Using the Bookings example. Create a couple of new LOCATIONS. Do not assign a CITY. Open a window with all instances of LOCATION. You will have a list of the two you just created.

Open an instance of a single LOCATION.... Assign a CITY to the locations. The window with the list of LOCATIONs does reflect the changes. If you have more than one instance of a LOCATION open, the changes are updated automatically in ALL of them. This is good (tm)

However, if you add a new LOCATION, the window with instances of LOCATION listed does not update. To see the new LOCATION, you have to open another window listing the LOCATION instances. This is bad(tm).

Assuming this was a call centre, one might want to keep a window with CLIENTs, LOCATIONs, etc open all the time, and have it show the current realtime position. Additions and removals should be updated automatically.

This become more and more important as you increase the number of users on the system.

Great work though. The system can only get better.

By the way. What are the passwords for the EXPENSES example. A cursory look at the docs did not reveal them.

tapiwa
Wednesday, December 11, 2002

Ah, sorry  -  that is the once case where the screen does not update automatically.  We're working on that one, but as mentioned above the difficulty is finding an elegant solution.  If the collection of objects was always small enough to be shown on the screen it wouldn't be a problem.  But if the collection is large enough then you will only be seeing a subset in any one view. Then, when a new object is added to that collection, we have the more complex issue of deciding which subset should now be displayed in the window.  This is not insoluble and I'm sure we'll have figured it out soon.  We'll look into the password query and update the website accordingly.

Richard Pawson
Wednesday, December 11, 2002

--------------------------------------------------------------------
took five seconds to fnd the cvs on the website.. huh
...
If you'd held out for that sixth second you'd realise it was read only.
--------------------------------------------------------------------

just like sourceforge then?


Sunday, December 15, 2002

*  Recent Topics

*  Fog Creek Home