Part of: Museum Computer Network

 

Page Actions: Edit Page • Recent Changes • Page History • Printable View

MCN 2004 Conference Detailed Presentation Notes

This is a detailed outline of what we covered in our presentation at MCN 2004. For the condensed outline that was passed out at the conference, please see the Session Outline.

Content Reuse For Multiple Output Devices

Nov 11, 2004, 3:30-5:00 - Room 3

Brent Gustafson, New Media Designer, Walker Art Center
Eric Williams, New Media Designer, Walker Art Center
Nate Schroeder, Webmaster, Walker Art Center

For the past year, the Walker Art Center has been redesigning its Web site and implementing a technical infrastructure that changes the way we work and think about our data and its output. The new site is database driven and generated using an XML application server called Ax Kit?. The XML can be translated to display on numerous devices, and is being used by the Walker for various output such as XHTML on walkerart.org, interactive Flash pieces, RSS news feeds, e-mail newsletters, dynamic signage in galleries, interactive telephony applications, and preformatted and edited texts for print. All data is administered through a centralized custom-built admin system accessed via the Web. This discussion will involve the thoughts and ideas behind this process.

Detailed Presentation Notes

  1. Intro - "Here's what we're going to talk about"
    1. Who we are, who the Walker is and how we fit into the Walker’s mission.
    2. Handouts - 50
    3. Briefly get feel for participants' experience and expectations
      • How many of you have worked with XML?
      • Get a feel for what they're using:
        • How many of you are using flat html files, maybe with some CSS?
        • How about PHP / CF / ASP / CGI, etc?
        • Full application server solution?
      • Who is looking at doing a redesign in the near future?
        • Have you decided on a platform?
  2. Main Presentation
    1. A brief history of the Walker online
      1. New Media Initiatives department was started in 1996 by Steve Dietz.
      2. Founded with responsibilities of presenting operational information, contextual information and using the web as a presentation space for commissioned work.
        • Commisioned work is important because it meant that we needed to move an archive forward.
      3. As web technology advanced it became clear we needed to rework our web presence from the ground up.
      4. Old site had static files, framesets, non-dynamic content. A big mess for updates and maintenance.
    2. Goals for redesign
      1. Put data entry and content generation into the hands of producers
        • More up to date content
        • Free the New Media staffs time for other tasks
        • Empower producers and allow them to take more ownership of the site.
      2. Create accessible pages -- no framesets, etc.
      3. Continue to give access to previously produced content and artwork.
      4. Reuse content to leverage producers time most effectively
      5. Reduced turnaround on new sites.
    3. Implementation Strategies
      1. Database driven to create a reservoir of content separate from the web-presentation
      2. Neighborhood design style
        • Using an urban metaphor the sites were designed to fit into a larger system with out being strictly confined by a previous design system.
        • Using a central navigation we could create a system of different sites with in the larger Walker neighborhood.
        • Since all the sites would be different it would reflect on the Walker’s larger mission of being a diverse multidisciplinary institution.
    4. Technical Choices We Made
      1. Databases Options
        1. Mysql
        2. postgreSQL (our chosen DB)
      2. Languages Options
        1. Mason (embedded PERL)
        2. PHP (embedded)
        3. XML/XSLT (transformation paradigm)
          1. Appservers
            • Axkit
            • Cocoon
        4. Deciding what implementation to use
          1. The Walker had done some Mason development previous to any of us being hired so there was some momentum in that direction. Eric had done some work with PHP and Brent had experience with XSL but not specifically with the XML server software.
          2. Embedded scripting vs. Separate Transformations
            1. Embedding
              1. Pros
                • Faster start up time for development
                • Ideal for single developer or very small team
                • PHP has a large labor/support pool
              2. Cons
                • Developer and designer have to work in same mark-up document
                • Less reuse
                • Data logic mixed with presentation logic
            2. Transformations
              1. Pros
                • Data logic and presentation logic are separate
                • Developer and designer do not work in the same file
                • More reuse of data and presentation markup.
              2. Cons
                • Longer initial set up time
                • More up front planning time agreeing on XML schema
                • Theoretically slower because of the transformations.
    5. Why we decided on XSL with Axkit
      1. XSL in general fit our team size and skills and naturally matched our institutional goals.
      2. Axkit particularly was chosen because our developer had extensive perl knowledge
      3. Was open source, which we support
      4. Allowed multiple forms of output from the same data very easily
      5. By being so XML-centric we have incredible flexiblity for the future and new products / technology.
    6. What exactly is XSL and how does it work.
      1. XML is a standard format, extensible, and is basically structured data
      2. XSL transforms one XML schema into another XML schema
      3. XSL is good for multiple outputs of data, as it can handle multiple XML schemas with the same data
      4. XSL isn't as great for one-off output, because it's slower and doesn't leverage the benefits of XSL
      5. Brief overview of how various other systems work compared to Axkit
      6. Extended Axkit diagram with multiple output/input
        • One WAC page can be used by multiple XSL files for different styling of the same data
        • One WAC page can generate different XML for different output devices that requre it
        • One XSL stylesheet can be used by different WAC pages for similar presentation with different XML data.
    7. Implementation
      1. Calendar
        1. Central repository for all event data
        2. Same data being used in calendar and Flash movies. XML is providing image info and link info
        3. The canopy concept, events can contain other events, nested data
      2. Learn
        1. Gets the same data as Calendar
        2. Flash movie is populated by same data and displayed in a different format
        3. Teens using same data in and entirely flash format
      3. Garden
        1. Event data again being pulled from the same record as Calendar, Learn and Teens
      4. RSS
        1. We can also send data in streams other than a web browser
        2. RSS is a simple method of syndicating information
        3. Users choose one of any number of news aggregators that retreive info
        4. It is a fast way for a person to review a lot of constantly updating content
        5. Since the Walker has a lot of events it is good for us to fit ourselves in that context.
        6. Extremely easy to impliment because it's XML
      5. HTML e-mail
        1. Data from calendar in different style
        2. Application logic unchanged, very quick on that side
        3. Presentation logic changed, so most work was only on design side
      6. Press/Visit/About
        1. Application layer changed, more work on the side
        2. Presentation layer reused, barely any work for the designer
      7. Site wide Navigation
        1. Consistant across all neighborhoods.
        2. Uses XSL include, so one change on the nav is reflected in every page on the Walker website
      8. Admin
        1. Had a bare bones admin initially that ran a few websites
          • Was not user friendly
          • Used an embedded language (Mason)
        2. Could have bought an off the shelf solution, but decided to build our own
          • Gives us flexibility and full ownership, can gear it towards our smaller evironment better
          • Cost is much much cheaper
        3. Decided to use the same tools as the site itself (Axkit + XSL)
        4. It's a web app, not platform dependant, can be accesses from anywhere
        5. Allows access by multiple authors
        6. Allows editorial oversight but remains simple enough to be geared towards a relatively small number of authors (10-15) and editors (2-3)
        7. Allows producers to make last minute changes without going through New Media
        8. Folder system allows for simple groupings of content
        9. Ability to push important content through featuring
        10. Uses Per Form?, a plugin of Ax Kit? to deal with form fields easily.
        11. Connections allow one content record to appear in multiple neighborhoods.
      9. Image Administration and Re-use
        1. Manage media feature separate from content admin
          • This allows media editors who are not content producers
        2. Media can be associated with multiple content items
        3. Media can be images, movies, music, PDF's, etc
        4. Standardization of media sizes speeds up the design and development processes
          • Our image media rendition sizes
          • Editors only need to worry about one size for upload, admin does the rest
          • Designers can choose correct size for output, and output to any device with any size
        5. Standardization of meta data speeds up the design and development processes
          • XML schema for media is solidified, works the same across any application
      10. Importing XML into Flash
        1. Allows us to fit a flexible amount of images in finite space
        2. Enables content producers to provide more or less context to an event, while still enabling an efficient user experience
        3. Transforms XSLT before importing into flash
        4. Styling with HTML 4.0 tags because of limitations inside of the Flash 6 plugin. This means Flash needs to get a separate XML from Axkit.
    8. The Architecture
      1. Server setup/Hardware/Software
        • Most pages are cached to speed up access
        • Pages that haven't been touched in a while, or are new, are uncached and thus slower
        • Caching speeds up performance significantly
      2. Axkit has modules and plugins (Per Form?, etc)
        • There are many free / opensource ways to extend the basic application - wiki, etc.
      3. Ax Kit? is not the end-all. Again, many ways to do this sort of thing - Enhydra, PHP, etc. This is just one way.
    9. Reality Check - How it went, how's it going
      1. Need money for servers and development environment
      2. Major time investment, lots of planning up front is needed
      3. Diacritics problems were found
        • Partly solved, Mac characters are still a problem
      4. Server load can be heavy because of the transformations
        • Caching cleared a lot of this up
      5. Training staff on how to use a new admin can be difficult
      6. Standardizing the XML schema took longer than we thought
        • Now that it's standardized things run much smoother
      7. Print calendar integration problems
        • In Design? XML import was not what we thought it was, and probably will not work with this application
    10. Moving forward
      1. Building signage
        • Passing images to display computers
        • Data is same data from our database, made into graphical output
      2. Art on Call
        • XML to voice translations using cell phones
        • Pulls content from our database
      3. Tickets
        • Driven from our calendaring system, won't need to reenter events in ticket system anymore
    11. Benefits we are seeing
      1. XML schema is solidifying, reuse happening
      2. Ramp up time for sites decreased significantly
      3. Separation of application and presentation a reality
      4. Most data in centralized DB
      5. We're not having to fix content for producers any more - if an event time changes, they can handle it.
      6. The XML paradigm is future proof - we're seeing it work well on upcoming projects beyond just websites
  3. Summary
    1. We are almost there
      • Still work to do on the Walker website redesign
      • Still functionality to add to the Admin system, etc
      • Many interesting projects coming down the pipe
    2. Wrap up/Reiterate:
      • This is a solution that's working for us, there are many options and they should be explored for your institution
      • By being so XML-centric we have incredible flexiblity for the future and new products/technology, this is our biggest benefit
    3. Questions/Discussion
Page last modified on November 16, 2005, at 03:59 PM
Page Actions: Edit Page • Recent Changes • Page History • Printable View