brlodi
commented
6 years ago For consideration, my mockup for the in-progress design, which addresses some of the concerns although in a different way.
Closed vforgione closed 6 years ago
brlodi
commented
6 years ago For consideration, my mockup for the in-progress design, which addresses some of the concerns although in a different way.
vforgione
commented
6 years ago I dislike using icons in menus without some sort of label. I'd prefer a catchall Developers drop down to catch the API, docs and links to repo landing pages.
That being said, I'm open to suggestion. I just really want the hodge podge we have going on right now to be cleaned up before we push this thing into prod.
brlodi
commented
6 years ago I should say the icon has all the appropriate accessibility properties, so a screen reader or someone with images turned off will see "Contribute on GitHub" instead, and when the menu condenses into a vertical dropdown on small screens it turns into a text link.
My pushback is mostly based on not liking unnecessary dropdown menus, which are difficult to use on mobile (even Bootstrap's thoughtfully engineered ones), work oddly in vertical navigation menus, and hide navigational aids like highlighting the active section of the site.
brlodi
commented
6 years ago As an aside, what distinction are you making with the separate "Documentation" and "API" links? Is one intended to point to the deployment docs and the other to the live API documentation?
HeyZoos
commented
6 years ago To be honest I don't find the navbar ugly at all, but I agree with @brlodi here. Not a fan of lots of dropdowns
vforgione
commented
6 years ago Dropdowns keep stuff organized, but it definitely can be overkill. Here's my mockup using them (note that it very definitely is overkill): https://jsfiddle.net/aq9Laaew/58792/
Maybe the answer is landing pages: but how do we do that? We need one to direct people to the regular explorer, aot explorer and data set list page; we need another for the data set api, aot api, docs and github links. Then there's the user links...
brlodi
commented
6 years ago 
There's no need to link to the API itself; navigating to /api/v2/ in a browser isn't very useful, since it's just going to return JSON with a URL to the docs anyway (which is presumably where the third link goes), and deeper endpoints are going to be unreadable. No one wants to click a link on a webpage and be greeted with a screenful of raw JSON.
Secondly, I don't think the user entry having a direct link to the "add a dataset" form is necessary; it saves one click on the user dashboard (such as it is) but puts the link to the dashboard behind another click, so it's actually a next loss overall. Condensing the sign out entry is fair, though. I think it would be a prime opportunity for a split button, a la https://jsfiddle.net/aq9Laaew/58865/
I also disagree with the conflation of Developers and Researchers in general. Researchers are just particularly savvy users, and don't necessarily care about contributing to the code base or standing up their own instance.
I'd put my rule of thumb for whether dropdowns are an improvement at whether they halve the number of top-level menu entries. In our case we'd be adding a bunch of extra clicks and some usability concerns to reduce the number of entries from 5 to 3 (not counting the Admin link), and three text items with associated dropdown arrows are arguably more clutter than just five bare text links.
Regarding the bare GitHub icon, it's not a hill I'm willing to die on but it wasn't exactly an arbitrary decision:
That's not even including all the projects that have it in the bottom nav without a conveniently placed logo, like Kubernetes:
vforgione
commented
6 years ago My concern here is that the app has 3 massively distinct user groups: regular people (like my mom), researchers (like academics and journalists), and developers (like us).
The problem with that is serving all of the information we have up in three different formats (explorer, bulk downloads, API) leads us to a ton of fragmentation in how we present a unified front. Once most of the latter two groups have their links, they'll never see the site again; but their first arrival and subsequent hunt for docs and links should be as easy as possible.
Having all sorts of cryptic icons and lingo can be intimidating for researchers who aren't well vested in our world, and it is especially troubling for regular people. They see stuff like that and they assume they aren't welcome.
So, without alienating any of the three constituents, how do we get our navigation and messaging in order?
brlodi
commented
6 years ago their first arrival and subsequent hunt for docs and links should be as easy as possible.
Then nesting them under dropdowns is the opposite of what we want to be doing.
Having all sorts of cryptic icons and lingo ... they see stuff like that and they assume they aren't welcome.
I don't think a single GitHub icon will have that effect on anyone who wasn't already scared away by the vagaries of sans-serif type, responsive page layouts, or the hamburger menu. It's a handy, minimalist shorthand that is immediately recognizable to its target users and easily ignored by everyone else (just like you glossed right over the 10+ other social media icons in those example navbars). If anything, I think Contribute on GitHub would be far more intimidating. Additionally, being an icon that clearly represents a brand of some sort (even if it's not one the user recognizes) naturally reinforces that it opens a different website or application.
What follows is a laboriously overdone discussion of my thoughts and suggestions.
serving all of the information we have up in three different formats (explorer, bulk downloads, API)
I don't think "bulk downloads" deserves to be a top-level interface feature. Especially considering we're not really validating data sets anymore, the only selling point we have over downloading directly from the source (AoT excluded) or using our API is the discovery aspect provided by the explorer. If we have users who want to be able to find a dataset purely by name (and I know that we do), rather than geographic and temporal constraints, then I think that's something the explorer should support, but presenting a flat list of dataset names with a bulk download link next to each of them seems out of scope.
Researchers who want a specific single dataset they know to exist can do so from the source. Manually downloading a CSV or a JSON file of a dataset from plenar.io gains them nothing over downloading an entirely unadulterated copy of it directly from the city of Seattle. We're essentially just acting as a rather poor mirroring service in that case.
I want to read an ebook, but I don't want to pay for a new one. Something classic gothic horror, then, in the public domain.
If I don't have a specific title in mind, I go to Goodreads (or wherever) and search for "gothic horror OR Cthulu". It gives me a list of titles I might be interested in, including a bunch of Lovecraft and Frankenstein. I pick one or two things from that list and click the convenient link to download the Goodreads-packaged version (which they note is sourced from Project Gutenberg) in my choice of either ePub or plain text.
If I know I want to read Frankenstein, I go directly to Project Gutenberg and download it in any of a dozen available formats straight from the source. I don't bother with Goodreads.
I definitely do not go to Goodreads and look for an all books button so I can Ctrl-F the page.
Our selling point in the web interface is discoverability of data sets, and I feel that should be our focus (discovery by name/keyword is a valid component of that). That's not the same thing as being a mildly moderated directory and mirror of raw open data sources. I'm not suggesting we intentionally cripple the fact Plenario can be used that way, but I also do not think it is worth the design and implementation agonies to specifically build.
Based on that lengthy manifesto (sorry), I would propose either:
With that adjustment we combine the vast majority of our users into a single top-level group. Perhaps we relabel it something other than Explore, which can be a later discussion.
Developers will go straight for the API or Documentation item they expect to be in the top navbar, like every other major API service or programming toolkit on the internet, unless they have a bug or want to see the source code in which case they'll look for either the word "GitHub" or the GitHub icon near the upper right. I only posted screenshots of the projects using the icon, but if you take a look at the websites of the top few projects on GitHub you'll find easily 90% of them have the GitHub link in that location (in one form or the other), and many of those that don't just completely lack top navigation. Hiding it under a dropdown actively violates user expectations of where to access that information, forcing them to process every item in the navigation to find the one that seems the closest category match.
If I had my way, our navigation would contain the following top-level flows:
That's 6 entries at most, with the GitHub link naturally de-emphasized by being an icon and the documentation link de-emphasized but still findable by being labelled something short like API or Docs. The most important item for a random visitor or a consumer is first, and the most important item for a contributing user/admin is highlighted as a button on the far right. API and GitHub links are in the middle, but still close to where they'll be expected
vforgione
commented
6 years ago Holy cow that was awesome. You raise some really excellent points, and we should make feature requests -- especially the text searching.
Given your arguments, I concede and we should do as you suggest with the nav.
The way we have things right now is super ugly. I'd prefer for it to be:
I'd like @sanilio and @HeyZoos to weigh in on this.