A journey from Foundation CSS to Tailwind CSS

All of our frontend websites start with this base repository which can be viewed at https://base.wayne.edu/styleguide/childpage. It has evolved in many ways since its closed source version to the new public version 5. One thing has remained the same, the whole time is being dependent on the Foundation CSS framework.

We used Foundation when we first started exploring responsive design in 2012 for these reasons:

  • The grid was easy to use and understand
  • Fast scaffolding for wireframes
  • Included many Javascript packages out of the box that we found useful (accordion, offcanvas, sticky header)
  • Ongoing support of bug fixes and new major versions
  • The framework didn’t have an opinionated style like Bootstrap

Why did we move away from Foundation?

The biggest drive for us to switch to a different framework was how hard it was for us to upgrade from even minor versions of the framework. It’s not a knock on Foundation as we consider it a wonderful framework. The custom CSS/JS we wrote on top of everything played a large role in making the upgrade a difficult task. The slightest changes to their default CSS or javascript components made it extremely time-consuming for us to realign base to accommodate for those changes. A related issue is the cascading part of CSS. While it’s extremely useful, it’s also a large hindrance to the maintenance of a project long term. Adam Wathan wrote a really good blog post explaining this very issue.

What did we move to?

Tailwind CSS. The concept of using a utility-based framework is having a class name that does one CSS property and value. You can think of it as doing inline styles on each element, but what makes it different is you control all the values of colors, sizes, widths, and heights in a single settings file. This creates more consistency, better naming conventions, and a pattern to your CSS names.

What it allowed us to change

Once we switched over to Tailwind CSS it allowed us to start looking at replacing other parts of Foundation that we relied on. Here is a list of changes:

What are the stats for the childpage template?

File Base 4 Base 5
requests 14 9
load time webpagetest.org 1.481s 1.117s
css 18.1 KB 10.4 KB
javascript 27.9 KB 21.2 KB
html 6.4 KB 8.4 KB
total size 133 KB 82 KB

We managed to lower the overall size by a 38% reduction! The only file that slightly increased is the html which was to be expected since we introduced a lot of new classes.

We’re excited for the future of our base site project knowing we can easily swap out any packages now or upgrade them without affecting the entire site.

Redesign: Academic Senate Website

academic-senate-oldacademic-senate-new

We recently launched a redesign of the Academic Senate website.

The previous site was a framed website and managed by hand. Since the site isn’t overly complex that workflow was efficient for a long time. There were a few barriers to that approach, though, and the Academic Senate came to us for help with a solution.

What we came up with is a fully responsive website managed through the university’s central CMS and automatically pulls in data from across campus. A few key features of the new site include:

Built on Foundation 5

As we evolve our responsive approach we have settled on Zurb’s Foundation framework. It is light weight, flexible and allows us to extend it where needed without having it feel like a “Bootstrap” site.

Membership lists using CMS profiles

A big part of the Academic Senate website is broken down into committees and related information. Since the membership of these committees changes over time, and people can be on multiple committees, managing this information can be cumbersome. We transitioned each member into the “profiles” area of the CMS where they can be associated with multiple committees if needed and the information can be managed by the people themselves or by the Academic Senate staff with just a Web browser. They can be updated once and published across the site.

Profile images and content pulling from existing sites

Almost all Academic Senate members already have existing profiles on their school/college/department websites. We didn’t want to duplicate this information so we pull their existing profile information to reduce redundancy. When the member updates their profile, it will automatically update on the Academic Senate website.

Under the hood

A few things you won’t notice is we are standardizing our build process with new sites. We have a Yeoman site generator that we use as a base for each project. Next, we’re using Grunt (soon to use Gulp) as our “build” step to check and compile all assets into their appropriate folders. This not only reduces the initial project build time but also separates source files from their rendered machine optimized results. On that same spirit we have begun to deploy sites in a standard way to speed up the process and reduce the possibility for mistakes.

View the new Academic Senate website at: http://academicsenate.wayne.edu/

Redesign: Division of Development & Alumni Affairs websites

Last week we launched the redesigned Division of Development & Alumni Affairs websites. These sites allowed us to accomplish some firsts that we’ve been working toward for some time.

The overall goal of the redesigns was to bring both into a similar look, feel and functionality. Previously, both websites were managed separately, in different content management systems and servers. They were not able to share content and the Alumni website didn’t utilize university resources. We set out to change all that and more.

Division of Development

giving-old-home giving-new-home

Over time the needs for the Development website had changed and we needed to refocus the homepage and the content within the site. The first thing that we changed from the old (left) to the new (right) was the centerpiece focus. We brought the stories that were buried and put them up top, front and center. These stories are what change the heart and mind of alumni and donors. The homepage highlights a handful of stories but we built a full donor stories archive where all will be available long term.

We then pulled the news and events up, but also created a clear left column for calls to action. This simple homepage gives the visitor an overview of what is going on while at the same not being overwhelming.

Alumni

alumni-old-homealumni-new-home

The Alumni website is actually two websites, the front facing homepage and a separate members-only community. The focus of our project was to reconstruct the front-facing site while giving a small facelift to the community. Keeping with the same overall feel of the Development website we kept the homepage simple. Alumni engagement events are highlights in the main centerpiece area, three main calls to action are highlighted in the middle and below a list of news, events and longer standing promotions.

The largest change though to the Alumni website was the information architecture. Between the time we started the project and finished, the university changed from a dues-based alumni model to a free one. This change had us and the Alumni staff re-thinking the purpose of every page on the site. It resulted in far fewer pages but the ones that remain are very focused.

Mobile and other firsts

giving-new-mobilegiving-new-child

I made an announcement a few months ago about only launching responsive websites from here on out and we are committed to that. This site started far before that announcement and was the first start we tailored to mobile from the ground up. The wireframes, designs and everything for this website started and continued in the browser environment instead of isolated in Photoshop. The end result is a very usable site on mobile, tablet and desktop, and we learned a lot along the way.

The first thing we tackled is how to handle multiple tier navigation without overwhelming or underwhelming the user. I’ve talked a lot in the past about how 60 percent or more of site visitors enter on an interior page and how to design the best experience around that. Those visitors need to orient themselves quickly with where they are on the site and where they can go from there. We wanted to keep the same approach we take with desktop websites, allow the user to get a sense of where they are at a glance and identify the local navigation quickly. We came up with a simple solution: on a small screen show the breadcrumbs of where a user is on the site, show the most local menu expanded up top, and give the visitor a “Menu” button to expand the full top menu. See an example, above, of the small screen (left) vs. full desktop version of the same page (right).

In addition to the mobile-first responsive design, these two websites are the first to feature a new global Wayne State University header that is also responsive. I will probably do a full post on it once it’s officially released. We are still working through a few specific browser quirks. But overall we were able to reduce the HTML, CSS, and image footprint of it by about 60 percent of the previous header. It only includes a single image, utilizes the same icon font that is used on the pages themselves and is fully responsive.

Lessons learned

Because our redesign projects typically span 9-12 months from initial meeting to launch, that leaves a lot to happen in the Web world. This website is no exception, over that span of time the CSS framework we used, Foundation, for the wireframes and the resulting design, updated from version 3 to 4 and changed completely (for the better) the way it handles HTML and CSS. By the time that happened we couldn’t go back and redo everything. The biggest lesson we learned from this was we have to be nimble when it comes to locking ourselves into a single framework.

ie8-usage-giving

The biggest lesson we learned though was about browser support. Most all of the newest Web technologies are supported fully only in the newest browsers. This isn’t a problem for most (95 percent+) of our external website visitors. But the world of higher education is filled with large enterprise systems that our campus relies on every day. Unfortunately those systems are slow to update and support those most recent browsers and thus there are a larger portion of computers on campus running older versions of browsers (read Internet Explorer 8). Recently a rash of Web technologies have begun to drop IE8 support, the Development and Alumni websites were not immune to that speed bump. So we had to put in an uncomfortable amount of small bug fixes and ended up relying on respond.js to bandaid the situation until we see IE8 visitors drop off enough. I’m hoping to have an official announcement soon about what are browser support will be long term.

View the sites: http://giving.wayne.edu/ and http://alumni.wayne.edu/