The Future of Drupal and Content Delivery
Let’s take a look back When we first started building websites, we would open up notepad and just write HTML tags to create websites. <html> <head> <title>My Great Website</title> </head> <body> <h1>My Great Website</h1> <p>This is my great website</p> </body> </html> Then we added CSS and JavaScript to help with layout and basic functionality. We would then save them in static files (.htm/.html, .css, .js) and then serve them over the web with other media files.
June 2000 – www.yale.edu
What if we needed a little extra functionality? What if you wanted a contact form that emailed you or read rows from a table in a database? HTML could not provide that functionality for us. Scripting languages such as Perl and PHP would allow you to do this. Usually the script file would be mixed in the HTML code to display text or process inputs. While HTML was not too difficult, you usually had to either learn to program in a language, buy premade software or hire a vendor to build these. Any changes would usually require some time for programmer to implement.
The birth of the content management system Well, actually, they have been around for quite a while. They have evolved with the web. CMSes like Drupal and WordPress have allowed us to build up websites, without having to know all the HTML, PHP and database queries needed. The module system allowed us to easily add more functionality. While there was a bigger time investment up front, management and modifications were easier to manage going forward.
We only had to worry about desktop computers When building out the layouts for our sites, we used to only worry about what they would look like on a desktop computer. Our conversations and decisions consisted of monitor resolution, Windows vs Mac (mostly Windows), and how it looked on IE5/6/7 & Firefox (maybe Safari). We would create overly designed layouts that looked great desktops. Any interactive elements would usually be done in Flash and embedded on the websites.
Then came the iPhone… The iPhone was released in June 2007 and changed the way we consumed web content. Apps were now available and gave us interactive content. The mobile safari browser screen was much smaller and you were not able to use a mouse pointer. Navigating webpages on an iPhone proved to be a challenge. The web community was not exactly ready.
…and Responsive Design followed One of the first techniques that came about was creating a separate mobile website. Most domains had an m. for the mobile site. This created management headaches as you had to maintain two sites. You would have to usually detect the type of device and browser to serve the correct site. Responsive design allowed us to create one site that would respond to the screen size and adjust accordingly.
June 2016
What’s next? We already have desktop and mobile. What is the next step? There are many internet connected devices out there such as TVs, refrigerators, VR headests, sensors and many more. These items are internet connected and are able to receive data.
Headless Drupal Drupal is beginning to recognize that developing a pure browser front-end is no longer viable. Starting with Drupal 8, they are allowing content to be exposed via an API interface. This will allow anything from single-page applications, mobile apps, VR headsets to be able to consume this data.
Examples of use for Headless Drupal Your department has a large screen display that is shown outside your building. You can use Drupal to power the content that is shown on the screen. Allowing students that have your mobile app to get notifications of events such as an upcoming speaker. You captured a 360 degree image of a historic site. You then use Drupal to power the text/annotation content that is displayed alongside the image.
The direction the YaleSites team is moving We want to be where the end user experiences are! YaleSites wants to help power those experiences. It is important for staff & faculty to understand how to build their content in Drupal.
Demo & Discussion!