[OPEN-ILS-DEV] Rethinking "no Dojo" in TT OPAC

[Bob Wicksall]

Comments Below...

> On 6/14/11 6:11 PM, Dan Scott wrote:
> > On Tue, Jun 14, 2011 at 01:44:36PM -0400, Lebbeous Fogle-Weekley
> > wrote:
> 
> <snip>
> 
> >> If Dojo's available, there's a temptation to do all the work with
> >> client-side logic, disenfranchising a small but real number of
> >> users. And if Dojo's available, it's a small step to Dijit.
> >>  Nobody
> >> really benefits from fade-ins and spinny things when they just
> >> want
> >> to find some books or pay a fine, so I think we definitely want to
> >> leave that out.  And then there's the existing JS fieldmapper and
> >
> > Agreed.
> >
> >> other stuff that we might want to reach for, let alone the
> >> Javascript for Google Analytics and ChiliFresh and so on that we
> >> kind of already need to use anyway, and before you know it 31 kb
> >> is
> >> 3100 kb, which has a real impact on usability for *lots* of users.
> >
> > Except, we're talking about it right now. So we could easily agree
> > as a
> > team that Evergreen's TT OPAC will never include Dijit or Dojox.
> > Anybody
> > else can fork Evergreen and include amazing spinny things, but we
> > have
> > the ability to say that we won't support anything beyond Dojo base.
> 
> Like Lebbeous, I'm not anti-Dojo, particularly for integrating added
> content, but I don't like the idea of requiring it for the baseline
> catalog.  It's not a fear of Dojo or 31KB, but a fear of what it
> means
> for future development.

I don't think Dojo should be required at all.  The baseline catalog 
should function 100% without JavaScript.  

> 
> For the sake of discussion, I'd like to propose a significantly more
> strict set of boundaries than Dan's on the use of Dojo, should we
> decide
> to go this route:
> 
> * It can only be used for retrieving and displaying remote content,
> i.e.
> content that comes from another server, whose response time is not
> controlled by Evergreen.

I'd like to see Dojo/JavaScript optional here as well.  It would be 
nice to have a fallback option that would allow everyone access to
the added content whether they had JavaScript or not.

> 
> * Dojo and any code that depends on it is only loaded on pages that
> offer such added content and then only when the added content is
> enabled.

Agreed but see above.  If possible still provide access to the added
content without JavaScript.

> 
> I realize this might seem excessive, but my fear is if we open the
> door
> to Dojo anywhere, even if we're forbidding Dijit, Dojox, etc., the
> OPAC
> will unwittingly evolve into a JS-driven interface, even if we're not
> using it to initially retrieve the data.  The temptation seems too
> strong.  I would sincerely like to avoid that.
> 
> -b
> 
> --
> Bill Erickson

I don't agree with that last set of concerns.  Even if we say no 
Dojo that's not going to stop someone from trying to add it later.
It doesn't matter if we open the door or not, someone will come along
and submit a patch.  It's up to the community to stand firm and
block it.  

My comments above make it sound like I'm against JavaScript.  Quite
the opposite.  I would like to see Dojo used where it makes sense.
No spinney things or fancy transitions.  No pseudo dialog boxes and 
definitely no remote OpenSRF calls.  Just common sense features where 
JavaScript can make the patron's experience more pleasant.  

My experience has been that the TT OPAC feels much faster for users
with slow connections and out of date browsers but feels a bit slower
if you have a fast connection and modern browser. 

I've been playing around with my own OPAC based on a Drupal module.
It uses PHP and cURL to make OpenSRF calls on the server side.  It
then sends a complete page to the browser.  So far I use JavaScript 
for 2 things.  To Check if JavaScript is available and then to
load the copy counts.  If no JavaScript is found it falls back and 
loads the copy counts on the server side.

Bob Wicksall