Calls are held every Thursday at 1 pm eastern time – convert to your time at http://www.thetimezoneconverter.com
Introducing Layne Johnson, VIVO Project Director
Contact information: firstname.lastname@example.org (preferred) or 201 421 1185
Ontology Working Group: next call is Thursday, May 15 at noon EDT
Agenda to be determined -- look for an announcement
Apps & Tools Working Group: next call is May 13th at 1pm EDT
Apps and Tools workshop at the conference. Looking for participants to do demos -- looking for the best ways to create, use, visualize VIVO data and would love to have additional authors and help
Information, Interaction, and Influence (May 19-20 at University of Chicago)
Digital Science Workshop on Research Information Technologies and their Role in Advancing Science (free registration for academics)
VIVO community members Kristi Holmes and Simon Porter are scheduled to speak. Project director Layne Johnson will be attending as will Paul Albert, Alex Viggio, and Bill Barnett
ORCID Outreach Meeting and Codefest (May 21-22 at University of Illinois at Chicago)
Community sharing of integration best practices by universities and professional societies, particularly highlighting the Alfred P. Sloan Foundation-funded Adoption and Integration Program projects -- Simeon from Cornell will be there
Participation is free but you must register before May 14 – webinar options to be made available if you cannot attend in person
Violeta Ilik from Texas A&M (workshop organizer) and Ted Lawless from Brown will be attending
VIVO Technical Roadmap presentation from March DuraSpace Sponsor Summit meeting now posted to this wiki
To contact Layne, email@example.com
First annual survey of VIVO sites
Next themed weekly call topic – May 22nd: Performance Part 2 or VIVO 1.7?
Look on JIRA for VIVO 1.7 issues -- items marked as Blockers will receive priority
Site updates during next week's callt
Theme: End User Documentation
Attendees: Brown, Cornell, Duke, DuraSpace, EPA, International Food Policy Research Institute, Memorial, Scripps, Smithsonian, Stony Brook, Symplectic, Virginia Tech, Weill-Cornell
Technical and Developer documentation versus End User documentation
Challenge that there’s always a shortage of resources -- new features, bug fixes, outreach, documentation
Developers don’t prefer to work on documentation
Developers don’t have expertise in documentation
Alex: have we had technical writers on the project ever? Jim: UF did devote some librarians to do documentation. Our site admin guide comes from those people, which is a mix of 1.3 and 1.4 versions of VIVO.
Ted: Started working on VIVO around time of GitHub and DuraSpace wiki -- too easy to find documents that are out of date. This can be confusing and frustrating.
Why does the VIVO SourceForge site still exist?
Alex: This has been brought up before, but maybe we need to track this in some JIRA tickets to make sure it is resolved.
Tammy: I agree. Having a dedicated tech writer to keep documentation up to date, and even helped with testing.
Jim: I would hope that we can include site contributions that are documentation improvements rather than only contributions to core.
Eric: which users do you want documentation for? Our approach… the challenge is keeping it up to date. Quickly becomes obsolete. What we have done is to support via a help desk, where requests come in as emails, are evaluated, and broadcast as FAQs on web site. Sometimes the simplest things (deleting a record) are the hardest to find.
Chris: who do we envision as the end users? Alex: academics, researchers, grad student and staff proxies. Chris: we have one group of secretaries who are responsible for maintaining the CVs and VIVO profiles for ~78 faculty. Jim: maybe we should be focusing more on forum software, rather than formal documentation? Eric: traditional approaches to formal documentation don’t always apply to systems like VIVO that are rapidly evolving (being replaced). Alex: Since VIVO is so easy to customize, that is also a challenge. Paul: Having institution specific end user documentation is the norm. Patrick: looking at docs produced by Julia’s team aimed at power users -- will link here -- tends to talk about the non-VIVO components that feed VIVO profiles. Might be useful here.
Chris: there is space for some documentation, e.g. Jim’s installation guide is invaluable, and it evolves over years
Examples of sites’ end user documentation (share yours!!):
Weill Cornell: http://vivo.med.cornell.edu/support
decided against videos because they cost too much to produce
tried to limit the number of questions
Here’s a lightweight way for how we display actions that require multiple steps: http://vivo.med.cornell.edu/support#h.wvaf8wuh3kc9
UCSF: 3 classes of users: most read-only site visitors (casual users) = focus on web site usability (“the 5 second test” using A/B testing, casual users not understanding the default technical language on the web pages); administrators = measured in their documentation investment -- “just in time documentation?”; the researchers . The UCSF team finds that engagement and documentation overlap as it is hard to get users to read it, and hard to keep it up to date. They are very conscious of how much they email their user community (staying in contact and keeping them engaged vs spammers): . Making sure our community understands is not lightweight while our approach to documentation is lightweight. Leslie might talk about this more at UChicago workshop.
Types of end user documentation: wiki-based versus web application help files -- also new ideas that came up around new forms of documentation.
Jim Blake's overview of current VIVO end user documentation on the wiki, with a few highlights such as managing documentation versioning for recent 1.5, 1.6, and the upcoming 1.7 release of VIVO
Too many top level pages
Too much content on the home page
Maintaining VIVO documentation link <here>
If we don’t prepare the documentation when we are doing the VIVO development work, we aren’t likely to do it at all
Using Confluence Spaces to version documentation?
Jim’s process diagram
Jim’s style guide
Confluence has a “PDF” link that will convert pages to a PDF on the fly
Latest VIVO Installation instructions on wiki far more current (and better) than old PDF instructions (that Ted referred to earlier) https://wiki.duraspace.org/pages/viewpage.action?pageId=41355376
Paul: Confluence has a “label” attribute, and he’s seen some projects use these labels to link pages to specific project versions/releases
Paul: Empowering people to have power to delete pages -- to clean up out-of-date pages. Jim: out of date doesn’t always mean obsolete.
Jim: Copying older wiki pages to archive Spaces. The Fedora project does something like this.
As always, we'll encourage attendee participation. Please bring up your end user documentation concerns and suggestions. We hope to hear from institutions that have rolled out VIVO. What questions came up from their end user communities that aren't addressed by the existing documentation. How could institutions best collaborate on documentation?
Is there interest in an online VIVO end user wiki documentation edit-a-thon, inspired by Wikipedia's app – http://en.wikipedia.org/wiki/Wikipedia:How_to_run_an_edit-a-thon
GitHub being used by non-coders for local political campaigns and other collaborative writing projects
Are there examples from other projects that do documentation better?
Alexandre Rademaker: it is an interesting idea that should be considered: http://www.gitbook.io. That is, we should treat documentation as code. It should be in a version control and could be made offline. Example of project that was developed in this collaborative way http://homotopytypetheory.org/book/
Dr. Ina Blümel, Technische Informationsbibliothek Hannover (TIB www.tib-hannover.de): “unfortunately no one of our team can join in the call today. Therefore some thoughts via email concerning the topics online edit-a-thon + platform.”
The topic of collaborative creating and (especially when it comes to far-reaching version changes) curation of a user documentation seems to be absolutely essential for a community driven project like VIVO. Like all VIVO newbies know, it takes some time to get familiar with the tool itself, the ontology, etc. (Thats the reason we are doing the VIVO bootcamp at ELAG conference, see http://elag2014.org/programme/elag-2014-bootcamps/bootcamps-l-koster/)
2 months ago, we have performed a Book Sprint, using a platform developed by my colleague Gabriel Birke (based on Wikimedia), see http://blogs.tib.eu/wp/opensciencelab/book-sprint-coscience-cebit-2014/?lang=en or a (german speaking) video at http://www.youtube.com/watch?feature=player_embedded&v=Hp4v-fz185Y.
We have good experience in the fast, collaborative writing of a manual and would be willing to participate in and looking forward to an edit-a-thon. E.g. it is having its kickstart at VIVO conference and continuing virtually later. Whether our tool would be used or another, we do not care. It certainly makes sense to maintain and continue with the existing wiki + Github.
Paul and Alex discussed the idea of running themes. Paul: “Where we can really contribute is to ask 3-4 focused questions that inspire spirited discussion, and these should probably go out on Monday to give people time to gather their thoughts.”
Paul: Next time we discuss documentation, I would throw this out there:
What are some other projects’ documentation we like?
Information architecture of the wiki: what it is and what it should be
What should be on the home page of the wiki?
Notable list traffic
- Date: Every Thursday, no end date
- Time: 1:00 pm, Eastern Daylight Time (New York, GMT-04:00)
- Meeting Number: 641 825 891
To join the online meeting
- Go to https://cornell.webex.com/cornell/e.php?AT=WMI&EventID=167096322&RT=MiM2
- If requested, enter your name and email address.
- Click "Join".
1. Call in to the meeting:
1-855-244-8681 (Call-in toll-free number (US/Canada))
1-650-479-3207 (Call-in toll number (US/Canada))
2. Enter the access code:
641 825 891 #
3. Enter your Attendee ID: