Model-driven Application Design for a Campus Calendar Network


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

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • consultants –> timesheets in different formats
  • Began as a Masters thesis project at UC Berkeley School of Information Management & Systems
    Currently in development in the e-Berkeley Program Office at UC Berkeley
  • list of events with some navigation
  • filter by audience
  • fewer events and more navigation
  • Visitors to the Berkeley campus
    Students & Alumni
    Faculty & Staff
    Often this is done by manually entering the event data into several different web forms
    Or, even more inefficiently, by emailing the event data
  • sure, there’ll be some users who will switch to have a better calendar, but we also need the “big important” calendars to make the system successful
  • admission info
    Repeating events
  • Users with specialized data storage or development needs (e.g. purchasing tickets online)
  • --------------------------
    components that are both reusable and more digestible to users
  • (these might look like inside out and outside in approaches but they are compatible and complementary, and were interleaved throughout our development process, as I’ll show)
  • You’ve probably heard of user-centered design, where applications are designed iteratively and constantly refined through user feedback testing
  • goals for their calendar
    Current method of creating calendar
    Ideal calendar, desired features
    Interest in sharing data with other calendars
    Their event model
  • Document Engineering emphasizes the analysis of existing physical models
    SKICal – Swedish initiative to create a model for public events (as opposed to personal calendar events)
  • Actual calendars analyzed were chosen from a list most of the calendars on campus
    Selection criteria: each calendar with something distinctive about its type of content
    80-20: elements we chose should be helpful to at least 80% of campus calendars…those with domain-specific data could extend our model
  • Lists all data elements and gives an unambiguous semantic meaning for each one
  • Looked at the event data entry forms as well as the presentation of event information in these calendars
    Any component that is self-contained or comprehensible in its own right
    Understand the data elements found in the document inventory by extracting the underlying semantic components from their physical implementation (how they are presented)
  • --------------------FIRST PARA
    Synonyms: “begin date, start date”, “end date” “end on”, “place” and “location”
    Homonym: title & speaker title – can add a context qualifier to clarify: Can sometimes find reusable components by removing qualifiers in the name
    Dis-aggregate structures to the level we need to know about
    dates…ISO standard 1003.2
    an element called "Event Description" may really contain information on the event's topic, the cost of the event, and who the event sponsor is.
  • Consolidated table of content components
    can see at a glance how many calendars contain an element we called “Location”
    Synonym for location - place
    Location – broken down further later
  • Goal: create a model that minimizes redundancy & maximizes reuse
  • Differ in prescriptiveness & formality
    Functional dependency – datetime, address
  • Choosing the entry point
    May modify cardinality (how many instances of each structure/element are permissible) & optionality requirements, but only making them more restrictive
  • -------------------
    It’s easy to join our club!
    Substitution groups necessary for creating a LectureEvent, or PerformanceEvent with special constraints
    open entry element -> substitution group
  • Used task scenarios created earlier in the process
    Users feel more free to criticize and make suggestions when there isn’t actual code that’s been written
    They also put less emphasis on color and design issues and concentrate on how well it allows them to *accomplish their tasks*
  • Gives users a better feel of what the real application will be like to use
  • Navigation
    Things we learned about terminology here fed back into the Event model
  • 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 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 UC Berkeley gateway site ( …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 ( ) 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 ( 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 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 ( Our transformation Original ( 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?
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.