LSD CSI Audience Research

The audience research report contains information about how the project was run, what information we gathered and how the architecture evolved.

• Background information for CSI Discovery
  • The goal of the discovery project was to further develop the idea of a content staging system. It was undertaken by Phase2 Technology, Acquia, and Palantir with the goal of exploring and developing prototype designs and architecture documentation for content staging in Drupal 7 while designing a forward thinking solution that would be upgradable to Drupal 8 with minimal effort.
• What we collected from LSD Members
  • The discovery team engaged in three rounds of focus groups which verified we were heading in the correct technical direction. Early deliverables were presented to LSD members who provided questions and feedback on flow charts and early architecture recommendations
  • Final presentation of all discovery documentation - LSD members are going to be able to give more indepth feedback before development begins (currently scheduled to start June 11 and expected completion in mid-August prior to DrupalCon Munich)
    • Prototype: http://groups.drupal.org/node/229813
    • Technical/Solution Architecture: http://groups.drupal.org/node/229693
    • http://groups.drupal.org/large-scale-drupal-lsd-projects-and-plans/content-staging
• Evolution of the architecture during discovery
  • Very early in the process (even before discovery started) Acquia decided to only tackle single site workflow and preview because it would satisfy most LSD members. Multi-site deployment process and architecture would be handled on a per implementation basis because the use case was too specialized and the cost to build was very expensive
  • Additionally, the discovery team started off fairly workflow heavy but after several rounds of architectural review that involved participation from Neil Hastings and Roger Lopez from Phase2 Technology, Larry Garfield from Palintir and Angie Byron from Acquia, the team decided that this workflow problem had already been solved. Consequently, the discovery team decided to decouple workflow from the architecture by providing integration points instead
  • The interesting and unsolved problem was site preview
    • Initial approach was very abstract and tried to re-event everything
    • Current approach is now more modular and makes it easier to integrate with other Drupal modules for instance using Views to create override list. Deciding which version of content to load
  • Scheduling of collections was a requirement from the beginning but through discovery, the team made it more generic. Meaning, the proposed architecture solution is providing an API to expose bulk actions to content on a revision level. This expands from the core concept of node operations/actions to revision operations/actions.
• Why we are building this way
  • Designed to use more of what already exist in Drupal
  • Discovery team did not want to dictate an approach when we knew LSD members would want to customize. We are making a framework and following best drupal practices but at the same time not making limited assumptions on the implementation approach. Essentially, we are implementing the framework but building into the framework and easy way to make changes and customize
  • We are implementing architecture patterns from drupal 8 into drupal 7 to allow for maximum forward integration
• Requirements around dependencies for implementing the CSI framework
  • Platform must be on Drupal 7.2 or later
  • Workflow selection is module agnostic. Therefore;
    • The selected workflow module must control content on a revision level
    • There will be support for Workbench and State Machine
    • Other workflow modules can integrate by implementing the API of the Site Preview System
  • In order for content to work with the Site Preview System
    • If certain content is not revisionable it will not work with the Site Preview System. Nodes are already revisionable and within the scope of this project we will be making the following revisionable:
      • Any module that implements the entity_api’s revision API
      • Beans (and boxes) will be tested and working
      • Entity Field Panels
    • Note: Taxonomy (Needs core changes, probably not possible in D7).
  • In order for content to work with the Collection System
    • The content must be revisionable and an entity.