Nav UX

[mkiser]

We have a small UX convention we should clean up. A nested nav with arrows indicates that this tab contains more information and the expected experience is for it to expand in place -- not reload the page with the nav now opened.

This gets super frustrating when you're trying to explore and figure out what you're looking for and have to wait for the page reload and then scroll down to find where you were at to further drill down via the nav bar. Try navigating to the Python language guide for algorithm development via the nav.

The user should be able to click on the "Working With Data" nav tab and have it open in place, allowing the user to then select the page they wish to visit.

I was under the impression that we were making "Overview" pages for each of the nav sections with a dropdown, which would have the blurb and various index info.

i.e. the "Working With Data" sub nav would be:

• Overview (/developers/data/overview)
• Dropbox (/developers/data/dropbox)
• Hosted Data (/developers/data/hosted)
• Amazon S3 (/developers/data/s3)

[anowell]

I can see that. Where would /developers/data link to in your example? I'd rather link "Overview" to /developers/data instead of /developers/data/overview.. (otherwise, I suspect we're just gonna end up with a bunch of new redirects to overview pages).

(fwiw, my preference would be for flat nav that never expands/collapses, and present the nested content in formats that are richer than just a list of links, but I think that ship has sailed...)

[mkiser]

Ah, good point! I think we can still resolve this without having to add that ugly /overview page.

If the navs opened/closed without reloading the page, we just slot in an "Overview" item at the top of each section and have that point to, for instance, /developers/data

[anowell]

started to dig in, and while it made decent sense for data overview, there are a bunch of places where this has awkward consequences. For example:

https://test.algorithmia.com/developers/algorithm-development/languages/

Would you really want this to be an "Overview" link under "Supported Languages"? IMO, adding an Overview link to the nav is a bit awkward, but still reasonable if the overview page provides an explanatory breakdown of the category (like the Data Overview). But when the Overview is just a collection of links (like most of the category pages currently), then the Overview link really doesn't belong in the nav, and the page would really only exist for direct linking.

I'm starting to wonder if it's not a better solution to just remove the down-caret so that it doesn't look like you can explore the site via expanding and collapsing nav items. :-/

[anowell]

experimented with just removing the caret in 08a62044 since it's a really trivial change. Pushed it to test so you can see if it's less misleading.

We can still go down the explorable nav route which is a bit more involved, but we'd need to figure out more precisely which categories merit an "Overview" page, and which just get a category page that exists but isn't linked to in the nav.

[mkiser]

Let's keep the arrows. The UX here is that the sidebar is a nav of nested tabs (i.e. think a quasi accordion nav). Arrows indicate the affordance that there is more enclosed here. The page shouldn't reload while navigating through the sidebar.

I don't disagree that the "Overview" link/page is overkill and awkward. I agree that we don't need to have the Overview page linked to from the nav at all, but the pages for all sections should exist for direct linking purposes.

For instance, as a user, I need to be able to go from here: https://test.algorithmia.com/developers/algorithm-development/languages/java/

to here: https://test.algorithmia.com/developers/algorithm-development/languages/

to here: https://test.algorithmia.com/developers/algorithm-development/

to here: https://test.algorithmia.com/developers/

...without any break in experience. The upshot to ensuring this structure works is that we can provide a single link to a user for resolving their problem (i.e. give a user the link to the Guides index page and allow them to find what they're looking for).

That said, these are the places where I believe we need an "Overview" page linked to in the nav:

• Working With Data section: This page contains vital context for the user about what "data" means on algorithmia
• Algorithm Development > Host Your Model: We need to be able to orientate people to wtf this is about.

Thoughts?

Algorithm Development >The Data Portal Guide > Hosted Data thing is very weird. I imagine we'll grow this to include other sources in the future (???) so the structure makes sense for extensibility. I'll address this in another ticket.

[anowell]

ok, cool. I think we're in agreement on how to accomplish a nav that expands/collapses without changing pages, and I agree those are probably the couple pages that need an Overview in that case. I'm just not convinced it's a better experience. Given these 2 experiences for navigating to my language client, I find the latter to be much richer:

---

(I'd go as far as to argue the former doesn't need to exist at all, but again, I think the single-level nav ship has sailed)

A small amount of text to explain the context of "Client guides" and recognizable icons seems more friendly to figuring out Algorithmia (yes, it may be one extra page load for those of us who know exactly where they want to go). And I think this applies to other categories as well. Tutorials doesn't merit an overview page, but having that category page is a chance to explain the relationship between "Recipes" and "Sample Apps" (i.e. "when should I be looking for one vs the other?"). It's a question of clicking "Tutorials" then "Recipes" then "Overview" to figure out what they are versus just clicking "Tutorials" and getting a brief explanation of what recipes are.

So I'm of the opinion that loading an extra page or two is a valuable opportunity to provide richer guidance to content, as opposed to boiling all navigation down to a javascript "quasi accordion" nav.

[mkiser]

Sounds good

re: single-level nav vs nested. We chose to go with a nested nav from the jump, despite some inherent issues it would pose in the IA. I feel you that it's not sexy. But this is where we're at.

Navigation and index/hub/overview pages serve different purposes. And, at the end of the day, it's all about consistency, expectations, and the user experience.

The index page of all the clients w/ icons is great -- totally agree. Especially if you come directly to that page, which we'll be sending lots of people to via on-boarding content.

But if you're just trying to poke around and see what's available, reloading tons of pages, scrolling down, being aware enough to check out that a nav has opened, etc. is confusing and shows a lack of respect re: user experience. That's also why we're not going to use one navigation convention for some pages and another for others.

[anowell]

k. I know most-to-all the planning here happened before my involvement, so it's not clear to me if this is decided (and just being explained to me) vs being discussed. Nor is it obvious where this falls on the spectrum of design vs content ownership. And I certainly don't want to drag this out unnecessarily.

So I understand your take; I feel differently about the experience, but believe my perspective is understood; so if javascript expanding/collapsing nav is the decision, I'll make it happen. :-)

[edit: the original version might have been interpreted more harshly than intended]

[mkiser]

This is experience we should follow as an example: https://www.twilio.com/docs/libraries

[stevielkim]

OK so my thoughts are 1: we will need the overview page if we change that 2: not sure if anyone but a designer or super ummm...attentive developer would ever notice or care about that 3: I actually like that anti-pattern, but that’s usually the case.

[mkiser]

re: 1) The overview/index pages stay, but they're not necessary as part of the navigation UI outside of the two examples provided above. The initial decision during design reviews was to have the Overview page in the UI. Anthony made a great point that they're a little redundant if all they do is repeat exactly what's in the nav -- the two other pages add value bc they provide useful context.

re: 2) What is this in reference to?

If you guys strongly prefer to go with an anti-pattern, then I implore you to anchor the page at the top of the content section on click so the user doesn't have to scroll down past the hero every single time.

[peckjon]

IMO: the overview pages are really useful for some sections (eg, some devs absolutely prefer the icon-grid of languages), so we can't scrap them entirely. Having an "overview" section inside each subnav is a space-hog. So if I had to vote, I'd say clicking the main menu item does jump to the overview page, while also opening the subnav. But I agree 100% with Matt's suggestion to have a #content anchor for those links to go to, so they aren't constantly scrolling past the banner.

[anowell]

I spent some time discussing all the options discussed here with @JamesHoover, and the conclusion was to use JS expanding/collapsing nav - more inline with Matt's original suggestion. All parent URLs continue to work, but many of them are not directly navigable from the site. Initially, "Working with Data" and "Model Guides" have Overview pages, and you content gurus are welcome to add additional overview pages as needed.

It's live in test if you want to play with it.