Recommended
Recommended
More Related Content
Similar to Energy.gov Case Study
Similar to Energy.gov Case Study (20)
Recently uploaded
Recently uploaded (20)
Energy.gov Case Study
- 1. Energy.gov Case Study Do It With Drupal October 12, 2011 Roger López
- 2. Energy.gov Roger López ‣ VP, Engineering ‣ Treehouse Agency ‣ Drupal.org member since July 2006 ‣ @zroger Do It With Drupal 2011, Roger López
- 4. Energy.gov Project Goals ‣ Consolidation of 100’s of sub-sites ‣ Sub-site creation should not require developer intervention. ‣ Content should be easily shared between sub-sites. ‣ Maintain a uniform style across all sub-sites. Do it with Drupal, 2011, Roger López
- 5. Energy.gov Drupal 7 ‣ Released January 5, 2011 ‣ Target launch date: August 4, 2011 ‣ Drupal 6 will stopped being supported in about 2-3 years Do it with Drupal, 2011, Roger López
- 6. Energy.gov What about contrib? ‣ Entities and fields ‣ DB API and EntityFieldQuery ‣ Image styles ‣ ... Do it with Drupal, 2011, Roger López
- 7. Energy.gov Organic groups ‣ Create groups ‣ Content is added to groups ‣ Users are members of groups ‣ Membership-based access control Do it with Drupal, 2011, Roger López
- 10. Energy.gov Group Type Do it with Drupal, 2011, Roger López
- 11. Energy.gov Group Membership Do it with Drupal, 2011, Roger López
- 12. Energy.gov OG Usage ‣ Group type ‣ Office vocabulary terms ‣ Group content ‣ Articles ‣ Pages ‣ Blocks* Do it with Drupal, 2011, Roger López
- 13. Energy.gov Not all terms are created equal ‣ Internal sites are groups ‣ External sites are not ‣ Otherwise the same Do it with Drupal, 2011, Roger López
- 15. Energy.gov OG Tasks Do it with Drupal, 2011, Roger López
- 16. Energy.gov http://drupal.org/project/og_tasks Do it with Drupal, 2011, Roger López
- 17. Blocks
- 18. Energy.gov Block Creator != Administrator Do it with Drupal, 2011, Roger López
- 19. Energy.gov User generated Blocks ‣ Node-like blocks ‣ Fields ‣ Templates ‣ Listing blocks ‣ User-defined filters ‣ Pre-defined styles Do it with Drupal, 2011, Roger López
- 22. screenshot of listing block example, with highlights like previous slide
- 23. screenshot of listing block example, with highlights like previous slide
- 24. Energy.gov Beans (Block Entities) Do it with Drupal, 2011, Roger López
- 25. Energy.gov Block Entities ‣ Block types ‣ Fieldable ‣ Simple data storage for settings ‣ Non-admin permissions ‣ Data entry is familiar to users Do it with Drupal, 2011, Roger López
- 28. Input form for a listing bean. Explain how non- field beans work.
- 30. Energy.gov View modes ‣ Previously called “Build modes” ‣ Provides multiple display options ‣ Out of the box ‣ Full content ‣ Teaser ‣ RSS Do it with Drupal, 2011, Roger López
- 31. Energy.gov Named styles ‣ Block teaser ‣ Related items Do it with Drupal, 2011, Roger López
- 32. Energy.gov Editorial listings ‣ Hand-selected listings of nodes ‣ Multiple Node Reference field ‣ View mode set in the Node Reference field settings ‣ Additional fields ‣ More link, Header text, etc. Do it with Drupal, 2011, Roger López
- 33. Energy.gov Block Placement Do it with Drupal, 2011, Roger López
- 34. Energy.gov Pages vs Nodes ‣ Users think about Pages ‣ Pages with only blocks ‣ Publishing workflow doesn’t include block placements Do it with Drupal, 2011, Roger López
- 35. Energy.gov Block References ‣ Block reference fields to emulate regions ‣ “Landing page” node types for each page layout ‣ Can be combined with other methods (context, core block module, etc.) Do it with Drupal, 2011, Roger López
- 40. Text fields
- 45. Context
- 46. Energy.gov Workflows Do it with Drupal, 2011, Roger López
- 47. Energy.gov Standard Workflow Do it with Drupal, 2011, Roger López
- 48. Energy.gov Standard Workflow ‣ Draft Do it with Drupal, 2011, Roger López
- 49. Energy.gov Standard Workflow ‣ Draft ‣ Needs Review Do it with Drupal, 2011, Roger López
- 50. Energy.gov Standard Workflow ‣ Draft ‣ Needs Review ‣ Approved Do it with Drupal, 2011, Roger López
- 51. Energy.gov Standard Workflow ‣ Draft ‣ Needs Review ‣ Approved ‣ Published Do it with Drupal, 2011, Roger López
- 52. Energy.gov Standard Workflow ‣ Draft ‣ Needs Review ‣ Approved ‣ Published ‣ Unpublished Do it with Drupal, 2011, Roger López
- 53. Energy.gov Other Requirements ‣ Workflow setup in code ‣ Exportable, API, etc. ‣ Multiple concurrent revisions ‣ Draft revisions subject to workflow ‣ Published revision is not editable Do it with Drupal, 2011, Roger López
- 54. Energy.gov Options ‣ Workflow ‣ Rules ‣ Workbench moderation Do it with Drupal, 2011, Roger López
- 55. Energy.gov StateFlow Do it with Drupal, 2011, Roger López
- 56. Energy.gov Revisions ‣ New nodes start as Drafts ‣ Published revisions are not editable ‣ Editing a published node creates a new draft revision ‣ Publishing a revision archives the current revision Do it with Drupal, 2011, Roger López
- 57. Energy.gov Do it with Drupal, 2011, Roger López
- 58. Energy.gov New Draft Do it with Drupal, 2011, Roger López
- 59. Energy.gov New Draft Reviewed Do it with Drupal, 2011, Roger López
- 60. Energy.gov New Draft Reviewed Published Do it with Drupal, 2011, Roger López
- 61. Energy.gov New Draft Reviewed Published Edit New Draft Do it with Drupal, 2011, Roger López
- 62. Energy.gov New Draft Reviewed Published Edit New Draft Reviewed Do it with Drupal, 2011, Roger López
- 63. Energy.gov New Draft Reviewed Published Archived Edit New Draft Reviewed Published Do it with Drupal, 2011, Roger López
- 65. Energy.gov API First ‣ 100% implementable from code ‣ State Machine ‣ Customize by extending ‣ Workflow ‣ States ‣ Events Do it with Drupal, 2011, Roger López
- 66. Energy.gov http://drupal.org/sandbox/ fmitchell/1298244 (waiting for approval) Do it with Drupal, 2011, Roger López
- 67. Energy.gov Data Visualizations Do it with Drupal, 2011, Roger López
- 68. Energy.gov Front-end Front-end Drupal Front-end Libraries Libraries Integration Libraries DataViz DataViz Adapters Format Do it with Drupal, 2011, Roger López
- 69. Energy.gov Libraries ‣ jqPlot ‣ jqplot.com ‣ The Jit ‣ thejit.org ‣ High Charts ‣ highcharts.com Do it with Drupal, 2011, Roger López
- 70. Energy.gov { "series": [ { "seriesName": "series1", "data": [ [2,1], [4,2], [6,3], [3,4] ] }, ], ... Do it with Drupal, 2011, Roger López
- 71. Energy.gov "options": { "title": { "text" : "A test bar plot." }, "description": {"text" : "A test description."}, "pointLabels": { "show": true, "location": "e", "edgeTolerance": -15 }, "barDirection": "horizontal", "seriesOptions": [], "legend": { "show": false, "location": "s" Do it with Drupal, 2011, Roger López
- 72. Energy.gov Do it with Drupal, 2011, Roger López
- 73. Energy.gov Do it with Drupal, 2011, Roger López
- 74. Energy.gov Do it with Drupal, 2011, Roger López
- 75. Energy.gov Do it with Drupal, 2011, Roger López
- 76. Energy.gov Do it with Drupal, 2011, Roger López
- 77. Energy.gov Do it with Drupal, 2011, Roger López
- 78. Energy.gov Do it with Drupal, 2011, Roger López
- 79. Energy.gov Do it with Drupal, 2011, Roger López
- 81. Energy.gov Resources ‣ Bean http://drupal.org/project/bean ‣ OG Tasks http://drupal.org/project/og_tasks ‣ DataViz Javascript Adapters http://github.com/treehouseagency/dataviz-adapters ‣ Data Visualization API for Drupal http://drupal.org/sandbox/LSU_JBob/1299606 ‣ StateFlow http://drupal.org/sandbox/fmitchell/1298244 Do it with Drupal, 2011, Roger López
Editor's Notes
- \n
- \n
- \n
- \n
- \n
- \n
- For the sub-site architecture, we turned to Organic groups.   A quick overview of OG: OG is a module that lets you specify groups, group content and group membership.  Users can be members of groups, and can create content within those groups.  OG can also limit access to content based on group membership, thereby sectioning off the site into separately mantained sections.  This fit very well with our requirements to have different editors for each office.\n\n
- OG got a major rewrite for Drupal 7, meaning that no longer are you limited to using only nodes as the basis of your groups.  \n\n
- In OG 7, groups are simply entities which have this field enabled and selected. Any fieldable entity can be a group, including, but not limited to nodes, taxonomy terms and users. \n
- In OG 7, the groups audience field can be added to any fieldable entity. The audience field adds creates a membership record for the entity in each selected group. This is the way user membership is handled, as well as content association.\n
- This is how we’re using OG on Energy.gov. Since the sub-sites always felt like categorization of content to me, we used a taxonomy term for the sub-site group entity in the Office vocabulary.  Although this still feels right from a schema standpoint, technically nodes are still better supported by OG. Pretty much all other node types, as well as custom blocks are assignable to groups.\n
- \n
- \n
- To assist with the initial setup of groups, we created the OG Tasks module.  This module allows developers to create automated tasks that can be run against the specified group.  Some of these tasks are optional, and can be run after the group is created.  Other tasks are required, and will be run automatically when the group is created.\n\n
- \n
- Remember when I told you that blocks could be specified as group content. That’s not entirely true.\n
- This site was going to have hundreds of blocks, which needed to be created by normal CMS users. How do we allow users to create blocks without granting them administrative access?\n
- \n
- Here we see 2 “Graphic” blocks. If these were nodes, we would immediately know how to build these. A title, an image field with a link, some body text. Then we style the template, or perhaps if the template isn’t too complicated, we just select the appropriate field formatters for this view mode. But these aren’t nodes, they’re blocks.\n
- \n
- \n
- \n
- Bean exposes blocks as a new type of fieldable entity.  Creating new block types and adding fields is as easy as creating new node types (screenshot of block type admin).  Use the display settings for the blocks to control the display output, just like with other fieldable entities (screenshot of “display fields” tab).\n\n
- \n
- Bean types can have custom logic and settings forms.  With this functionality, we created simple listing blocks that give CMS users the ability to create custom filtered lists.  The article listing bean has filters for the Article type taxonomy, the Topic taxonomy and the Audience taxonomy.  It also has options for the title, number of articles to display, link to use for a “more link” and an option to group the results by date (screenshot of article listing edit form).  These options give the users the ability to quickly create special purpose blocks that list, for instance, the latest 3 articles of type “blog”, which are in one of the solar, wind, or geothermal topics and are targetted towards the “homeowner” audience.  \n\n
- \n
- As for display, there is a View Mode option, which controls the output of the nodes being listed.  This empowers the users to select one of several predefined styles, ranging from a simple linked title, to a more complex display with title, teaser, thumbnail and date.  (screenshots of same block rendered with various view modes)\n\n
- \n
- Here’s a quick recipe that we used a lot on the site. It is very easy to implement and your users will love it.\n
- So now that we have all of the blocks, how do we place them? We’ve made block creation a non-admin task, how can we do the same for block placement?\n\n\n
- Now that the users can easily create blocks, they need an equally simple way to place these blocks on pages.  The problem with the most common methods for block placement (block.module, context.module), is that they are largely considered administrative tasks, not something you would allow a typical CMS user access to.  But most CMS users think of “pages” not nodes, especially for “landing page” type content.  Nodes typically consist of the “content” portion of the page.   Pages contain the main content, but also the blocks on that page.  Pretty much everything but the truly common elements like the header and footer.  (wireframe showing the node vs page concept)\n\n
- Using the Blockreference module, we were able to match our node creation workflow to the expectations of the users.  We created many different types of “landing page” content types, each representing a different layout with different block placement options.  Many of the have no other fields besides the block references.  (screenshots of different layouts, marked up to show block reference field regions)  Templates and these faux regions are marked up in the node template and css.  These do not integrate with standard regions.  We are also combining this method with the standard methods, namely using the context module.  We use the context module to place the common blocks, that should not be managed by normal CMS users.  \n\n
- \n
- \n
- \n
- \n
- \n
- \n
- Here we have not only block reference fields, but additional text fields to use as headers for the groupings.\n
- Here we have not only block reference fields, but additional text fields to use as headers for the groupings.\n
- Here we have not only block reference fields, but additional text fields to use as headers for the groupings.\n
- Here we have not only block reference fields, but additional text fields to use as headers for the groupings.\n
- Here we have not only block reference fields, but additional text fields to use as headers for the groupings.\n
- Here we have not only block reference fields, but additional text fields to use as headers for the groupings.\n
- Here we have not only block reference fields, but additional text fields to use as headers for the groupings.\n
- Here we have not only block reference fields, but additional text fields to use as headers for the groupings.\n
- Here we have not only block reference fields, but additional text fields to use as headers for the groupings.\n
- Here we have not only block reference fields, but additional text fields to use as headers for the groupings.\n
- Here we have not only block reference fields, but additional text fields to use as headers for the groupings.\n
- Here we have not only block reference fields, but additional text fields to use as headers for the groupings.\n
- Here we have not only block reference fields, but additional text fields to use as headers for the groupings.\n
- Here we have not only block reference fields, but additional text fields to use as headers for the groupings.\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- We evaluated several options for tools to accomplish this workflow.  In addition to the ability to supply this workflow, we were also looking for a module that would allow us to easily put the workflows in code, possibly by creating the workflows from the install profile or a module install file, either via an exportable mechanism, or a clear API.\n\n
- Workflow - no drupal 7 version.  The drupal 6 version, which we had worked with before, has a pretty complicated interface, and lacked any sort of exportability or install API.  \nRules - Drupal 7 version available, and exportable via ctools/features.  No readily apparent way to deal with the revisions issue.\nWorkbench Moderation - This seemed to be a good match to our required workflow, but at least at the time we started development, it was very young and lacked any sort of install API or exportability.\n\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n