Building websites for scientists, the management and the public: An example from CERN

The session will be devided in 4 parts: 
 
Part 1: Getting specifications: an approach to bring a number of very smart people in a room and go away with a plan everyone agrees on. 
 
Specifications are always one of the hardest parts of any technical project. In the scientific world, where consensus is vital, one can find themselves in need of multiple approaches in order to please everyone. In this part I will use my experience building websites for the CERN Physics department as an example to provide some tools for extracting and freezing specifications.  
 
Part 2: Populating the pages: ways to gather content and feedback. 
 
After the design process the next vital collaboration one has o handle is the initial content. In some cases this can be found from existing resources. When one deals with scientific content though, such as a large Physics Laboratory, the existing information is rearly 100% up to date. Additionally updating this content requiers deep understanding of the subject at hand and therefore can only be handled by the experts. In this part I will share workflows that help keep people accountable and on track with the content creation.  
 
Part 3: Proactive workflows: destributing editing work in the most efficient way. 
 
Without constant effort, a website can be outdated the very second it goes live. When this site represents teams of people, or even collaborations, finding the correct person who has the information, the time and the competency to update them can become a chaotic process. For that one needs to provide comprehensive and sane workflows along with the website. In this part I will take as an example a Drupal 7 website from 2014 and it's migration to Drupal 8 in 2018. I will explain the challenges that the group faced maintaining it, and how we solved them in the next migration. 
 
Part 4: Finalization, training and documentation: making sure everything is intuitive so none will be tempted to hack their way through. 
 
After finishing a website and pushing it into production, the editing team takes over. It is vital in that time to leave behind a comprehensive documentation and train all the people involved, either physically or with tutorials left behind, in order to ensure smooth operation. I am in the unique position to have made a few websites and still work for the same team while those sites are online. It is therefore easy to observe the issues faced by each team or person when they are left with my work. In this part I will give examples of the documentation and training material that have helped our teams keep up with Drupal. I will explain different approaches taken for different backgrounds: scientists, programmers or administrative personnel.