Discussion on search page layout/design

[Pasanna]

As discussed in the search bugs thread, the search layout is wonky and confusing.

The problem

A lot of the wonkiness comes from there being no boundaries on the search-results-item section. I’m about to submit some fixes on this area to help contain the results in their column. In the process of figuring out how everything existed I drew a wireframe. It’s SVG. Do with it as you like! Everything in this component appears in both desktop and handheld

This is just a close-up of the search-result-item

The confusing is the content position.

Firstly with mobile, it is currently displaying as two columns, thanks to this function.

Which looks like this currently.

or this

but will not crash out of it’s column once I apply the fixes to .search-result-item’s children.

Our starting point

More wireframes

Because the above is a bit confusing, I have more wireframes.
They’re all SVG, so you can play along.

Current desktop layout

Current handheld (up to 700px)

Current handheld when you do a title search

Handheld, if we were to remove the two bits of heavy handed styling in the above mentioned function.

Fixes to the ‘search result item’

ETA: The overflow/escaping has been fixed and a PR is waiting in the wings to be updated.
This is what it looked like before.
(I added the red line to illustrate the edge of the div that the content was escaping from).

After
(with the red line, to show the fix)

And the following are what was submitted in the PR, showing different screen sizes.

---

What do we want search to look like heirarchically?

Search at the moment seems to return 3 kinds of things.

• search result items (translations, followed by root texts- 20 at a time)
• dictionary cards
• suttaplex cards

In a desktop setting, the left hand column is prime real-estate for search.

In handheld,
I think that we should go to full width, single column and decide on our order.

1. search results (max 5 for mobile, with a load more)
2. suttaplex cards
3. dictionary/maps (reference items)

Is my current thought on this

How this plays out on desktop, I’m not so clear. I like to read the dictionary entries if they pop up, but that’s not usually what I am searching for. I wonder if we can have dictionary in a closed accordion. This would help the suttaplex cards rise to the top.

I’m also not sure whether suttaplex cards should get lefthand side real estate, and if so when?

I’m opening this up for discussion.

What do you think?

[Snowbird]

Venerable, thank you so much for bringing all this up. It is in need of serious help.

Regarding desktop/wide layout…

@Pasanna

I’m also not sure whether suttaplex cards should get lefthand side real estate, and if so when?

I am 100% opposed to putting suttaplex results in the right hand column. (as it is now) The difference between a suttaplex result and what you are calling a “Search result item” is that if the search term is in the title of the text it is displayed as a sutaplex card. To me this is completely arbitrary. In both cases the result is a sutta/text.

I think it makes sense to have the dictionary (and map results, btw) in the right column because they are fundamentally a different sort of thing. (Kind of like how google used to put the ads in the right column. Those were the days!)

But as it is now, the more central the term is to a sutta (i.e. the term itself is in the title) the more we obscure it by putting it in the right column. I can’t tell you how many times I have been confused by search results because of this.

[Pasanna]

I agree with all of this!

I think about the right hand column as the place in duck-duck-go that has the wikipedia clipping etc. Perfect for dictionaries and maps.

It was hurting my brain from a design perspective to put the suttaplex cards in the lefthand side. However, I’m sure this is a challenge we can overcome, because I fundamentally agree with you on their importance.

Is there a time where a search-result-item would outrank a suttaplex card?

[Snowbird]

Currently there is no ranking done with search results. AN results come before DN, MN, and SN.

As I said, the only difference between suttaplex and non-suttaplex results is that the search term is in the tile. That could be the pali title or the translated title. And sometimes it will be a string of English found in a Pali title, which is really confusing.

I have never understood the logic of having two kinds of text results. I had proposed a hybrid card that was a mixture of both, but that got rejected (probably rightly so!)

[agilgur5]

@Pasanna

a PR is waiting in the wings to be updated.

The PR, for reference: fixes to stop the contents of search results escaping/overflowing by delightedbydhamma · Pull Request #3676 · suttacentral/suttacentral · GitHub
I’ll take a look and review and test it when I can, although I only have triage permissions right now.

The red lines are quite helpful for illustrating the problem too!

Thanks for all the wireframes too - similarly helpful references!

@Snowbird

I am 100% opposed to putting suttaplex results in the right hand column. (as it is now)

@Snowbird

I think it makes sense to have the dictionary (and map results, btw) in the right column because they are fundamentally a different sort of thing.

@Snowbird

But as it is now, the more central the term is to a sutta (i.e. the term itself is in the title) the more we obscure it by putting it in the right column.

Agreed on all. I forgot about dictionaries and maps.

I don’t know what the past rationale for having a full suttaplex card was, but if it was just to make all the different translations and parallels etc visible directly in search, there is a different way to handle that: make the title expandable into a full suttaplex card.
Although if someone is familiar with the UI/UX, the extra click to get a suttaplex when you’re on the text already is pretty straightforward navigation. I.e. if the title was not expandable or a suttaplex and was just a clickable title (same as the other text), that seems fine to me.

Honestly, not having any special logic for titles seems better in a way - the display and usage is consistent regardless of text vs. title. More consistent UX than having a special case for title.
Plus less code

Can say ditto regarding currently confusing parts, I have to keep remembering how search works:

@Snowbird

I can’t tell you how many times I have been confused by search results because of this.

@Snowbird

And sometimes it will be a string of English found in a Pali title, which is really confusing.

[Pasanna]

This might be a bit distracting from the discussion, which is mainly about how we handle results.

However, I’ve been wanting to propose a more GUI solution for search filter for years.

This is based of the standard GUI for other search engines like ddg and google’s image search filter.

I haven’t figured out how to do references, as this is a different kind of search.

[agilgur5]

@Pasanna

However, I’ve been wanting to propose a more GUI solution for search filter for years.

I proposed something similar before too:

@agilgur5

In particular, I think having a “Filters ” dropdown button in the search bar (left or right) or just below it would already improve it a lot.
Lots of websites already have this, so it is somewhat of a UX convention. Some examples being Amazon and GitHub:

GitHub in particular updated the search UX a few years ago. Prior to that it was very similar to the current SC experience where there was a page describing filters and you could type them in, but there weren’t many other indications.

When you click on a filter in the dropdown, it could just move the filterX: text into the search bar.
As a first pass, could even just have the “Filters ” button just link to the /search-filter page, with no other interaction initially, just a more explicit button

Additionally (can be added later), if a filter is fully written out, the UI can convert it to a pill shape inside the search bar to differentiate it from the plaintext query. Or do it similar to GitHub with the highlighting, or current SC with the text color change.