Nodejs.dev: Website Wireframes

[amiller-gh]

Hey everyone!

In the previous meeting we left with an action item to start iterating on site wireframes so we can have more detailed conversations about site structure and IA, especially now that https://github.com/nodejs/website-redesign/issues/4 has defined the site structure in broad strokes. I'm excited to help kick that off 🎉

This weekend I've taken the time to knock out initial wireframe layouts of most of the major top-level sections of the site for us to start iterating on (Ironically the only top-level page I haven't gotten to yet is the "Community" page 😅). The wireframes are living on InVision for easy design feedback, I've already left a few comments and open questions scattered throughout to help kickstart conversation. Feel free to click through and explore!

If anyone else has been working on wireframes, please share them here! We can discuss how to reconcile differences and work to converge on a single source-of-truth for the project.

InVision Project:

https://invis.io/SJG12D028NX#/281335816_Home

Note: Keep in mind if you comment, that wireframes are iterating on IA, general site structure and broad user experiences! In this phase, wherever/whenever we are reviewing wireframes, please keep feedback focused on these topics and not on visual design!

Proposal for Moving Forward:

If the above wireframes feel like a solid foundation to start working off of, I'd like to propose the team move forward by leaving comments, and have a more focused discussion, over on the InVision board. We can continue to iterate there until we have consensus on a content-complete, robust wireframe to pass off for whoever is going to do the high-fidelity design pass.

I'm happy to volunteer as idea-synthesizer throughout the iteration process and integrate any and all feedback left on the InVision board (that appears to have reached consensus) back into the wireframe for further iterations. However, I'm also more than happy to share the source Sketch project with anyone who would like to help with the pixel pushing! We will just have to coordinate closely with changes – unfortunately true collaborative design software is difficult to come by...

Again, if anyone else has been working on wireframes, please share them here! We can all discuss how to reconcile differences and work to converge on a single source-of-truth for the project.

---

Let me know your thoughts on both the wireframes, and how you believe is best to move forward into this next phase – excited to finally be looking at mock ups!

[ghost]

@amiller-gh This is some amazing work! Thank you so much for dedicating time towards making this happen. I'll be sure to give this a good look in the next days.

/cc @nodejs/website-redesign, and also @nodejs/website in case anyone is interested in giving feedback from the perspective of the current website.

[ryanmurakami]

@amiller-gh I love this. Great work. Just wanted to say that, because an emoji response wasn't enough. 😄

[amandeepmittal]

It looks great! My question is, is it going to be blue?

[MylesBorins]

I have to agree, I'm quite impressed with the wireframe. Similarly interested in the color scheme. I'm partial to the emerald green, but open to something different.

It might be a good idea to present this to the TSC, Community Committee, and potentially even the board. Getting feedback from all potential stakeholders early is likely to help the project be successful. That being said no pressure, if it is too early or not a good use of time at the moment I trust the judgement of the team.

[fhemberger]

Blue is just for the wireframe (you could also use grayscale), it does not represent the final design.

All pages look really great so far. Impressive work, Adam!

A few comments:

Homepage:

• (6) Default version should be LTS, I guess ("current" or "LTS" should be added to the version number)
• (5) Do we stick to one download button on the front page? (one more click required) (Ref: #1075)
• We need also a place to include a "Important security updates" header, maybe just above the Node.js Interactive banner
• Footer: Please don't use flag/country for a language switch.

Learn:

• The navigation items under "Advanced Guides" should not be linked, as they don't form a path.

Release:

• Release list at the bottom should be on a separate page. It's quite long and is not that important to be presented on the main release page.
• There has also been a discussion how to better integrate the "install via package manager" instructions (Ref: #676):

[JonahMoses]

Adam this looks incredible, thank you for taking the time to do this.

To add onto a few points that Frederic pointed out:

Homepage:

(6) Default version should be LTS, I guess ("current" or "LTS" should be added to the version number)
(5) Do we stick to one download button on the front page? (one more click required) (Ref: #1075)

As a newer-ish member to the node community (and anytime I’m new to a community) I really enjoy when the steps to get involved are clear. When I click a “Download now” button which does anything other than start downloading something for me it’s a bit odd, imho. I’d prefer the download now button to starting downloading and make me aware which one I’m getting.

Release:

Release list at the bottom should be on a separate page. It's quite long and is not that important to be presented on the main release page.

I agree having the full release list as a separate page/tab/section would help make the release landing page more focused on the release process, maybe an idea could be to have the x most recent releases readily available with the ability to drill down for more historical info.

Overall I’m really excited about this wireframe and am looking forward to the work to come.

[emilypmendez]

Great work on the wireframe @amiller-gh! I left a comment on the InVision wireframe about the overall visual impression of the page layout from a UX standpoint, it came from user feedback from some folks I happened to have around me physically at the time. I'm really looking forward to building out more UX oriented designs!

[amiller-gh]

Thank you all! Love the feedback, keep it coming. I'll try and find time in the next week to re-incorporate it into the wireframe 👍

Going to re-iterate this note to keep conversations on topic:

Keep in mind if you comment, that wireframes are iterating on IA, general site structure and broad user experiences! In this phase, wherever/whenever we are reviewing wireframes, please keep feedback focused on these topics and not on visual design!

So no, the site won't be blue 😉

@MylesBorins, would love to run this by the larger TSC, Community Committee, and board after this smaller working group does a few iterations 🙂

@fhemberger @JonahMoses

(6) Default version should be LTS, I guess ("current" or "LTS" should be added to the version number)
(5) Do we stick to one download button on the front page? (one more click required) (Ref: #1075)

As a newer-ish member to the node community (and anytime I’m new to a community) I really enjoy when the steps to get involved are clear. When I click a “Download now” button which does anything other than start downloading something for me it’s a bit odd, imho. I’d prefer the download now button to starting downloading and make me aware which one I’m getting.

Currently, download button on the homepage takes you to the Releases page where you can select the version you want. Despite it being an extra click, it keeps the homepage CTAs very simple and gives a clear path to success for new users. For new users, it also invites them to learn more about the project and the release process while they wait for the download. It also seems to be standard across other lang sites to direct folks to their dedicated download page from their homepage CTA (golang.org, scala-lang.org, etc). I would argue that as long as our Releases page has a clear and obvious way to download Node in the header, we should be fine.

That being said, I can also totally see how the releases pages may be intimidating for new users! And, having the homepage download button just autodownload LTS would be dead simple new newcomers! Getting some user testing on preferences from a larger swath of new devs on homepage download CTA behavior may be helpful :)

I could also see the home download CTA starting the LTS download and routing users to the Releases page with a message "We're downloading Node.js LTS on your machine! While you wait for the download to finish, feel free to explore our other release lines and learn about the Node.js release process." May be a little much, and annoying for users who just want a quick way to get to Releases, but I do like the idea of educating users on the ecosystem as they get set up.

We need also a place to include a "Important security updates" header, maybe just above the Node.js Interactive banner

Yup!! Will add.

Footer: Please don't use flag/country for a language switch.

Really good call! Will make a note of it for the visual design phase. May stay the same in the wireframe for now because I don't want to have to make a new asset for it ;)

Release list at the bottom should be on a separate page. It's quite long and is not that important to be presented on the main release page.

I agree having the full release list as a separate page/tab/section would help make the release landing page more focused on the release process, maybe an idea could be to have the x most recent releases readily available with the ability to drill down for more historical info.

My one counter would be: scrolling is cheap and if there is no more content on the page, having the releases list at the bottom will only increase discoverability of the section and make the site easier to navigate.

We also had discussed integrating the current "News" section into the releases page, since its mostly just changelog rips from Github anyway. Those changelog links are surfaced in the current wireframe, but I may play with turning that "All Releases" section into more of an infinite scrolling changelog view – initial load has ~10 items, scrolling down loads more – that just also just happens to function as a past versions list. Clicking on the line item title can take you to a dedicated Node version page. What do you think of that concept? May be fun to play with.

There has also been a discussion how to better integrate the "install via package manager" instructions (Ref: #676):

Good call! Will play with how to integrate that. @MylesBorins, are there any plans on better supporting "official packages" as part of the release pipeline? How do we feel about package manager installation being the default recommended installation path?

---

Some other outstanding questions:

• On the docs pages, is it enough to have a stability marker in the module header, or do we need more granular API stability marking?
• Are there other Globals we'd like to document on the API page than are there right now? (May be a TSC question)
• What format do Event and Method property / argument typing data come to us in? Is it just markdown for some structured data we can do something more fun with? (See bottom of docs page)
• What are we legally required to keep in the footer for trademark disclosures? Can it instead live on the trademarks page?
• How do we feel about the casual language for LTS, Current, and Nightly descriptions? I think it strikes a nice welcoming tone for an otherwise dry page 🙂 We can talk more about that on the voice and tone ticket I suppose.
• Is anyone here annoyed by my novel-length issues/comments yet? ;) I'll break this all out into more granular issues for detailed discussion if the conversation here gets too multi-threaded.

[julianduque]

This is amazing, I love the docs layout and structure and how the navigation works. 🎉

[bnb]

That being said, I can also totally see how the releases pages may be intimidating for new users! And, having the homepage download button just autodownload LTS would be dead simple new newcomers! Getting some user testing on preferences from a larger swath of new devs on homepage download CTA behavior may be helpful :)

I could also see the home download CTA starting the LTS download and routing users to the Releases page with a message "We're downloading Node.js LTS on your machine! While you wait for the download to finish, feel free to explore our other release lines and learn about the Node.js release process." May be a little much, and annoying for users who just want a quick way to get to Releases, but I do like the idea of educating users on the ecosystem as they get set up.

@amiller-gh I think deferring to the TSC on this one may be helpful. I personally think LTS should be the default, but I think that enabling the TSC to make this choice may be our best path. That said, I don't want us to get stalled on it once we're at the point where we need a decision - requesting that an individual or small set of individuals from the TSC advise without bringing this to a vote/discussion would probably be best 🤔

I know @Fishrock123 is on the TSC and is already actively engaged with this project. Not sure if @MylesBorins would also want to help out with that kind of decision as a representative as well.

[MylesBorins]

This would make sense for @nodejs/release and @nodejs/website to decide together. I only think we need to involve the entire TSC if there is not consensus

[silverwind]

How do we feel about package manager installation being the default recommended installation path?

I think package manager installation should be the default for most platforms, except maybe Windows where package managers are still is a somewhat alien concept (thought, I could see us pushing choco). Maybe you want to take some hints for the download page from https://yarnpkg.com/en/docs/install. I could see a "tabbed" interface with the current platform selected by default which will list the most common installation methods and a "advanced" tab that link to direct downloads.

On the docs pages, is it enough to have a stability marker in the module header, or do we need more granular API stability marking?

I'm not entirely certain, but I think all current stability markers are all on module level, but there may be exceptions. Idea for the API page: Present a list of module names that expands into a TOC of first-level headings on click. Stability could be represented by a colored icon besides either the module name or heading.

What format do Event and Method property / argument typing data come to us in?

It's plain markdown from https://github.com/nodejs/node/tree/master/doc/api. Note that the doc html is generated by the venerable "doctool" living at https://github.com/nodejs/node/tree/master/tools/doc which produces static html.

[bnb]

@ZibbyKeaton per request in today's Website Redesign meeting, would we be able to get a high-level overview of the nodejs.org website's Google Analytics? @darcyclarke and @amiller-gh may have specific requests on which analytics the group would like to see.

[fhemberger]

@bnb I also have access to Google Analytics for the website, so feel free to ask me as well.

[bnb]

@fhemberger oh, I didn't know that. Awesome, that would be super helpful if you could gather some general overall stats from the site and share them 🤔

[fhemberger]

Ok, I picked out some basic data for February.
If you're interested in certain details or something is missing, please let me know.

Top 10 visitor's countries

Top 10 browser languages

es-419: Spanish for Latin America

General stats

Average session length

User flow

Top 30 pages

Top 30 pages (only English website without API)

/cc @obensource

[maddhruv]

More visitors are over the download and docs sections excluding the home page visitors

[bnb]

@maddhruv I personally am totally not surprised by that - I believe a former Foundation team member told me that about a year ago and it seems to have held true. People want to get in, get Node.js, and get out.

@obensource that top 30 pages has some really good info for the @nodejs/i18n group - Spanish, French, and Chinese translations are among the most trafficked pages of the site 💥

[maddhruv]

If we can get a tutorials/documentations section over the website like how python, digital ocean, we can easily draw a huge traffic 😋

[bnb]

@maddhruv to be fair, this site already has pretty impressive traffic - my impression was that we were getting 1 million page views a month, now I'm seeing we have 4 million 😱

With that in mind, pagerank shouldn't be an issue - and we do actually have a guides section, which you can see reflected in the last screenshot - the 9th most trafficked page is one of those guides.

[maddhruv]

It is obvious seeing a good traffic over Spanish, French and Chinese translations, as they are already set up with a good base and are already ready to be tasted.
But second most traffic is from India with over 11% which can also be not ignored over.

[maddhruv]

@bnb I am not offending the current website and its values and also it is appreciable getting over a million users/hits
But to be a community of developers and open source and also keeping the same feather over the hat to us, I think we should get more friendlier to our user base and get closer to people.
https://www.digitalocean.com/community/tutorials
The digital ocean's tutorials are although public/community driven but they have a very user/developers approach towards teaching and guiding them using tech (no matter they are of digital ocean's or not) but on the other hand we (NodeJs guides) are pretty techie and harder to understand for a new developer or node user.

[bnb]

@maddhruv this actually raises a good point - we created The Node.js Collection for basically exactly the reason you described, and I think we may have missed it in the original pass on Information Architecture.

@amiller-gh not sure where this would fit in - maybe under the Community section.

[franciscop]

I really like the wireframes. To iterate in the points, I agree that a button saying "Download" should probably just download it, a button to the releases should be more appropriately called "Releases" or "Install". Though I really like Ubuntu's approach in this page:

A big, "Download" button and a smaller link underneath with an "Alternative downloads" or, more appropriately for Node.js, "Alternative versions and OS". The button would detect the current OS and download the correct package (showing the OS symbol on the side). Maybe even morph into an "Install" with instructions, depending on a case-by-case basis like using a package manager.

const os = {
  debian: { text: 'Download', download: 'https://...' },
  windows: { text: 'Install', href: 'https://nodejs.org/download#windows' },
  osx: { text: 'Install', href: 'https://nodejs.org/download#osx' },
  // ...
  other: { text: 'See Downloads', href: 'https://nodejs.org/downloads/' }
};

Then I wanted to comment about the documentation. I am the creator of this documentation (design, code & content) which I can easily extract and integrate it into the official website if something like that is wanted. It is inspired partly by webpack docs.

The main thing I'd add to the wireframes is search, which would be very useful for power users. I also added some comments/notes on the wireframe :smile:

[fhemberger]

The button would detect the current OS and download the correct package (showing the OS symbol on the side).

We're already doing that on the current website, it will also be included in the relaunch.

[bnb]

Ping @nodejs/tsc and @nodejs/release–we've got two questions for y'all:

1. Given the pretty high numbers around the Package Manager page, do we want to begin supporting that more officially?
2. Do we want the download button to be a direct download, or link to the Downloads page?
   
   
   
   1. If we _do_ have it as a direct download, should it be a direct download of Current or LTS?
   
   

[gibfahn]

Given the pretty high numbers around the Package Manager page, do we want to begin supporting that more officially?

I'd say yes (depending on what officially means).

Do we want the download button to be a direct download, or link to the Downloads page?
If we do have it as a direct download, should it be a direct download of Current or LTS?

I'd say direct download of LTS, if you don't know what you want, that's probably the one you want (sanest default IMO).

[bnb]

Awesome, thanks for the context @gibfahn 🙏

[milapbhojak]

Hello community,

Milap here, I am product designer from india. After going through all threads. I would love to design for nodeJS new website. As per last meeting note @chowdhurian has to split out team. I would like to take responsibility of IA, Design. @fhemberger thanks for providing GA data. I would like to see how people are using nodeJS website through mobile web browser. Great work on the wireframe @amiller-gh! I was checking other open source projects and saw Python.org website has really good IA. @amiller-gh do we have updated IA or requirement list? Would like to take a look.

Look forward for next meeting :)

[JonahMoses]

@amiller-gh Do we still want to keep this issue open?