Re: Adding Search Functionality to boost.org

From: Darryl Green (darryl.green_at_[hidden])
Date: 2023-06-24 04:05:43

On Fri, 23 June 2023, 4:30 am Mohammad Nejati [ashtum] via Boost, <
boost_at_[hidden]> wrote:

> Hey everyone,
>
> One of the issues with the current Boost website is the absence of
> search functionality... However, this
> approach has several problems. ... versions ... Secondly, it lacks a proper
> hierarchical presentation to effectively guide users. Moreover, there
> is no way to filter the results for a specific library.
>

These are addressed which is great.

This hierarchical presentation can
> significantly enhance the user experience.
>

It does. This is very nice.

> The Boost libraries utilize various documentation formats such as
> QuickBook, AsciiDoc, Doxygen, and even multiple handwritten formats.
> This diversity posed a challenge in creating a generic crawler script.
> To overcome this obstacle, we initiated the Boost.Gecko project. This
> project involved the development of 16 custom crawlers, tailored to
> extract search records from the 151 Boost libraries.
>

We have leveraged this library to design a
> customized user interface for the search box, enhancing the navigation
> of search results.
>

I was interested in seeing how this would work for searching for features
across libraries. This works (chose an arbitrary library and you get the
"other libraries" results. However these are neither ordered nor grouped by
library, presumably there is some other ranking at work, which makes sense.
It would be a nice enhancement to list "hits per library" and allow
selection of a library from the result set to view just that library's hits.

 Our plan is to incorporate a search button
> into the header of every library page, defaulted to search within that
> specific library.
>

This would still benefit from a better (condensed) "other libraries"
handling - simply being able to navigate to another library and see the
result of the same query in that libraries context would be nice.
A search for "asynchronous" produces 1.8k hits across multiple (hard to
tell how many in current interface) libraries.

That isn't a criticism. It's a "this would be a nice feature" note.

Thanks
Darryl Green