Reorganizing the contents of TopBarSticker

katydecorah commented 4 years ago

I've been thinking about how we can better organize the contents of TopBarSticker, this ticket contains some ideas.

Also relevant: #259

Current problems

On smaller screens, the navigation wraps:
- the wrapping doesn't always do so evenly so it can feel a little disconnected
- the wrapping forces the TopBarSticker to gain height and since it's sticky, takes up more space
Search takes up a lot of space.

Ideas to solve: the wrapping navigation

On smaller screens, the tabbed navigation in TopBarSticker wraps:

I've been seeing horizontal scrolling on too long navigation across several sites, more recently on: https://developer.twitter.com/en/docs/labs/hide-replies/api-reference/put-hidden

Stage	Image
Current
Proposed (draft)

I'm not sure that I love this solution:

It feels unusual to essentially hide navigational items, but we could argue that the concept of a hamburger button hides the entirety of a navigation and at least with a scroll you see most of the contents.
On the subject of hamburger button, I don't think that's an option since the main navigation employs one on smaller devices. Too much burger.
It also feels like we have dueling scrollbars given the scroll on the sidebar.

I would like to continue to research this and other patterns.

Ideas to solve: search takes up a lot of space

I wonder if the search button should live in the docs-page-shell.

Stage	Image
Current
Proposed (draft)

A few notes:

The action of "search" and the product "Search" have an unfortunate name collision, however I think if we styled the action "search" differently we can make the distinction.
The docs-page-shell has a different build process than our sites, so I'm not sure if there will be any challenges to including component in the page shell.

katydecorah commented 4 years ago

I spent a few minutes this morning exploring what it would look like to add search feature to docs-page-shell. I think this is pretty interesting and will require discussion with the team:

The docs-page-shell using JavaScript (not React) so we wouldn't be able to plugin the dr-ui Search component. But this mean that we could use Swiftype's out-of-the-box JavaScript implementation.

Pros to using Swiftype's out-of-the-box feature

We no longer have to maintain a search component - To me, this is this biggest pro, especially since the search component caused us to be red one week due to a missed IE11 compatibility. It's really nice when we don't have to worry about maintaining a codebase.
Implementation is fast and easy.
The feature includes paginated results.
Swiftype's search is faster. This is mostly due to the fact that our Search component uses search-as-you-type and we debounce the results to prevent every single letter from being searched.

Draft mock-up of what Swiftype's input could look like in the docs-page-shell (I'd spend more time making it look more Mapbox.)

Swiftype's result view modal with paginated results and highlighted description based on search query. We would add CSS to make these results and in the input blend with the docs brand better.

Cons to using Swiftype's out-of-the-box feature

We lose some customization, for example our current search component's results include content type and code language.
We lose opportunities to attach Segment tracks, which we currently have enabled on the Search component - however we aren't doing anything with this data at the present.

Our current search results implementation

Testing

I pushed a demo of using Swiftype's out-of-the-box search to the /geographic-analytics staging site, but please note that I didn't do much to customize the styles yet, especially around responsive design yet.

Impressions

I'm surprised to say this, but I think I like Swiftype's out-of-the-box solution. Having spent a significant amount of time developing the dr-ui Search component, it would be nice to not have to continue to maintain it.

colleenmcginnis commented 4 years ago

I'm surprised to say this, but I think I like Swiftype's out-of-the-box solution.

I also like it! It's clean and I especially like the pagination.

katydecorah commented 4 years ago

Adding a note that @colleenmcginnis made a really great proposal in https://github.com/mapbox/documentation/issues/413 to use a dropdown for the main navigation items:

katydecorah commented 4 years ago

Building on some of these ideas:

Given the dropdown, we could keep the search on TopBarSticker and remove the button and modal to always show the input:

katydecorah commented 4 years ago

We'll also want to consider NavigationDropdown which is used as the mobile view for NavigationAccordion:

Image	Image

NavigationDropdown is a styled select which makes interacting with it a lot easier on mobile devices. Some page would see two dropdown menus on mobile if we move forward with making the TopBarSticker navigation a dropdown.

Things to consider:

How can we prevent a clash of dropdowns on mobile? Should they be styled the same? Or differently?
Should TopBarSticker's navigation be a popover on large screens and then a select on smaller screens to make it easier to interact with?

katydecorah commented 4 years ago

Regarding the clashing of the navs (NavAccordion + TopBarSticker). For smaller screens, we could consolidate the navigation.

Larger screens

No changes to NavigationAccordion at this viewport.
TopBarSticker navigation is a popover (as we've been discussing adding) and shows the main navigation items and lists all the API reference versions (if that site has them).

Smaller screens

Image	Image

The NavigationDropdown in NavigationAccordion is disabled/removed.
TopBarSticker's popover is automatically hidden on mobile and replaced by a control select (like Navigation Dropdown). The control select will include the menu items that are found in NavigationAccordion's NavigationDropdown.

katydecorah commented 4 years ago

Doing some research and it appears that using select element as navigation is not an ideal pattern in terms of accessibility. The select element it's meant for input (interacting for forms) and so it changes the scope of the element.

Ref: https://inclusive-components.design/menus-menu-buttons/

There some helpful patterns in the link above that I think we should explore, including this React component: https://github.com/HugoGiraudel/react-menu-button

katydecorah commented 4 years ago

Sharing some beautiful fly-out menu design inspo: https://dribbble.com/shots/11052651-Fly-out-menus/attachments/2648852?mode=media

mapbox / dr-ui