Modeldriven 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_at_berkeley.edu
• November 18, 2004

2
Todays 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

• Cant share data
• Models arent captured, cant be shared or reused
• Cant 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 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

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.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

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

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 (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

26
DE - Component Analysis

• Creation of a Consolidated Table of Content
  Components

27
DE - 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

28
DE - 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

29
DE Component Analysis (cont)

• Look for elements from other vocabularies to
  reuse
• AddressType from UBL
• PersonalNameType from BABL

30
DE - Component Assembly

• UML Class Diagram created with Dave Carlsons
  hyperModel tool

31
DE - 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

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 (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 (?)

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_at_berkeley.edu