After running a pilot of Sakai at NYU, we took a semester to step back and analyze the feedback that we were receiving, and also to place the feedback in context of user research that has been conducted in the higher education field. By following a more formal user needs analysis process, we were able to come to some fairly solid conclusions about what a next generation LMS would need to do for faculty and students at NYU.
Based on this analysis, NYU has created some mock-ups that rethink how Sakai manages and shares content. This is an attempt to envision an ideal Sakai¿so these are draft, the technical complexities have not been addressed, user interface consistencies and usability have not yet been considered, and we are not trying to be practical. Though, one thing worth noting is that while it is an attempt for "ideal" it also aims for a balance between ideal and using developments that already exist with Sakai; several elements of this design would build directly on efforts already underway, with tweaks to make them more unified within the larger vision.
Summary of User Needs Analysis
High-level goals
On a very high level, and framed within institutional goals, NYU needs a system(s) that can:
- connect globally disparate campuses
- support fluid transitions between scholarship and teaching
- use social networking functionality as a way to support research and learning
- support information sharing across institutional and international boundaries
- provide a Do-It-Yourself approach to displaying and creating content
- encourage and sustain the growth of collective intelligence
Of course this touches on almost all areas of support that ITS provides at NYU, so we can't address all of the needs that fall within these high-level goals. So, while these high-level goals guided our vision, we did narrow in.
Direct User Needs
We decided to 1st deal with resource management and content presentation (2 tightly integrated concepts). The mock-ups that we came up with direct address the following user needs that we believe faculty (and students) want to do:
- make their own work available to others
- have easy access to others' work
- control the presentation of the materials they wish to share;
- control access to the materials they wish to share
- organize their materials and references according to their own schema
- integrate the management and presentation of materials that are currently stored and accessed in disparate institutional systems and locations
Example User Scenario
Professor Sabowski: Professor Sabowski is an anthropologist using video and audio to record her raw research; in addition to the text records of interviews and data sets of surveys that she and her research assistants have conducted. While she has been storing the video and audio on a central server, she needs a system that she can use to manage all of her research materials according to her own schema regardless of their file type. In addition, she needs a project site that she can easily share research data, and analysis materials with her research team, some of whom are in the field in South America. She would like to take some of the team's analysis and share them with some peers outside of NYU, as an initial peer review of the work being conducted before she seeks to formally publish within her field.
Professor Sabowski also teaches a graduate seminar every semester. Her current research has some relevance to the course. She would like to provide her students access to some of the research materials, as well information about some recent articles and books that she has been reading, within the course's site.
Summary of Proposed Designs
The proposed developments would hit on multiple tools within Sakai, however the focus of the design is centered around two tools: References and Content Pages.
References:
this tool would provide faculty and students a single application that is designed around popular social bookmarking type functionality, that they can use to manage their personal materials, websites, and references to materials within institutional repositories, using their own organizational schema. We envision selecting an open source tool (e.g., Zotero or Simile), and adapting it to work tightly within Sakai; but this would also need to stand outside of Sakai, and integrate with other institutional systems, like the libraries research portal. The References tool would store meta-data about files, but meta-data would be independent from file storage.
Content Pages:
owners of a site would create web pages using a web-based page editor to easily share learning materials and their own work. This tool would be based on the existing Resources tool. A Content Page(s) could be linked in the toolbar, and deeper links would be made inside of the content pages themselves. These pages would be stored "flat"; the system would not attempt to create hierarchical relationship between pages. This would mean the system could 1) avoid the types of system overhead that content management systems naturally incur; 2) avoid the user interaction design complexities that would need to be developed to support the hierarchies; 3) allow these pages to also become "references" and live within user-defined, non-hierarchical schema sets; 4) allow full user control over presentation and layout.
Faculty and students will be able to share materials filed in the References tool through Content Pages and ALEX's wiki and blog tools. Users would select to embed a media file or link to the reference's citation. In many ways the References tool would replace the role that Resources (and resources helper) now plays for Sakai.
Mockups
References
Access to the References would be broken into 3 levels:
- Personal (My References)
- Community References
- Public References
Public references would be available for WWW, and can be accessed before someone logs in.
A Site's Dashboard
A site's dashboard would let people edit their list of sites, and the toolbar in a more AJAX"y" style. The toolbar would become a sidebar, meaning a site owner could choose to add content pages not just tools to the sidebar, and just because a tool is active in a site will not mean it is automatically added to the sidebar. Certain links will always remain in the sidebar though these are only visible to the site owner (references, content pages, workspace/site settings, and a help link).
People can edit the access rights to their site within their workspace/site settings. The dashboard could remain widget-like. Students and Faculty would all be given a personal site that they could use much like a facebook page that people can join or unjoin from (or we would expand the user access settings so that a person has for their workspace, so that workspace might be able to function this way, allowing people to selectively turn on and off parts of their workspace to different groups of people).
Content Pages
This tool would be a modified Resources tool. Any content Pages that are created would be stored in Sakai, and also added as a Reference in the References tool. There would be a "Link" and "Embed" option, and this would use the References file management metaphor to locate and select media that is included in a Content Page (and same user metaphors would be used to link to files in the Wiki and Blogs, etc.). Any new files added that were not already stored in an institutional repository will added to a person's directory on NYU's central web storage space (we currently use Xythos). References would inherit permissions of the site once added.
