Presented by Allison Bloodworth at the XML 2004 Conference. Winner of the best presentation award.

1. Model-driven Application Design
v
for 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


Model-Based Application Design


Model used for information exchange & to
guide the user interface designer
Our Approach



UC Berkeley Calendar Network
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
1.
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
2.
3.

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/Eve
)
A centralized repository of Event
information
A calendar management tool



Manage events in the repository
Customize a visually compelling, dynamic webbased calendar
A design for a system architecture
allowing XML feeds to and from the
repository for calendars who choose to

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)



User-Centered Design (UCD)


Help us design the documents that are
interfaces to systems or services
The data exchange model of an Event
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 webbased 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


Component Analysis


Designing a (Relational) Component Model
Document Assembly


Harvesting and Consolidating data elements
Component Assembly


Inventory of Existing Models and Information Sources
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



Academic Departments & Schools










Center for Latin American Studies
Institute of East Asian Studies
International House
Museums


Information Systems and Technology
Centers, Institutes & other campus organizations


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


Associated Students of the University of California
Graduate Assembly
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)
Calendar
Calendar
Element
Name
Element
Glossary
Name
Name of
Evaluator
Doe
Library
Location
Location
Sara
Event
Location
Math
Dept
Location
Location
Sara
Event
Location
IAS
Place
Location
Sara
Event
Location

Element
Glossary
ID
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,

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




“Garden of Eden” style schema – everything’s
global!

Redefines (types)




Important for creating enumerated lists
Substitution Groups (elements)


Allows us to gain the necessary critical mass of users in
our domain
Allows for reuse in other domains
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
Paper prototype
1st Interactive prototype
Latest Design

Terminology



Post vs. Publish
Event Contact
Features

Export

38. Calendar Transforms


Event Instance
Institute of East Asian Studies calendar



Letters & Science calendar



Original (http://ieas.berkeley.edu/events/)
Our transformation
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