1. The UC Berkeley Calendar Network Final Master’s Project Allison Bloodworth Nadine Fiebrich Myra Liu Zhanna Shamis

2. Presentation Overview  Intro to UC Berkeley Calendar Network & Calendar Management tool  Heuristic Evaluation  Compare current design to 1 st interactive prototype  Demo of the current design  Pilot Usability Study Results  Plans for the last iteration  Lessons Learned

3. What is the UC Berkeley Calendar Network?  A way to allow the many calendars on the Berkeley campus to share event information  Events may be stored:  In a centralized repository provided by the campus  In individual department repositories  These entities can either use, or map to, the comprehensive “event” data model our team has created

4. What is the BCN Calendar Management Tool?  An application that allows calendar owners to:  Create and format a calendar that can be “plugged in” to their website  Manage the events displayed on their calendar  It is useful for calendar owners who:  Do not need their own repository  Do not have special web development needs

5. Heuristic Evaluation  Main Points  Navigation still could use improvement  The “Filter By” options in the Event Manager are overwhelming  It is sometimes confusing to allow actions to be executed in multiple ways  Confirmation messages should stand out  “Deleting” events is too strong a word  “Cancel” & “Back” needed on Add form confirmation  Need to standardize button locations Thank you SIMS Corpus!

6. Event Manager - Posted First Interactive Prototype Smaller top Nav No Date Filter By Add Event View/Edit Buttons & links

7. Event Manager - Posted Second Interactive Prototype Date Larger Top Nav Search w/Advanced Options Create Event Link & Edit Button only

8. Advanced Search Second Interactive Prototype

9. Event Posting Confirmation First Interactive Prototype

10. Event Posting Confirmation Second Interactive Prototype

11. Event Detail First Interactive Prototype

12. Event Detail Second Interactive Prototype

13. Demo of our current prototype  http://dream.berkeley.edu/EventCalend ar/MyraTestFolder/ThirdInteractiveProto type/login.php http://dream.berkeley.edu/EventCalend ar/MyraTestFolder/ThirdInteractiveProto type/login.php

14. Pilot Usability Study  Goals  Ensure that participants can find and use the various functions in the interface  Determine whether the functionality provided is valuable  Determine whether the interaction flow is natural and intuitive and matches current user workflow  Determine whether the application will meet the needs of these calendar administrators  Participants  Two calendar administrator and one calendar content manager, all of high-level calendars

15. Pilot Usability Study Results  Users found the system relatively easy to use, though more explanatory text and help is needed in many areas  Users thought the system would be valuable to their department as well as other campus departments  One high-level calendar owner even thought she could use it to send events to other departments  Users thought the functionality provided was valuable, but some functions more than others depending on their needs

16. Plans for the next iteration  Event Manager  Change navigation so Event Manager includes a “Department Name” Calendar Events section which will encompass the Pending/Posted/ Archived tabbed section  Put search functionality on all three tabs and change label to “Search Posted Events” etc  Add red background to confirmation messages  Create Event Form  Change “Event Status” to “Event Sharing Status”  Add explanatory text to “Event Listing Contact”

17.  Navigation  Change “Calendar” on nav to “View Live Calendar”  Format Calendar  Add explanatory text to “Preview Calendar”  Remove “Restore Default Settings”  Event Details  Change “Cancel” button to “Back”  Subscription  Remove “Event Date” from the options offered Plans for the next iteration

18. Lessons learned  Navigation is tricky, and it can require multiple iterations to get it right  Craft the language used in task scenarios for user testing carefully, as unclear language can cause unnecessary user confusion  It is sometimes better to provide users with less functionality if using all available options would be confusing  You can iterate a lot longer than you might think and continue to improve your design