STAFF RESOURCES

Minutes of July 18, 2001 Meeting

Present:
Rebecca Gardner (Chair), Jeanne Boyle, Sara Harrington, Sam McDonald, Leslie Murtha, Pat Piermatti, Ka-Neng Au, Theo Haynes

Reports

Design Group:

Immediate Things:

Research Guides:

Instruction:

Discussion Topics:

Comments Received:

The following are decisions/changes made from reading and considering each comment.

New Indexes Proposal:

See Appendix A for original proposal

Goal Setting::

Rebecca's first list:

  1. Finish prototype and rollout
  2. Design consultant for look-n-feel
  3. New Indexes page
  4. Passwording sections of the Staff pages
  5. Assessment/User Evaluation (Spring 2002)

Sam recommended thinking about goals in 6 areas:

  1. Content (new and revisions) - e.g. new research Guides, new Ebooks page
  2. Look-n-feel - with help from the design consultant
  3. Usability/Assessment - (Spring 2002)
  4. New Services - e.g. How do I?, R&D
  5. Infrastructure - Sam's stuff: documentation, clean code, policies, procedures
  6. Interactivity / Personalization - e.g. MyLibrary, My TILT
  7. Appendix A:

    Concept for streamlining the 'Indexes & Databases' pages
    __________________________________________________________
    
    Current setup:
    
    Currently we have the indexes arranged with different parts/views.
    
    - The main hierarchy;
      - Main index pages
        - (branch) 1 of 6 subject pages
        - (branch) 1 of 2 alphabetical sub-pages
          [these to sets lead to listings and cross-links, of 
           Research Guides, descriptions, and in some cases How2DEP;
           also, VALE affiliation, and restrictions are listed there and some cross-help
           (like Beilstein, WOS, & Medline)
    
    - indexes/dbs are also accessible via Research Shortcuts and Research Guides
      - Research Shortcuts generally links as directly to the vendor as possible with 
        non-browser db's being the exception (eg. Beilstein)
      - Research Guides, in general, lead to the part of the page on an alpha page
    
    - we also have a trial page and news paths (and telnet) for our process of making these 
    available, but this is not pertinent at this time)
    
    __________________________________________________________
    Problem/Issue:
    - the alphabetical pages, as well as the subject pages, although being clear, concise, 
      and fairly attractive, are quite large and bit cumbersome (length, complexity, 
      bandwidth, and the back button problem).  Originally the idea was that the 2 alpha 
      pages would be split into 4 or 5 to handle the many new databases gained this year 
      and to handle the many new ones coming next fall.  
    
    Although the changes will be a lot of work not matter how it is done, perhaps there 
    is a better choice than just splitting them up.
    __________________________________________________________
    Possible option:
    - first, eliminate the 2 sub-alpha pages comepletely.
      - on the main indexes page, have a 2 column listing(A-G/H-Z) of all the 
        databases (as in the prototype), links to the subject breakdown pages 
        would also be available from this page, similar to the protoype version
      - the links from this two column listing would lead directly to the 
        description page.  The description pages currently have a link 
        directly to the resource.  Additions to these pages to accomadate the 
        data available on the now eliminated alpha sub-pages would include:
     - adding the VALE logo where appropriate
     - adding the restriction type (RU only, Unrestricted)
     - adding How2DEP or cross-link as necessary
     - any extra info, help or tutorials as applicable or info such as 'discontinuation..use x'
     - it may be logical and desireable to x-link to the subject index listing, or 
       to a research guide, to give the kind of support that means 'show me more like this'
    
    Subject pages:
    - the subject pages would still exist, though they needn't look like they do now.  
      They could be just lists of title/links that lead to the description pages.  
      An advantage of this is that the page will be much simpler (less data overload 
      for the user), and we can actually list more than 7 +/-2 and the page will still 
      be much lighter in bandwidth usage.   Each section would still link to the 
      appropo Research Guides.
    
    __________________________________________________________
    Implementation notes:
    - either change, splitting the pages up or eliminating them, will require an 
      equally large amount of work fixing the research guides so that the link properly.  
      With a bit of planning and some judicious search/repalce it will only take time 
      and not be too onerous.
    
    __________________________________________________________
    Discussion - Advantages, disadvantages:
    Why consider this:
    - seems to be simpler in concept, maintenance and is clearer.  We have been wrestling 
      with this for years, as have all large academic libraries, and although we get better 
      with each revision, it never feels just right.
    - it seems that due to our increasingly large number of db's, and the complexity of info 
      and relationships between them, that we will need to consider generating a backend 
      database to generate these pages.  This proposed design atomizes the structure a bit 
      so that it might be easier to evolve to this.
    
    Advantages:
    - more straightforward, less distractions, faster
    - easier to maintain; makes more sense from the Reseach Guides to the descriptions
    - I think that in some ways we will create some more knowledgable users; instead of 
      clicking and fishing around on a title that seems promising, they may, 
      in some cases, read the few lines of description and be able to dismiss a 
      resource, or discover an aspect or special focus of a database that will help them 
      adapt and focus their search strategy.
    - back button problem might go away or at least be less irritating if the pages get 
      shorter and less complicated code-wise
    
    Disadvantages:
    - change is hard on a fairly static population.  However, behavior, paths, 
      sections etc. will be very similar and will mesh fairly well with our other changes though.
    - users who are used to sliding up and down the H-Z list will have a couple extra clicks.
    - there will be 2 non-exist pages (the sub-alpha) on which I would put 
      move-to's, but may cause some users bookmarks to be less than optimal
    

    Respectfully submitted,
    Sam McDonald
    July 19, 2001



 
URL: http://www.libraries.rutgers.edu/rul/staff/groups/web_advisory/minutes/wacmin_01_07_18.shtml
Website Feedback  |  Privacy Policy

© Copyright 1997-2013, Rutgers University Libraries   (Further Copyright Information)