STAFF RESOURCES |
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:
Sam recommended thinking about goals in 6 areas:
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