RFC: hood.ie redesign

[espy]

What's going on? 🤔

We'd like to redesign hood.ie, for a variety of reasons (see below). We'd like your input before we get started.

Why? 😱

When we launched the current, second version of hood.ie, we had a larger team and really ambitious goals for the website. The first version had been a quick afternoon hack, basically one enormous page that included everything, and we'd always meant to replace it and do it properly. We all know how those things go. When we tackled the relaunch, we overdid it, plain and simple.

🆘 Problems and Goals 🎯

First off, we put in too many features and too much content, which led to a complicated navigation (both in terms of content and code) and a confusing structure.

• The site is too big: there's too much content.
• The structure and content is confusing: the navigation is complicated, fragmented and intransparent. From now on: page links at the top, fixed, and page anchors in the left sidebar, fixed. Done.
• We're going to ditch translations. This is painful for us, because we really wanted to be internationally accessible, but we have to come to terms with the fact that we're simply too small a project to justify the additional complexity. For now.

Secondly, we tried to be too clever for our own good and have reusable CSS across all our web real estate. So we had a separate repo for styles, but all the blog content (images!) was in the website repo. This led to problems when people tried to contribute to the site: the setup was complicated, the repo was massive, and it wasn't clear which changes needed to be made where. Contributors were scared off. And that includes us.

• The setup needs to be much, much simpler.
• Contributing to the site needs to be straightforward and simple.

Thirdly, design. The original Hoodie logo had six strong, contrasting colours, and while they were nice for stickers, adapting them for use in layout has always been problematic. In short, the colours need to go.

• Far fewer colours, no more individual styles for separate sections of the site.
• We still love our animals, and they're all pretty colourful and whimsical. We think they're probably going to end up being the primary splashes of colour.
• Fonts: Fira out, Bariol in. Fira is too light for our copy text, and too neutral for the project in general. We'd like to go back to using Bariol Bold (the font from the logo subline) for headlines, and use system fonts for everything else (Helvetica/Arial/Sans + Menlo/Monospace). So we only load one webfont, not three.
• We make code. We want super amazing syntax highlighting.
• No fancy tricks. Less but better.
• URLs should stay alive, we are going to make heavy use of the redirect jekyll plugin

Finally, the index page. It also currently does too many things at the same time. We want to go back to

• a clearer initial ("above-the-fold") message.
• a single-column layout with a single visual flow and clear focus points. This will also make mobile-first layout easier.

Who does this well? 🔭

We really like the PouchDB site for its neatness and clarity. Also, Ember is really nice with its versioned guides and docs and increasingly powerful examples on the index page.

Process 📈

As stated above, we're currently looking for initial feedback and experimenting with layouts and designs. After that, we'd like to build the foundations and the design ourselves, and then see if we can find anyone who'd like to support us with contributions.

RFC 🙌

So, what do you think? 🐶

[NickColley]

I think this is a great idea, I agree that the current site is really complicated and with a lot of content.

It'd be good to see this done from a user first approach, let me know if you want any help with that. 👍

[chrisdemars]

I think it is a good idea as well and I would love to help out.

On Tue, Jul 19, 2016 at 11:57 AM, Alex Feyerke notifications@github.com
wrote:

What's going on? 🤔

We'd like to redesign hood.ie, for a variety of reasons (see below). We'd
like your input before we get started.
Why? 😱

When we launched the current, second version of hood.ie, we had a larger
team and really ambitious goals for the website. The first version had been
a quick afternoon hack, basically one enormous page that included
everything, and we'd always meant to replace it and do it properly. We
all know how those things go. When we tackled the relaunch, we overdid it,
plain and simple.
🆘 Problems and Goals 🎯

First off, we put in too many features and too much content, which led
to a complicated navigation (both in terms of content and code) and a
confusing structure.

• The site is too big: there's too much content.
• The structure and content is confusing: the navigation is
  complicated, fragmented and intransparent. From now on: page links at the
  top, fixed, and page anchors in the left sidebar, fixed. Done.
• We're going to ditch translations. This is painful for us, because
  we really wanted to be internationally accessible, but we have to come to
  terms with the fact that we're simply too small a project to justify the
  additional complexity. For now.

Secondly, we tried to be too clever for our own good and have reusable
CSS across all our web real estate. So we had a separate repo for styles,
but all the blog content (images!) was in the website repo. This led to
problems when people tried to contribute to the site: the setup was
complicated, the repo was massive, and it wasn't clear which changes needed
to be made where. Contributors were scared off. And that includes us.

• The setup needs to be much, much simpler.
• Contributing to the site needs to be straightforward and simple.

Thirdly, design. The original Hoodie logo had six strong, contrasting
colours, and while they were nice for stickers, adapting them for use in
layout has always been problematic. In short, the colours need to go.

• Far fewer colours, no more individual styles for separate sections
  of the site.
• We still love our animals, and they're all pretty colourful and
  whimsical. We think they're probably going to end up being the primary
  splashes of colour.
• Fonts: Fira out, Bariol in. Fira is too light for our copy text, and
  too neutral for the project in general. We'd like to go back to using
  Bariol Bold (the font from the logo subline) for headlines, and use system
  fonts for everything else (Helvetica/Arial/Sans + Menlo/Monospace). So we
  only load one webfont, not three.
• We make code. We want super amazing syntax highlighting.
• No fancy tricks. Less but better.
• URLs should stay alive, we are going to make heavy use of the
  redirect jekyll plugin

Finally, the index page. It also currently does too many things at the
same time. We want to go back to

• a clearer initial ("above-the-fold") message.
• a single-column layout with a single visual flow and clear focus
  points. This will also make mobile-first layout easier.

Who does this well? 🔭

We really like the PouchDB https://pouchdb.com site for its neatness
and clarity. Also, Ember is really nice with its versioned guides and docs
https://guides.emberjs.com/v2.6.0/ and increasingly powerful examples
on the index page http://emberjs.com/.
Process 📈

As stated above, we're currently looking for initial feedback and
experimenting with layouts and designs. After that, we'd like to build the
foundations and the design ourselves, and then see if we can find anyone
who'd like to support us with contributions.
RFC 🙌

So, what do you think? 🐶

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#312, or mute the thread
https://github.com/notifications/unsubscribe-auth/AGfActDv9-FNwWoXPlmmJ5OHit9elyS7ks5qXPP3gaJpZM4JP4hY
.

[toh82]

Aye, very good idea. Would love to see a clear/smaller navigation and a more focused content, the old navigation and content are a bit complicated to focus on, IMHO.
Dunno yet if I like getting rid of the logo colors, sure it looks nice in white but I like the colors a lot.

Yeah nice, do it 👍
Would love to help/contribute, too

[HipsterBrown]

I absolutely love the current Hood.ie design but understand and appreciate the goal of simplifying the overall content, discovery, and user experience as the entry point for most folks to learn about the Hoodie project.

URLs should stay alive, we are going to make heavy use of the redirect jekyll plugin

Super 👍

Contributing to the site needs to be straightforward and simple.

Also really ❤️ this. I liked the hoodie-css idea and still believe there can be reusable utility classes, as exemplified by Tachyons and Basscss, that makes prototyping and contributing to the site a bit more approachable and maintainable.

a single-column layout with a single visual flow and clear focus points. This will also make mobile-first layout easier.

I want to see some concepts for this idea before fully judging it but, initially, this sounds like over-simplification and losing some of the personality that exists in the current Hoodie site.

Some of my favorite open-source project site designs:

• Johnny-Five
• Electron
• Terraform
• Atom
• Travis.ci

There a lot of great examples via Beautiful Open.

Also, It would be cool to see some open prototypes or designs via live examples like on CodePen.

I'm very excited to watch this process and learn from it. Keep up the great work, friends!

[gr2m]

this is great, thanks for the RFC @espy!

Maintainability and easy for contribution is something that we care a lot about, happy to help with that in any way I can

[espy]

@HipsterBrown Great examples, and that's basically what I mean by single-column, not an actual single layout column, but only one really meaningful item of content at any given vertical level. Not too many things next to each other.

The Atom header is very close to what I'd like. Logo, description, video button, code example, interesting background. Bam.

[jameswestnz]

Sounds good to me!

Ditching translations is an interesting one - although I understand the complexity, could we find a way to make it so translated versions of the sites could be add via contribution? I know this makes updates hard - if the english version get's updated, it's hard to justify keeping an outdated version of the site in another language...

I myself only speak/read english, but I have built a number of sites where it was worth the pain having other languages - so I know it's a tough one to consider.

The other point of view is that most developers find it normal for these sorts of sites to be in english, especially when code is written in "english"...

Just thought I'd put this out there to hear other points of view!

[jennwrites]

From an editorial perspective I think this is a fantastic idea, and I've just been nodding along as I've seen these responses come through. Huge fan of simplifying things and making the ideas presented on the site much clearer.

I reviewed @HipsterBrown’s recommended sites and the Electron one stood out the most to me. I think we have some great visuals and could do a lot with some strategically placed animal characters and icons.

👍

[gr2m]

nice example we could learn from to visualize what Hoodie does / how it works / benefits https://www.talater.com/upup/

[espy]

Just had another look around, and I'm also quite taken by craftcms.com:

Clean, warm, nice.

[gr2m]

awwwman one day I dream to have something like this for Hoodie: https://auth0.com/docs/quickstart/spa

[verpixelt]

Yes to all of it! Especially the technical part has to be much much easier/cleaner to enable ppl to contribute. Also simplifying the design and content flow is an A++ decision.

[kouryuu]

This sounds amazing!

I believe we have to focus on four different types of users:

• Users who have never used hoodie before and would like to know what hoodie is about.
• Users who are looking to contribute/help the hoodie project.
• Users that already use hoodie and are looking for docs and things related to hoodie development.
• Power Users that use hoodie in big projects and would like to give talks/ showoff use cases and software using hoodie etc.

So based on these assumptions I think it could be a good idea to structure the site such that these users find whatever they need as quickly and simple as possible.
(Of course I would suggest running a survey to really have an insight as to how the use the site)

I would love to contribute to this vibrant community so if you need anything I am rodkings on the Slack channel.

[espy]

Also this time, I'd like to keep a11y in mind from day one. This might help a bit: https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=en

[espy]

What's been missing in the past was also this type of inline code highlighting, and I just found another really nice instance of it on http://mojs.io/tutorials/shape/

[gr2m]

@fredguth suggested to have a look at http://horizon.io for inspiration in terms of clarity of their message

[fredguth]

Based on the benchmarks (Ember.js, Horizon.io, PouchDB), I started this mockup.

Would be something like this? What should be the call to action?

I really liked the talater.com/upup example, though. I just think the animation is way too long.

[gr2m]

we also had some discussion on the slogan in slack, here is a log:
https://gist.github.com/1b7f8f399a806042b810a148a5c5bf9f

[espy]

A couple of things have happened! There’s been progress, some new ideas, and the basics of the new design and site now exist, but are not quite ready for collaborative work yet, sorry. Still got a few foundations to set up. In all these things, I’m happy to get feedback. The thread so far has been really useful.

1. Monorepo ideas

Gregor had a great idea the other day which solves our massive monorepo problem, people have always been put off by the repo size, which is mainly due to the many images in the blog. His solution was to use the organisation page as the root of the hood.ie site, and pull in larger submodules of the site via separate project page repos, which are automatically hosted as subdirectories of the org site:

If you are not using a custom domain, the Project Pages sites are served under a subpath of the User Pages site: username.github.io/projectname

So we’d have a github.com/hoodiehq/hoodiehq repo that contains most of the site, but we'd also have github.com/hoodiehq/blog, which would get pulled into the website as hood.ie/blog.

A related idea was to have an github.com/hoodiehq/and/ repo with subfolders like ember, react, heroku, bluemix etc (so we'd get hood.ie/and/ember, for example), each with a short page explaining their use. Not sure whether this should actually be a separate repo, but hey. The blog definitely should be.

2. Project Progress - Infrastructure

In an effort to make the whole thing slimmer, I’ve set up a Jekyll/Gulp combo which turned out to be really nice, it does the whole SCSS/concat/uglify/browsersync thing in concert with Jekyll watch, but the cool thing is that all the asset compilation is an optional step, because the compiled assets are part of the repo. That means that content-only updates can be done in the GH-interface or on any device that runs Jekyll/Ruby, you don’t need node/npm etc. unless you‘re changing the assets. Development is also nice and speedy so far.

3. Project Progress - Design

I’ve been struggling combining the original Hoodie colours, the animals, and accessibility concerns (mainly contrast ratio) in multiple attempts over the past year, but I’ve fiiinally got somewhere nice. The design uses gradients for big coloured backgrounds and manages to accomodate both the animas and the original section colours without being as punchy as before. Contrast in general is reduced a bit, but readability improved by a larger font size and a weightier font, plus Bariol is back for headlines. All this is in no way set in stone, and the content is still placeholdery, but I’m happy enough to continue in this vein.

Again, it’s not quite ready for public collaboration yet, but I wanted to show that there’s finally quite a bit of progress :)

Oh, and it has nicely working colour schemes already too :)

[verpixelt]

Thanks for the update and the work you've put into this so far :) A question that popped into my head right away was, why using a preprocessor for CSS at all? I assume we don't run any super fancy calculations, Mixins or even functions in Scss for that page. With a developer focused product using CSS goodies like custom-properties shouldn't be an issue in terms of browser support. I'm only bringing this up bc, removing that preprocessor and writing plain CSS would remove another hurdle for ppl wanting to edit things.

[espy]

Uh, that sounds interesting. For context, what I’m doing is using colour vars, includes and a theme mixin for the colour schemes, plus this:

$themes: (
  theme-orange: $orange $orangeLight $orangeDark,
  theme-blue: $blue $blueLight $blueDark,
  theme-green: $green $greenLight $greenDark,
) !default;

@each $themeName, $colors in $themes {
  @include theme($themeName, $colors...);
}

Which I think might be too much for current CSS, but I’m having a hard time keeping up 😄 . What do you think?

[NickColley]

It'd be interesting to approach the project as standard CSS

<!-- inline in the page, dynamic theming! -->
<style>:root { --theme-color: red; }</style>

<style><!-- loaded via a link tag, main.css etc -->
.background {
  background-color: blue; /* default */
  background-color: var(--theme-color);
}
</style>

[verpixelt]

Iterating over the themes won't be possible with plain CSS. The variables in general, yep: http://caniuse.com/#feat=css-variables even without using any postCSS plugins the support is pretty decent + u can add a fallback color. If the displayed code example is the only instance you're currently using stuff like that I'd recommend reconsidering the importance of it and how big of an effort it would be to translate these into reusable classes. Imho the ease of using plain CSS pays of in the long run. Also moving "complexity" out of the CSS towards HTML has proven to be easier to understand.

[NickColley]

@verpixelt you wouldnt need to iterate at all since you could define theming variables at runtime I guess

[gr2m]

I’m very much in favor to remove the preprocessor if possible 👍

I also don’t keep up with CSS development right now, but if say Chrome has native support for all the CSS features we need while other browsers need polyfills, we could have a postCSS build step as part of the deploy maybe?

[gr2m]

regarding the monorepo: I think we ended up leaning towards using sub-domains and using a different layout than the main page for "project" pages of which the blog could be one, but also the "Hoodie & Friends" page or the community dashboard.

The problem with the main website being the hoodiehq.github.io repo and then have a repo for blog is that both would need to share the same CSS, it should be part of the respective repository so you can develop it locally, but when deployed than the blog should use the same CSS as the website ... and it just gets very complicated very quick. Maybe one of you have an idea @verpixelt @NickColley?

[verpixelt]

Putting the core styles into an asset repo could do the trick. Load that repo into main page / blog and have the site specific CSS/assets inside the respective repo. We did something similar for CSSconf 2017, if I recall correctly. But I see your question is almost 2 months old so you might have already found a solution. In general if you need some help or another pair of eyes, ping me any time.