Design Pass

[therebelrobot]

So we need to pull together a navigation design for the iojs.org site, make sure that we can add additional links and pages as needed in the future without it looking like a potato.

Anyone with shiny design experience want to take a crack at it?

I guess we could go with a free bootstrap theme or something, though I don't know how you all feel about libraries and whatnot.

I guess we need to decide a few things:

• what JS libraries we want to include (jQuery, Angular, Browserify, etc.)
• what CSS libraries/preprocessors to use (Bootstrap, Foundation, LESS, SASS, etc.)
• what we want to do with navigation
• if we want to use a template
• what to do about branding (logos, taglines, etc) while it's still being discussed

[Twipped]

what to do about branding (logos, taglines, etc) while it's still being discussed

Do what http://d3js.org/ does on their front page, but instead of examples just fill all the hexes with all the logo ideas people have submitted.

[laosb]

I am designing a landing page :) I will create a PR when I finished.

[Fishrock123]

@laosb's pr: #16

[therebelrobot]

I like the new index design in #16 , but I do have a couple reservations with it.

1. It looks more like just an iteration on the current design rather than a new design pass, which, given the amount of design variation in the logo alone, should be discussed and evaluated for the site
2. It's not necessarily answering the questions we need to, like what to do with navigation long term, what we want to do about branding short term, or if we need/want front-end libraries for js or css preprocessing. Standardizing libraries and build processes will help streamline all of that for new developers and for making updates. I, for example, wrote a lot of code a couple weeks ago that is now defunct because these answers weren't available nor discussed. I want to make sure that doesn't happen again for me or any other contributors to the site itself. And maybe that needs to be a separate issue itself, but I figure the libraries for the site are very tightly intertwined with the design of the front-end itself, making it a valid topic for discussion here.

[Fishrock123]

Re: 2 / Tech used
(Note: I'm not terribly hard on these points if people want to discuss them. Expect for Angular.)

I want nothing to do with angular. Besides, we shouldn't need anything that heavy. If we do, React + Flux is far more favorable, imo.

Browserify is a good idea, I have a very good existing gulp+browserify pipeline I can use for this.

For CSS I would be in favor of using the reset I have commented out in the file as of now, though resetting the font is something I need to investigate on mobile more.

SCSS, LESS, Myth, and Stylus are options for css pre-processing. I prefer the latter by convenience.

[Fishrock123]

I have a terrible urge to take #17 (comment) and turn it into an old-school crt-esq design haha

[laosb]

It's not a long-term design, but it looks better than the present one. We should first choose a logo, and then I can do more design based on the logo design.

[therebelrobot]

@laosb, that's the main issue here, the TC has all but washed their hands of the logo until the release, and then only enough for the install logo, and the way most conversations are going on the logo thread make it seem like the community won't pick any one in particular, but allow all. Without any determined roadmap on branding or logo design, we need to come up with a longer term solution here that will work no matter what the final say on the logo is, which, while difficult to do without a set color pallet, is not impossible. IMO, we should pull together a number of screenshots of ideas here, see which one would be easiest to implement/ has the most lasting value, and run with it.

@Fishrock123, No Angular then. I figured as much since it has an enormous learning curve. I'm not terribly familiar with React or Flux, but from what I understand their learning curve is pretty high themselves. I'm ok with a Browserify+jQuery stack (or some other jQuery clone), while trying to adhere more or less to Node production standards. It seems to me like that would be the easiest for someone with little front-end experience to work with.

For CSS, we will want to decide on fonting and resets, I normally grab something from google fonts since they are numerous and available. Pre-processing, I am most familiar with LESS, SCSS, Stylus, then Myth, in that order. I've actually never worked with Myth. Something for me to look into. I would swing for LESS or Stylus as our choice, since SCSS requires ruby binaries and I prefer playing inside the Node playground whenever possible.

[laosb]

@therebelrobot LESS+1. To improve the user experience of China users, I don't think it's a good idea to use Google fonts, since they can't be loaded in China. The same to other Google services.

[therebelrobot]

@laosb fair point. We'll want to avoid cdn's for that reason too then. I can, however, still manually download a Google font and make sure it's converted properly for relative inclusion. Super easy to do. We just need to pick one whose license is open, which I think all of Google's are, but I may be wrong.

[therebelrobot]

Just found a cool tool trending that does exactly what I described above: google-webfonts-helper

[therebelrobot]

Though to be fair, most fonts we choose would be mostly latin characters; we'd want to find a desirable font for various language glyphs: chinese, japanese, korean, arabic, hebrew, russian, etc. No one font is going to cover all glyphs gracefully, so we need to make sure we have sufficient backups if needed.

Which brings in the entire issue of internationalization in the first place. We would need to make sure the design allows for RTL and LTR word placement, as well as how to handle the loading of internationalized fonts, which could add a bit of load time to the site if we didn't do it properly. I worked on the front end for an internationalized product for Estee Lauder a while back, and I have a few ideas on how to approach it, but i18n definitely needs to be taken into account for this design pass.

[therebelrobot]

A possible option for i18n: https://github.com/wikimedia/jquery.i18n

[laosb]

It's not a good idea to use web fonts with Chinese since a Chinese font file would cost a lot of time to load, even on a foreign website for China users. :( There's a great css font-family for the mixture of Chinese and English, since not every word in technologic English can be translated to Chinese: font-family: "Myriad Set Pro", "Lucida Grande", "Helvetica Neue", "Luxi Sans", "DejaVu Sans", Tahoma, "Hiragino Sans GB", STHeiti, "Microsoft YaHei Light", "Microsoft YaHei", Arial, sans-serif;,I've used it in most of my projects and it looks well on both Mac/PC/iOS/Android.

BTW: I can be a translator to translate the site to Chinese.

[therebelrobot]

That's kinda what I'm looking for, a good mixture of font families that will adequately handle most languages, falling back where necessary. Chinese is needed, Korean, Russian, possibly Arabic, Japanese, etc. Not all of the files need to be an included font, they could just be a good web-safe font or list of local fonts, but they definitely need to be handled.

The switching of the fonts based on language will need to be addressed, as will the copy itself, which most likely will need to be put into json files for easy access.

[snostorm]

Hi! First thought: it might be interesting to throw those logo designers in the #megathread a chance to mock up a homepage design. I'll admit I'd be stuck to know where to start without a sense of the project's colours, logo (and the inherit themes inspired by it.), etc.

Regarding debating React/jQuery/angular/CSS... I think it is important not to over front-end engineer the site in these early stages. I'd almost opt for a (clean, useful, pretty, functional) design that covers the small amount of initial content the project will have and the stuff that might reasonably come in soon after.

Really, what JavaScript might the project need for now? Other than some stuff that might happen fairly close to the DOM -- like a class toggle. React, etc. would be overkill at this stage and in the end might only serve a role with interactive documentation/demos, or something (not necessarily the home page.)

A basic CSS framework is probably a smart choice to start out, especially if there's a desire to stick to a grid system and get some responsiveness "for free."

Re: i18n, keep in mind SEO considerations. No French-speaking user is going to find the French-translated site if it is all translated/served post-load. It is probably better to use whatever tool is statically generating the site** to just output language variations of the site in to subfolders or something. http://iojs.org/en/contributing.html vs http://iojs.org/fr/contributing.html

** I assume this will continue to be hosted on GitHub pages? Further research tells me the site runs on DigitalOcean according to #18 . Either way, it sounds like it is assuming static HTML resources (no on-the-fly generation.)

[therebelrobot]

I like the idea of throwing to the wolves over in the megathread. We're bound to get some good designs out of that.

If we do static gen'd sites for different languages, we could probably forgo most of the front-end js right now. I still like going with LESS for css compiling, but we'd need to make sure we are storing both the source and compiled if it's just going to be statically pushed over to digitalocean.

[Fishrock123]

Re: i18n: I know that mozilla knows a lot about this, we should maybe take cues from their projects.

Re: Javascript: I don't really like jQuery as I think it encourages a way of doing things I don't find favorable. My suggestion is build what we need via Browserify. I also have a great gulp+browserify setup if need be.

cc @mikeal on all this