Typical Omission?: Client Side Caching Support

[luxspes]

Hi!
It seems like a simple problem, but it is not (to day, I have not been
able to find a way to do this without complex javascript coding):

You have chained comboboxes: County and State.

You select USA in the Country combobox, and its 50 States are loaded
in the States Combo (roundtrip to the server to fetch them)

You select Mexico in the Country combobox, and its 32 States are
loaded in the States Combo (roundtrip to the server to fetch them)

Now you select USA in the Country combobox again... how do I tell
Ariba that I do not want it to go to the server for them, since it
went for them the last time I selected USA, I want it to use that as a
cache and do not go for them until I tell it to do so?

Regards,

LuxSpes

[Craig Federighi]

Hi LuxSpecs,

We wouldn't call it an "omission" as much as a "design choice"... :-)

We don't cache this data on the client because, in the general case,
we can't detect that it's statically cacheable. (e.g. your code may
be filtering this list the second time around based on other
selections on the page or other changes in server-side state). In
practice we have not found this to be a significant issue in
application responsiveness or user experience.

> want it to use that as a
> cache and do not go for them until I tell it to do so?

That last part is exactly the issue: we don't want your programming
burdened with needing to "tell it to do so" -- this leads to a lot
more code and a lot more opportunities for errors.

Thanks!

- craig

[luxspes]

All right, so it is not possible to do it now... (and by what you
said, it will not be possible to do it in the near future)

Now, lets say I have already built my app using Ariba and I have a
very important ($$$) customer that really wants this feature (you
probably know how irrational some customers can be about some
features).

What would you recommend me to do to make my customer happy? Perhaps
creating an specially designed "combobox tree control" with inherent
caching/chaining capabilities encapsulated inside it?

Would it be hard to create such a "low level" new control in AribaWeb?

Regards,

LuxSpes


On Feb 24, 10:03 am, Craig Federighi <craig.federi...@gmail.com>
wrote:

[Craig Federighi]

Hi LuxSpecs,

Now, lets say I  have already built my app using Ariba and I  have a
very important ($$$) customer that really wants this feature (you
probably know how irrational some customers can be about some
features).

Well, we have millions of users from a large fraction of the (very demanding) Global 2000, so we've managed to satisfy a pretty broad swath of your potential customer base on this count.

Here's what I'd try with your customer:

1) Your users are most affected by "common case" performance, not edge case optimizations.

2) 80% of the time they will either A) select US, and pick a state, or B) Select US, then Select Mexico, then pick a state.  Their perception of app performance will be based on how well the server handles those common case operations.  (The app must be capable of performing those operations with acceptably low latency, or your users will be unhappy).

3) Given that you've satisfied your users in the common case #2, then the edge case (C) of  select US, select Mexico, then select US must meet their expectations: it will perform as least as fast as the common case (without additional caching).

[Now, I know that you provided this use case as just one illustration of a broader class of client side caching scenarios.  I too offer the reasoning above as largely applicable to most cases where users think they need client-side caching.  In practice, we've found this reasoning to be sound across a wide range of business applications].

Would it be hard to create such a "low level" new control in AribaWeb?

It wouldn't be all that hard to do, but you'd be writing some JavaScript.  (I'd tell your client that you'd be better off applying all the time you saved using AribaWeb instead to building out more business functionality!  ;-)

Thanks,

- craig

[luxspes]

Hi!
First, thanks for you answers so far!
You are right I provided this use case as just one illustration
of a broader class of client side caching scenarios, and you resoning
works fine... for particular kind of use case, for example for user
registration... sadly, I do not build that kind of application where I
work now, the kind of application I have to build is the kind where
the UI is used repeatedly, the kind where the user is not someone in
his house registering himself and only himself... yes, I build those
dreaded "enterprise level" applications used internally:

Say you have someone answering the phone and filling this information,
this person answers phone for several different countries, and needs
to capture this information during each phone call, so, he typically
select USA, and then Mexico, and then France, and the USA, and then UK
and then.... and he has a really slow network connection... so he
really doesn't like to wait those 3 or 5 seconds after he selects the
country, so he complains to his boss, he complains to the IT
department, and the IT department says: "well, it needs to load those
States, that is why it takes time", but the user complains: "yes, but
with our previous system built with VB6 was only slow the first time I
selected a country, why the new system can not remember the states of
the country I selected 5 minutes ago, even if that country is having a
civil war it can not be changing its political structure every 5
minutes"

So you are left (AFAIK) with no arguments.... (BTW have you noticed
that chained combo boxes are very common, but a control to easy handle
them is never pre-packaged as a widget?)...

I wonder... Is this problem really impossible to solve in a
declarative way? is this really the unsurmountable frontier for server
based frameworks? I could some trick be built that worked? Perhaps by
storing in the client snapshots of previous states of the UI and then
telling some part of the UI to re-sync with them?

Thanks
Regards,

LuxSpes


On Feb 24, 12:18 pm, Craig Federighi <craig.federi...@gmail.com>

[Craig Federighi]

Hi again, LuxSpes,

I understand where you are coming from, and it is certainly possible
to build a client-side caching multi-level chooser control in AW
(particularly it the choosers are essentially navigating a static
hierarchy). That said, we are finding that incidences of the "slow
network connection with 3-5 second latencies"), while common years
ago, are much less so now: particularly for data entry workers doing
repeated data entry from their primary terminal.

Gziped (as AW responses typically are in a production configuration),
a list of 50 states in HTML <option> form, is 553 bytes. That's a
single packet, with a single network round trip. From my home DSL (in
California) my ping time to China is 220 ms. Even with satellite
links latency over 1.5 sec is becoming rare.

Long and short:
- Yes, the client situation you describe can exist, but is (in our
experience) becoming increasingly rare
- AW is an open system: you are free to drop down into JavaScript and
build a custom component for caching multilevel choosers, if you must.

Thanks,

- craig

[luxspes]

Have you though about perhaps integrating with Cappuccino ( http://cappuccino.org/
) to make building this
kind of client optimized widgets easier to build?

And the integrating with Besping ( https://bespin.mozilla.com/ ). OMG
my mind boggles thinking of the possibilities!!!!