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

[Dan Scott]

On Tue, Jun 14, 2011 at 01:44:36PM -0400, Lebbeous Fogle-Weekley wrote:
> On 06/14/2011 10:09 AM, Dan Scott wrote:
> >In going through the TT OPAC and seeing where JavaScript has been used,
> >there's a statement in web/js/ui/default/opac/simple.js "/* Keep this
> >dead simple. No dojo. */"
> >
> >Although I understand the desire to avoid the JavaScript monstrosity
> >that our classic OPAC has turned into, I would like to reconsider the
> >"No Dojo" policy in the TT OPAC.
> >
> >At 31 KB, Dojo base offers CSS3-based queries, DOM manipulation,
> >an event framework, and more with routines optimized for each browser;
> >and Dojo offers documentation and tests. (Yes, jQuery fans, jQuery is
> >also 31 KB and offers pretty much identical functionality - the reason
> >I'm not proposing it here is because we have an extensive existing
> >amount of Dojo-based functionality and experience to build on).
> >
> >simple.js is currently 1.5 KB and doing raw DOM operations; staff.js is
> >smaller at close to 1 KB but contains the seeds of a custom event
> >framework. (Yes, I realize these are uncompressed sizes vs the Dojo base
> >compressed size, but it's what we're currently serving up.) One could
> >argue that simple.js and staff.js are self-documenting, because they're
> >still relatively small -- but they're also still relatively young and
> >seem likely to grow. There is also custom JavaScript sprinkled through
> >the TT OPAC touching window.onload() and the like.
> >
> >With the TT OPAC, we could adopt a current version of Dojo (1.6, with
> >1.7 on its way) and move past some of the bugs we've had to work around
> >with the 1.3 release to which we're currently tied in the rest of
> >Evergreen.
> >
> 
> We /could/ do that. Dojo offers the CSS3 queries, the DOM
> manipulation, the event framework, and so on, but why do we need
> those things?  Those things serve programmers, who in theory would
> leverage them in turn to serve end users, but I don't see any
> improvements to the end user experience that would come from using
> Dojo.
> 
> What DOM manipulation we're doing so far is super minimal, and
> really I hope to reduce it even further.  In that regard, we're not
> rolling our own framework, but rather we're not using a framework at
> all.  There's not that much work to do.  It'd be like powering a
> blender with a car engine.
> 
> Regarding window.onload and the beginnings of an event framework in
> staff.js, I'd rather try to find another way to do whatever that
> does or is going to do, rather than to replace it with Dojo.
> 
> >Again, the idea is not to build lots and lots of functionality into the
> >TT OPAC using JavaScript. The goal of making everything work fast and
> >light without JavaScript must continue to be the front and centre goal
> >for the TT OPAC.
> 
> Of course I agree with the above wholeheartedly.
> 
> >Rather than rolling our own JavaScript framework, I
> >would like to consider using a standard, optimized, cross-browser
> >JavaScript framework for those times when we do want a JavaScript
> >flourish (cursor focus set to the search text box, for example).
> >
> 
> I think it's an exaggeration to describe what we're doing so far as
> rolling our own framework.  Setting the cursor focus to the search
> text box is kid's stuff.  A plain browser-neutral invocation that
> does that is not significantly more complex than any given
> framework's idiom to do the same.  Plus there are so few instances
> where we even want to do it that including Dojo for things like that
> seems like overkill.

Sure, it's kid's stuff, until a browser works subtly differently and
it's not. I want to spend less time debugging browser behaviour
differences for the tiny bit of JavaScript that we do use in the TT
OPAC.
 
> >(Aside: have we written down a set of design goals for the TT OPAC
> >anywhere that contributors should try to adhere to?  Is "all core
> >functionality must be available with JavaScript disabled" an explicit
> >goal, for example?
> 
> I don't think we have these things written down, and we should, but
> yes that should definitely be our explicit goal.  Surely nobody
> would argue with that.  Too many users are left behind otherwise.
> We're talking about a library catalog that should Just Work, not a
> whiz-bang Google AJAX thing.

I think we're generally on the same page; I'm just trying to prep for
spending a couple of days working on the TT OPAC in a couple of weeks,
and explicit design parameters would really help: not just me as an
implementer, but also the people focusing more on the design aspects of
the TT OPAC - and future developers.

> > One current issue is that the search textbox
> >default text "Search keyword" gets in the way when JavaScript is
> >disabled, for example, suggesting that the default text should also be
> >added via JavaScript to avoid hampering usability in a non-JavaScript
> >environment.)
> 
> You're absolutely right: we should fix that, or move the "Search
> Keyword" onclick stuff out of the generic templates into
> KCLS-specific files.  It's just an artifact of the TT OPAC's origin
> in the dynamic KCLS skin.  It's such an unimportant feature that I
> don't think we should worry about bringing in a framework to do it
> Right.
> 
> Look, I know I come across as pretty negative on Dojo.  But consider
> how Evergreen, like any open source project, gets developed.  People
> are popping in to add new features or scratch their itches all the
> time, and they start with what they see.

I don't think you're being negative about Dojo here; I think you feel as
strongly about avoiding JavaScript bloat in the TT OPAC as I do. That
said, if someone is going to scratch an itch and offer a feature as a
patch, would you rather they base it on Dojo core or custom JavaScript?
I know that I would be much more comfortable with seeing something using
dojo.byId / dojo.query / dojo.forEach than custom DOM iterators and the
like.

> 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.
 
> I think we've already got most of the Javascript we need, so I don't
> see us even approaching that 31KB number (not counting Google
> Analytics and added content things like ChiliFresh).

It's actually the added content things that I've been thinking about.
One of the most beloved parts of the current OPAC in our parts is the
embedded Google Books viewer, and the OpenLibrary online reader is bound
to be popular as well. With the deprecation of the existing Google Books
API, we're going to need to rewrite that functionality. As mentioned in
a separate thread, I doubt that we want to block TT OPAC page responses
waiting for Google / OpenLibrary / whatever to respond, which pretty
much pushes that functionality in an AJAX direction.

And that quickly leads to different XHR implementations on different
browsers, and that's where I would much rather just lean on a solid
framework than deal with cross-browser headaches.
 
> The elegance and power of Dojo (conditional on good browser, good
> hardware, and good luck) comes at too high a cost for what we need
> it to do (which is very, very little).  We need "select-all"

Okay, here I think you're selling Dojo short. Good hardware? Good
luck? Dojo core as of 1.6 supports Firefox 3.6, Safari 4/5, Chrome 8, IE
6/7/8, and Opera 10.50
(http://dojotoolkit.org/reference-guide/releasenotes/1.6.html). While
we've certainly run into problems on the current AJAXPAC, we've been
using a wildly long in the tooth version of Dojo, mixed with plenty of
legacy JavaScript, and far-from-core dojox / custom dijits.

> checkboxes, maybe the ability to hide or reveal a widget very
> occasionally, maybe focus the cursor on an input, and a way to
> exchange the occasional datum with the staff client.  That's about
> it.  I'll even excise the print-from-an-iframe thing myself.  It's
> really not all that necessary.

Well, let's figure out what we're doing with added content first.