The OCLC Research site use cases demand a certain set of functionality from a web site. This document tries to tease out an inventory of that functionality. This first draft is far from comprehensive. To become more complete it requires feedback. Talk back! See the comments section below.
A note about scope of possibilities: our call, as confirmed by Jim and Lorcan, is to implement the new OCLC Research website on the OCLC enterprise Collage CMS. This imposes severe constraints on the universe of possible functionality, in particular on the availability of broad-based editing. This inventory has been drafted without particular reference to how well Collage can implement the functions described. We particularly need feedback about the feasibility of this functionality within Collage. If you have thoughts on that, please share!
In the text below, any letters in parens are references to the individual use cases.
This inventory is divided into a few sections: fitting into the web, internal navigation, cross site content assembly, interactions, formats, and contributions.
1. Fitting into the web
1.1. The site must be easy to visit (A). This means that it must be easy to find on the main OCLC page, among other things.
1.2. The old RLG site should redirect to OR site (D) or at least to an intermediary page that offers a link directly to the OR page.
1.3. Google and other crawlers should be able to index and search the site (A) (F). Both the current OR site (A) and old RLG content (F) should be searchable.
1.4. Much of the site should be available via RSS: events (C), news (B), and newsletters (G) included.
1.5. The site should be navigable on mobile devices (N).
1.6. Pages within the site should be bookmarkable (N), which is another way of saying "persistent."
2. Internal navigation
2.1. The OR site should be centered around a list of activities. These would include:
2.2. Each activity might contain some or all of the following:
-
2.2.4. Downloads (F)
-
2.2.5. Documentation (F)
-
2.2.6. Data (A)
-
2.2.7. Events
-
2.2.9. Partnership and collaborator logos
-
2.2.10. Feedback link
2.3. The site should also provide:
-
2.3.1. A listing of RLG partner institutions (L) and a description of the partnership
-
2.3.2. List of visiting scholars (M)
-
2.3.3. List of grant opportunities (N)
-
2.3.4. Record of Distinguished Seminar Series (C)
-
2.3.5. Information about Kilgour Award (O)
-
2.3.6. List of external collaborations
2.4. Elements of the OR site should be found on the main OCLC site
-
2.4.1. Newsletters (G)
-
2.4.2. Events
3. Cross site content assembly
3.1. The system should be able to assemble certain content found around the site into feeds of various sorts.
-
3.1.1. Recent news (B)
-
3.1.2. Events (C) including minutes and notes
-
3.1.3. Newsletters (G)
-
3.1.4. Reports (H)
3.2. The system should be able to notify users of new items in any feed (C).
3.3. The system should be able to present these feeds as lists on any other page of the site.
-
3.3.1. The system should be able to limit the scope of these lists to:
-
3.3.1.1. a certain number of most recent items
-
3.3.1.2. items created within a certain date range
-
3.3.1.3. items regarding a certain date range (in the case of events)
-
4. Interactions
4.1. Users should be able to sign up for events using the OR web (J)
4.2. Users should be able to apply for grants using the OR web (G)
4.3. Members-only workspace
-
4.3.1. Shared documents
-
4.3.2. Discussion
5. Formats
5.1. Many formats supported beyond CMS/HTML including:
-
5.1.1. PDF
-
5.1.2. PPT
-
5.1.3. audio (MP3)
-
5.1.4. video (Flash) [really? or point externally?]
6. Contributions
6.1. The communications team should be able to directly edit content on the site
-
6.1.1. add reports (H)
-
6.1.2. add bios (I)
-
6.1.3. add pages via Collage (H)
-
6.1.4. select feeds that will report new content (H)
6.2. Program officers and research scientists should be able to review new content
- 6.2.1. A staging area or review site will be available to review pre-published content (I)
6.3. Program officers and research scientists should be able to add "micro-outputs" to the system.
-
6.3.1. These should be recorded in such a way that they can be sliced:
-
6.3.1.1. By activity
-
6.3.1.2. By author
-
6.3.1.3. By date range
-
-
6.3.2. These should provide an opportunity for public comment.
6.4. Website visitors should be able to send feedback to the maintainers of the site.
Comments
This document could use your feedback. Share it! Thanks, ...Eric
Melissa / 08 April 2009 / 23:58
Bob and I reviewed this together and think it generally looks good. We only have a few comments:
2:1: We're fine with the idea of having ResearchWorks be an access point for finding other information but wonder if there should also be some kind of store or library available as an alternate point of finding information (e.g. something like the current complete list of presentations, publications or events).
6.2.1: Thanks for mentioning a review site. It made us realize that it wasn't part of our use cases but it's definitely an important and needed feature.
efc / 09 April 2009 / 00:16
Regarding the need for a "store" or "library" for some items scattered throughout items in 2.1 (ResearchWorks): I imagined that 3.1 (assembling into feeds) would do that. But now that I read it I do see how the presence of "feeds" does not necessarily demand the presence of lists on the site itself. Yes, I think we should require the presence of these on the site as well. I've added 3.3, do you think that might cover it.
Regarding 6.2.1: Actually this only occurred to me because it was included in a use case, see (I) for the inspiration.
efc / 13 April 2009 / 13:05
After last Friday's phone call I changed the wording in 2.1 and 2.2, added 2.2.9 and 2.2.10, added 2.3.5, and added 6.3 and 6.4. I also note that there was considerable skepticism in the call about research scientists and program officers contributing content at all. If 6.3 could be implemented as a blog, that might simplify things enough to get some participation, but expectations on the call were low.