Updating Navigation for Stack Overflow, Enterprise, and Stack Exchange Sites
This post refers to “Channels”, a product which is now called “Teams.” This post is part of a series on how we’re making Channels, the thinking behind the product, and insight into the process. Read “How We’re Designing Channels” and “Why Channels” for more background info.
In his post, How We’re Designing Channels, Kurtis wrote that this project required a change to Stack Overflow’s information architecture. We created several prototype navigations, narrowed to two, and tested with a group of users. This brought us to the following design direction, with content navigation on the left side:
We’re confident that this design will serve Channels users, but what about the greater Stack Overflow, Stack Exchange communities, and Enterprise? Our design explorations were guided by the following questions:
- How will the new information architecture support existing Stack Overflow users? How will it impact important workflows like reviewing posts or answering questions?
- How will this scale to Stack Overflow Enterprise and the Stack Exchange network sites? How can people transition seamlessly between Stack Overflow and other sites without having to learn new patterns?
- What about people using smaller screen sizes? Adding a vertical left navigation increases the page width, and how will we support people across a range of screen sizes and devices?
- Is the new information architecture inclusive and accessible? How will this impact people using screen readers or with other accessibility needs? How can we leverage this moment of change to improve the site’s accessibility?
- How will the new information architecture scale as the site grows and changes over time?
In this post, I’ll talk about our approach to answering these questions. First, though, I want to step back and explain why it’s important for us to be thinking about these needs simultaneously.
Background
You may remember that we updated the navigation design last year. Our approach was to focus on the already complex needs of Stack Overflow, and solve Enterprise and network site solutions soon after.
Through that project, we learned that – despite many similar or overlapping use cases – there were major differences that were not easy to resolve. As a result, it took us longer than expected to ship navigation to network sites, and we still haven’t updated Enterprise sites.
This means there’s been extended or unresolved fragmentation between Stack Overflow and our other sites. This is problematic because there’s a lot of overlap between people using Stack Overflow, Enterprise, and network sites. For example, about 70% of users joining network sites already have a Stack Overflow account.
More generally, fragmentation means that shipping basic improvements to Enterprise and network sites becomes increasingly costly as differences accumulate over time.
This time, we wanted to make sure that we were considering Enterprise and network site use cases early, as well as ensuring that basic improvements like accessibility and responsiveness can benefit our 150+ communities and Enterprise clients as quickly as possible.
How We’re Addressing These Needs
We started by broadly considering use cases across our product offerings: Stack Overflow, network sites, Enterprise, and soon – Channels. This approach helps us avoid fragmentation and allows improvements to flow quickly to all of our users. I’ll explore these use cases in further detail below.
First, here’s a recap of the basic design solution, with content navigation on the left side:
Next, I’ll layer in the principles and use cases that have guided our designs so far.
Principle #1: Flexibility
The new information architecture had to be flexible enough to support a broad range of use cases and screen sizes, including:
- User has joined Stack Overflow only
- User has joined Stack Overflow and a private channel
- User has joined Server Fault only (or a different network site)
- User is viewing on a tablet or mobile
Let’s see what the navigation looks like for each of these use cases.
User has joined Stack Overflow only:
User has joined Stack Overflow and a private channel:
User has joined Server Fault only (or a different network site) :
User is viewing on a tablet or mobile:
Principle #2: Scalability
The new information architecture also needed to scale reasonably over time. People should be able to expect a coherent experience as the site grows and changes. Here are some hypothetical scenarios that we can use to approximate the use cases that the information architecture needs to consider:
- A new product offering that is a separate entity from Stack Overflow
- A new feature on Stack Overflow
Next, let’s see what the navigation looks like for these hypothetical scenarios.
A new product offering that is a separate entity from Stack Overflow:
A new feature on Stack Overflow:
Principle #3: Accessibility
We know that Stack Overflow and our other sites could better support people with differing abilities. That’s why the new information architecture also needed to support our effort to make Stack Overflow accessible to all.
We are learning from the Inclusive Design approach, and also piloting a collaboration with the University of Washington AccessComputing initiative to identify improvements that bring our sites closer to conformance with the W3C Web Content Accessibility Guidelines 2.0 Level AA. We are also interested in hearing additional recommendations from you, if you encounter barriers that WCAG AA doesn’t address.
While all of these changes may not be ready on day one, we are taking this opportunity to improve access for all of our users.
What We’ve Learned So Far
In December, we launched Channels Alpha and kicked off research with Enterprise and high-rep Stack Overflow users.
We asked questions about their day-to-day workflows on Stack Overflow, showed them mockups of the new information architecture, and discussed potential disruptions to their workflows. Overall, we learned that this change caused minimal impact to their workflows. Any concerns about the extra screen width this would introduce were alleviated with knowing that the site will become responsive.
We’ll also be testing with network site users in the upcoming months.
Next Steps
We’ll be rolling out these changes in the near future. In the meantime, please look for future posts sharing our design, research, and product process for Channels. If you have any questions for the team or me, feel free to drop them in the comments below. Note that these designs are not final, and we’ll continue to iterate as we receive feedback. Let us know what you think.
9 Comments
Since you said you’re interested in recommendations… as an experienced SE user who also uses larger fonts and sometimes smaller windows (or a tablet), I’d like to be able to narrow the new left-side pane quite a bit. I’m an experienced user; I have positional memory and know what the options are. If longer words like “Sparkle” get clipped, no big deal — especially if you provide a tooltip. If you let me move the divider between the left panel and the main page (and make it sticky), even better — if I later start using Channels and need a few more pixels to see enough of the names to disambiguate, I can move it. If a page (like a question with lots of code) needs nearly the full width, I can move it and then move it back. The movable divider is a pretty common pattern, so people are used to it.
Thanks for the feedback Monica! Great point. I find the movable divider to be helpful too. I’ll share this with the team.
I do most of my work on network sites, and I feel that once again they are being short-changed in this redesign. The “Stack Exchange” logo in the header is far too big (although I appreciate that it may get reduced from this mock-up; it’s currently quite small); and the sub-heading should go the full width of the screen: the “Questions” link belongs to the site, not to Stack Exchange as a whole.
Mobile screen estate could be improved if — along with the movable divider — icons were used like the app. You have introduced an inconsistency with the hamburger menu/search bar on small screens: inconsistency in placement of icons was a major issue with the current design (and still is, with the Help icon disappearing with rep).
But my biggest bugbear, I think, is: If you want a common look-and-feel, why not treat Stack Overflow like any other site on the network and give it the “network site” header with the Stack Exchange logo? After all, that logo is the gateway to the network which Stack Overflow users might like.
Supplementary questions: How does the existing work on site design fit into this — like the fancy ELU header, or Travel, or Seasoned Advice? What’s happening to the footer?
Have to agree with this: I don’t see why the network sites lose both the “home” link in the left navigation and the top left logo home link.
I appreciate that this is often the issue with sub-brand sites, you want the parent navigation to be to the brand, and then have the sub-brand nested, but especially in your example of the user only being on Server Fault they don’t know about the rest of the network.
Alternatively, if 70% of your new network users already have an SO account, they expect a similar behaviour across the sites (so fold SO into the Stack Exchange brand more)
No, no, no. Please no navigation on the left.
Re “What about people using smaller screen sizes? Adding a vertical left navigation increases the page width”:
Indeed. It is not only for smaller screen sizes, but also using high zoom levels. In my current view/zoom level, if I scroll to the right, the left panel takes up 40% of the space (horizontally). Please don’t make it more difficult to use or even practically unusable (others do this all too well. I am looking at you, Microsoft).
What is next? Frames???
It is bad enough with this very blog. The actual reading area is less than half the screen – vertically (Firefox also takes too much of it.)
If you do it anyway there should be options to turn it off (or get the old view).
thanks for the feedback Peter! We’d definitely want to make sure the site is usable for folks at high zoom. Will take this feedback back to the team.
Thanks for taking Peter’s feedback into consideration. I have a similar problem. I currently use a two-monitor setup: one monitor is the 14″ WQHD display in my ThinkPad (2560×1440), and the other is a 24″ 4K/UHD monitor next to it in portrait mode (2160×3840). The portrait mode monitor is pretty great for reading, as it reduces the need to scroll. For example, typical PDF documents can display a full page at a time with no scrolling.
I run both monitors at 225% scaling in Windows 10. (I tried 200% but it makes text smaller than I like.) So the logical (scaled) width of the 4K/UHD portrait mode monitor is 960 pixels.
The current Stack Overflow site doesn’t quite fit in this width, but what gets clipped off is just part of the right sidebar. All the main content is visible with no scrolling.
It would be a bummer if a left nav panel pushed things to the right and caused the main content to start being clipped.
Can you clarify this sentence from the post?
> “Any concerns about the extra screen width this would introduce were alleviated with knowing that the site will become responsive.”
Specifically, what is meant by “the site will become responsive?” I was thrilled when the Documentation site went away, because it resolved the problems with the header being too wide. Adding left navigation introduces lots of concern about the width of the pages.
Also, an anecdote: Back in the 1990s, I worked on a very popular consumer application that had the navigation on the right edge. For the next version, a UI designer decided to move the navigation to the left edge. Lo and behold, in controlled usability testing, scores plummeted with the navigation on the left. Every task took longer, even for new users who’d never been exposed to the navigation on the opposite side. The product was quickly changed to move the navigation back to the right side (with an option to move it to the left). A few years later, when the web started to catch on, we laughed at all the sites with left-nav. Our usability folks repeated the experiments, wondering if the web was teaching users how to deal with left-nav. Though the scores eventually converged, right-nav retained a slight edge.
Thanks Adrian! Re: my comment that “the site will become responsive” – the site will adapt to fit different screen sizes and zoom levels. The goal is that we won’t have issues with the site being “too wide” anymore, since it’ll scale to fit the exact width of the window or device that you’re using.
And we’ll be doing plenty of testing to make sure we’re making the right move 🙂