You are on page 1of 40

Model-driven Application Design v for a Campus Calendar Network

Allison Bloodworth Project Manager e-Berkeley Program Office University of California, Berkeley November 18, 2004

Today’s Talk
  

The Generic Problem of Incompatible Data Models Our Case Study Context

UC Berkeley Calendar Network Model used for information exchange & to guide the user interface designer Document Engineering User-Centered Design

Model-Based Application Design

Our Approach
 

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 UC Berkeley gateway site ( …and more than 70 others

U.C. Berkeley Gateway Calendar

Boalt Law School

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

1. 2. 3.

Incompatible Data Models

U.C. Berkeley Gateway Site

Haas School of Business

The Solution

 

A standard data model of an Event ( ) 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 maintain their own website & repository

System Architecture

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

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

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 (

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 selfcontained logical message”

(from Glushko & McGrath, Document Engineering, MIT Press, 2005)

Document Engineering (DE)
     

Context & Business Process Analysis Document Analysis

Inventory of Existing Models and Information Sources Harvesting and Consolidating data elements Designing a (Relational) Component Model Assembling a Document Model Encoding Models as Schemas Deploying Models in Applications

Component Analysis

Component Assembly

Document Assembly

 

(from Glushko & McGrath, Document Engineering, MIT Press, 2005) (from Document Engineering courses taught at UC Berkeley)

Context Analysis – Needs Assessment


 

Student Organizations
Associated Students of the University of California Graduate Assembly 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 Information Systems and Technology Center for Latin American Studies Institute of East Asian Studies International House Berkeley Art Museum and Pacific Film Archive

Academic Departments & Schools
      

 

University Administration

Centers, Institutes & other campus organizations
  

 


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 Web Event Cal Agenda iCal MS Outlook Yahoo Calendar

Competitive Analysis
      

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

Analyzed 23 calendars in all
  

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)

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 Location Element Glossary Name Location Location Location Name of Element Evaluator Glossary ID Sara Sara Sara Event Location Event Location Event Location

Doe Library

Math Dept Location IAS Place

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

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 Allowed too much flexibility in the instance in our domain Wanted to allow them if necessary in other domains

Substitution Groups (elements)
 

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

UCD – Iterative Design Process
Interactive Prototype

UCD – Iterative Design Process

Findings from Usability Testing

Application Layout
Paper prototype

1st Interactive prototype

Latest Design

 

Post vs. Publish Event Contact Export


Calendar Transforms
 

Event Instance Institute of East Asian Studies calendar
 

Original ( Our transformation Original ( Our transformation

Letters & Science calendar
 

The use of XML & XSL is critical in allowing calendars to easily create a customized view of the data