Skip to content

Wayne State University

Aim Higher

Mar 9 / Nick DeNardis

Next Web workers meeting – March 20, 2015 – Accessibility

RAVPDo you manage a school/college/departmental website that represents the university? This meeting is for you.

Come share your successes, failures, questions and lessons learned with other Web workers from around campus.

This meeting’s agenda includes:

  • Matt Ouellett from the Office of Teaching and Learning will be facilitating a group discussion to create a Web accessibility working document
  • Round table

Everyone is welcome and encouraged to share their experiences.

March 20 at 10:30 a.m. in the Simon’s Room, 144 Purdy Library

RSVP is not required but suggested.

Jan 13 / Nick DeNardis

Next Web workers meeting – Feb. 6, 2015

RAVPDo you manage a school/college/departmental website that represents the university? This meeting is for you.

Come share your successes, failures, questions, and lessons learned with other Web workers from around campus.

This meeting’s agenda includes:

  • Elliot Polak talking about the recently redesigned Library System website and how their team has worked to improve the site since the initial redesign in August.
  • Nick DeNardis talking about front-end workflow and speed optimizations.
  • Round table

Everyone is welcome and encouraged to share their experiences.

Feb. 6 at 10:30 a.m. in the Simon’s Room, 144 Purdy Library

RSVP is not required but suggested.

Jan 9 / Nick DeNardis

Welcome Jenny Ingles – Our new full-time front-end developer

Our team has changed shape a bit in the last year, especially in the role of front-end development. The primary role of a front-end developer is to “create the best possible user experience for features on desktop and mobile Web.” For us, that means translating the information architecture, design and content to HTML, CSS and Javascript to bring it to life. Because there is no medium like the Web this is a pretty unique task and always a moving target.

In previous years we had three full stack developers who were responsible for the entire programming of a site from the database data binding to the performance and accessibility of the user experience. It became pretty clear last year that doing everything was spreading them thin and we weren’t able to accomplish the fine grain optimization we were used to. So we decided to split the developers into front-end and full stack roles. The full stack developers still had knowledge of the front-end but their primary focus was university tools and optimizing the data in and out of our API. The front-end roles can spend their time optimizing every pixel that the end user interacts with.

Welcome Jenny Ingles

After months of searching we have found Jenny Ingles, our new front-end developer. Jenny comes to us from St. Louis and has extensive background working with HTML, SASS, Javascript, and Illustration. She has brought a fresh eye to how we structure our code, approach problems, and testing. Since she has started to get involved with projects our code has not been more semantic, page weight has decreased, and the user experience is the quickest yet.

It has taken me a few months to make this announcement on our blog and in the meantime you have probably been browsing her work and not even realizing it. Recently she worked on the front-end of the following projects:

Pivotal Moments


For her first project, a website that was already architected and designed, she was thrown in with a pretty PSD and told to make it work. Not only did she break it down technically but also worked very closely with the client at every step to educate on expectations, opportunities that the Web as a medium brings, and responsive implications. What came out of all that was an implementation that was not only within budget but also looks and performs beautifully. Browse around the Pivotal Moments website and see for yourself.

College of Fine, Performing and Communications Arts


Jenny got her feet wet with our workflow, process, and structure using our Yeoman Foundation 5 site generator (not public yet). With this she was able to add some new features to the site. The homepage of the College of Fine, Performing and Communications Arts features some uniquely positioned areas with semantic HTML, parallax scrolling and CSS 3. 

The Baroudeur


In the same line with the CFPCA website, Jenny built upon her knowledge to not only include parallax scrolling but also responsive background video. Although the background video didn’t make it into the first launch of the website, we hope to find a video in the future that meets everyone’s needs.

Student Service Center wait times


In addition to full scale website builds, Jenny also has been working on the little big details that make the user experience a little more enjoyable. For the Student Service Center she added visual elements to highlight the important information at a glance. In addition, the tabbed view for hours brings the relevant information into initial view and secondary information a click away without scrolling or a refresh. Below that, the frequently asked questions are now within an accordion so they are easy to scan and quick to jump between. An improvement that didn’t revolutionize the page, but made a useful page more of a joy to use.

Art & Art History (upcoming)


Although it isn’t live yet (hopefully soon and I will update this post when it does launch): the Art & Art History department website. Another soup to nuts website that Jenny was involved with that really shows off the attention to detail. This site was build on our Yeoman site generator (which means it is a standard starting point for all future sites) and lazy loads hidden images/content, changes design naturally at different breakpoints, and utilizes icon fonts as much as possible. It also features something I have yet to talk about, progressive enhanced page loading with YouTube’s SPF JS. This is something we have been playing around with for a bit and this site shows off how we have nicely adapted it to our Web experience. We can’t wait to show you the final website, which should be available shortly at

Just a few short weeks

This is just a snapshot of what we’ve done in the last few weeks. We don’t believe we’d be where we’re at without Jenny. Let’s give her a warm welcome! We can’t wait to see what she’s able to accomplish in the next few months.

Jan 5 / Nick DeNardis

Life in Web Communications, then and now

A lot has happened over the last 10 years that I’ve been in the Web Communications department, but looking back it made me realize how much has changed just in the last year.

I thought I would break down some of the basics to put it in perspective:

Then Now
Relied on multiple methods of contact: Basecamp, email, and a shared inbox. Now using a true ticket system, TargetProcess. All support and project related activity is in one place.
Used Campfire for group chat which was limited to just our department. Now we use Slack which allows anyone around campus to join so more people can be on the same page throughout the day.
Almost everyone was working at a desktop computer. Now most work is done on laptops, in shared spaces, and as much as possible, with the client.
Coffee was the drink of choice for the office. Now it seems most people have converted to tea.
Down a few staff members for various reasons and thus not able to take on the amount of work we were used to. Now fully staffed and back up to speed with all projects. Almost each positon has a ‘pair‘.
Our development stack used to be all over the place with MAMP, Ruby and Gem requirements unique to each machine. Now everyone is running the same Vagrant image which can be replicated in just a few steps. Bringing up a new computer now takes minutes instead of hours.
We used to host all our code in SVN which is great for a single project, but multiply that by 600 and it becomes a pain to manage. Now every project has its own GIT repository, branches and pull requests. We use git-flow to standardize code contributions.
Deploying code changes to the server were done by hand and in some instances involved voodoo. Now all code is deployed by script and in a standard way to ensure accuracy, repeatability, and enabled the ability to roll back if anything goes wrong.
We used to wear multiple hats, switching projects and contexts all day long as support requests and quick turn-around items came in. Now we have two teams, the project team works on scheduled client work and the support team handles hundreds of support-related tasks per week. The teams switch up every month and everyone starts each day knowing what to expect and what they are going to work on.
Our office space hasn’t changed, we are still in an open ‘pit’ area but we used to have our large L-type desks configured to take advantage of space optimization. Now we have removed all L’s and have placed the desks in paired rows to allow for people optimization. This allows a pair from each discipline to work closely together all day. We also have one dedicated standing desk that anyone can use.
Everyone used to have a phone and their own phone number. Now we have a one single phone number for the entire department. We still remain without a single printer, and rely on shared resources as much as possible.

But some things never change.

We hire great people and work on great projects for awesome clients around campus. We continue to challenge ourselves to be the best at our craft, contribute to open source and the higher ed community, and raise the stature of the university.

Oct 3 / Nick DeNardis

Refresh Detroit – Frontend Web tooling – Build steps, managing assets, logistics and consistency. – Oct. 15, 2014


When: Wednesday, Oct. 15, 2014 at 6:30 p.m.

Building a single website is tough in itself but building and maintaining hundreds of sites results in exponential maintenance. Luckily there are frontend tools to help. You’re probably already familiar with a few of them and may use them on a handful of projects. We’ll explore how to use frontend tools to make life easier regardless if you’re working on a single or hundreds of sites.

Focusing on the end resulting HTML, CSS and Javascript brings a whole set of new and evolving tools. This discussion will focus on optimizing workflows with Node.js, NPM, Yeoman, Bower, SASS, Gulp, etc. If this is your first time being exposed to these tools we will walk through why and how to use them. If you’re familiar with some or all, we’ll work together to hone and build upon your skills.


Nick DeNardis is Director of Digital Communications at Wayne State University, where he leads the strategy, execution, and implementation of most all public facing digital communications for the university. His team is responsible for websites, social media, and digital signage around campus. They also are responsible for creation and maintenance of several university-wide tools including a content management system, events calendar, RSVP system, HTML email creator, form creator, and short URL system. Nick has 10 years of experience optimizing university websites for a forward moving user experience. He is a nationally recognized speaker, blogger and scientist in discovering and analyzing Web behavior.

Venue and Parking

Grand Circus is located in the Broderick Tower, and you enter from the Woodward-facing doors.

Once inside, go to the end of the hall, and take the elevator to the fourth floor.

Parking is available at the Detroit Opera House parking garage, located on Broadway. Parking is $10 (unless there’s a special event). There’s also limited street parking on Woodward.

The Detroit Opera House parking garage is a short walk up Broadway and around the corner from the Grand Circus space. Here’s parking information from the Broderick Tower website (PDF).

Jul 30 / Nick DeNardis

[Video] Web Workshop: Intro. to Google Analytics

Last week I presented a workshop on Google Analytics. Since many schools/colleges/departments use the tool to track Web visitors, I thought it would be a good opportunity to get them in a room to explain the features/power of the system.

The workshop covered the following topics:

  • Setting it up on a site/multiple sites
  • Account/Property/View management
  • Intelligence Events
  • Real time
  • Audience overview/behavior
  • Technology/browser/mobile
  • Acquisition/referrers/search/campaigns/social
  • Behavior/visitor flow/site speed
  • Events/tracking/formy
  • Goals

Since a handful of people could not make the workshop, I recorded it. The audio is not ideal, but it will do.

Next workshop:

The August workshop will be on social media content strategy. The date/time is still being determined, but it will be posted here when it is confirmed.

Jun 16 / Nick DeNardis

Why we retrospective

The best tool a team can have is the ability to analyze and adapt. The last few weeks I have been talking a lot about Agile agile practices. I intentionally use the lowercase “A” because I am not advocating for any specific methodology but instead to use the Agile Manifesto at its core and use team “agility” to find the best practices for your team.

This process starts with the ‘retrospective‘, which is adopted from the ‘Scrum‘ methodology but is used to look back at a period of time, usually one or two weeks, and introduce a feedback loop for the team to discuss and improve. This is the foundation to critically analyze processes and goals.

This is the basis for a talk I have adapted twice, with more iterations coming in the next few months. Retrospectives are just one topic in the talk but it’s the foundation for the rest. The higher education specific version is below.

Highedweb Michigan presentation

When a team has an existing process, it can be uncomfortable for some people to change, especially if something isn’t going ‘horribly wrong’ and thus is less apparent. But we all have room for improvement as long as we are willing to try.

All team buy-in

Everyone must be willing to try ideas for some time before dismissing them. If the entire team isn’t on board, the reflection and process planning won’t result in the best possible solution. The team shouldn’t dismiss even the most out of the box ideas unless they try them for some time, one or more weeks. If the change totally fails, no one likes it or it doesn’t produce the desired results, that will come out in the next retrospective and everyone will agree to go back or adapt what was tried.

Start with your current process

Don’t change a thing in the beginning, just talk. You may find that a two,three hour argument discussion may take place the first few retro’s. This is good, it may not feel like it’s producing anything productive, but these feelings, ideas and issues need a vehicle to get addressed and out of the way before real improvement can happen. You’ll find that other members of the team may be very passionate about the same things you are, but you may never have noticed. Over time the retrospectives will become shorter and more productive. Hang in there.

Running a retrospective

First rule: No technology during the retrospective, everyone take out their phone and place it in the middle of the table. This may get people squirming at first but giving all team members the equal respect of your attention makes a world of difference.

Next, there needs to be a facilitator, this can be someone on the team or someone external. Their role is to keep everyone on track and to record the discussion points.

Then, go around the room and have each person answer the following questions:

  • What went well?
  • What didn’t go so well?
  • What have I learned?
  • What still puzzles me?

Our team also adds the question, “How stressed were you on a scale of 1-10?” We make it a point to focus the changes for the next iteration on reducing the number for the most stressed person.


After everyone goes around and the team has heard how the last week or two went, only then can an effective discussion happen about what should stay the same and can be improved. As a group, although it shouldn’t be limited to an unanimous vote, everyone should agree (or be willing to try) what to change over the next week or two (depending on how often retrospectives are done).

The facilitator has the job of moving the discussion along and ensuring comments are moving in a productive direction. Discussions that get out of hand for a few minutes are fine, but make sure it doesn’t diverge into complaining about a person or process that the team doesn’t have the ability to improve.

Change just one thing

Like any iterative process, it is important to change just one thing at a time, or at least one thing per area. Depending on the size of the team and who/what they interact with, more than one change can happen, just make sure it isn’t too much to keep track of. But document the changes and determine when it should be revisited.

Iterate, rinse, and repeat

At the end of the day being happy working on meaningful work that makes an impact is the ultimate goal. If you’re not moving in the direction, bring it up in your next retrospective.

Jun 9 / Nick DeNardis

We’re Hiring: Full Time Front-End Web Developer

We are hiring! The Web Communications office is looking for an in house Web Developer. It’s not often we put a call out for new staff but we are filling a much needed void in our team. Our department started eleven years ago with little staff and resources, we have since grown to a staff of eleven and take on new responsibilities every day. Almost everyone in the department started as a student and worked their way up (myself included). It’s not often we get the opportunity to hire from the outside, we’re looking for a talented individual to help level up the Web.

Group Work

The job

We are looking for someone with front-end development experience producing responsive and standards compliant HTML5 + CSS2/3 websites. Have experience with Javascript without the reliance on a specific library like jQuery. Proficient in using the latest front-end build tools such as Yeoman, Sass, GIT, Zurb Foundation, Gulp, Vagrant, etc. An understanding of PHP, MySQL and other back end programming languages isn’t required but is preferred.

With three developers the projects are distributed evenly so everyone has the opportunity to work on something new. We are a collaborative environment and this position has the opportunity to affect the direction of all future Web projects. If you have read our blog in the past you will know we push out a lot of sites, about one per week. All sites are created from the ground up, completely by hand, and completely responsively. The Web is a craft and we make sure we build all the tools needed to do it as streamlined as possible. This position has the opportunity to build and maintain these tools that impact the entire institution, not to mention work with an amazing team.

Primary Web property responsibilities


  • LAMP
  • Zurb Foundation
  • Sass
  • Yeoman
  • Gulp/Grunt
  • GIT
  • Vagrant

Official duties

  • Experience collaborating throughout the entire project cycle, from research, strategy, information architecture, visual design, front-end development and maintenance.
  • A solid grasp of modern front-end Web development, such as HTML, CSS and JavaScript and their associated build components.
  • A solid grasp of back-end Web development environments, including HTTP, Web servers, load balancers, the interpretation layer, databases and associated Web frameworks.
  • Considerable skill in writing web applications that retrieve and update information in relational Web centric databases.
  • The ability to clearly communicate to project stakeholders and process feedback internally and externally.
  • The ability to troubleshoot website layout and Web application performance issues and resolve issues independently or direct issues to the responsible party.
  • Provide direct supervision to internal Web site interns and guidance to unit Web site content authors.
  • Ability to work with accuracy and attention to detail to meet deadlines.
  • Ability to understand and execute oral and written instructions, policies, and procedures.
  • Considerable project management skills, including ability to provide time estimates and prepare accurate records and reports.
  • Proficiency in the use of Web applications programming languages, tools, and/or methodologies for developing integrated Web applications typically acquired through formal education or equivalent experience in Web application development.
  • Demonstrated ability in analyzing customer requirements and developing basic information systems solutions typically acquired through one to two years of directly related experience in Web application development and support.
  • The ability to translate functional requirements into cross-browser Web applications.
  • Strong understanding of Web technologies and related user device capabilities required to access the Web.
  • Strong understanding of test driven development.


  • Have worked with creating templates for a content management system.
  • Have experience with device and browser testing.
  • Working knowledge in Photoshop.
  • Enable and execute A/B tests to measure different design approaches.
  • Can code HTML Email templates with understanding of limitations, and standard practices.
  • An eye for detail and great communication skills, for example, multi-tasking in a dynamic, fast-paced environment.
  • Effectively communicate with Project Managers, Designs, Clients and other Developers.
  • Have an unquenchable thirst for knowledge and professional growth.
  • Create tools and resources to communicate with our rapidly expanding developer community.
  • Stay current with trends and best practices.

How to Apply

Please do not send resumes directly to me. Apply at Posting #040365
Apr 1 / Jennifer Di Sano

Wayne State loves bacon

It’s April Fool’s Day, 2014, the one day of the year where you can’t believe everything you see on the Internet.

The Wayne State Web team hasn’t done anything fun for April Fool’s Day in the last few years and we have a new homepage, so we *had* to do something.

One day while we were out walking on campus, taking a quick break from sitting in front of our computers all day, we started talking about an internet phenomenon re: hiding bacon.

That’s when the idea hit: we could hide Kevin Bacon on our website! After all, there are six degrees of Kevin Bacon, right? If he *is* everywhere he should also be at Wayne State.

One of our graphic designers, Dan Greco, found some stock images of the famous actor and worked them into two of the main photos we have on the homepage. We loved the results and had him work up a few more for April Fool’s Day.

The goal was to be subtle but funny. We think it worked.


Mar 6 / Nick DeNardis

Student Center Renovation website: 24 hours from sketch to production

Student Center Website  Recently we were given the task of putting together a website for the Student Center Renovation Project. We knew it was coming but we didn’t have much to go on until the details were approved. On a Thursday we got word everything was approved and set up a conference call to talk requirements, content and images.

Outlining the requirements

After an hour discussion with the client we determined that we had to mirror the messaging/feel of a banner being placed outside on the actual Student Center building. We also determined an initial set of menu items that included: The Project, Visions, Highlights, FAQ and Contact. We had no idea what was going into each of these areas but the task to finalize the content was on the client, so we had to work with Lorem Ipsum.

Sketching exercise

SketchesEveryone in the conference call was then involved in an initial individual sketch exercise. Everyone got 5-10 minutes to sketch one or more ‘wireframe’ layouts of how they perceived the site should be organized. This was a great first step to get designers and non-designers collaborating. Even though everyone was in the same meeting, heard the same questions, responses and decisions from the client, everyone came up with different interpretations of the client’s and project’s needs.

Student Center WireframeOnce the time was up, everyone presented their wireframes and explained why they chose to place elements where they did and how they saw the website working. We talked pro’s and con’s as a group.  In this case everyone agreed all the content could fit on a single long page so we decided to go right to a single wireframe. This time we used a whiteboard so we could draw, move and erase as we worked down the page.

Divide and concur

Once the wireframe was decided upon we split up the tasks to parallelize the work. The tasks broken down:

  • Base CMS and Foundation structure setup
  • Photoshop polished elements
  • Frontend interaction polish
  • Gathering and preparing the assets

Foundation WireframeI started getting the logistics of the base site setup in our CMS, the folder structure on the server and the wireframe mapped out. Once that was in place Tom was able to start working on each section in isolation to get the interaction working so the site functioned with placeholder content. In the meantime, Dan started polishing the design in Photoshop. And lastly, Rolaine worked on gathering, formatting and cutting the images that would be used on the site. We are now about five hours in and things are starting to take shape.

Content creation

While we divided up our work  for the Web, the client and editorial were going back and forth on finalizing and approving the content. This usually starts with Word documents but as soon as the a piece is 80 percent finalized we transition it into its final location in the CMS. This is so it can be edited in the native editor and as we are refreshing the frontend assets we can see real content and how it meshes with the finalizing design.

Putting it all together

Student Center 80 percent doneEight hours in and the elements are starting to come together. The template is now more refined, final content is pulling from the CMS and being updated in real time so we could see and test it within the final site. Assets were polished to ensure pixel-perfect definition and the non-interactive HTML started to get some javascript life.

Adding the interaction layer

Every site we create works for the lowest common denominator browser, basically Google scraping the pages looking for content, links and assets. We then use progressive enhancement to add the style layer of CSS that most users see and browse with. After those foundations are in place we add interaction with javascript. For this project specifically we use Foundation’s ‘top bar’ for the main navigation combined with the ‘fixed’ positioning to allow it to follow the user down the page. We also utilize Foundation’s Magellan to create a ‘smooth’ scrolling effect for the user down the page to the desired content. Add in some alpha transparency on the menu as the user scrolls and it results in what feels like a must more polished experience than just a bunch of static pages that someone has to click through. Lastly, the FAQ’s expand only when needed and the renderings of the floor plans open in lightboxes so users don’t have to leave the page to view them. In order to add the interaction layer efficiently it’s important that everyone can work independently without colliding with anyone else’s work.

The final product

23 hours later the site was ready to be deployed to production. It was tested in all modern browsers and devices, the content was edited several times. The images have been proposed, refined and optimized per device. The open graph, twitter card and other meta data are added. We send the client the signoff and as soon as they are good we run the deploy…

grunt deploy:production

Final Student Center websites

And we’re live!