[OPEN-ILS-DEV] The future of the craftsman skin

[Mike Rylander]

On Thu, Aug 5, 2010 at 12:14 PM, Dan Scott <dan at coffeecode.net> wrote:
> There have been a number of recent commits to Evergreen (trunk - no
> changes are proposed here for 1.6) that have de-emphasized the role of
> the craftsman skin:
>

Alas, the curse of many round holes and not enough properly shaped tuits.

>  * http://svn.open-ils.org/trac/ILS/changeset/17076 - "segregate the
> old version of facet-modified JS to be craftsman-specific" which mostly
> duplicates several thousand lines of JavaScript code in order to
> preserve some level of functionality for craftsman - albeit far behind
> the "default" skin
>
>  * http://svn.open-ils.org/trac/ILS/changeset/17096 - the most recent
> commit changes the default skin back to "default" from "craftsman" so
> that the most functional skin is what potential new adopters will see
> when they finish installing Evergreen
>
> This is in the context of the craftsman skin being broken in trunk for
> some time now, along with a number of long-standing display problems
> that have never quite been fixed.
>
> At this point, it seems that the bold craftsman experiment, for whatever
> reason, isn't working out. Patches to fix craftsman problems have been
> few and far between, and the focus of Evergreen developers seems to be
> almost entirely on the "default" skin. (One possible cause is that we
> don't maintain a canonical list of the document structure and IDs that
> rdetail.js and friends depend on, so when a new requirement gets added
> to the "default" skin, it's only via debugging or closely watching
> commits that one can work out what needs to be fixed in another skin
> such as craftsman - and that's an issue not just for craftsman, but for
> any other skin in the wild).
>

IMO, the crux of the problem is that the rendering requirements of
craftsman, being significantly higher than default, make it cost
prohibitive for rapid development.  Your point about structure is a
good one, but I think is a symptom as much as a cause.

When the craftsman skin was first commissioned, it was envisioned as a
thin layer of shiny veneer over the otherwise knotty and rough-hewn
default skin.  It was farmed out to a web design firm that had no
Evergreen experience, and at the time we thought that would be a
benefit -- forcing us (EG developers and the outside firm) to separate
form from function.  Now, I think that could have succeeded except for
one big problem -- the implementation timeline crossed the 1.2/1.4
release boundary, starting before there was a 1.4 OPAC, and ending
after the 1.2 OPAC was all but EOL'd.

Bill Erickson, through valiant effort, was able to mostly punch
craftsman into a 1.4 shaped thing for release -- the expense of going
back out to have it done right was prohibitive.

It has been downhill from there.

Anyway, everything you say is true and valid, I just thought I'd add
some texture and background.

> As a result, I would like to call for volunteers willing to maintain
> craftsman. In my opinion the ideal approach would be to work towards
> getting back to a state where separate, divergent copies of rdetail.js &
> friends are not required. As part of the process, these volunteers could
> hopefully create that canonical list of document structure / IDs (in the
> hopes that other skins would have a chance of being viable), and / or
> eventually refactor the getting-long-in-the-tooth custom Ajax code to
> let Dojo do the heavy lifting.
>

There may be another way, and it may actually make things simpler for
a prospective skin maintainer or steward, be they for craftsman or
otherwise.  If we completely diverge the code, which for the default
skin is about as stable and mature as it will get in terms of being a
static base for development, then one only need learn the code
contained in opac/skin/craftsman/ and developers working on default
needn't worry about further breaking other skins.  As I see it:

 Cons
---------
* Initial code duplication
* Multiple targets for bug fixes (though, with skin maintainers (or
stewards), that /can/ be mitigated)
* More pressure for server API stability, possibility for cruft-growth
(missed opportunities for refactoring)

 Pros
--------
* Lower barrier to entry per skin (only have to learn one)
* Potential for more experimentation and new features
* Plenty of opportunity for cross-fertilization without feature
support being a requirement
* In short ... (the chance for) less talk, more do

> If we do not find volunteers willing to maintain craftsman, or the
> volunteers aren't able to contribute the patches necessary to bring it
> into respectable shape, then I will subsequently propose moving
> craftsman into the ILS-Contrib Subversion repository
> (http://svn.open-ils.org/trac/ILS-Contrib) where it will at least have a
> chance of living on and being resurrected at some point.
>
>

I agree.

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com