Redesign Post Mortem #65
Description
I know there's talk of killing this site in favor of something simpler, and I want to comment on that.
First, I want to acknowledge the current site's many failings:
-
The technology stack is far too complicated. My decision to use livescript was bad for maintainability. But that decision could be undone reasonably simply (e.g. by replacing the livescript with a slightly-cleaned-up version of the compiled code). My decision to use flight, skrollr, and a custom fork of skrollr stylesheets, though, was even worse.
Flight, skrollr, and skrollr-stylesheets are each playing a critical role, and they're actually pretty good at the tasks they're being asked to do. The problem isn't any one of them, but their effect in the aggregate, which is a codebase that's too hard to understand and debug; ridiculously slow; and that's locked into prior versions of skrollr and sass because of our extensive changes in the skrollr-styleseets fork (to support a different set of animation sets on the desktop and mobile designs).
-
The interior pages are poorly designed (and never really got any attention). There not visually compelling nor do they effectively showcase what we do. Ship and the Job Board are not nearly prominent enough, and Demo Days is in a category where it doesn't quite make sense. Also, there's no mention of the press that tech@nyu has received over the years.
All that said, I don't think the site is entirely a failure. Here are some things I think it got right:
-
The homepage is visually striking and the animations set us apart. Tech@NYU deserves a design that's striking and that's clearly technically sophisticated. This isn't just "shininess for shininess' sake" but also because we're a tech and design club, so using top tech and design on our own website is a meaningful signal to others that we're not all talk.
-
The design started to categorize our events around the user's perspective and goals (i.e. Get started in tech, Improve your skills, etc.), rather than around our org structure. This was a good idea, but the execution didn't really work because the new top-level categories had to contain our initiatives rather than containing particular events—remember, this is before we had the API with Event.level and Event.categories, so the system didn't know enough to put events at this second level.
Putting the initiatives, rather than events, under these top level categories ended up as a wash (it was arguably helpful because it grouped the initiatives, but the downside was that some initiatives didn't fit perfectly into their category). Still, the basic idea was right, and I think any new site should push this idea somewhat further of categorizing events as they relate to user goals, instead of the initiative they came from.
-
The homepage prominently shows our tagline, the next event, and a way to stay up to date on what we do (by subscribing to our digest). This is a pretty low bar for success, and its one that other attempted redesigns have met too, but, still, our prior Squarespace site got these key calls to action wrong.
Which leaves us, still, with the question of what to do next. I'm undoubtedly a biased observer. I wrote this code so I'm somewhat attached to it; I remember the places where I came up with some novel approach that I'm still proud of (e.g. this) or sweated over some detail that I'd hate to see lost. But I'll try to put that aside.
My bigger concern with scrapping this is the amount of time and focus that making a new site would take away from everything else. A new site wouldn't be complicated because of its technical requirements. Instead, the timesuck would come because, whenever the website's up for changes, everyone wants to have input on the design and copy. That makes sense, since the site's our biggest shared property. But it also means that we're likely to get stuck in endless conversations and revisions, and we'd be diverting Cheryl—who represents the entirety of infrastructure's design resources—from projects like the intranet and checkin. That's a pretty heavy cost.
So, my thought is this: let the website limp along in all its suckage for as long as possible. Make incremental, uncontroversial changes (like adding a calendar), the decisions for which can stay inside the infrastructure team without pulling the rest of the board down an existential rabit hole. Maybe fix some of the biggest bugs if there's free time. (I'd be happy to get the team up to speed enough on this codebase that at least those fixes are easy.) And then, once checkin and feedback are done, and using the intranet is on the path to being a joyful experience (rather than just a tolerable one), scrap the whole fucking site and redo it in whatever the fancy technology of the day is then.
Just my two cents.