MD search results page

Meta SC Next
1

Presentation of search results closely follows the implementation at the MD spec site:

Here is a visual (non-functional) mockup in plain HTML.

search-results.zip (447.1 KB)

And here is a screenshot of the top of a search results page.

image
image1904Ɨ2020 567 KB

Here I will specify each point in detail. Note that the line between UI for search and search functionality is not always clear. What i describe is an ideal to aim for, and we implement what we can.

##General

:point_right: Use sans serif throughout, except where noted.

:point_right: Container has the same width as suttaplex list.

:point_right: Show ten results.

:point_right: When a search term is the head word in a dictionary, that should show as the top result.

##Header

This is as normal, with the following details

:point_right: Main title says : ā€œSuttaCentral ā€” search resultsā€

:point_right: Use a distinct header color. Green means ā€œGo!ā€ Use MD green 600 = #43A047

#search options

The aim of search results is to immediately get the user what they are looking for. We should aim to minimize or eliminate completely any complications of UI.

Old version has options for ā€œadvancedā€ (which is actually ā€œprimitiveā€) and ā€œdetailsā€. These should be eliminated.

Occasionally a search term might show so many results that additional filtering is required. This is especially the case in examples such as the one shown, where Sāvatthī shows up frequently in root texts, translations, and dictionaries. To handle such cases, use a dropdown menu, with options:

  • All
  • Root texts
  • Translations
  • Dictionaries

This dropdown is normally hidden, and only shows when necessary. The two necessary conditions are:

  1. The results are in more than one category of root texts, translations, and dictionaries, and
  2. there are more than ten results in total

:point_right: When a search meets both these requirements, show the dropdown.

#language filtering

The search results show for your primary language, as selected for the main UI, as well as source texts. Generally, it will be rare for a term to appear in more than one language. Exceptions include:

  • proper names
  • technical terms, which may be left untranslated
  • Chinese, which occurs in both root texts and translations.

If it is necessary to filter language additionally, it should be adequate to use the main site language filter. Adding an extra language filter will essentially do the same thing, adding complexity to little use.

:point_right: Language filtering is determined by main site language selector.

##Results heading

:point_right: Main <h1> heading for results gives the number of results.

Knowing the number of results is useful on SC. Rather than adding extra text saying ā€œ10 of 64 resultsā€ or something, it is cleaner to just add it in the heading.

:point_right: Style the term in the heading in primary green, bold, serif.

##Results

Entries follow style on material.io. The main layout of the search results is similar to the suttaplex list. The text sizes, vertical metrics, etc. should all match.

Beneath the results heading, we have a line of secondary text that shows:

  • For text results, the URL
  • For dictionary entries, the name of the dictionary.

:point_right: Metrics and styles match suttaplex (except where noted)

:point_right: Heading of search results is <h2>, styled weight normal, sans, primary green.

:point_right: Use primary green and bold to highlight the search term in results.

:point_right: Use a simple divider between results.

##Load More

Rather than paginated results, load more results as the user scrolls to the bottom. In case auto-load is flaky, have a load more button at the bottom. Load an additional ten results each time. Here is a mockup.

image
image1896Ɨ2027 242 KB

##Map

The Google map works well, and should be promoted more.

:point_right: Show the map on main search results when the search term is a head word for a dictionary entry that is in the map

:point_right: Show the map at full width (rather than 50% as old version)

#dictionary definitions

When you click on a search result for a dictionary entry, you get a page with entries from the several dictionaries that we host, as well as a sidebar listing ā€œadjacent termsā€ and ā€œsimilar spellingā€. Generally speaking, this will remain the same, adjusted for the MD design.

The name of the dictionary can go as secondary text above the term, rather than at the side as in the old design. This creates a minor inconsistency with the main search results, where the name of the dictionary is below the term. It seems hard to avoid this, however, as there may be more than one result per dictionary.

Otherwise the structure of entries remains unchanged, with head word, grammatical information as secondary text line, then main entry. Etymological info goes as secondary text at the end.

Note that the list structures of entries especially in PTS dict can be quite intricate. The default appearance of HTML lists is tricky to modify, so this is handled with some fairly delicate CSS. Ensure that the appropriate list CSS is applied here.

As for the sidebar, this can remain as is. A couple of details. We should remove the right-arrow pointing to the current term. It is enough for this to be bolded and highlighted with the primary green. Other terms can simply be main text color, with headings in bold and in secondary text color.

On narrow screens, shift the sidebar to the bottom of the page.

2

So, 6 impossible things before breakfast. :smiley:

I watched a few polymer videos on Sunday. It looks pretty cool.

The main tasks then would be:

  • Create the card elements - sutta, dictionary, anything else that might turn up in a query. The sutta card may be reusable by @vimala in her division view.
  • Grab search results as JSON from our REST API.
  • Display cards in a multipage list.
  • Implement search options in the MD Tabs.
  • Other todo items.

Iā€™ll be starting with unstyled HTML, first focusing on grabbing the data and displaying it.

3

I donā€™t know, I just like to have a nice walk and a cup of coffee before breakfast. Then Iā€™m ready for the impossible!

Perhaps the other way around, check what sheā€™s using and adopt them. paper-card is pretty standard and generic.

Having said which, I would recommend having a look around and seeing how a few different MD sites show their search results before getting too much into details. I expressed reservations about using cards for search results, and these grow the more I look into it. For example, the Material Design site itself, which is where this recommendation comes from, doesnā€™t eat its own dogfood:

It just has a divider between results. Inbox by Gmail is similar. The new Youtube in MD doesnā€™t even have a divider.

So I would suggest ignoring the whole card thing. Anyway, the main thing is to get the results in a sane and clean markup from the search results. We havenā€™t discussed this, but I assume these will be in a similar form to what is provided currently. It will probably be easiest to simply start with what we doing now, and make the minimal changes necessary.

Yes.[quote=ā€œJhanarato, post:2, topic:5035ā€]
Display cards in a multipage list.
[/quote]

Yes.

Iā€™d leave this till last. Ideally we can make the search cooler and eliminate these entirely. But this is not something that is on our immediate roadmap. Iā€™ll have a chat with Blake about it.

4

OK, so today is one of those days - guests sorted, email read - 8:10am and itā€™s time for some hacking. :slight_smile:

You know, I just looked at the existing search page for the first time. I can start work on a MD version of that.

5

Another good example:

https://www.webcomponents.org/search/list

More simple:

https://www.polymer-project.org/search/?q=paper

As far as I can see, neither use cards.

6

Indeed, yes, simple is best.

Another few:

https://developers.google.com/s/results/?q=cat&p=%2Fweb%2F

https://angular.io/search/#stq=car&stp=1

7

Just one remark about iron-list. Iā€™m have abandoned that one because it gave a lot of problems with other elements in that the iron list is always on top and you cannot get rid of that. Itā€™s a known bug on GitHub and Stackoverflow but they have not figured out a way around it yet. So if you have an iron list, and somewhere else there is a dropdown-box, the dropdown will appear underneath the iron-list.

There are a couple of good courses on Pluralsight:



You can do a 10-day trial to watch the videos and get the example-files.

1 Like
8

Interesting. I myself spent several hours trying to get the <iron-input> example to work.

If you go to this page: https://www.polymer-project.org/2.0/start/quick-tour

and scroll down to ā€œBind to a propertyā€ you will find the editable-name-tag.html works only if you use the links as they are:

<link rel="import"  href="https://polygit.org/polymer+2.0.0-rc.2/iron-input+polymerelements+:2.0-preview/shadycss+webcomponents+1.0.0-rc.2/components/polymer/polymer-element.html">
<!-- import the iron-input element -->
<link rel="import"  href="https://polygit.org/polymer+2.0.0-rc.2/iron-input+polymerelements+:2.0-preview/shadycss+webcomponents+1.0.0-rc.2/components/iron-input/iron-input.html">

By changing these to the local bower_components directory you lose the interactivity between typing and updating the text. My idea was to use <iron-input> with <iron-ajax> and update the ajax params property on the fly. It is just an idea, and perhaps not a good one. Anyway, Iā€™ve given up on that for now.

1 Like