Model-driven Application Design v for a Campus Calendar

Model-driven Application Design v for a Campus Calendar

Model-driven Application Design v for a Campus Calendar Network Allison Bloodworth Project Manager e-Berkeley Program Office University of California, Berkeley [email protected] November 18, 2004 Todays 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 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 Cant share data

Models arent captured, cant be shared or reused Cant 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 systems users

1. Design a shared data model of an event that met almost everyones 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. 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/Ev ents.xsd ) 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) 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 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) 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) 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 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 (cont) 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 (cont) 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 (cont) 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 (cont) Calendar Calendar Element Name Element Glossary Name Name of Element

Evaluator Glossary ID Doe Library Location Location Sara Event Location Math Dept Location Location

Sara Event Location IAS Place Location Sara Event Location Look for elements from other vocabularies to reuse

AddressType from UBL PersonalNameType from BABL DE - Component Assembly UML Class Diagram created with Dave Carlsons hyperModel tool DE - Component Assembly (cont) 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 (cont) 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 everythings 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 (?) 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 Terminology Post vs. Publish Event Contact Features Export

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 Demonstration Questions? [email protected]

Recently Viewed Presentations

  • O Programa Segundo Tempo no Contexto da Poltica

    O Programa Segundo Tempo no Contexto da Poltica

    mario fernando borges felice. treinamento desportivo. pelo salario e por poder estar ajudando crianÇas em seu meio social, educacional e esportivo. mauro cÉzar da costa. 30 anos. É uma area que pgosto e pratico com frequencia. burutis. mauro henrique carvalho...
  • Ux PowerPoint Name - HPHS ENGINEERING

    Ux PowerPoint Name - HPHS ENGINEERING

    Center Line. Define the center of arcs, circles, or symmetrical parts. Half as thick as an object line. Section Line. Define where material is cut away. Short-Break Line. ... Extension Line. Shows where a dimension starts and stops. Used with...
  • Tree Diagrams - eccgcmaths.weebly.com

    Tree Diagrams - eccgcmaths.weebly.com

    Julie and Pat are going to the cinema. The probability that Julie will arrive late is 0.2. The probability that Pat will arrive late is 0.6. The two events are independent. Draw the tree diagram for this data. Find the...
  • Ang Kasaysayan at Iba pang Agham Panlipunan

    Ang Kasaysayan at Iba pang Agham Panlipunan

    Pag-aaral ng pisikal na katangian ng mundo. Anyong-lupa Anyong-tubig Kasaysayan Nakakaapekto ang pasikal na kaanyuan ng isang lugar sa paraan ng pamumuhay ng mga taong naninirahan doon. Hal. Sa pamamagitan ng mga katubigan ay nagkaroon ng ugnayan ang mga Pilipino...
  • Asian Literature - Winston-Salem/Forsyth County Schools

    Asian Literature - Winston-Salem/Forsyth County Schools

    Asian Literature Unit Introduction ... Alliteration Assonance Consonance Onomatopoeia Figurative Language Imagery Simile Metaphor Personification Oxymoron Haiku and Tanka Haiku: Three lines Kigo Syllabic structure 5 syllables 7 syllables 5 syllables Tanka Five lines Caesura Syllabic Structure 5 ...
  • DalSpace Deposit Process http://dalspace.library.dal.ca Updated August 2, 2011

    DalSpace Deposit Process http://dalspace.library.dal.ca Updated August 2, 2011

    The DalSpace team will set up the "Community" and the "Collections" within which a depositor has authorization to make deposits. A Community will generally correspond to a Dalhousie academic or administrative unit. e.g. Faculty of Computer Science Each Community will...
  • Impressionism 'All that is solid melts into air' (Marx and ...

    Impressionism 'All that is solid melts into air' (Marx and ...

    in Latin America "The Royal Academy of San Carlos in Mexico City, founded in 1785, was the first academy of art in America, and the only one established under colonial rule…. In Brazil, the Academia Imperial de Belas Artes was...
  • EU policies in E&T - Cedefop

    EU policies in E&T - Cedefop

    Change to learning outcomes approach (EQF, ECVET, validation of non-formal/informal learning) New Skills for New Jobs The role of guidance Interface between E&T and labour market Awareness of results of forecasting initiative - inform the clients to make the right...