Model-driven Application Design for a Campus Calendar Network

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

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

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.

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

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

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

U.C. Berkeley Gateway Calendar

Berkeley Natural History
Museums

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

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

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

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.

Incompatible Data Models


U.C. Berkeley Gateway Site




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

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

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

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)

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)

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

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

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

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

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

DE - Component Analysis


Creation of a “Consolidated Table of
Content Components”

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

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


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

DE - Component Assembly

UML Class Diagram created with Dave Carlson’s “hyperModel”
tool

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


DE – Document Assembly


Document hierarchy imposes an
interpretation on a relational model

Image from Glushko & McGrath, Document Engineering, MIT Press,

DE – Implementation


Encoding our model in W3C XML Schema



Creating the application that uses the
Event model to exchange of event
information between calendars

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

UCD – Iterative Design Process



Allowed us to refine the way we presented
information to users
Inject user feedback into the design process

Paper Prototype

Interactive Prototype



Findings from Usability Testing


Application Layout
Paper prototype

1st Interactive prototype

Latest Design



Terminology





Post vs. Publish
Event Contact

Features


Export

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

Questions?
abloodworth@berkeley.edu

Model-driven Application Design for a Campus Calendar Network

More Related Content

Similar to Model-driven Application Design for a Campus Calendar Network (20)

More from Allison Bloodworth (8)

Recently uploaded (20)

Model-driven Application Design for a Campus Calendar Network

Editor's Notes