Model-driven Application Design for a Campus Calendar Network

1. Model-driven Application Designfor a Campus Calendar Network Allison Bloodworth Project Manager e-Berkeley Program Office University of California, Berkeley abloodworth@berkeley.edu November 18, 2004

2. Today’s Talk • The Generic Problem of Incompatible Data Models • Our Case Study Context • UC Berkeley Calendar Network • Model-Based Application Design • Model used for information exchange & to guide the user interface designer • Our Approach • Document Engineering • User-Centered Design • Demo of Prototype

3. The Generic Problem of Incompatible Models • Many large organizations struggle with incompatible models for applications created in different departments • Time sheets, contact management systems, expense forms, project schedules, registrations, etc.  • The problems are also typical of those that arise between enterprises with incompatible catalogs and transactional documents like orders and invoices.

4. Generic Symptoms • Can’t share data • Models aren’t captured, can’t be shared or reused • Can’t easily create and maintain interconnected or similar applications

5. Case Study: UC Berkeley Calendar Network • Goal: Design an enterprise application to allow web-based event calendars to share event information • Challenge: Working in a decentralized university environment where: • There are very few formal guidelines on creating web-based applications • It is difficult for different departments to coordinate with one another • Many departments have very limited technical resources

6. Our Case Study Context • There are numerous calendars on the Berkeley campus • The Academic Calendar • Bancroft Library • Berkeley Art Museum/Pacific Film Archive • Boalt Law School • Cal Performances • College of Engineering • College of Letters & Science • Haas School of Business • Institute for East Asian Studies • Lawrence Hall of Science • Live.berkeley.edu • UC Berkeley gateway site (www.berkeley.edu) • …and more than 70 others

7. U.C. Berkeley Gateway Calendar

8. Boalt Law School

9. Berkeley Natural History Museums

10. The Purpose of Web Calendars • A web calendar is a marketing tool • Its main purpose is to publicize events, either within a community, or to the general public • Calendars should make it as easy as possible for users to find information on events of interest to them

11. The Problem with calendars at Berkeley • It is difficult to get a comprehensive view of all campus events on a given day • It can be very difficult for calendar users to find events of interest to them • If they really want to do a thorough search, they must go to many different calendars

12. Our Challenges • Because the purpose of a calendar is to publicize events, many of these calendars would like to share their events with each other • Currently there is no automated way to do this • Incompatible data models & lack of technical resources prevent an automated exchange

13. The Key to Project Success: • Convince departments on campus to switch to our system • Have to gain “critical mass” of users in order to obtain enough event information to be useful to the system’s users • Design a shared data model of an event that met almost everyone’s needs • Allow calendars to provide their users with a customized view of the data • Assist users of varying levels of technical skill in creating a customized calendar that is better than the one they currently use

14. Incompatible Data Models • U.C. Berkeley Gateway Site • Haas School of Business

15. The Solution • A standard data model of an Event (http://dream.berkeley.edu/EventCalendar/Events.xsd) • A centralized repository of Event information • A calendar management tool • Manage events in the repository • Customize a visually compelling, dynamic web-based calendar • A design for a system architecture allowing XML feeds to and from the repository for calendars who choose to maintain their own website & repository

16. System Architecture

17. Model-Based Application Design • The collection, presentation, and exchange of data is governed by a formal model • Application can be generated from model in limited circumstances (simple forms, workflow) and when interfaces are only to other applications (e.g, Web Services) • In other cases, model can guide the UI designer • What information is most important • How best to group information together • Co-occurrence constraints

18. Our Approach • Document Engineering (DE) • Help us design the documents that are interfaces to systems or services • The data exchange model of an Event • User-Centered Design (UCD) • Help us design the applications that are interfaces for people • Our context had both service interfaces & user interfaces

19. What is Document Engineering? • “A new discipline for specifying, designing, and implementing the electronic documents that request or provide interfaces to business processes via web-based services” • UC Berkeley Center for Document Engineering website (http://cde.berkeley.edu) • A document-focused method of analyzing information from diverse sources and merging it to create a single, unified data model of the domain • End result: a document that “defines a packet of information needed to carry out a self-contained logical message” (from Glushko & McGrath, Document Engineering, MIT Press, 2005)

20. Document Engineering (DE) • Context & Business Process Analysis • Document Analysis • Inventory of Existing Models and Information Sources • Component Analysis • Harvesting and Consolidating data elements • Component Assembly • Designing a (Relational) Component Model • Document Assembly • Assembling a Document Model • Implementation • Encoding Models as Schemas • Deploying Models in Applications (from Glushko & McGrath, Document Engineering, MIT Press, 2005) (from Document Engineering courses taught at UC Berkeley)

21. Context Analysis – Needs Assessment • Interviews • Student Organizations • Associated Students of the University of California • Graduate Assembly • Academic Departments & Schools • Boalt Law School • College of Letters & Science • College of Natural Resources • Haas School of Business • Graduate School of Journalism • School of Public Health • School of Information Management & Systems • University Administration • Information Systems and Technology • Centers, Institutes & other campus organizations • Center for Latin American Studies • Institute of East Asian Studies • International House • Museums • Berkeley Art Museum and Pacific Film Archive • Recreational Sports

22. Interview Findings • Very important to maintain brand, or “look and feel” of rest of website • Ability to update information easily and quickly • Share events with other organizations on campus • 3 levels of users: • Low level – Static html or no calendar • Medium level - Willing to try other calendar applications • Advanced level – Do not want to replace current system but want to share events with UCB community

23. User-Centered Design Tasks (UCD) • Personas & Goals • Scenarios • Task Analysis • Frequency & importance of tasks to each persona • Competitive Analysis • Web Event • Cal Agenda • Calendars.net • Live.berkeley.edu • iCal • MS Outlook • Yahoo Calendar

24. DE - Document Analysis • Creation of a “Document Inventory” • Document guidelines & standards • Sample document instances • Web pages • Other information sources • Standards Investigated • iCalendar (RFC 2445) • Source of our repetition rules • SKICal • Influenced our Admission Info section

25. DE- Document Analysis (con’t) • Calendar types selected for evaluation • Academic Departments • Academic Colleges/Schools • Research Centers • Libraries • Museums • Athletics • Personal Calendaring Systems • Administrative Departments • Student Groups • Analyzed 23 calendars in all • A representative sample of the domain • Kept analyzing new calendars until “law of diminishing returns” told us when to stop • Used 80-20 rule to focus efforts

26. DE - Component Analysis • Creation of a “Consolidated Table of Content Components”

27. DE - Component Analysis (con’t) • Harvesting & Consolidating Components • Need metadata to capture the meaning & business rules of each component because the name is not “self-describing” • Calendar • Name of data element in calendar • Our semantically unambiguous name (glossary) • Composite Name (groups of related elements, e.g. DateTime) • Description • Data Type • Possible Value • Default Value • Etc. • Harvesting took on average 2 hours per calendar

28. DE - Component Analysis (con’t) • Glossary • Our simplified version of a controlled vocabulary • Ensure that every component is semantically distinct by weeding out homonyms & synonyms • Ensure that we break elements down to an appropriate level of granularity for our context of use • Collected average of 16 data elements per calendar from 23 calendars • 350 total elements from all the calendars • 150 had unique names • 100 had unique semantic meaning

29. DE – Component Analysis (con’t) • Look for elements from other vocabularies to reuse • AddressType from UBL • PersonalNameType from BABL

30. DE - Component Assembly UML Class Diagram created with Dave Carlson’s “hyperModel” tool

31. DE - Component Assembly (con’t) • Strict Normalization • Functional dependency • If the value of one component changes when the other changes • We may relax our normalization principles for the sake of efficiency or ease of use • “Core & Contexts” • Top down vs. bottom up approach • Core - set of elements that are common to all document models • Context - structures more related to specific contexts • Sometimes there are few pre-defined strong semantic constraints, so we create our own • Admission Info section in “Add Event” form

32. DE – Document Assembly • Document hierarchy imposes an interpretation on a relational model Image from Glushko & McGrath, Document Engineering, MIT Press, 2005

33. DE – Implementation • Encoding our model in W3C XML Schema • Creating the application that uses the Event model to exchange of event information between calendars

34. DE – Implementation (con’t) • Schema Design Issues • Design for reuse, maybe even in other domains • Optional vs. Required Elements • Required: Event Title, Event ID, DateTime • Minimal “Core” of required elements sets low barrier to entry • Allows us to gain the necessary critical mass of users in our domain • Allows for reuse in other domains • “Garden of Eden” style schema – everything’s global! • Redefines (types) • Important for creating enumerated lists • Substitution Groups (elements) • Allowed too much flexibility in the instance in our domain • Wanted to allow them if necessary in other domains • xsi:Any as opposed to defining an “Open-entry” element • Codelists (?)

35. UCD – Iterative Design Process • Allowed us to refine the way we presented information to users • Inject user feedback into the design process Paper Prototype

36. UCD – Iterative Design Process Interactive Prototype

37. UCD – Iterative Design Process • Findings from Usability Testing • Application Layout • Terminology • Post vs. Publish • Event Contact • Features • Export Paper prototype 1st Interactive prototype Latest Design

38. Calendar Transforms • Event Instance • Institute of East Asian Studies calendar • Original (http://ieas.berkeley.edu/events/) • Our transformation • Letters & Science calendar • Original (http://ls.berkeley.edu/events/) • Our transformation • The use of XML & XSL is critical in allowing calendars to easily create a customized view of the data

39. Demonstration

40. Questions? abloodworth@berkeley.edu