[community] search function for support.tpo

[Linus Nordberg]

emma peel <emma.peel at riseup.net> wrote
Fri, 16 Nov 2018 07:41:00 +0000:

> silvia [hiro]:
>> 
>> On 11/15/18 10:06 AM, emma peel wrote:
>
>>> What I like about the 'central search' idea is that you can get a
>>> User Manual result when searching Tor Support... because we have so
>>> many different pieces of content that I liked the idea of moving
>>> the user from one site to the other through the searches.
>>>
>>> Is this still going to happen with your proposal?
>> 
>> I like that too, but I think UX wanted search results per portal?
>
> I don't know about doing it project-wide, but I feel that for example
> support.torproject.org and tb-manual.torproject.org could share search
> results.

I think this is a good time for figuring out what Tor Project wants from
a search function. I've put down a couple of statements sprinkled with
questions below. Please jump in and argue against false statements and
answer questions where possible. And please add more questions.


- The web site support.tpo needs a search field and a button next to it
  resulting in the user seeing a list of matching url's (and their
  titles) in their browser.

- What corpus would such a search look at? support.tpo only? support.tpo
  and tb-manual.tpo? More than that?
  
- Are there other tpo sites that need/want a search function? Should
  search results include matches from other tpo sites as well, or only
  the one the user is currently visiting?

- Sending the user to a separate site, say search.tpo, is considered not
  UX friendly enough.

- Is search.<site>.tpo good enough?

- Are we limited to using solr, as mentioned in #25322, or can we
  explore other options?

- User fronting tpo web sites are "on the static rotation" because
  that's how we can keep them up and running given the resources at
  hand. Adding dynamic content, i.e. anything that is not "oh, that url
  corresponds to this file, let's send it to the user", would not be
  possible on our current set of VM's given the load we see on user
  facing tpo websites. This means that one of the proposed solutions
  with web servers proxying requests to a separate service, search.tpo,
  is not an option. Another argument against proxying is that it breaks
  the expectation of end-to-end security given by HTTPS.