ScholarSphere User Dashboard


ScholarSphere is an online resource for faculty, students, and staff to upload and share their scholarly works and research. It is an open-source Ruby on Rails application built on a core gem called Sufia–also built at Penn State.

It is a self-service institutional repository. The earliest challenges involved generating awareness of the application as a resource and understanding users’ interactions with ScholarSphere. It was a new service and presented many challenges in terms of the language used by librarians compared to users and the perceived requirements of the open-source community.

My Role

  • User testing facilitator
  • Wireframes
  • High fidelity mockups
  • Implement dashboard using HTML, Twitter Bootstrap, and Ruby on Rails


We needed to solve an issue with the user experience–what to do next after logging into the repository. People didn’t know what to do next or what the application offered them. The only thing that changed on the home page was that the login button changed to a user button with an icon, and their name appeared on the button. There wasn’t a noticeable change on the home page, and the “share your work button” wasn’t seen at all.


The proposed solution was to create a user dashboard as the launching point. On the dashboard, users can create new works and collections and get information about actions that they could perform without looking for it hidden under a dropdown menu or in the user profile. Once a user logged in, their dashboard displays. It was to be command central.

I worked with the product owner, architect, and fellow developers in an iterative fashion to create wireframes and style boards during sprint cycles. I used Adobe Illustrator to create the wireframes and style boards and delivered the output as PDFs so that people could make them up or print them out and mark them up. It’s a library. People still print documents. I would take their feedback and evaluate to produce the next round of wireframes. We started with black and white wireframes to avoid the “my favorite color” discussions and focus on information and actions. Once we had the functionality and layout nailed down, then I would produce higher fidelity mockups for the team to review.

The Dashboard

It was, like I said, command central. Users perform actions and receive status information from the dashboard. We put the four most common or crucial tasks for users at the time right up at the top as buttons with plenty of white space. The rest of the page is a two-column layout with a 1/3 and 2/3 layout. The 1/3 layout contained smaller sets of information and were for sections that informed the user about their statistics and their directory information. The 2/3 layout is for more information-heavy and interactive areas like recent user actions and proxy information.