Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Model-driven Application Design
v
for a Campus Calendar Network
Allison Bloodworth
Project Manager
e-Berkeley Program Offi...
Today’s Talk



The Generic Problem of Incompatible Data
Models
Our Case Study Context




Model-Based Application Des...
The Generic Problem of Incompatible
Models


Many large organizations struggle with
incompatible models for applications ...
Generic Symptoms


Can’t share data



Models aren’t captured, can’t be shared or
reused



Can’t easily create and mai...
Case Study: UC Berkeley Calendar
Network


Goal: Design an enterprise application to
allow web-based event calendars to s...
Our Case Study Context


There are numerous calendars on the
Berkeley campus














The Academic Cale...
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 withi...
The Problem with calendars at
Berkeley


It is difficult to get a comprehensive view
of all campus events on a given day
...
Our Challenges


Because the purpose of a calendar is to
publicize events, many of these calendars
would like to share th...
The Key to Project Success:


Convince departments on campus to
switch to our system


Have to gain “critical mass” of u...
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/Eve
)
A centralized repos...
System Architecture
Model-Based Application Design


The collection, presentation, and exchange
of data is governed by a formal model



App...
Our Approach


Document Engineering (DE)





User-Centered Design (UCD)




Help us design the documents that are
i...
What is Document Engineering?


“A new discipline for specifying, designing,
and implementing the electronic
documents th...
Document Engineering (DE)



Context & Business Process Analysis
Document Analysis




Component Analysis




Design...
Context Analysis – Needs
Assessment


Interviews


Student Organizations





Academic Departments & Schools




...
Interview Findings





Very important to maintain brand, or “look
and feel” of rest of website
Ability to update info...
User-Centered Design Tasks (UCD)




Personas & Goals
Scenarios
Task Analysis




Frequency & importance of tasks to ...
DE - Document Analysis


Creation of a “Document Inventory”







Document guidelines & standards
Sample document i...
DE- Document Analysis (con’t)


Calendar types selected for evaluation












Academic Departments
Academi...
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 &
busines...
DE - Component Analysis (con’t)


Glossary
Our simplified version of a controlled vocabulary
 Ensure that every componen...
DE – Component Analysis
(con’t)
Calendar

Calendar
Element
Name

Element
Glossary
Name

Name of
Evaluator

Doe
Library

Lo...
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 ch...
DE – Document Assembly


Document hierarchy imposes an
interpretation on a relational model

Image from Glushko & McGrath...
DE – Implementation


Encoding our model in W3C XML Schema



Creating the application that uses the
Event model to exch...
DE – Implementation (con’t)


Schema Design Issues



Design for reuse, maybe even in other domains
Optional vs. Requir...
UCD – Iterative Design Process



Allowed us to refine the way we presented
information to users
Inject user feedback in...
UCD – Iterative Design Process
Interactive Prototype
UCD – Iterative Design Process


Findings from Usability Testing


Application Layout
Paper prototype

1st Interactive p...
Calendar Transforms



Event Instance
Institute of East Asian Studies calendar





Letters & Science calendar



...
Demonstration
Questions?
abloodworth@berkeley.edu
Upcoming SlideShare
Loading in …5
×

Model-driven Application Design for a Campus Calendar Network

1,460 views

Published on

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

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

Model-driven Application Design for a Campus Calendar Network

  1. 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. 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. 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. 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. 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. 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. 7. U.C. Berkeley Gateway Calendar
  8. 8. Boalt Law School
  9. 9. Berkeley Natural History Museums
  10. 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. 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. 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. 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. 14. Incompatible Data Models  U.C. Berkeley Gateway Site  Haas School of Business
  15. 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. 16. System Architecture
  17. 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. 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. 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. 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. 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. 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. 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. 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. 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. 26. DE - Component Analysis  Creation of a “Consolidated Table of Content Components”
  27. 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. 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. 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. 30. DE - Component Assembly UML Class Diagram created with Dave Carlson’s “hyperModel” tool
  31. 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. 32. DE – Document Assembly  Document hierarchy imposes an interpretation on a relational model Image from Glushko & McGrath, Document Engineering, MIT Press,
  33. 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. 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. 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. 36. UCD – Iterative Design Process Interactive Prototype
  37. 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. 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. 39. Demonstration
  40. 40. Questions? abloodworth@berkeley.edu

×