Interactive Session: Build a Performance-Driven 2015 Content Calendar
Model-driven Application Design for a Campus Calendar Network
description
Transcript of Model-driven Application Design for a Campus Calendar Network
![Page 1: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/1.jpg)
vModel-driven Application Designfor a Campus Calendar Network
Allison BloodworthProject Manager
e-Berkeley Program OfficeUniversity of California, Berkeley
November 18, 2004
![Page 2: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/2.jpg)
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
![Page 3: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/3.jpg)
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.
![Page 4: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/4.jpg)
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
![Page 5: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/5.jpg)
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
![Page 6: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/6.jpg)
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
![Page 7: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/7.jpg)
U.C. Berkeley Gateway Calendar
![Page 8: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/8.jpg)
Boalt Law School
![Page 9: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/9.jpg)
Berkeley Natural History Museums
![Page 10: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/10.jpg)
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
![Page 11: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/11.jpg)
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
![Page 12: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/12.jpg)
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
![Page 13: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/13.jpg)
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
![Page 14: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/14.jpg)
Incompatible Data Models U.C. Berkeley Gateway Site
Haas School of Business
![Page 15: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/15.jpg)
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
![Page 16: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/16.jpg)
System Architecture
![Page 17: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/17.jpg)
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
![Page 18: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/18.jpg)
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
![Page 19: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/19.jpg)
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)
![Page 20: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/20.jpg)
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)
![Page 21: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/21.jpg)
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
![Page 22: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/22.jpg)
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
![Page 23: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/23.jpg)
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
![Page 24: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/24.jpg)
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
![Page 25: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/25.jpg)
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
![Page 26: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/26.jpg)
DE - Component Analysis Creation of a “Consolidated Table of
Content Components”
![Page 27: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/27.jpg)
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
![Page 28: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/28.jpg)
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
![Page 29: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/29.jpg)
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
![Page 30: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/30.jpg)
DE - Component Assembly
UML Class Diagram created with Dave Carlson’s “hyperModel” tool
![Page 31: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/31.jpg)
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)
![Page 32: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/32.jpg)
DE – Document Assembly Document hierarchy imposes an
interpretation on a relational model
Image from Glushko & McGrath, Document Engineering, MIT Press, 2005
![Page 33: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/33.jpg)
DE – Implementation
Encoding our model in W3C XML Schema
Creating the application that uses the Event model to exchange of event information between calendars
![Page 34: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/34.jpg)
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 (?)
![Page 35: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/35.jpg)
UCD – Iterative Design Process Allowed us to refine the way we presented
information to users Inject user feedback into the design process
Paper Prototype
![Page 36: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/36.jpg)
UCD – Iterative Design Process
Interactive Prototype
![Page 37: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/37.jpg)
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
![Page 38: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/38.jpg)
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
![Page 39: Model-driven Application Design for a Campus Calendar Network](https://reader035.fdocuments.in/reader035/viewer/2022062322/568150fb550346895dbf19b6/html5/thumbnails/39.jpg)
Demonstration