The latest version of Scholar@UC displays user email addresses when searching for users to add as an editor or group member. This will avoid confusion if there happens to be more than one user with the same name. Several minor bug fixes are also included.
In this Scholar Story, Dr. Nan Niu PhD, CEAS professor of Software Engineering talks about how he benefits from UC’s institutional repository Scholar@UC for his research in software engineering and teaching as well as archiving his own scholarly output. Additionally he discusses how the library can partner with research and teaching faculty to develop research projects and bring real-world agile development experience to the classroom. Library Staff mentioned in this story are Eira Tansey -Digital Archivist, Sean Crowe, Glen Horton,Thomas Scherz and James Van Mil–Scholar Development Team, Linda Newman Head of Digital Collections and Repositories, and Amy Koshoffer- Science Informationist. For more about the projects mentioned and the “i*” modeling approach, read the Liblog Entry – Scholar@UC Goes to Class (01/04/2016).
Nan Niu on Scholar and Requirement Engineering project
With Scholar@UC 1.7 we have deployed various display improvements for mobile users. We have also adjusted the handling of Document Object Identifiers (DOIs) for embargoed and private works, so that DOIs are held in reserve until a work is made public, at which time the DOI becomes public. (You can read more about DOIs and access rights on the Scholar@UC FAQ.) The name of a submitter of a work is now shown with the work metadata, with a link to the submitter’s Scholar@UC profile page.
Other changes include: Read more ›
With the Scholar@UC 1.6, we have enhanced the user’s image experience with the OpenSeaDragon viewer. This viewer allows zooming, panning, and full screen display of images, including JP2. Take a look at an image from John Wallrodt’s The Durrës Regional Archaeological Project (DRAP): https://scholar.uc.edu/works/images/j96021256
Scholar@UC also supports video deposits with a new work type and metadata targeted towards this type of material. This is the first step towards a larger video experience.
The other changes with version 1.6 are:
UC Libraries invites faculty and researchers to submit their research, creative and scholarly works to Scholar@UC, the university’s cutting-edge digital repository.
A digital repository makes accessible, enables re-use, stores, organizes and preserves the full range of an institution’s intellectual output, including all formats of scholarly, historical and research materials. Faculty and researchers can use Scholar@UC to collect their work in one location and create an Internet-enabled, durable and citable record of their papers, presentations, publications, data sets or other scholarly creations. With sponsorship from a faculty member, undergraduate and graduate students may also contribute their academic output, such as capstone projects, senior design projects, research data and other creative and scholarly works. Read more ›
Scholar@UC now sorts users’ lists of collections by title. Other accessibility and security fixes are also included.
Scholar@UC 1.4 now shows a welcome page that is customized for students when they log in to https://scholar.uc.edu using their UC central login. Additional help dialogs have also been added to the file edit/rollback/delete/download actions.
Scholar@UC’s development is largely informed by the feedback we get from our Early Adopters. Early Adopters are the UC faculty members who are making the earliest use of Scholar@UC and providing valuable insights to our Early Adopter Working Group on issues related to submission, description, and sharing within the repository.
So what happens to this feedback once the Early Adopter Working Group receives it? It is passed on to the Use Cases Working Group, and the feedback is transformed into a list of recommendations for the development team behind Scholar@UC (these are alternately referred to as use cases or user stories — the two are often used interchangeably even though there have been attempts to articulate the differences between the two). The Use Cases Working Group issues use cases similar to the following (all can be viewed here):
As a: repository submitter
I want: the input form to visually flag which specific fields need to be filled out if I submit an incomplete record
So that: I don’t have to click on each field to see if it is required
Done looks like: indication next to required fields such as “error” or “required” in red if incomplete record is submitted
The Development Team then takes these various Early Adopter cases into consideration to prioritize what features to work on next. In the last several months, the following issues have been addressed, based on the feedback from our Early Adopters:
The Development Team continues to work on the following issues, brought forward due to Early Adopter feedback:
If you are currently using Scholar@UC and have ideas for functionality you would like to see in the future, please contact Eira Tansey, chair of the Use Cases Working Group.