RWIB Mission 1: Front page overhaul and nav restructure

[brson]

Link.

The amount of content we need to present is outgrowing our nav bar. Community links are growing and there are lots more links we need to expose but no room.

Completely restructure the nav bar as a few 'category' links that lead to their own pages:

• Documentation
• Community
• Downloads
• Contributing

The content of these pages is discussed in further missions below. Because this adds 'downloads' to the navbar, we also need to remove the redundant 'Other Downloads' button.

There are some other important links that need to be integrated into the front page:

• crates.io - It takes a lot of clicks to discover that crates.io exists today! I don't know the best way to integrate this, but one possibility is to call the crate ecosystem out in the feature list and hyperlink there.
• play.rust-lang.org - To discover play.rlo you have to click 'Run', then the 'fold-out' icon. This is a useful enough newbie tool that it ought be completely obvious how to find it. Again, no great ideas about where this link lives in the current design.
• stability guarantee - I like the idea of adjusting the sales pitch / feature list to tout stability and making this an inline link there. This isn't written yet, discussed below in another missions.
• security policy - The page exists but isn't linked.
• GitHub - via banner is fine.

If these can't all be integrated organically into the flow of the page then you might consider adding them to a new footer.

Consider making the feature list link to various blog posts. Make sure the page style continues to attract attention to the more crucial links we already have.

Propose tweaks to the design to accomplish all these goals.

[nagisa]

I personally like the current simplistic design of the frontpage and believe that we should try to preserve that.

Completely restructure the nav bar as a few 'category' links that lead to their own pages:

Sounds a lot like what happened to haskell.org.

Because this adds 'downloads' to the navbar, we also need to remove the redundant 'Other Downloads' button.

Rather than that I think the navigation bar looking something like

[logo] [Documentation] [Community] [Contributing] [Download for OS | Other downloads]

is better.

Usually when menus become unmanageable, some sort of sub-menus are employed, such as used by the Python website. We could do something similar as well. I like the way Python’s website splits the organisational links (e.g. PyPI and PSF) and links related to implementation of Python itself into two separate menus. While we probably don’t have enough links to consider that yet, it might point to the correct approach for us.

[alilleybrinker]

One thing to consider is the degree to which we'd like to change the header. It may be advantageous to maintain consistency with the current design. I have whipped up a potential design which allows for the inclusion of more information while keeping as close as possible to the current design. You can find it here: https://github.com/andrewbrinker/rust-www/tree/new-index

In this design, the "1.2.0" in the Docs section header is a toggle between the current stable and nightly branches. When clicked all the links below is are changed to point to the appropriate pages for the selected version. This could be expanded to allow a selection of any number of older versions of the language, should we want to do that in the future.

The arrow next to "Downloads" is meant to make it more visually striking, but can obviously be removed.

The grayed out links are for pages that have not yet been written, but that are currently planned.

[brson]

@AndrewBrinker Interesting, take thanks. Under this design perhaps the 'Docs', 'Community' and 'Contributing' links also link to full pages for each?

One obvious downside to this header as presented is that 'Downloads' is very deemphasized (and is an awkward fit under 'contributing').

[alilleybrinker]

They can definitely be links.

I've actually been playing around with the design some more, and changed "Contributing" to "Development". Downloads fits a little nicer under that header, I think.

These changes also include some updates to the pitch and install box, pictured here:

[alilleybrinker]

So I spent a little more time on a front-page design, and here's what I've got:

The links in the gray box change the displayed code example (at the moment they're all the same code, but that needn't be the case now), and each code example is properly linked up to http://play.rust-lang.org.

You can see the code at: https://github.com/AndrewBrinker/rust-www/tree/new-index. The JS for the different code examples is pretty ugly, and will definitely need to be cleaned up. The CSS could use some reorganizing as well. But the idea is there.

[alilleybrinker]

Actually, I've been thinking more about how the design for this front page should work. As @steveklabnik pointed out in a recent post on Hacker News, people coming to Rust tend to come from three distinct "realms of experience": functional languages, systems languages, and scripting languages. Each of these three groups appreciate and understand distinct parts of Rust, and struggle with distinct parts.

It's also (I think) a good idea to have a small introduction to the language (similar to what Elixir does) on the front page. What if there were actually three introductions, one for people coming from functional languages (OCaml, Haskell, F#, etc.), one from systems languages (C, C++, D, Java, Go, etc), and one from scripting languages (JavaScript, Ruby, Python, PHP, etc.)?

So the site would look something like this:

• Header containing logo and navigation
• Small blurb about the language
• Download buttons
• Introduction selector (tabs, with a prompt saying something like "What sort of languages do you have experience with?" and then selections for "functional languages," "systems languages," and "scripting languages" (with maybe a small list of example languages for each, like I provided above))
• tutorials tailored to the three groups

The tutorials would cover roughly the materials laid out in Steve's post.

For people coming from functional languages, we could cover:

• immutability by default
• pattern matching
• first class functions
• (almost) everything is an expression
• generics via traits

For people coming from systems languages, we cover:

• borrowing and lifetimes
• zero cost abstractions
• safety guarantees
• concurrency via send/sync

For scripting languages, we cover:

• building and package management with Cargo
• wide range of editor support
• already strong library ecosystem, including Hyper, serde, crossbream, etc.
• Clippy and racer

Each of these then leads people into either trying the language out more in the playground, downloading the language, and/or reading the book.

I am planning on putting something together to show this in clearer detail. I'll share it here once it's built.

[alilleybrinker]

I decided to try a different direction for the new navigation, with the simplified structure suggested in the first post rather than something close to what we currently have. Here is what it looks like:

[brson]

There's still a lot to do here, but the nav is no restructured according to the op.