Monday, August 11, 2014

Responsive Design Next Level: Entirely Modular Pages

You may have heard we are converting the Tarleton website to responsive design via our Project Squishy website. A lot goes into designing a new website, its layout, functionality, and interactivity, so we decided to provide you with a window into the designing and programming process involved in this very complex project. You may have already read Ernesto's post on our design for the new search engine and what he did to program it (if not, go check it out!). Today's post is going to be more focused on what you will be able to do with the new responsive design in Cascade Server, our Content Management System (CMS): modular pages.

How We Got Here

Before we moved to a CMS, web maintainers were able to design their websites, sometimes with the assistance of Web Services for website layout:
  • Full control: Maintainers control website layout and content
    • Adobe Dreamweaver
    • Microsoft Frontpage
    • Mozilla Composer
  • Partial control: Maintainers control content in an editable region on each webpage
    • Adobe Dreamweaver
    • Adobe Contribute
A screenshot of the Financial Aid website as seen in the Layout view of Cascade where editable regions are shown as three columns on the page.
Three editable regions on one of the first
page layouts made available in Cascade.
Web marketing strategy was very lax at that time, since everyone was able to set colors, logos, navigation, and content up any way they wanted. When President Dottavio came on board, though, he wanted to improve the marketability of our degree programs and usability of the Tarleton website, so he directed Web Services to approach websites in a consistent manner, look and feel. This would, in turn, help us also meet legal requirements regarding accessibility of content, security of information, and intellectual rights of content owners.

Our solution moved us into Cascade Server where web maintainers have control over smaller editable regions of their web pages. We started out very basic, since users were already used to a large editable region on each page and called us to help update the navigation. Many of them had full control of their websites before, so they had access to do much of what they did before, however, not every web maintainer is tech savvy. We wanted to give our web maintainers more control without making them learn how to program a web page, a simplified approach to content updating and web page creation.

A screenshot of the Band website as seen in the Layout view of Cascade showing the complexity of a modular page.
Multiple editable regions are available in modular pages,
however, depending on the programming needed,
Web Services has to maintain specialized modules.
We started to create more specific pages to meet those needs, such as:
  • frequently asked questions (FAQ)
  • faculty/staff listings
  • news listing
  • many, many, many more
This wasn't enough, either, because web maintainers needed content before and after a FAQ or maybe two FAQ sections, or a FAQ and a news listing all on the same page.

The Need to Change Course

Each new page we created made building a new website a longer process. What pages do the web maintainers need? Does Web Services need to build each page that could be possible? Does Web Services need to program more specialized pages each time a web maintainer requests the content modules be placed in a different order on a page?

This is when I started pondering modular pages, a way for web maintainers to decide what content module (i.e., FAQ, news listing, directory listing, or basic content such as paragraphs, lists and tables) goes where without worrying about programming any of it.

With the new design in Project Squishy coming into view, we weighed the good and bad of modular pages.


  • Web maintainers will be able to update content modules without programming skills.
  • Content modules can be arranged on a page in multiple ways without requesting Web Services create a brand new page layout.
  • Content will be created more accessibly without extensive training for the web maintainers.
  • Screenshot of the content modules that make up the Tarleton homepage's main content section.
    Content module folder containing the content modules
    (or blocks) linked to the Tarleton homepage
    that make up the main content area on the page.
  • Web maintainers will have the assistance of Web Services to provide recommendations of best practices for content.


  • New pages will be created initially by Web Services, not the web maintainers. 
    • Upside: Web Services will consult with maintainers on content strategy for the pages first, so web maintainers will only need to update content, not worry about layout.
  • Editing a page will really mean editing content modules that are located in content module folders separate from their pages. This will be a new process for almost all web maintainers who are used to clicking on a page inside Cascade and then clicking the Edit tab for that page.
    • Upside: Content modules are re-usable, so a number of maintainers who may need content they don't personally own can include other maintainers' content modules as opposed to duplicating content. This cuts down on outdated information available on Tarleton's website and the time it takes to make duplicate copies of content.

What Content Modules Will Be Available in Project Squishy?

There are well over 200 options for modules on our current website, however, a majority of them will not be transferable to the Squishy website.

Many are based on program scripts that are no longer maintainable, such as a number of our slideshows, because their program authors dropped these projects. Think of it like anticipating what you will be able to still use when Apple or Microsoft pushes out a new operating system. Software companies have to make updates to their applications to make them compliant and functional with the newer operating systems, but if those software companies go out of business, the software becomes obsolete.

A screenshot of an unresponsive feature we will not be implementing across the website.
The Tarleton F.O.C.U.S. uses a light box feature that is actually unresponsive (does not properly change dimensions depending on screen size or device orientation). The scope of this solution is limited to the homepage due to the complexity of the programming required.
Other modules just do not function on a responsive level, so they would be inappropriate to move over to the new design layout. For example, a light box (as seen on the desktop version of our website when clicking on a testimonial or picture on the Tarleton F.O.C.U.S.) is not responsive because it tries to (a) provide the entire content in a predetermined shaped box that cannot be reshaped or moved and (b) center it on the page, however, screen dimensions differ across devices. The solution we pulled off for the Tarleton F.O.C.U.S. only works because the content is connected to a database that dynamically generates pages for mobile phone screen sizes. If we implemented the same solution across the website, since our web maintainers do not have database access to store images, we would have to create each and every page for the individual images.

So What Can We Expect in Project Squishy?

Screenshot of responsive directory listing content module.
Mockup of redesigned directory listing that is responsive
on all devices and seen here as the mobile version.
We are doing a lot of research on what modules would work for our website and our users. We will start with a small set of options and add more when we are able to build them. Each one requires a lot of planning because we are trying to determine their behavior on varying screen sizes. You've already seen some modules on the homepage that are being considered for use on the rest of the website:
  • Highlights: a rotating set of pictures linked to valuable information or calls to action
  • Slideshow: a rotating set of pictures and their captions that can be used for testimonials as well as calls to action
  • Calendar: currently linked to content automatically generated from the Online Calendar System, our plan is to also include a manual feed for websites that don't have specific categories of events related to them.
  • Statistics: a rotating set of pictures and stats that show off the points of pride for any department or program.
  • Testimonials: currently only one design for testimonials is available. This version is a panel with a huge quote and a picture of the person cited. A new one will be available that rotates through multiple testimonials on the side of textual content.
However, we're missing the most important modules that focus on textual content. We are creating some with options for adding pictures, colorful blocks of content (asides), rotating content on said colorful asides, and more (see the above new directory listing). As we get ready to finalize modules, I'll post the new ones.