RE: RE: vendors and usability

Comparing lines of code is a poor metric.  Customizing our OPAC was like stepping back through a bad time
machine to 1997 (wretched, malformed HTML 3.2 with a stylesheet only a programmer who "knew some HTML"
could love).  Configuring our OPAC was like stepping back to 1990 (terminal interface, green screen).  Our
vendor can't even get a shopping cart to work right.  Didn't everyone figure out how to do those back in 1995?

What you're counting there is bloat, legacy code, hacks and pure ugliness (in the commercial ILSs, that is,
MS Word's code is another flame war for another list).

An earlier poster commented that a programmer in the corporate world would be fired for producing the
buggy, ill-designed code that comprises our ILSs.  That is spot on.  We are the ones to blame, because we keep
buying/licensing them despite this.

Consolidation or no, zero-sum game or no, we are all wasting our time and money if we do not demand a minimum
level of user interface design, interaction design and usability both for our interfaces and those we
force our patrons/students/customers/whatever through before they can use our services.

I do not envy the ILS vendors.  They have to accomodate libraries large and small that present some arcane
requirements.  I don't think anyone is saying creating and maintaining an ILS is easy.  There's no excuse,
however, for them to ignore usability issues and it is our responsibility to demand it of them.

Oh, and don't get me started on those 2500 pages of ILS docs. ;^)

Yours,
-Steve

Stephen Bollinger
Internet Specialist
CAPITAL AREA DISTRICT LIBRARY
401 South Capitol Avenue
Lansing, MI  48901-7919
http://www.cadl.org/

-----Original Message-----
From: web4lib-bounces@...
[mailto:web4lib-bounces@...]On Behalf Of C.S. Durfee
Sent: Monday, July 18, 2005 8:39 PM
To: web4lib@...
Subject: Re: [Web4lib] RE: vendors and usability

As far as I know, vendors haven't ever made that claim.  I made that
claim.  If you disagree with it, I'd like to hear your reasoning or
evidence to the contrary rather than some blanket statement like "that
sounds like it came directly from a TLC proposal...it's simply not
true".

I made it because I know about how many lines of code there are in the
entire OpenOffice suite (about 10 million lines total among the 5
separate programs that make up the suite) and about how many lines of
code there were in one major ILS vendor's product as of a couple of
years ago (around 3 million if you include the OPAC software). 
OpenOffice Writer has pretty much the same feature set as MS Word.  So
with only a little handwaving I feel confident saying that there are
about as many lines of code in a for-pay ILS as MS Word, and since the
ILS holds your hand a lot less than Word does, I think that adds up to
it being much more complex overall.

Furthermore, the documentation on all the configurable features in
that major ILS is about 2500 pages long, it's written at a very high
level for people with a deep knowledge of how libraries operate and is
not particularly prolix.  "Microsoft Word 2003 Inside Out" is 976
pages long, a lot of which is on using Visual Basic for Applications
macros, and is written for total beginners.  The ILS' manuals don't
cover programming stored procedures or scripting at all, which would
be the  equivalent to VBA macros.  I think the number of pages of
documentation required to operate a piece of software is probably an
even better measure of how complex it is than the number of lines. 
The number of function points would be the best metric, but I don't
know if anyone's performed such an analysis on any ILS software.
_______________________________________________
Web4lib mailing list
Web4lib@...
http://lists.webjunction.org/web4lib/