Wiki for the Ref Desk

I've been fiddling around with trying to solve a problem that the reference
librarians have with sharing information about sources and class assignments,
etc. We played around with the idea of a blog, but that isn't really what we
need. I think a Wiki would be a good tool to use. There are some Windows-based wiki software programs. I've taken a look at some and am favoring one called Flexwiki

http://www.flexwiki.com/default.aspx

Live Chat link on the navigation bar

Red fielded a complaint about the color contrast of the Live Chat link on the home page navigation bar. He asked if I could change it.

>Red Wassenich  said:
>
> > A faculty member said we should not have the link to chat on the home
> > page not be in red letters. He said it was hard to see due to lack of
> > contrast. I agree.

I informed the Web Cmte and asked for suggestions:

>Shall I make it cyan?  Julie likes the current color but really just wants it
>to stand out.  I use cyan on the second catalog pages if you want to look at
>what it might look like.  Then I'll run it by the Web Cmte before making the
>change.
>
>As an aside, I wanted to make it different, but didn't want to make it so
>different from the ACC homepage so I chose a color that stood out just a
>little from the other nav links.  This is the first adverse comment we have
>got on it.

...... Committee replies .......
> I would make it the yellow color that appears when you mouse over it. The mouseover color could be white. The
> professor is right about the contrast. --Teresa

> Maybe bright yellow words? If not that, maybe we could change the background behind that part of the bar?
> Don't know if we want to go there. We could also detach it from that bar in some way, although I'm not sure
> where it would go. --Steve

> I think the yellow color that appears on mouse overs would be more readable. --Jon

There are some issues that govern why we might not follow these suggestions. My reply to these suggestions:

> The mouseover color is one determined by the ACC stylesheet. That is -- the style sheet determines what
> the color is for the mouseover on all the items on the nav bar. If we made the item that color, it would look
> like the mouse is over it all the time. I agree that it is a nice color, but we will have to use something else.
> --mp

I experimented with several colors, trying to balance the look but make the link distinctive while keeping the look of an ACC second tier page. And sent an example to the Cmte.
http://library.austincc.edu/libhome-chatover.htm


With some amusement, I read the following two replies:

> I find this more difficult to see than the current red lettering. - Red

> It's a lot more visible and doesn't clash with the graphic above it. --Teresa

NISO Best Practices - Web...Library Context

Thanks to Red for finding this:

NISO Issues “Best Practices for Designing Web Services in the Library Context”

The National Information Standards Organization (NISO) Web Services and Practices working group has completed NISO RP 2006-01, Best Practices for Designing Web Services in the Library Context. This new Recommend Practice publication covers the following areas: HTTP caching, filtering of user input, reuse of output formats, security, and throttling. The document also describes typical output formats used in web services DTD, XML schema, RDF, Relax NG, and DSD…

The url for the document itself:
http://www.niso.org/standards/resources/rp-2006-01.pdf

Rethinking the networked user

snippets from
Lorcan Dempsey
[Main Articles: 'The Library Catalogue in the New Discovery Environment: Some Thoughts', Ariadne Issue 48]

One of the interesting aspects of the last couple of years is the emergence of several large consolidated information resources - Amazon, iTunes, Google, etc - which have strongly influenced behaviour and expectation. Unlike these resources, the library resource is very fragmented: it is presented as a range of databases, places, and services. In other words, libraries do not aggregate supply very well. There are at least two factors here. Firstly, there is no unified discovery experience, and, secondly, the transaction costs of using the system are often high (transaction costs refer to the cost in time or effort to perform the steps required to meet a goal). There are a range of potential transaction costs, where you have to move between systems, re-key data, or pass authentication challenges: you may have to search several resources, check for locations, make ILL requests, and so on. Compare this to popular Web resources like those mentioned a moment ago. These provide a unified discovery experience and work hard to reduce transaction costs: they aggregate supply. Think of demand. And, again, think of the large Web presences: they aggregate demand by mobilising large network audiences for resources. The fragmentation of library resources reduces the gravitational pull of any one resource on the network. Nor do these resources tend to be projected into user environments such as the course management system or RSS aggregator. There is limited aggregation of demand. Better matching supply and demand closely relates to what has become known, following Chris Anderson, as the long tail argument. (I explore this in more detail elsewhere [4]). The long tail argument is about how a wider range of resources may be found, used or bought in network environments which better match supply and demand through aggregation at the network level.

--- snip ---

In some ways we have end-to-end integrated library systems where the ends are in the wrong places. At one end, we have a catalogue interface which is unconnected to popular user discovery environments or workflows. It is often a somewhat flat experience with low gravitational pull in the crowded network information space. We expect people to discover the catalogue before they can discover what is in (part of) the collection. And this points to the issue at the other end: the 'fulfilment' options open out onto only a part of the universe of materials which is available to the user: that local catalogued collection.

--- snip ---

In a pre-network world, where information resources were relatively scarce and attention relatively abundant, users built their workflow around the library. In a networked world, where information resources are relatively abundant, and attention is relatively scarce, we cannot expect this to happen. Indeed, the library needs to think about ways of building its resources around the user workflow. We cannot expect the user to come to the library any more; in fact, we cannot expect the user even to come to the library Web site any more.

-----

Web Opac

Work is begun on examining the effects of Rel 2006 on the webpac. Nothing will change much until we go to Webpac Pro. Then we will need to work with the following:

• wwwoptions -- need to check on
• BRIEF=UR (can't find UR in documentation)
• When we go to briefcit.html and iterations, will BROWSE options become redundant?
  
• Besure to change WEBADDRESS to reflect WorldCat nearby
• "briefcit.html" and its iterations will need to be tweaked
• Ask iii to make us a "webpub.def" to emulate what we currently have and then we can tweak.

More as I think of them....