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

[Lebbeous Fogle-Weekley]

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.

> (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.

 > 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.

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 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.

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).

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" 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.


-- 
Lebbeous

Equinox is going to New Orleans! Please visit us at booth 550
at ALA Annual to learn more about Koha and Evergreen.