This project is read-only.

Eager vs. lazy loading of object member details

Jul 19, 2012 at 8:53 AM

Hi all,

I've been working on building out an RO client api by merging the work done by Johan Andries with what I've learned I needed to build my viewer. AROW really needs this stuff separated to be able to sanely build the next round of features I have planned and Dan mentioned this as a nice goal for the project so I ran with it. I've reached a point where I need to step back and ask for some opinions.

Reducing the number of requests made to the server increases performance, scalability, and improves the user experience. So finding ways to limit server roundtrips, even when the server would return 304 Not Modified, can have a noticeable effect in the browser.

One property that affects how you can reduce requests is the domain metadata scheme. In the simple scheme, most of the information you need to display an object is right there in the object representation and on it's members: friendlyName, memberOrder, disabledReason, etc. In the formal scheme, this information is kept under the domain-types/ resource and can be read once and cached locally (I believe the spec says that this is OK) since it does not change.

There is however the case of the "details" link. Much of information read from the places above (friendlyName, etc.) is duplicated in this representation. But it does contain a few unique bits of data.

* 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[1].

* 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?")

* on actions: invoke link and parametersI think in the case of actions, "details" will always have to be followed to grab the invoke link and parameters.
If all of these issues are spelled out in the spec just let me know and I can track them down. I'm trying to limit how much time I spend reading the spec when writing my viewer to see how little "out-of-band" information I can get by with. I did have to go back to it though for working out the differences between simple, formal, extensions, details, and describedby. I am, of course, reading the spec when coding for Isis :)

I guess my final question is what is the general feeling around eager vs. lazy loading of the "details" links. For example, when requesting a domain object I build up a javascript object (RO.DomainObject) to hold the title, properties, actions, 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.)

This seems to be one of those cases where it's more about the user's perception of "snappiness" rather then a scientific measurement of "time spent."

Thanks for listening to me ramble.
--
Adam

[1] https://github.com/danhaywood/restfulobjects-spec/issues/2

p.s. I have further questions like these about other topics related to building an API for RestfulObjects such as using OID's or URL's to uniquely identify objects and balancing synchronous vs. asynchronous server requests, but I'll save those for another day.

Jul 19, 2012 at 11:00 AM
Edited Jul 19, 2012 at 11: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[1].

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.

I guess my final question is what is the general feeling around eager vs. lazy loading of the "details" links. For example, when requesting a domain object I build up a javascript object (RO.DomainObject) to hold the title, properties, actions, 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.

Jul 19, 2012 at 3:13 PM

Interesting. I've thought that perhaps WebWorkers could be utilized to preload all of the domain-types/ resources while the user begins to use the system. I hadn't thought of it being used within a domain object dialog though. That does bring up part of the sync/async discussion I wanted to have related to the client api. I'll try to put my thoughts together on that topic today and post them tonight.

On the second point, are you saying that along with the field labels being in red and having an asterisk next to each required field that the OK (or Persist) button should be disabled until those fields are filled in? I like that. Maybe tabbing out of a field could trigger a background request to validate the data as well. In AROW, when viewing a persistent domain object you're always in edit mode. Click a field, edit it, tab away and your change is saved to the server. Currently there is no mechanism to edit multiple fields and send them together as a single update. I've worked on both kinds of systems and they each present different benefits and drawbacks.

Jul 19, 2012 at 10:11 PM
Now that we have two full-blown RO clients in development (AROW and Spiro), we're going to start uncovering the areas that are uncomfortable. Which then gives us a basis for making things more comfy.

For this point, can I summarize this... we want the object representation to provide enough information that the object can be at least viewed by the user, and optionally allow the client to start preloading information for if the user decides to edit?

In the case of choices, the ticket [1] suggests that the choices be returned in the object representation. However, to accomplish the above, I think we only need to indicate that there *are* choices, but they don't need to be enumerated, eg:

"someProperty": { ...
"hasChoices": true
}

Happy to have this discussion here; once we come to a conclusion, then I'll copy over to te github issue page.

Dan



Jul 20, 2012 at 2:27 AM
I read that ticket as describing exactly what you proposed. We just
need a flag, not the whole list of choices.

One question about introducing this new property. How is the decision
made whether this goes directly on the property or under extensions?
Why is disabledReason directly on the property while friendlyName is
under extensions? What does this difference indicate? Can I not count
on friendlyName always being there? I was under the impression that
extensions was reserved for implementation-specific additions.

Adam

On Thu, Jul 19, 2012 at 4:38 PM, [email removed] wrote:
> From: dkhaywood
>
> Now that we have two full-blown RO clients in development (AROW and Spiro),
> we're going to start uncovering the areas that are uncomfortable. Which then
> gives us a basis for making things more comfy.
>
> For this point, can I summarize this... we want the object representation to
> provide enough information that the object can be at least viewed by the
> user, and optionally allow the client to start preloading information for if
> the user decides to edit?
>
> In the case of choices, the ticket [1] suggests that the choices be returned
> in the object representation. However, to accomplish the above, I think we
> only need to indicate that there *are* choices, but they don't need to be
> enumerated, eg:
>
> "someProperty": { ...
> "hasChoices": true
> }
>
> Happy to have this discussion here; once we come to a conclusion, then I'll
> copy over to te github issue page.
>
> Dan
>
>
> [1] https://github.com/danhaywood/restfulobjects-spec/issues/2
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe on CodePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at CodePlex.com
Jul 20, 2012 at 6:55 AM

On 20 July 2012 02:27, adamhoward <notifications@codeplex.com> wrote:


I read that ticket as describing exactly what you proposed. We just
need a flag, not the whole list of choices.

good. I've updated it to say as much.


One question about introducing this new property. How is the decision
made whether this goes directly on the property or under extensions?
Why is disabledReason directly on the property while friendlyName is
under extensions? What does this difference indicate? Can I not count
on friendlyName always being there? I was under the impression that
extensions was reserved for implementation-specific additions.

The distinction is more to do with supporting optional capabilities or not. In the case of friendlyName, this depends on the support for x-ro-domain-model (3.1); if simple scheme is supported, then it's in the extensions json-prop, if formal scheme is supported, then its over in the relevant domain-types resource.

By definition, implementation-specific stuff will also be in extensions.

HTH
Dan
Jul 20, 2012 at 10:56 AM
adamhoward wrote:

On the second point, are you saying that along with the field labels being in red and having an asterisk next to each required field that the OK (or Persist) button should be disabled until those fields are filled in? I like that. Maybe tabbing out of a field could trigger a background request to validate the data as well. 

Yes  -  that's the way Naked Objects MVC works, and I think it is a good pattern for any generic Restful Objects client

"In AROW, when viewing a persistent domain object you're always in edit mode. Click a field, edit it, tab away and your change is saved to the server. Currently there is no mechanism to edit multiple fields and send them together as a single update. I've worked on both kinds of systems and they each present different benefits and drawbacks."

That comment made me smile.  That's exactly how the first Naked Objects viewer (the 'DND') was designed to work, and reflected Robert and my views at the time.  Since then we've tended to go for the explicit edit-mode pattern  -  but that's more a reflection of the fact that most of our corporate clients prefer that pattern than because of a fundamental change in view.

Jul 20, 2012 at 11:06 AM
dkhaywood wrote:
For this point, can I summarize this... we want the object representation to provide enough information that the object can be at least viewed by the user, and optionally allow the client to start preloading information for if the user decides to edit?

I think that the two guiding principles here are:

1. The representation should have sufficient information such that the view can be rendered without following links  - and that any eager following of links (which might be asynchronous) doesn't change that. The point about the 'choices' - which we are all agreed on  -  is that, in an editable-view at least, there is typically a need to render the triangle indicated that there are choices, though the choices values can wait until the user clicks on it (or be eagerly loaded).

2. There is sufficent info such that the user cannot attempt to do something only to be told that it isn't valid for them to do it (Disabled being a good example).