add switftype search

[svelle]

This PR adds the federated swiftype search to the docs to search multiple sources (as of now kb and docs) at the same time.

[github-actions[bot]]

Newest code from svelle has been published to preview environment for Git SHA d15355a5dbfa37d3db67cabcd1d68da8d4601865

[github-actions[bot]]

Newest code from svelle has been published to preview environment for Git SHA d15355a5dbfa37d3db67cabcd1d68da8d4601865

[svelle]

@cwarnermm I think this is ready for review. Do you think it would make sense to also add Emily as a reviewer to go over the style changes?

[github-actions[bot]]

Newest code from svelle has been published to preview environment for Git SHA 05ec2a3d9d3c885f190a0db5e6dfe6a6b56a4be3

[github-actions[bot]]

Newest code from cwarnermm has been published to preview environment for Git SHA 803f2965f6e5ea79d5934347a868275c4b304135

[github-actions[bot]]

Newest code from cwarnermm has been published to preview environment for Git SHA 803f2965f6e5ea79d5934347a868275c4b304135

[svelle]

Thanks @emdecr this is super helpful.

However this will also make this a lot more complicated since for now I was relying on the search implementation that swiftype provides and any customization means I or we will have to implement this completely ourselves. Not that that's a bad thing, I already thought this would eventually be the case so lets just take the time and make it right from the get go.

I'll see what I can come up with on my own and report back. In the meantime I'll set this back to work in progress, since this will take some time :)

[github-actions[bot]]

Newest code from svelle has been published to preview environment for Git SHA 803f2965f6e5ea79d5934347a868275c4b304135

[neflyte]

Hi @svelle :) I cloned the branch and ran a build but I didn't seem to get the search working. I get an ERR_INVALID_URL when the index page tries to load st.js; I think this happens because i'm testing locally and not on a public host somewhere. Do you know of a way to make this work in a local environment?

BTW: You will want to update your branch against master as it appears to have changed.

[svelle]

Thanks @neflyte I'm happy to help where I can. How are you building your local branch? I'm really just running it with make livehtml but happy to check if there's anything else I might've changed.

[neflyte]

@svelle I see what's happened. Apparently the page needs to be served from a web server to get the swiftype search to work. If i open the locally-built index.html as a file in my browser, the swiftype integration doesn't seem to load. :smile: Using make livehtml runs a local webserver, so that resolves the issue.

[neflyte]

I was able to apply some styling to make the autocomplete results look nicer. The following was added to the end of the redesign CSS styles in source/templates/index.html:

/* swiftype styles */
.st-install-Hxat6NPk3oUDZDszHuga .st-ui-result .st-ui-type-heading {
    font-size: 16px !important;
    font-family: "trade-gothic-next", "Lato", "Helvetica Neue", "Arial", sans-serif !important;
    color: #1C58D9 !important;
}
.st-install-Hxat6NPk3oUDZDszHuga .st-ui-result .st-ui-type-detail {
    font-size: 14px !important;
    font-family: "trade-gothic-next", "Lato", "Helvetica Neue", "Arial", sans-serif !important;
}

I couldn't find a way to make the autocomplete results float along with the search box, however. It seems the location of the results is dynamically controlled by the swiftype library.

Hope this helps! :smile:

[cwarnermm]

@svelle - We weren't able to make changes on your fork. However, @neflyte has provided the specific CSS code needed to brand the federated search results based on Marketing's recommendations. Would you be open to applying these updates?

@emdecr - @neflyte notes that he wasn't able to make the autocomplete results float along with the search box, however. It seems the location of the results is dynamically controlled by the swiftype library. Would you be open to taking a look to see if there's anything you're able to suggest to float the results?

[svelle]

@cwarnermm added his changes, waiting for the preview environment to build now :)

[cwarnermm]

@svelle - I suspect that the build preview isn't generating because this fork is quite a bit outdated compared to master. You'll need to update your fork to get the latest changes from master, and then update your branch on your fork with the updates from master.

[github-actions[bot]]

Newest code from svelle has been published to preview environment for Git SHA 9754598bc0e9c06a273afedff2d98dc887f1967b

[emdecr]

Thanks for your patience folks! @neflyte was spot on about the library dynamically injecting the results container – it just tacked it on way outside of the search field area.

But seems like we can assign a results container? https://swiftype.com/documentation/site-search/guides/design-and-customization#result-container

In source/templates/index.html:

<div class="landing-search" role="search">
    <form id="rtd-search-form" class="wy-form" action="{{ pathto('search') }}" method="get">
      <input type="text" name="q" placeholder="What are you looking for?" class="st-default-search-input" autofocus />
      <input type="hidden" name="check_keywords" value="yes" />
      <input type="hidden" name="area" value="default" />
    </form>
</div>

...if we add in a div with the st-search-container class, we should be able to specify which container results show up in and style accordingly, so that the results can sit relative to that parent container (.landing-search) or somewhere else – ex:

<div class="landing-search" role="search">
    <form id="rtd-search-form" class="wy-form" action="{{ pathto('search') }}" method="get">
      <input type="text" name="q" placeholder="What are you looking for?" class="st-default-search-input" autofocus />
      <input type="hidden" name="check_keywords" value="yes" />
      <input type="hidden" name="area" value="default" />
    </form>
    <div class="st-search-container"></div>
</div>

cc: @cwarnermm @svelle

Not 100% sure that this is the case, but hopefully this helps with troubleshooting.

Let me know if you have any questions/how else I can assist. TY!

[cwarnermm]

@svelle - Would you be open to incorporating Emily's feedback?

[neflyte]

I gave @emdecr's changes a shot but I'm not getting results in the custom div. I suspect this is due to a setting on the Swiftype side. @svelle, could you take a look at the Swiftype settings for Site Search and see if it's configured for "Results Container"?

Here's the Elastic forum post that led me down this path: https://discuss.elastic.co/t/cant-configure-search-results-to-show-up/207401

[cwarnermm]

@svelle @emdecr - If we wanted to make the search criteria highlight more obvious, where would a change like that need to be made? Via Swifttype or via the formatting code for the results container?

[emdecr]

@cwarnermm To clarify: the highlight for the search term in the results? Just took a look again, and if that's what you're referencing, agreed that it's a very faint blue 👍

Should be something we can address with CSS vs settings for swifttype.

[cwarnermm]

@svelle - Thanks! Yes -- it's a very faint blue. We'll want to make that more obvious, especially since users are used to the bright yellow highlight available today.

[cwarnermm]

@svelle - Can you please take a peek at the SwiftType settings for Site Search and see if it's configured for "Results Container"? (See @neflyte's comment above)

[svelle]

@cwarnermm I just checked swiftype and I noticed a problem with this. I currently have it setup without results container. I can change it however that would probably break the existing search in the KB, so either I have to figure out if I can create two searches for the two sites that point to the same search engine, or we'd have to create custom CSS for the KB to also use the search container.

[svelle]

Okay I was able to change that setting without breaking the KB it seems

I've activated the following settings. Let me know if that helps @cwarnermm @neflyte

[cwarnermm]

Thanks so much @svelle!

[neflyte]

I spent a little more time with this and I think there's some confusion around the different Swiftype components at play. There are two ways Swiftype surfaces information to the user: autocomplete and search results

A second after we type something into the search box, a pop-up appears below it with what looks like search results. This is actually the autocomplete.

When we press <Enter> in the search box, the search results are loaded and displayed.

Swiftype seems to give ways of configuring search results but not the autocomplete; search results can be displayed in a pop-over dialog (the "Swiftype Overlay"), in a static <div> container, or a dedicated search results page. Currently we've got it configured for a static <div> container, however this may not be the desired approach as it seems to apply everywhere Swiftype is used. The docs site and the KB site would need to align on layout for the static container to make sense in both places.

I'd like to suggest a couple next steps:

• Revert the change to Swiftype results; this will display search results in the "Swiftype Overlay"
• Take another look at Swiftype's display options to see if there's a way to satisfy the needs of both sites, and potentially others if this solution fits

Note that the KB site is using the same Swiftype account as we're using here; changing display settings will affect the production KB site immediately.

[cwarnermm]

@svelle - Any objections to closing this docs PR since docs search is moving in a new direction and integrating SwiftType has proven to be quite challenging?