consistent location of search bar

[MortenHofft]

@rdmpage Currently the search bar changes location. On the front page it is in the top. On other pages it is in a drawer to the right. That could be confusing. Especially so as users is used to a top search bar from Google.

[MortenHofft]

I'm not certain about this, but the rational for not doing so is as follows:

I'm not convinced that it is a big issue that the search bar is promoted on the front page, but we could consider not doing so and keeping it in the drawer (the Google search bar also have a different location on the front page)

We could of course always have it in the top, but it takes space and on the typical screens we have more width than height.

And if we have (as we do now) filters and the right, one could argue that it makes sense to have the free text search together with the other filters.

The initial design actually had a top search bar on the search pages, but it seemed odd in combination with the filters. You too easily forgot that there was a search term in it. And when clearing filters it was unclear what it would clear (filters in the drawer or the search bas as well?).

All of that could of course be due to the initial design being badly implemented/thought out. So I'm not ruling it out as a good idea, but I would like to get feedback from others before redoing this.

[rdmpage]

@MortenHofft Here's an example where the search bar doesn't jump even though there are facets (http://search.crossref.org)

Home page

Search results

Note that search bar is smaller, but still heads the list of results. I feel that this provides context for the user (what was I searching on, oh, right, "gbif").

[MortenHofft]

that is indeed how it worked in an earlier version. That is - having the free text search bar across the page in the top. I didn't like it when using it, but it might be worth revisiting that decision.

[MortenHofft]

either way i completely agree that the free text search field disappears as it is now. It should be marked/highlighted somehow. If not moved completely as you suggest

[rdmpage]

The other question is what happens on mobile. If search bar disappears with facets, then on mobile all user sees is list, which might be disorienting ("wait, what am I'm looking at hear...?")

[MortenHofft]

I'm thinking that I would list the filters that is selected in the top on mobile and possibly have the search bar as well (possibly not the search bar for occurrences as free text search seems secondary for occurrences). That at least is my idea currently. The search bar would then be accesible from both the drawer and the 'page', but would hopefully not be confusing as only one is visible at a time on small devices where this rule would apply

[MortenHofft]

the thinking behind having it in the drawer is to use the drawer as a general theme. So that when you are on an occurrence page (or dataset or How To Publish etc) you can open the drawer, do an omni search or go directly to a subset search (species/datasets etc). Further we would have space in the drawer for listing previous searches.

Likewise for a profile area could open a drawer, with login options, stats on your downloaded datasets, etc. Notifications as a drawer with system status. Annotation could possibly follow a similar pattern.

And if that is the way you get to the search elsewhere on the site, then I'm thinking that it would be nice if it stayed in the drawer. But there is no harm in trying different versions.

[MortenHofft]

[MortenHofft]

above some quick mocks of how I imagine the mobile version working.

For species and datasets a free text search (with suggest) makes sense and hence makes sense to show as a primary entrance on those pages. But for occurrences I think it will lead to more confusion than joy to but the free text search top and center. On larger devices I think it makes sense to have them along side the other filters

For all search current filters should be visible. Either as shown above or clearly stated so that you know they are there.

ps: don't get hung up on the way species is displayed above

[rdmpage]

Looking at popular mobile apps, e.g Booking.com and AirBnB a common design pattern seems to be have search box at top, which scrolls out of way as you scroll, don't display individual filters but always show button (either on bottom of screen - Booking.com, or floating near bottom - AirBnB) labelled "filters" that user can click on to remind themselves of filter, and/or apply new ones.

There is a lot of screen area in the mockups given over to stuff that probably isn't useful (e.g., number of results, mode of search, etc.)

I also think a more "card-based" list might work on mobile, e.g. thumbnails of species, thumbnails of occurrence map, etc.

Obviously, all of this is subjective unless there's some sort of user testing...

[MortenHofft]

Cards I like them and also believe that the would work well on mobile. See https://github.com/gbif/portal16/issues/55 for example.

AirBnB yep I like airBnB as well. And I have also looked to them when trying to figure out how to approach it. But it is a somewhat different problem they have and I couldn't see any sensible way to do a 1:1 mapping.

Space taken in top for other stuff than the results header Yeah we loose some to the fixed top bar. AirBnB do that as well, but theirs scroll. I explicitly made it stick to make it easier no navigate the site by always having the menu and search available. There is pro's and con's of that i guess. The amount of scrolling needed is practically the same

count Count of results: I would have thought that was very useful information, but intersting that you question that. Might be worth removing then.

one search vs many The difference is as I see it that you know what you search when using airBnB. Namely accommodation. Not articles about apartments, not furnitures, etc. We have several search interfaces. Partly due to technicalities but also because we want specialised search filters for different content types. That is why there is a headline stating what you are looking at. I think it would be a shame to loose that context.

listing filters Not showing the filters is an option yes, but you also rightly mentioned that it is a shame if a mobile user arriving do not know that this view is filtered (they wouldn't on airBnb for example). I see two versions: 1) listing the filters. 2) simply stating clearly that this is a filtered view or 3) assume that the filter/search button is enough to indicate the existence of filters (possible color coded or marked when used) This seems especially important for occurrence search that probably isn't explored through free text search. So even if we had it on the page it would be empty most of the time.

FAB vs header button We use the floating button on occurrences detail pages for feedback. And share on article pages. The plan was to have that for filters on mobile. But I'm in doubt if it is better to stick with the header drawer toggle that have initiated the search in the first instance. The argument for the FAB is that it might be more obvious and in line with the one on the occurrence page. Basically using it as the button for primary interaction with the page at hand. The argument for not using the FAB in this case is the real estate it takes and that search is initiated from the top bar

From here Either way the mobile view hasn't been implemented yet, so I'm thinking that it makes sense to pause here and talk again when there is something that you can use and give feedback on.

The first iteration will likely not be much different, but at least there will be less arm waving when talking.