Embed Size (px)
Citation preview
vModel-driven Application Designfor a Campus Calendar Network
Allison BloodworthProject Manager
e-Berkeley Program OfficeUniversity 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-Based Application Design Model used for information exchange & to
guide the user interface designer Our Approach
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
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
1. Design a shared data model of an event that met almost everyone’s needs
2. Allow calendars to provide their users with a customized view of the data
3. Assist users of varying levels of technical skill in creating a customized calendar that is better than the one they currently use
Incompatible Data Models U.C. Berkeley Gateway Site
Haas School of Business
The Solution
A standard data model of an Event(http://dream.berkeley.edu/EventCalendar/Events.xsd)
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
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 (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
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)
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 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)
Look for elements from other vocabularies to reuse AddressType from UBL PersonalNameType from BABL
CalendarCalendar Element Name
Element Glossary Name
Name of Evaluator
Element Glossary ID
Doe Library
Location Location SaraEvent Location
Math Dept
Location Location SaraEvent Location
IAS Place Location SaraEvent Location
DE - Component Assembly
UML Class Diagram created with Dave Carlson’s “hyperModel” tool
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 - Component Assembly (con’t)
DE – Document Assembly Document hierarchy imposes an
interpretation on a relational model
Image from Glushko & McGrath, Document Engineering, MIT Press, 2005
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
Substitution Groups (elements) 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
UCD – Iterative Design Process
Interactive Prototype
Findings from Usability Testing Application Layout
Terminology Post vs. Publish Event Contact
Features Export
Paper prototype
1st Interactive prototype
Latest Design
UCD – Iterative Design Process
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
Demonstration
