MW Tech Paper

Here is a shared place to work on our paper text. When we are done we'll need to cut and paste this into a word doc. For now we can review and edit each other's work in one place.

Architecting the Elephant: Software Architecture and User Interface Design for Pachyderm 2.0

Interface Design

The first version of the Pachyderm authoring system was a large, lumbering, somewhat strict creature ridden by only a few people. Yet its immense size and power did not prohibit that small group from creating intricate, beautiful works.

Traditionally, with a limited, in-house development team, many deficiencies in a piece of software can be overlooked easily and worked around, as those imperfections become an ingrained part of the creation process. It was and is our goal to retain the power and potential of San Francisco Museum of Modern Art’s original Pachyderm authoring system, with a much simplified face that enables all types of users to create strong presentations.

In order to facilitate the easy creation of presentations in Pachyderm, we have employed a few standard, proven methods of design. According to designer and educator Philip B. Meggs, the design process is a sequence of events that begins when the designer receives and assignment and continues until the problem is solved and the solution is accepted and implemented. (Meggs, 1992) The process includes defining the problem, gathering information, searching for effective ideas, deciding on a solution and finally implementation.

Design of the new authoring screens were both based on the existing screens in use by SFMOMA and many discussions with the main user group of the software, namely museum curators and university faculty. In addition, the need to implement new features and functionality required re-designing portions of the authoring process.

Essentially, through anything from iChat and Breeze screen-shares to Sharpie on butcher paper in San Francisco hotels, the development team worked through many iterations of the flow of authoring, or the easiest and quickest succession of screen interaction. This took the form of a flowchart document for various users with boxes, lines and arrows based on target user groups and scenarios of how certain people would use Pachyderm. By creating such a graphical representation of typical user scenarios and succession, we have been able to ascertain the best order all the interlinking screens to get a user from the left side of the flowchart to the right in the fewest amount of boxes, or tasks.

Once we were more sure of what the order of the screens would be, we began to sketch out the individual screens in the interest of creating a basic graphical system with attention to all the elements that needed to be on the screen, such as navigation and software controls such as “save” and “delete.”

With the sketches in hand, we moved them into a digital format that we termed “wireframing,” in reference to 3-dimensional design programs having a skeletal, bare-bones view of an object minus it’s skin or covering. The wireframe stage allowed us to more precisely place all needed elements onto the screen designs with attention to spelling, hierarchy and usability. We then put these wireframes into the hands of some university faculty and museum patrons and curators and incorporated the feedback we received.

The next stage required us to turn the designs into a standards-compliant xhtml format that could be read by Web browsers, where the actual authoring will take place. This included mocking-up the screens with actual Web form-based buttons and controls and straightforward color and design treatment.

The programmers on the team then took control of these coded screen designs and made them unction by marrying the coding and programming elements. The testing of these working screens is underway.

During this testing time, we are paying particular attention to feedback on issues of usability and accessibility, with an attention to moving closer to a parity of visual design between the authoring and presentation screens.

References

Meggs, Philip B. (1992). Type and Image: The Language of Graphic Design, New York: John Wiley & Sons, Inc., 153.

Software Architecture

Historical Overview

The first version of the Pachyderm software was built by the San Francisco Museum of Modern Art, with the express purpose of facilitating the development of an online interactive version of their Making Sense of Modern Art exhibit. With the production of that exhibit as the primary requirement, the design and development of the Pachyderm authoring application was initially limited in scope. As is often the case with successful prototypes, it became an important tool for the SFMOMA staff.

As online versions of additional exhibits were needed, the Pachyderm 1.0 software was adapted and extended, with pieces being bolted on to support new functionality. The database schema blossomed, and code became spaghetti.

Since it was created to solve a set of needs internal to the SFMOMA, the developers made some decisions to require a set of software dependencies that would allow them to build the software faster, and integrate with the existing SFMOMA collection management database. These dependencies included Windows 2000 Server, SQL Server, Macromedia Generator 1.0, and Filemaker 5.

Requirements Gathering

The first step of the development process involved a large-scale effort to document the requirements of the software. These requirements would be used to determine gaps in functionality between the existing version and the next version of the Pachyderm authoring application. We built a custom Requirements Tracker application that was used by project participants to describe and categorize the requirements of various users of the system. This requirements database has grown to 289 items, and fully describes the intended functionality that the finished application will have.

Refactor or Rebuild?

Once the requirements had been documented and reviewed, we were able to begin a gap analysis on the existing software. We needed to identify which requirements were not met, and what changes would be required to satisfy them. Part of this analysis was to examine the existing software code and database schema to determine the feasibility of extending it for our needs.

The first development effort was focussed on the creation of a portable, installable version of the Pachyderm 1.0 software. This effort resulted in the “Pachyderm 1.1 Rhino” release, which was more portable than the initial software due to the isolation of configurations that were hard-coded to the Pachyderm 1.0 server at the San Francisco Museum of Modern Art. This version also included a new asset upload feature, which was intended to form a bridge between the integrated Filemaker asset database and the web-based interface.

Once we had a portable version of Pachyderm 1.0, we began to analyze the database schema and software design. As we waded into the source code, we realized that the software had been developed by accretion - adding features and functions onto the prototype in an ad-hoc manner. While this served the immediate needs of the users of Pachyderm 1.0, it would prove to make radical modification and extension more difficult for us.

We compiled a list of software dependencies assumed in Pachyderm 1.0, which relied on a suite of proprietary applications, including Macromedia Generator, FileMaker, Microsoft SQL Server, Microsoft IIS, a commercial .zip archiving library, and a substantial collection of custom Active Server Pages (ASP) code.

The original database schema had over a dozen tables, with much of the design having redundant functions with minor tweaks for specific purposes.

Although our initial plan was to simply extend the original Pachyderm 1.0 software, we started realizing that we would have to refactor large portions of the programming in order to make it do what we needed, and would possibly have to rebuild some or all of the code from the ground up.

Design Decisions

The primary goal we had in mind when selecting the platform for Pachyderm 2.0 was to enable flexibility, collaboration, and stability while preventing single-vendor lockdown where possible. We were willing to make some compromises, as long as we were confident that our platform would enable us to build the functionality we needed while letting us deploy it on a wide variety of servers.

The “highest risk” component was Macromedia Generator, which had been discontinued several years ago and was no longer commercially available. Without a functional replacement, we would be unable to publish Flash formatted media that is an essential part of a Pachyderm presentation. Our search for replacements led us to the jGenerator project - an open source Java library that was designed to be a drop-in replacement for Macromedia Generator. This jGenerator library was identified as the only reliably functioning Generator replacement.

With the java library selected, we next had to select the language we would be using to program Pachyderm 2.0.  Our initial plan was to port the Active Server Pages code to Java Server Pages, in what was estimated to be a short-term endeavor. Upon further analysis, we decided it would be best to leave the legacy design decisions behind, and use Pachyderm 1.0 more as a prototype than an initial codebase.

One of the requirements that was identified involved the ability to demonstrate database independence. We needed to be able to connect to a variety of database servers, including Microsoft SQL Server, MySQL, Filemaker, and potentially many others, including XML databases, that had yet to be identified. The only software development platform that we were aware of that offered this level of database independence was Apple’s WebObjects application server. WebObjects is a java-based set of frameworks and applications, including a database management framework called “Enterprise Objects Framework” (EOF). EOF would be able to take care of the “heavy lifting” of connecting to various databases, and would free us to focus more on application-level development.

The architecture of the WebObjects frameworks offered us a high degree of modularity which we could mimic when developing our Pachyderm 2.0 application. We could build a set of shared functionality into a framework, and this could be accessed by any WebObjects application deployed on the server. This could let other groups easily build tools to integrate with Pachyderm 2.0.

Also, since WebObjects can be deployed on a variety of platforms, including MacOSX, Windows 2000 Server, Solaris and Linux, we would be able to satisfy the requirement that we not be tied to any single server vendor.

APOLLO

At the same time we started Pachyderm development, The University of Calgary was working on their successor to the CAREO learning object repository, code-named “APOLLO”. APOLLO was designed to be an extremely flexible set of frameworks and applications, that would allow the development of a wide variety of different but related functionality, specifically aimed at enabling people to publish, locate, and reuse learning objects.

We realized that there was a strong overlap in requirements, and in the summer of 2004, we decided to base Pachyderm 2.0 on the APOLLO frameworks and concepts. This would let us further focus our development effort on the features directly required to support our presentation authoring application, while working with the APOLLO developers to further enhance its functionality.

One very powerful feature of APOLLO is the ability to build small components and plugins which can be integrated dynamically into a running application, allowing the addition of customized functionality without modifying an entire application or framework.

APOLLO also provides a set of services for transforming media from one format to another, which we would be able to leverage as part of the Pachyderm presentation publication process. As part of that process, we would need to be able to resize images, convert them into a Flash-friendly format, and compile them into Flash-wrapped media for use in the final published presentation. This process was a strong limiting factor in the scalability of Pachyderm 1.0, so the ability to generate transformed media on the fly, and on demand, would allow us to support a potentially unlimited library of media assets as part of the system.

Open Source

The Pachyderm 2.0 project was strongly oriented toward Open Source development. It had been a strong theme in the project from the proposal stage onward, in an effort to ensure collaboration from interested groups. We intended our development to be as open as possible, and to result in a strong set of source code that could be used and extended by others.

The initial development was kept within the core development team, in order to let us make some difficult decisions about the direction of the development effort, and to put together a coherent set of code to demonstrate our design principles. The source code and developer’s guide will be released to the public in the fall of 2005 under an Open Source Initiative (OSI) approved license.

Collaboration

• Pachyderm team composed of members all across North America (US and

Canada).

• Distance posed significant cost of intercommunication and collaboration,

as well as risk to the project.

• As part of process, team had to establish efficient means of

collaboration.

• Making plans for efficient collaboration involved many decisions:
  • Development platform
    • Expertise varied across the team in varying different platforms. The team had to decide upon a common platform that spanned the widest set of expertise.
    • Several iterations of system architecture using different platforms were designed and considered based on team experience, pros and cons of platform technology, etc. (can refer to original matrix)
    • In the end, Web Objects with Apollo frameworks was chosen as the development platform. The benefits of developer expertise and refactoring work already done for Apollo into the Pachyderm project were self-evident.
    • Team knowledge and expertise were maximized, with an emphasis on bringing the less knowledgeable members up to speed on the relevant development platform and architecture.
    • In choosing Web Objects as the development platform, Apple hardware became the obvious technology platform for development. The team standardized on Macintosh hardware, removing other risk factors during development.
  • Collaboration Tools
    • The mere fact that the project involved a number of developers necessitated some sort of version control. We decided on Subversion, the heir-apparent to CVS for a number of reasons:
      • http interface makes it very easy to access from remote locations.
      • Many applications very easily tie into Subversion, including XCode, the chosen development IDE.
      • CVS had a link to it on its home page
      • It¹s open source and free to use.
    • Distance pair/team programming required means of sharing a work space. VNC became an early adoption to the project, because it is open source, open standards, free to use, and very good. Many clients and servers are available on a multitude of platforms.
    • We also employed Instant Messaging on a daily basis, along with audio and video chat to accompany team programming sessions, to free the typing channel and to ease communications.
    • Tools such as SubEthaEdit allowed for joint editing of the same document without having to share an entire desktop, and also tracked contributions/changes from different members.
    • We maintained a wiki for keeping group institutional knowledge current and available/updateable by all members.
  • Communication process
    • Instant messenger became a life-line for team members to keep in touch with one another, to work together and share pertinent information.
    • Audio / Video Chat helped immensely in freeing up the hands to work while still communicating.
    • First bi-weekly, then weekly, then twice-a-week development team meetings helped keep us on track. We used an online free conferencing service (only toll calls) (http://www.freeconference.org)
    • Other communication tools were investigated, such as Macromedia Breeze
    • Email was also heavily used for intra-communication, but not as extensively as instant messenger. Usually reserved email to communicate with the whole team.
    • Pachyderm blog helped us communicate successes to the whole team and to the outside world.
  • Development methodologies
    • 'Pair' or 'Team' programming (borrowed from Extreme Programming)
    • Team code review.
    • A blurring of the line of ownership of any particular piece of code ­ everyone owns everything.
  • Scheduled face-to-face meetings
    • Any long-distance project necessarily must contain a component of face-to-face time. We managed to get the group together on the larger scale at project meetings, and during conferences at which many of us were in attendance.
    • In addition, team members would physically spend periods of time (typically a week at a time, every other month) on-location with other members of the team, to allow for social bonding, and for a more productive team-development environment. Sometimes nothing quite beats a bunch of people in the same room with a white board.
  • Analysis
    • What worked
    • What didn¹t
    • What could be improvements to the process.

Future Plans

When we started planning for Pachyderm 2.0 in October of 2003, we came up with a lofty vision of what the authoring tool could be. We have spent the last year and a half carefully pruning our expectations to define a goal that is both desireable and achievable. Our big ideas, however, have not gone away. They give the project places to grow.

We are actively seeking funding to continue development of the larger vision. While being proud of what we have accomplished so far, we feel that this project still has great potential. Once Pachyderm 2.0 is released to the public, we expect that user feedback will guide the development of features which the community truly values. Here we will describe a few of the features we hope to add on to Pachyderm in the coming years.

Template Creation and Customization

One of the acknowledged strengths of the Pachyderm system is that it comes with a set of professionally designed, pedagogically sound templates into which authors inert their content. None the less, early in development our team recognized that the twelve templates we provide would not be sufficient for every author in every situation. We envisioned three possible senarios in which authors might need to adjust the templates: 1.An institution or project already has an established style to which they want the presentaion to comply. The style might include particular fonts, background colors, or icons displayed within the templates. 2.An author's content would fit better into one of the base templates if the template could be slightly modified (e.g. allowing for four thumbnails on the right of the variety of media template instead of three). 3.An author's content requires a completely new template to be properly conveyed. As use of Pachyderm extends beyond the art world, we expect there will be a greater need for completely new template layouts. Knowing that such customizations would be needed, we were careful to architect Pachyderm 2.0 with a template-independent code base. Unlike the original prototype, we have ensured that adding a new template to the system will not require changes to the database structure or the authoring interface. It will, however, require a flash programmer to create the template. In future development, we hope to create a template authoring tool so that authors can easily customize and create new templates without knowing any flash programming. The template creation tool would rely on the component architecture that we have already put in place. Template authors would be able to select from existing components (such as image slots, text boxes, sliders, etc) and place them in their templates where they would like. They would also be able to copy the existing templates and customize them for specific needs.

Creating a Culture of Sharing

One of our more grandious visions for Pachyderm is that through skillful handling of digital rights, we could promote a culture of sharing among Pachyderm authors. Not every digital image can or should be shared, but there are many others that are already in the public domain, or could be offered up by their owners if they so chose. We would like to build a system that fully supports both models by distinguishing and enforcing different rights associated with different media. We believe that we can encourage sharing of digital media simply by asking authors when they upload their images and videos whether they are willing to share their media with others. We also hope to be able to distinguish between different user groups so that an author can share their work with colleagues at their institution, for example, but not the wider world. Another way we would like to facilitate sharing of media is by allowing authors to search and retrieve media from multiple different on-line repositories to which they might have access. By building a capibility for federated digital repository searching, we will provide authors with rich and varied selection of images and video to embed in their presentaions. We would also like to encourage the sharing of finished presentaions, in their entirety or on a per-screen basis. The sharing of presentaion sub-components will probably be taken care of through user permissions and group rights. A whole presentaion, however, could be shared though wrapping the presentation in standards-based metadata. We intend to use SCORM packaging for our current release, and look forward to adding options to import and export presentations in other formats.

Pachyderm Presentation Screens

Overview on Flash technology (very brief)

• Different versions of Flash
• Pro and Con for using Flash on the web
• Flash and instructional development

Flash used in Pachyderm 1.0

• 12 Templates
• Static contents and dynamic contents used in 1.0

Flash upgrade in Pachyderm 2.0

• New Challenges
  • Server side assets managements requires a better solution than plain text files
  • Assets managements inside of Flash needs to be more efficient
  • Multiple language support
  • More flexible templates required
  • Accessibility concerns
• Decision making process from Flash 4 player to Flash 6
  • Challenges in xml parsing
  • Challenges in modular design
  • Challenges in forward compatibility issues
• Changes being implemented
  • Preservation of the feel and look from 1.0
  • XML parsing
  • New navigational structure
  • WYSIWYG authoring capability (under development)
  • SCORM packaging

Challenges ahead on Flash

• Version Upgrades
  • Issues with Flash 6 and Flash 7 players etc.
• Accessibility
• Componentization
• Template redesign

Macromedia Flash is a popular application because it enables the professional media designers to easily create interactive and dynamic online experiences. The Flash Player has been well adopted in web communities because of its ability to produce small files facilitating the streaming of rich media content. Within an amazingly short period of time, it has grown to be the most predominant piece of web software. The newest studies indicate over 97% of internet users have the newest Flash players (V 7.0) on their computers. Non-computer based electronic devices such as Web TV, Pocket PC and some cell phones are supporting Flash files today. The secret of success is the small sized player (less than 500 K for Flash Player 7). The new Pachyderm presentation templates are completely designed in Flash MX 2004 and users are expected to have Flash Player 7.0 or above.

Flash based web presentations have many advantages over traditional html based web contents. The most valued benefit of using Flash to author web content is that it is browser and platform independent. The same Flash movie will look exactly the same cross-platform (Windows, Mac OS, and Linux) and cross-browser (Netscape, Internet Explorer, FireFox and Safari). This is very important for the online learning communities since educators and learners often have very diverse selection of hardware and software. However, Flash does have its weaknesses. Developers need to be aware of the version issue while developing Flash files. Similar to most software, Flash is not forward compatible (one can not run Flash 7 files on Flash 6 player). Another concern is that major search engines are still having trouble in indexing the content inside Flash based content packages. This makes the meta-tagging procedure and XML content aggregation so important while creating learning objects in Flash. This is a major reason for the Flash upgrade in pachyderm 2.0.

Pachyderm 1.0 includes twelve Flash templates created in Flash version 4.0. Since XML parser was not implemented at the time, variable based text files were used to accommodate the assets for the flash presentations. The text files were generated in ASCII standard encoding and meta-data was not adopted within the design. This means the authored learning objects are language dependent and reference limited. With additional considerations of forward design requirements such as templates modularization and learning object standards, the Pachyderm has decided to integrate the XML referencing model into Pachyderm 2.0.

In the new implementation, Flash MX technology is being used. Content aggregations on the presentation end are handled by XML files. Presentations are constructed by templates, and each template references a unique XML file. The Flash templates parse the XML files in order to fetch assets into the presentation. While serving the purpose of describing assets, these XML files are also being used for assets searching, template referencing and presentation meta-tagging purposes.

During the implementation of Pachyderm 2.0, a new issue was raised, should we expect the users to have the newest Flash plug-in? To be more precise, the debate was over whether we should raise the bar on the client side from Flash Player 5 to Flash Player 7. The later version of Flash have many obvious advantages over the previous versions, such as the upgraded XML parsing, better media support, maximum file compression, optimize sound quality and advanced object oriented handlers. During this decision making, the team strategically jumped over Flash Player 6 due to lack of compatibility support between Flash 6 and Flash 7.

With the up-to-date Flash support, Pachyderm 2.0 development team is enabled to fully integrate XML based learning standards (SCORM) with the learning objects authored using Pachyderm 2.0. The presentation will process the IMSmanifest XML file to lay out the navigation through the authored templates. IMSmanifest XML is the key file for SCORM 2.0 compliance learning objects. From this file, a navigational presentation map can be then generated. This key file also performs as a “messenger” to connect the learning objects with the learning management system (LMS) which will allow the institutions to fully integrate Pachyderm as a learning object authoring platform with their existing LMS.

The nest step in the Flash development of Pachyderm 2.0 is to implement the Model View Controller framework and componentized screen elements. This will allow other Flash designers/developers to generate new Pachyderm templates using pre-defined Flash components and not to worry about actionscripting. Following this stage, we are aiming to pass the template authoring wheel to the non-flash users. A truly WYSIWYG flash designing interface would empower the subject matter experts to directly author the templates that suit their needs.

[Please suggest if I should write in detail about how are we planning to SCORM package the LO and how does the WYSIWYG template authoring kit work, e.g. Liang's Frame editor] [will include 1-2 diagrams]