|
SFX-Verde Group Home >
Minutes
9/28/2005
SFX-Verde
Notes, 9/28/2005
DLG/TSAC review:
Ellen gave an overview of the DLG/TSAC meeting and the major questions
asked.
Project plan:
Creating structure for an ambitious timeline.
Nicole and Ellen will update the project plan based on the group's discussion
and send out to the team.
To make sure we understand and take care of issues raised at the meeting
we each agreed to talk to various people. Here's a list thus far: Beth
with Rebecca, Tracy with Anna, Rich with Nina, Nicole with MacKenzie,
Millicent with Steve, etc.
Other things to explore (not on the DLG/TSAC list):
1. What are other libraries doing?
2. Explore "FAST"
3. Full assessment of Metalib functionality. What does Metalib do that
we want? Is there a staff-efficient way to get those features without
Metalib?
4. Need for cross-database searching needs to part of the user needs assessment.
5. User needs assessment: explore MIT research and other usability and
research into user information seeking behaviors
6. Need to integrate knowledge from research with users with knowledge
of MIT academic portal at MIT regarding need for individual interface,
need for custom interfaces.
Need to define terms as we go. For instance: Barton versus web opac, etc.
Action: Add an Oct 31st meeting to help with the load proposed for the
November 9th meeting.
Discussion on advantages/Disadvantage of maintaining separate interfaces
in addition to a new integrated interface.
What is the most effective way to maintain interfaces?
Can we build a UI that totally replacers individual tools?
Maintain out of box interfaces only. This would require work. Do we really
need this option?
Still need circulation info from ILS since functionality unique.
Not feasible in terms of staff to maintain dual interfaces to same thing/data
Can X server do all that OPAC currently does?
Is there a user need to have access to individual tools? (There may be
a staff need, but that can be fixed by staff access)
The era of the catalog as the sole gateway is over - we need tools that
search across more domains and includes the universe of what's available,
not just what is owned.
If create custom UI, catalog can to continue to be an inventory system;
with a custom UI, you don't need to put everything in catalog you want
to display since displays are integrated with other access tools. This
could mean that we wouldn't need to load aggregators into OPAC if we had
custom UI
If our tool works well people will use it in addition to google.
Discussion on one central starting point versus exposing our info in other
interfaces at MIT.
Can't we/shouldn't we do both? What do we want to be able to do well?
What are the trade-offs?
Easier to expose w/Xserver
Easier to expose with RSS feeds
Can easily publish/extract in any format you want w/ XML if you have already
done extract for purposes of integrated UI
Integrate results in one tool from many. XML files of our records extracted
and exposed to other engines. Those records, when found, could pull you
into our display/tool pages. Easily click to add the record/information
to whatever the user is interested in (Sakai, Refworks, OCW, etc.). Enables
remixing.
It will be possible to do both because if you do the job right it will
be easy to serve out in multiple places. e.g. rss feeds.
We have to be able to know how to expose our data in order to build our
interface so it is not a significant add-on to do both a custom UI and
expose data in our other UI's, e.g. academic portal, OCW, Sakai.
Even if we expose our data, the other interfaces will not take full advantage
of that data to serve the large and varied needs of our specific users.
We have the expertise needed to expose our data to its full value.
Not professional or effective to leave it entirely to others to design
interfaces to our content.
Discussion on Staging and Scoping
At first, expose catalog through cross-database searching
Start with only what vera does now, ejournals and dbs but not just by
implementing metalib since we need faceted browse
Start with Database Discovery Tool - do a functional approach, add functions
over time.
Don't want to give the impression that we are doing option 2.
Change current web site to reflect interface feel even with links to separate
tools. De-emphasize tool names
Should be incremental so that users (oh that works this way now? Cool!
versus Oh, I can't do that anymore. Shoot)
Avoid cut-over notion.
|