Redesign Post Mortem

[ethanresnick]

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:

1. 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).

2. 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:

1. 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.

2. 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.

3. 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.

[ethanresnick]

cc @AbhiAgarwal @grungerabbit @terriburns @freialobo @maxdumas

[terriburns]

I totally agree. It would be a shame to nix the whole site. It is visually striking, and I think has been a big factor in making us seem "legit" to students, companies, and other organizations we have been involved with. It is by no means perfect, and I agree that the best way to move forward is to make incremental changes over time. Perhaps we can set up a meeting where we discuss the more glaring issues/bugs to prioritize the changes we want to make and when, and then the infra team can work from there.

[grungerabbit]

Adding @oa495 to this discussion!

[AbhiAgarwal]

Also adding @aliceyli. Her idea was to bring some content from our child sites (ship, nyusw, demodays and what not) and put it on the main site. I think she wanted to move the team page onto the main site (among other things).

Also: we should add press to it.

[ethanresnick]

Awesome. Lmk if I can help with debugging, or who I should get up to speed on this code. I'll also try to go through soon and compile the livescript to pure js and then clean that up, so that it's one less thing for maintainers of this site to learn.

[terriburns]

I really like @aliceyli's suggestion to put all of our external sites in one place. It makes sense for a lot of reasons. I personally would like this to be somewhat of a priority, contingent upon you all's time/plans.

[oa495]

@ethanresnick I'll be working on the site with Dana possibly. I agree that we can start with incremental, uncontroversial changes like the calendar. We're getting started on the job board and the idea is that we use that as a guide for the main site when the time comes.

I do think adding ship + job board to the main site is a good idea but @grungerabbit and I like having one off sites for our events.

[aliceyli]

Adding ship and the job board to the main site would be great. I just want
a way for potential sponsors or members to easily find out more about us. I
didn't even know about the demo days site as an eboard member for a long
time.

It is nice having the freedom to structure the one off sites according to
the events though. Maybe instead of consolidating them completely, we could
do this:

• add a little more info on the main site about our initatives
• when we consolidate design days and hack days, link the "improve your
  skills" section to the main facebook page that has all our events and
  doesn't look as spammy as the individual hack and design facebook groups
  (we can still link those later in the about us tab where "follow us on" is
  just so we don't lose all those followers)
• have all the one off sites have links that go back to the main site, so
  people can connect those events back to techatnyu
• have all the links on the main site to the one off sites open in a new
  tab instead of leaving the site
• I think Freia said some nyu local people are interested in joining
  marketing and blogging for us, so it'd be great to add a blog component to
  the site somehow. Maybe just add a link to our medium in "about us". Right
  now, no one can find out about the medium post about our summer jobs if
  they go to the website. :(

On Thu, Aug 13, 2015 at 10:23 AM, Omayeli Arenyeka <[email protected]

wrote:

@ethanresnick https://github.com/ethanresnick I'll be working on the
site with Dana possibly. I agree that we can start with incremental,
uncontroversial changes like the calendar. We're getting started on the job
board and the idea is that we use that as a guide for the main site when
the time comes.

I do think adding ship + job board to the main site is a good idea but
@grungerabbit https://github.com/grungerabbit and I like having one off
sites for our events.

—
Reply to this email directly or view it on GitHub
#65 (comment)
.

[terriburns]

I think having external sites is just confusing. Whats the advantage of keeping them? @aliceyli you mentioned liking having the freedom to structure the external sites according to event, but can't we also do that on the main site? we just have so many events it seems decentralized to maintain external sites.

(slightly related: @freialobo re what @aliceyli just said -- nyu local peeps want to join marketing? have they applied? if not but you know that they are interested can you make sure they do?)

[oa495]

If we have external sites for just DemoDays & Startup week I don't think
it'll be decentralised. If they were attached to the main site I don't know
if we would have so much creative freedom when making them. I feel like it
would have to fit in with the general look of the site - which is not a bad
thing necessarily but I think it would be nice to be able to design them as
we see fit.

@cheryl what do you think?

What would the urls be? (techatnyu.org/demodays?)

On Fri, Aug 14, 2015 at 1:58 PM, Terri Burns [email protected]
wrote:

I think having external sites is just confusing. Whats the advantage of
keeping them? @aliceyli https://github.com/aliceyli you mentioned
liking having the freedom to structure the external sites according to
event, but can't we also do that on the main site? we just have so many
events it seems decentralized to maintain external sites.

(slightly related: @freialobo https://github.com/freialobo re what
@aliceyli https://github.com/aliceyli just said -- nyu local peeps want
to join marketing? have they applied? if not but you know that they are
interested can you make sure they do?)

—
Reply to this email directly or view it on GitHub
#65 (comment)
.

[cheryl]

Hi @oa495 I think you've got the wrong cheryl?

[freialobo]

yep we meant @grungerabbit :) sorry @cheryl!

[AbhiAgarwal]

Yeli++ I definitely agree with your points!

We can't be as flexible on the main site because it's hard to change for
each event.

The demodays site helps us catalog all our previous demodays and the hacks
that were presented there. Also the people who presented there.

Our ship site is to help have a place to show off all the projects we have
done. Not just only the best projects but all our projects (alumni,
friends, etc).

Our startup week site helps us display all the events that have happened
and all the events that are going to happen. We can add all the speakers
and mould it as we wish. If we did a job fair then we can put the companies
and the people they want to hire. The idea is that it's easily adaptable.

Etc. It's really hard to have all this built and updating on the main site
at the same time. It's complex and the main site will become a giant
application that would be hard to maintain if we did. We can do it but it
would require a lot of maintaining.

The idea of having small sites is that they are easy to make and keep
updated. In the sense of design (not information). I think it's valuable.

It helps us present all the information we have and display it nicely. We
probably can't get as detailed about each event on the main site as we can
on subsidiary sites. What do you all think?

The stack of all the subsidiary sites are also all similar. So it can be
maintained by one person pretty well.

On Friday, August 14, 2015, Terri Burns <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

I think having external sites is just confusing. Whats the advantage of
keeping them? @aliceyli https://github.com/aliceyli you mentioned
liking having the freedom to structure the external sites according to
event, but can't we also do that on the main site? we just have so many
events it seems decentralized to maintain external sites.

(slightly related: @freialobo https://github.com/freialobo re what
@aliceyli https://github.com/aliceyli just said -- nyu local peeps want
to join marketing? have they applied? if not but you know that they are
interested can you make sure they do?)

—
Reply to this email directly or view it on GitHub
#65 (comment)
.

Abhi

[grungerabbit]

Alice, Abhi, Yeli++. awesome ideas and comments. I think the main problems with the one-off sites are they're not currently findable from the main site, and there isn't much cohesion with or back to the main site.

It's useful to keep them separate though because they are much much easier to develop and update. techatnyu.org is more of a static, informational site about our institution, which are supplemented with API feeds with current events/blog posts/job postings (these structures only need to be built once and are updated independently through the intranet or another CMS.)

Alice already suggested some good starts. We can and should definitely:

• Add better, clearer linkage and descriptions to the microsites that open in new tabs.
• Create a consistent, fixed header banner that explains this XYZ microsite is part of tech@nyu and which links back to the main site.
• Create aliases on techatnyu.org that either redirect or serve the microsite content, e.g, techatnyu.org/demodays would lead you to demodays.co
• Be a lot better about explaining our other initiatives on techatnyu.org, by writing better copy or possibly making child pages on techatnyu.org about them (e.g., techatnyu.org/freshman-circuit)
• Move or copy the team section off of Ship and onto techatnyu.org main page directly. Hook this up to the API. Keep the alumni on Ship.
• Do some visual redesign of certain microsites (mainly DD) to align better with current or future techatnyu general brand direction.
• EXTRA CREDIT: use the API to pull in live, relevant snippets from each microsite. For example, the next 3 SW events during SW; the location of the next DD; the featured project on Ship. This would be some overhead, but offers us a better preview of the microsites and avoids us needing to update the main site manually.

Currently, Ship and SW are built to pull in their data directly from the API. They also run on githooks and are built on Jekyll. Anyone can modify the copy or design and have that push instantly, like we saw on the sponsorship repo. Those are huge technical advantages to the microsites.

With that in mind, I feel it's also useful to keep these one-offs stylistically distinct and modular. They're for our flagship events and also help document the cool stuff people make. Demodays for example is an archive of ALL the DDs that have ever happened, in addition to its main function as a marketing site for the next DD.

Ethan and I started bringing some of the Ship styles back in line with his styleguide. DemoDays needs a reskin because it was designed around the Emanuel brand with the rainbow pastel circles and logos. Startup Week does the best job of having a distinct brand that's aligned with the main brand (colors, type) as it was built after Ethan's brand was established. I cover this a little somewhere in the techatnyu/branding repo.

Do any of these tasks sound like something you might want to take on, y'all? Let me know what you think!

[grungerabbit]

Also, keeping them separate means we don't have do do a massive redsign of EVERYTHING AT ONCE the next time our site or brand changes...

[grungerabbit]

Here's the microsite design audit https://github.com/TechAtNYU/branding/blob/master/screenshots/README.md

[grungerabbit]

Also for example, all of these DD archive pages make less sense on techatnyu.org (it's possible people have never found this page tho and that's my bad) http://demodays.co/archive/

[ethanresnick]

I think it's hard to predict how these sites will get integrated long term, though I do think integrating them from the user's perspective should be the goal. By that, I mean we should focus on better discoverability (with interlinking) and consistency (in both the visuals and interaction patterns).

User-focused integration sometimes gets easier with technical integration (e.g. having one stylesheet linked to from all our sites that sets up the basic brand features would make the brand the most consistent and easiest to upgrade everywhere at once). Other times, though, the technical stacks are better left separate to minimize complexity, and that's fine.

My immediate goal is to make the tech@nyu main site more extensible and maintainable, so that pulling content into it, in the cases where we decide that's the right thing to do, doesn't feel like a scary task requiring a CS PhD. Here are my thoughts for tackling that:

1. Convert the Livescript to JS, as mentioned. (I'm working on this now.)

2. Remove the features related to pagination. (By this I mean the way that the site "sticks" at certain discrete "pages" as the user is scrolling.) These features weren't adding much, and they make the site slower and the code much more complex. Taking them out should be relatively easy.

3. Update the Navigation dramatically. I’m thinking we could have:

   • Home (the tech@nyu logo)
   • Events (described below)
   • Job Board (just a link off site?)
   • About (with the team section and a link to Ship + Medium, and probably Press)
   • Contact
   • Sign Up (not yet, but eventually; this would be a way for people to create a profile in the API and, possibly, get a customized version of the site)

   All the content currently under the "Get Started with the Tech Scene", "Improve Your Skills", "Build & Socialize with Cool People", and "Follow the Latest in Tech" sections would get pulled under the Events section.

   Per yall's suggestions above, the events section would have:

   • some intro copy ("Events are the best way to get involved with tech@nyu, meet our members, etc. The types of events we run are...")
   • a calendar, maybe with filters or whatever
   • Promote ways to subscribe to notifications about our events (facebook page; the various calendar feeds!)
   • A link to Demodays.co
   • when startup week is happening (or close to happening), a prominent link to/preview of the SW microsite

   Maybe @oa495 and @danagilliann could design that section?

4. Possibly move the site to Jekyll. It already works very similarly, actually, but Jekyll has some nice conventions and usability improvements that we're already used to.

5. Integrate @aliceyli and @grungerabbit's suggestions, all of which I agree with (except that I wouldn't have the microsites open in new tabs; that's considered bad practice. People know how to use the back button and, I think, often resent sites that open new tabs for them).

[AbhiAgarwal]

Love idea 4! Good idea to embed all of this into our current stack. Would love to set a deadline for this so we can get rolling on this :) Also so we can get the new infra recruits to help on this going forward.

[ethanresnick]

Love idea 4! Good idea to embed all of this into our current stack. Would love to set a deadline for this so we can get rolling on this :) Also so we can get the new infra recruits to help on this going forward.

I'm glad.

Maybe we can get the new infra recruits helping in converting the livescript to pretty JS? I've already converted some of the files (in the ls-to-js branch), but there are still a bunch that need it and I don't have a lot of time to work on this.

The workflow should be pretty straightforward, though, if others can help out. I've just been compiling the site as usual, then looking at the output of a file in build, cleaning that up, and then replacing the .ls file from src with the js file.