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

[Bob Wicksall]

I agree.  Dojo is not the enemy.  The classic OPAC is one extreme and
the TT OPAC is currently another extreme.  I'm really excited with the 
TT OPAC but I'd like to see a little more JavaScript.

I want balance.  Enough JavaScript to enhance the user experience while 
avoiding the bloat of the classic OPAC.

Bob Wicksall
Systems Administrator

Pioneer Library System
2557 State Rt. 21
Canandaigua, New York  14424


----- Original Message -----
From: "Dan Scott" <dan at coffeecode.net>
To: open-ils-dev at list.georgialibraries.org
Sent: Tuesday, June 14, 2011 10:09:25 AM GMT -05:00 US/Canada Eastern
Subject: [OPEN-ILS-DEV] Rethinking "no Dojo" in TT OPAC

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.

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

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