1. Attach:mcn1.jpg Extended Axkit diagram with multiple output/input Δ

EricWilliams Eric Williams?, New Media Designer, Walker Art Center
NateSchroeder Nate Schroeder?, Webmaster, Walker Art Center

BrentGustafson Brent Gustafson?, New Media Designer, Walker Art Center\\

Brent Gustafson?, New Media Designer, Walker Art Center\\

• Axkit
• Cocoon

1. Application logic unchanged, very quick on that side
2. Presentation logic changed, so most work was only on design side

1. http://press.walkerart.org Press/http://info.walkerart.org/visit Visit/http://info.walkerart.org/about About
   1. Application layer changed, more work on the side
   2. Presentation layer reused, barely any work for the designer
2. 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

1. Had a bare bones admin initially that ran a few websites
   • Was not user friendly
   • Used an embedded language (Mason)

• Gives us flexibility and full ownership, can gear it towards our smaller evironment better
• Cost is much much cheaper

1. Decided to use the same tools as the site itself (Axkit + XSL)

1. Allows producers to make last minute changes without going through New Media

1. Uses Per Form?, a plugin of Ax Kit? to deal with form fields easily.

• This allows media editors who are not content producers

1. Media can be images, movies, music, PDF's, etc

• http://newmedia.walkerart.org/admin/renditions/ 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

• XML schema for media is solidified, works the same across any application

1. Enables content producers to provide more or less context to an event, while still enabling an efficient user experience
2. Transforms XSLT before importing into flash

1. The Architecture
   1. Attach:mcn5.jpg 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.

1. 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

1. http://newmedia.walkerart.org/example_files/front_quicktime.mov Building signage
   • Passing images to display computers
   • Data is same data from our database, made into graphical output

• XML to voice translations using cell phones
• Pulls content from our database

• Driven from our calendaring system, won't need to reenter events in ticket system anymore

1. The XML paradigm is future proof - we're seeing it work well on upcoming projects beyond just websites

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

1. Brief overview of how various other systems work compared to Axkit
   • Attach:mcn4.jpg How flat HTML files work Δ
   • Attach:mcn3.jpg More advanced PHP / CFM / JSP Δ
   • Attach:mcn2.jpg The basic AxKit model Δ

• 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.

1. http://calendar.walkerart.org Calendar

1. Same data being used in calendar and Flash movies. XML is providing image info and link info
2. The canopy concept, events can contain other events, nested data

1. http://learn.walkerart.org Learn

1. http://teens.walkerart.org Teens using same data in and entirely flash format

1. http://garden.walkerart.org Garden
   1. Event data again being pulled from the same record as Calendar, Learn and Teens
2. http://calendar.walkerart.org/newscenter.wac RSS

1. Since the Walker has a lot of events it is good for us to fit ourselves in that context.
2. Extremely easy to impliment because it's XML

• Commisioned work is important because it meant that we needed to move an archive forward.

1. http://www.walkerart.org/archive/F/0D317243B35C73A56172.htm Old site had static files, framesets, non-dynamic content. A big mess for updates and maintenance.

• 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.

• 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.

1. Technical Choices We Made
   1. Databases Options

1. postgreSQL (our chosen DB)

1. Languages Options

1. XML/XSLT (transformation paradigm)
   1. Appservers
      1. Axkit
      2. Cocoon

1. Attach:embeded_procon.gif 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. Attach:transform_procon.gif 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.

1. XML is a standard format, extensible, and is basically structured data

1. XSL isn't as great for one-off output, because it's slower and doesn't leverage the benefits of XSL
   1. Attach:mcn4.jpg How flat HTML file work Δ
   2. Attach:mcn3.jpg More advanced PHP / CFM / JSP Δ
   3. Attach:mcn2.jpg The basic AxKit model Δ
2. Attach:mcn4.jpg Extended Axkit diagram with multiple output/input Δ
   1. One WAC page can be used by multiple XSL files for different styling of the same data
   2. One WAC page can generate different XML for different output devices that requre it
   3. One XSL stylesheet can be used by different WAC pages for similar presentation with different XML data.

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

• How about PHP / CF / ASP / CGI, etc?

1. A brief history of the Walker online

1. http://www.walkerart.org/archive/F/0D317243B35C73A56172.htm Old site had static files, framesets, non-dynamic content. A big mess for updates and maintenance. (show archive)

Detailed Presentation Notes

Brent Gustafson, New Media Designer, Walker Art Center\\

Brent Gustafson, New Media Designer, Walker Art Center

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

MCN 2004 Conference Detailed Presentation Notes

Content Reuse For Multiple Output Devices

Session Chair: Brent Gustafson, New Media Designer, Walker Art Center

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

MCN 2004 Conference 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.

3:30-5:00 - Room 3 Content Reuse For Multiple Output Devices

Session Chair: Brent Gustafson, New Media, Walker Art Center

Panelists: Eric Williams, Walker Art Center Nate Schroeder, 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.

So from that, I think we should focus our talk broadly into these sections: (brainstorming)

1. Intro - "here's what we're going to talk about" (~10 minutes)
   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.
         1. 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. (show archive)
   2. Goals for redesign
      1. Put data entry and content generation into the hands of producers
         1. More up to date content
         2. Frees the New Media staffs time for other tasks
         3. Empowers producers and allows 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
         1. Using an urban metaphor the sites were designed to fit into a larger system with out being strictly confined by a previous design system.
         2. Using a central navigation we could create a system of different sites with in the larger Walker neighborhood.
         3. 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
      1. Databases
         1. Mysql
         2. postgreSQL
      2. Languages
         1. Mason (embedded PERL)
         2. PHP (embedded)
         3. XML/XSLT (transformation paradigm, explain)
            1. Axkit (appservers)
            2. 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 Pros
                  1. faster start up time for development
                  2. Ideal for single developer or very small team
                  3. PHP has a large labor/support pool
               2. Embedding Cons
                  1. Developer and designer have to work in same mark-up document
                  2. Less reuse
                  3. Data logic mixed with presentation logic
               3. Pros for separate transformations
                  1. Data logic and presentation logic are separate
                  2. Developer and designer do not work in the same file
                  3. More reuse of data and presentation markup.
               4. Cons for separate transformations
                  1. Longer initial set up time
                  2. More up front planning time agreeing on XML schema
                  3. 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 background - standard format, extensible, etc
      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 is bad for one off output, because it's slower and doesn't leverage the benefits of XSL
      5. Show diagram and explain process
         1. Start with most basic flat html
         2. Then more advanced PHP / CFM / JSP
         3. Show basic Ax Kit? model
      6. Show extended diagram with multiple output/input
         1. Show complex Ax Kit? model
         2. One WAC page can be used by multiple XSL files for different output
         3. One WAC page can generate different XML for different output
         4. One XSL stylesheet can be used by different WAC pages
   7. Implementation
      1. Calendar
         1. Central repository for all event data
         2. Same data being used across in calendar and Flash movies. XML is providing image info and link info
         3. Explain the canopy concept
      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 (if there are any upcoming calendar events)
      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.
      5. HTML e-mail
         1. Data from calendar in different style
         2. Adaptation of presentation code and application functions
      6. Press/Visit/About
         1. Application layer changed
         2. Presentation layer reused
         3. Site wide Navigation
         4. More info here
      7. Admin
         1. Had a bare bones admin for a while that ran a few of our websites
         2. Could have bought an off the shelf solution, but decided to build our own
            1. Gives us flexibility and full ownership, can gear it towards our smaller evironment better
         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 us
         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 w/ form fields easily.
         11. Connections allow one content record to appear in multiple neighborhoods.
         12. Show how it all works with live site
             1. Change Diva's record subtitle to "Girls in the Directors Chair"
      8. Image Administration and Re-use
         1. Manage media feature separate from content admin
            1. This allows media editors who are not content producers
         2. Media can be associated with multiple content items
         3. Standardization of media sizes speeds up the design and development processes
            1. Show rendition sizes
            2. Editors only need to worry about one size for upload, admin does the rest
            3. Designers can choose correct size for output
            4. Output to any device with any size
         4. Standardization of meta data speeds up the design and development processes
            1. XML schema is solidified, works the same across any application
      9. 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.
         3. While still enabling an efficient user experience
         4. Transforming with XSLT before importing into flash
         5. 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 specifics
      1. Server and Nate’s stuff - Server setup / hardware / software
      2. briefly into mod_perl, Ax Kit??, hardware, proxy, etc.
         1. show diagram
      3. Axkit modules (Per Form??, etc)
         1. there are many free / opensource ways to extend the basic application - wiki, etc.
      4. 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. money / servers
      2. time investment - new technology
      3. Diacritics (partly solved, Mac characters biting us now)
      4. Server load
      5. caching
      6. Training staff
      7. Standardizing the XML schema
         1. took longer than hoped for, but it's pretty solid now
      8. Segue into moving forward: Print calendar
         1. Problems with this and workflow
   10. Moving forward
       1. Signage
          1. Passing images to display computers
          2. Show image of front of building
       2. Art on Call
          1. XML to voice
       3. Tickets
          1. Driven from our calendaring system
   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.
3. Summary

   1. We are almost there
   2. Wrap up / Reiterate:
      1. This is a solution that's working for us, there are many options and they should be explored for your institution.
      2. By being so XML-centric we have incredible flexiblity for the future and new products / technology.
   3. Questions / discussion