1. Admin

1. Admin

Mcn 06 Links

Mcn Links?

1. iCal

1. Art on Call

1. iCal

1. iPod

Art on Call

1. HTML e-mail

1. Admin

• Ticketing. Same issue, 3rd party software, doesn't easily allow import and display.

• Brief overview of how various other systems work compared to Axkit
  • How flat HTML files work
  • More advanced PHP / CFM / JSP
  • The basic AxKit model

1. Flash useds same XML as HTML page, but parses in it's own way

1. AOC
   1. XML in XML
   2. RSS embedded into regular schema in RSS node
   3. No real work, just importing
   4. Can use it to add content to pages from two separate CMS's
   5. Easily add related links to calendar from blog
   6. No work on designers side, this time all on dev.

1. Admin
   1. What to do for CMS?
   2. Buy something expensive? No.
   3. Build our own, but with what? Same problems as before (PHP, JSP, etc?)
   4. Use XSL/XML!

• Thankfully this is something we can fix in the future with hardware upgrades

• Interactive signage. Issue with 3rd part software and import.

1. iCal

1. Attach:iCal Δ

• Talk about how we ended up using XML for our data output at the Walker
  • Main decision stemmed from a change in development process

• In Design?, and Walker Calendar Magazine. Does allow XML import, but not in the way that works the way we would need.

1. Data again from calendar database
2. Application logic has very little changed. Adds in ability to make a custom statement.

1. Everywhere else
   1. Using it a ton of other places on the website, and can extend what we've done in the future for just about anything that uses XML.

1. What didn't work
   • Interactive signage. Issue with 3rd part software and import.
   • Ticketing server. Same issue, 3rd party software, doesn't easily allow import and display.

1. iCal
   1. iCal and many calendar apps use .ics files for data
   2. They're simply XML so it's just as simple for us to make an iCal subscription to our Calendar
2. iPod
   1. We have cell phone audio tours, called Art on Call.
   2. We also have a version for iPods, which we have for checkout in the galleries.
   3. iPods accept iCal calendars, so it's a natural fit we include this on our audio tour iPods.
   4. They're simply XML so it's just as simple for us to make an iCal subscription to our Calendar on each iPod.
   5. Auto updated when they're recharged, through iTunes.

• One side does not affect the other as long as the XML stays the same.
• XSL can be written and not interfere with logic. Logic can be rewritten (even a switch to a totally different language) and not affect presentation.

1. Film/Video
   1. Event data again being pulled from the same record as Calendar
   2. App logic is the same, so is the XML, zero changes. Just chance the XSL and you get a different layout tailored to that audience.

1. Again, same data, this time different output.

• Cocoon (JSP)

1. XSL transforms one XML schema into another XML schema, future proof.

• One side does not affect the other as long as the XML stays the same. ****XSL can be written and not interfere with logic. Logic can be rewritten (even a switch to a totally different language) and not affect presentation.

• Stick with static files
• Mason (embedded PERL) (old dev knew this well, we didn't)
• PHP (embedded) (popular, everyone would have to learn it)
• XML/XSLT (transformation paradigm) (From Brent's previous job)

• We chose XML/XSLT, Axkit
  1. XSL in general fit our team size and skills and naturally matched our institutional goals.
  2. Was open source, which we support
  3. Allowed multiple forms of output from the same data very easily
  4. By being so XML-centric we have incredible flexiblity for the future and new products / technology.
  5. Brief overview of how various other systems work compared to Axkit
     • How flat HTML files work
     • More advanced PHP / CFM / JSP
     • The basic AxKit model
  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.

• Old site had static files, framesets, non-dynamic content. A big mess for updates and maintenance.

• What tech to move to?
  • Mason (embedded PERL)
  • PHP (embedded)
  • XML/XSLT (transformation paradigm)
    • Appservers
      • Axkit
      • Cocoon

Encode Once, Access Many: Using the Power of XML to Present Museum Information

Presentation Notes

Moderator/Presenter: Mary W. Elings, The Bancroft Library, University of California, Berkeley\\

• Thank you for coming, introduce yourself
  • Briefly get feel for participants' experience and expectations
    • How many of you are working with XML?
    • Anyone not? If not, will they in the future?
• Main Presentation
  • How we moved to XML at the Walker

MCN 2006 Conference Presentation Notes

Encode Once, Access Many: Using the Power of XML to Present Museum Information

Nov 10, 2006, 8:30 - 10:00

Moderator/Presenter: Mary W. Elings, The Bancroft Library, University of California, Berkeley Participants: Brent Gustafson, Walker Art Center, and Karim Boughida, Getty Research Institute

XML technology is a powerful tool in providing access to information. This panel will look at how XML provides museums with flexibility and cost efficiency in presenting information for institutions as a whole and for individual collection materials and assets. Panelists will discuss how the various types of information in XML can be encoded once and accessed many times via methods such as XHTML/HTML, OAI, interactive Flash pieces, RSS news feeds, email newsletters, dynamic signage in galleries, interactive telephony applications, etc. The panel will look at CDWA Lite, a developing XML schema coming out of the museum community that will further use of XML by cultural heritage institutions and provide increased access to cultural heritage information.

Presentation Notes

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
         • How flat HTML files work
         • More advanced PHP / CFM / JSP
         • The basic AxKit model
      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