Title: Modeldriven Application Design for a Campus Calendar Network
1Model-driven Application Designfor a Campus
Calendar Network
- Allison Bloodworth
- Project Manager
- e-Berkeley Program Office
- University of California, Berkeley
- abloodworth_at_berkeley.edu
- November 18, 2004
2Todays 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
3The 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.
4Generic Symptoms
- Cant share data
- Models arent captured, cant be shared or reused
- Cant easily create and maintain interconnected
or similar applications
5Case 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
6Our 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
7U.C. Berkeley Gateway Calendar
8Boalt Law School
9Berkeley Natural History Museums
10The 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
11The 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
12Our 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
13The 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 systems users - Design a shared data model of an event that met
almost everyones 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
14Incompatible Data Models
- U.C. Berkeley Gateway Site
- Haas School of Business
15The Solution
- A standard data model of an Event
- (http//dream.berkeley.edu/EventCalendar/Events.x
sd) - 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
16System Architecture
17Model-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
18Our 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
19What 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)
20Document 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)
21Context 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
22Interview 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
23User-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
24DE - 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
25DE- Document Analysis (cont)
- 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
26DE - Component Analysis
- Creation of a Consolidated Table of Content
Components
27DE - Component Analysis (cont)
- 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
28DE - Component Analysis (cont)
- 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
29DE Component Analysis (cont)
- Look for elements from other vocabularies to
reuse - AddressType from UBL
- PersonalNameType from BABL
30DE - Component Assembly
- UML Class Diagram created with Dave Carlsons
hyperModel tool
31DE - Component Assembly (cont)
- 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
32DE Document Assembly
- Document hierarchy imposes an interpretation on a
relational model
Image from Glushko McGrath, Document
Engineering, MIT Press, 2005
33DE Implementation
- Encoding our model in W3C XML Schema
- Creating the application that uses the Event
model to exchange of event information between
calendars
34DE Implementation (cont)
- 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 everythings
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 - xsiAny as opposed to defining an Open-entry
element - Codelists (?)
35UCD Iterative Design Process
- Allowed us to refine the way we presented
information to users - Inject user feedback into the design process
- Paper Prototype
36UCD Iterative Design Process
37UCD Iterative Design Process
- Findings from Usability Testing
- Application Layout
- Terminology
- Post vs. Publish
- Event Contact
- Features
- Export
Paper prototype 1st Interactive
prototype Latest Design
38Calendar 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
39Demonstration
40Questions?
abloodworth_at_berkeley.edu