Jul 19, 2012 at 10:00 AM
Edited Jul 19, 2012 at 10:02 AM
* on properties: modify/clear links and choicesWe can determine whether there will be modify/clear links by looking at the disabledReason and optional properties either in extensions (simple scheme) or on the property-description (formal scheme.) For
the time being though we must follow the details link to see if their are choices for this property. This will be addressed in a future version of the spec.
Your understanding on this one is correct.
* on collections: addto/removefrom linksCan we also use some combination of disabledReason and optional to determine if addto and removefrom will be provided for this collection? Does that come down to individual members of the collection? ("You
can remove this member but not that member?")
[edited] If a collection property has a DisabledReason, then it is not possible to add to or remove from that collection directly and there will be no AddTo or RemoveFrom links. I think this is reasonably clear from 17.5.2 in the spec.
* on actions: invoke link and parameters. I think in the case of actions, "details" will always have to be followed to grab the invoke link and parameters.
Yes, that is the case right at present.
etc. Each property is an instance of RO.Property which holds data about that property: friendlyName, value, etc. And each action is an instance of RO.Action that does the same. So when a user clicks a link on a list (say from executing the All Customers service
action) I will GET the object representation and build my RO.DomainObject and then display it. Should I follow the "details" links for each property, collection, and action at this point so I can immediately respond to user interactions (adding overhead
before displaying the object) or should I wait until the user tries to perform an operation like modifying a property to request the "details" link, grab the "modify" link and then execute it (causing overhead for each operation.)
I think there are actually two subtle distinctions here.
One is responsiveness, which you've covered. Robert Matthews and I (when we started work on Naked Objects - which was then called 'Expressive Systems') were both influenced by the ideas of
Jeff Raskin on UI design. He had a lovely story that when the Canon Cat was started up, it immediately loaded a bit map of the last screen. Users were convinced that the whole system was functional
immediately. In fact it wasn't: it would take several seconds before the system was live and the (tiny) cursor started flashing. Perhaps we need to take a similar line: load up and present the minimal amount, and then asynchronously follow details
links while the user isn't doing anything to make the UI more responsive when they do - if the user happens to click on anything before this is finished then this pre-empts anything else.
The second point though is that I believe that the user should never be allowed to do anything only to be told that they can't/shouldn't. For example: you should be able to hit OK only to be told that you have missed out a mandatory field. (This
idea is well documented in UI design, but not widely practiced). This suggests to me that there are some forms of information that should be in place before the view is presented. Where possible, this information should be available in the RO representation
without having to follow further links - for example: disabled and mandatory (not optional). We may identify need for more such info.