Skip to content

Wayne State University

Aim Higher

Aug 24 / Nick DeNardis

The Wayne State calendar story

Most everything has a story behind it and the Wayne State University event calendar is no exception. Our calendar looks different than other universities, so I naturally get questions about it:

What system is used to run and maintain it?
What department updates the calendar?
What department pays for the costs?
How did you launch the calendar to students?

The most popular question, though, is what system we use. It seems like everyone is constantly shopping for the holy grail of event calendars because they absolutely hate theirs. When I tell them we built our own their response either opens the flood gate of questions or they dismiss it as a sub-par system that obviously can’t be sustainable long term.

What’s happening on campus?

This was simple question that seven years ago had a different answer depending on who was asked. It wasn’t that events weren’t happening on campus, hundreds happen every day, but every department had their own idea of what was going on.

We didn’t set out to solve a software issue, we set out to solve a human issue.

Communicating when and where events were happening seemed natural within our existing systems. We have an internal student portal and email system that has shared calendaring. But just because these functions were available didn’t mean they were being used. Believe me, some of these system are pretty powerful to communicate events and keep everyone in sync. Unfortunately, the adoption rate of these systems was almost zero. A few events were added but they seemed to be limited to IT focused items entered by IT staff.

Being responsible for the university homepage, admission websites and general Web promotion we have an interest in what is happening on campus. We investigated and started asking why the existing tools were not being used. The answers all had common themes, “the tools are just too complicated”, “I don’t know where they go once I put them in”, “doesn’t someone need to be logged in to see my events?”. There seemed to be a lot of frustration with the systems.

We tried them ourselves and stumbled across the same usability issues. It was clear the “calendaring” that was part of these large existing systems was an afterthought. It was a shame.

Idea, proof of concept, iterate, rinse & repeat

If you’ve been following me you know I have a thing about iteration. So we had a crazy idea: let’s just set up a form to collect events and list everything that is in the future. At the time (2005ish) we didn’t have a PHP framework (PHPSimpl) and we definitely didn’t have the robust server environment or insights we have now. So we did what most developers do, created a functional app that looked like a backend system. We also took a daring approach to submissions, anyone with a campus ID could add events and they went live immediately, no approval process.

But hey, it worked!

Circa 2007 (First release in 2006)

The first release was really a proof of concept. I’m not sure how many hours went in to building it but I know it was up in under a month (we literally locked a developer in his office to work on this and only this). It didn’t do very much but that is what made it successful. The left menu of the only screenshot I could find (above) says it all. “View”, “Search” and “Add”. That’s all a user needed to interact with.

A win-win for everyone

There wasn’t a mandate for everyone on campus to use the calendar, so we had to get creative to grow adoption. The way we accomplished this was we made it insanely enticing to add events. If someone took a few minutes to add an event we would do all the hard work after that. The events then fed to their website where they had the chance of being promoted on the university homepage and all over campus. The campus community got their events promoted by doing just a little bit of work and we got all campus events in one place. A win-win for everyone.

Circa 2008

The second release of the calendar was more of a visual refresh. We watched our analytics really closely and talked to a lot of staff and students to figure out how we could make the “view” of events easier.

It came down to these things:

  • The ability to see and pick an individual day’s events
  • Each department needed to be able to link to just their event listing
  • The introduction of categories
  • Date ranges for event listings so we could promote a single week or an entire semester of events
These simple items were a natural next step. Without giving the system time to grow in to them we would have just been designing in the dark. They came out of the needs of campus and so far we haven’t added a single feature that hasn’t being widely adopted.

Current version (launched 2010)

The third major release was yet another visual refresh with a few added features after some lessons learned. In the previous version every event had the same prominence. The “Power Cycling” fitness class and the “Last day to register for classes” looked exactly the same to the end user.

We created three levels of events

  • Reminders – Things everyone needs to know which are promoted at the top of every page
  • Featured – Campuswide events that are open to everyone and need a little bit of visual attention
  • Regular – Things that happen every day and maybe have a smaller or limited audience
The amount of calendars in the system started to get out of control, over 500, and the list was unmanageable from the user’s end. So we categorized them on the homepage by type and audience. This helped to bundle events and encourage discovery.

Learning from our failures

We introduced two features that we thought would be a good idea: community uploading of photos and videos per event. The idea was to link re-occuring events to their previous years and highlight photos/videos so users would get a better sense of what the event was about. Great idea, right?
We should have noticed the red flag right away, the idea for these features came from us, not from the calendar community. The problem was these photos/videos took an extra step for the user to upload them, the benefit to uploading them wasn’t mutual (not win-win), and included an approval process, adding a day or two before the media actually showed publicly. Long story short but this lasted about six months before we disabled them. We’re still looking for a good way to passively gather photos and videos from an event.

I’m going to your event!

Mid-2011 we added the most requested feature to our calendar, RSVP’s. From the beginning everyone was asking to collect RSVP’s for events, so we knew this was important but every event had their own needs. Some were completely public, others were invite-only and some even required payment. We knew we couldn’t screw up a feature like this so we didn’t add it right away.

We purposefully took the hard road and hand created every RSVP form for everyone that asked for one. Every form had their own page, database table, manager and access. We worked with the event owners to walk through the entire user process from beginning to end, both their physical process and how that translated online. It was a grueling process but it was the only way for us to learn how to ask the right questions, reign in requirements and get creative about reusing elements.

A year later we had a really good understanding of what it would take to create a self service RSVP system that fit 90 percent of the needs of campus. Above is a screenshot of the RSVP creation process, it works a lot like Wufoo (but not as sexy yet). It also was the foundation of our broader self-service form manager, Formy.

Open data, what’s ours is yours

In the past year we have been busy expanding our (almost) public API. Right now it is invite only but I’m making it my mission to start allowing public sign up for keys by the end of the year. As more students and departments are experimenting with their own mobile websites/apps or just remixing data it’s important for us to be able to provide everything we can in a safe and standard way. This means opening our data to the community as yet another benefit to using the events calendar. Adding events now have effects far beyond anything we in central marketing could imagine.

Our m.wayne.edu is currently run completely on the API and we are in the process of moving most every website to use it for data access.

Two years, due for another redesign?

It’s been two years since our latest redesign which has our minds churning. We have a few things in the works… But nothing we can announce just yet. We know the overall menu structure in the administration area is a nightmare and we know that we have all sorts of other data that can be connected to an individual event to make the page even more useful. Have a suggestion? Just email us.

More than just software

If you’ve made it through this entire story I hope I’ve been able to get a few things across. The first is that although the calendar is just another piece of software it serves a larger purpose, to bring the campus community together. I don’t think a vendor-provided solution could have effected campus in the same we have been able to. Being on the ground level, listening, responding and consulting has really shaped how campus thinks about current events and planning for future events. Secondly, without the amazing support from everyone on campus we wouldn’t be able to provide students with what we think is the best event calendar in higher ed. Thank you all.

Follow the updates to our events calendar: http://blogs.wayne.edu/web/category/calendar/

2 Comments

  1. Adam Lincoln / Aug 24 2012

    One major thing I love about this post is that it highlights this problem:

    “When I tell them we built our own their response either opens the flood gate of questions or they dismiss it as a sub-par system that obviously can’t be sustainable long term.”

    You may imagine that I hear the second of these all the time and think it’s total crap. It’s one thing to hear it from consumers of applications – they have other interests in mind, like ramp up time/cost, “supportability”, etc. But to hear this from people in IT – and I do frequently – makes me sick. This post and the product it describes is a glaring example (among many!) of why people in IT, both grunts and management, must be open to developing solutions internally. Sure, it takes time, but you can end up with a killer product at the end that, shockingly, does everything you want it to do… *and* now you don’t have to pay yearly licensing/support costs for that killer product!

    • Nick DeNardis / Aug 27 2012

      Adam,
      I know that internal development of applications isn’t for everyone, and I surely wouldn’t recommend it to any group. It is something that has to be born from an individual or group. There has to be a certain curiosity, chemistry and talent for internal teams to be successful long term. And as many have experienced in the past, this perfect storm doesn’t come around often.

      Far too often “internal development teams” are not created/charged to come up with really smart solutions but instead to save money. The drive to save money short term more often than not creates products which are not well thought out or supported long term. The focus isn’t on the actual end users of the product who should be the product champions.

      But back to the positive, my favorite example of a hugely successful internal team is the IT department at Purdue. They have been able to focus on needs and build some amazing products with an internal team. They are truly innovating education with an in house team.

      Just take a look at their Studio by Purdue suite:
      http://www.itap.purdue.edu/studio/
      http://higheredlive.com/studio-by-purdue-and-the-future-of-e-books/

Comments are closed.