Closed taymonbeal closed 3 years ago
Swiftype Site Search is the only one of these that we could integrate without writing a lot of custom code. Swiftype App Search is an API service; it's only useful if we write or find something that uses it. The Elasticsearch hosted offerings are even lower down the stack than that; it only really makes sense to look at those if we happen to have something that needs an Elasticsearch cluster to power it.
(Also, Elastic's first-party hosted offerings tend to be targeted towards larger-scale customers, at a higher price point than we're looking for. Bonsai.io is a competitor whose offerings are suitable for smaller organizations like us. AWS is also an option, since it scales up and down.)
As for maps, Google Maps is probably the best place to start; they have the best map data and are the de facto standard. It's pretty straightforward to put a bunch of markers on one. The bigger issue is getting the data in place to populate those markers.
I'm particularly disinclined to spend too much time on a sophisticated search solution pre-launch because I think there's a real chance that it'll wind up being worse than the five-minute Google solution. (Making a good search out of a small corpus is actually a pretty serious technical challenge.) Ideally we'd just install the Google search on the staging instance right away and then later switch to a different solution if it performs better, but unfortunately Google only works with sites that are already live, so we'll have to first launch with whatever we can easily integrate on the staging site, and then do the comparison with Google.
I think we should disentangle medium-term ideas/solutions and short term ideas/solutions. I generally agree that if we just want to get something up, a google custom search would probably be fine but we would need to configure it for a non-profit or otherwise we will get ads in the results (https://ziplineinteractive.com/blog/10-alternatives-google-site-search/). Moreover, it won't be a nice integrated experience at all, so I wouldn't want to keep this in the long-run. But for an MVP I would be fine with it if we start working on a better solution in the background.
Regarding the options, it wasn't meant as an exhaustive list but rather as an illustrative example of the different kinds of options out there. As you say we have the options from using lower to higher level building block, each with distinctive advantages as well as shortcomings. For the medium-to-long-term it will make sense to consider all of them. For example, if we think about the hub as a central repository for data crunching in EA, I do see a lot of value for going lower-level than "site search". But we certainly agree that this might not be feasible or desirable for an MVP.
@Richenda would you be fine with going for a really simple search for the MVP and then work on something more sophisticated in the background? If so, we could use this issue to focus on the MVP and make a new one for the future search.
Algolia might be a good thing to try plugging in. It's available as a WordPress plugin, and is recommended by Netlify (the world's experts in Git-based static site hosting) for that use case as well. It also has a free tier, and as a registered nonprofit we're likely to be able to get their paid tier for free as well.
What do people think of me trying to just plug it into the existing staging site and seeing what happens?
Actually, are there any specific requirements we have at this point that the existing search doesn't fulfill?
So just to document my meeting with David. They use Algolia and are very satisfied with it. They also have a free tier for open source/non-profits. Regarding development time, he said it's really easy to get going. They have client libraries for front end stuff, etc.
There is also a Wordpress plugin if we should have wordpress involved in our stack. But I am with Taymon that we should think about what our requirements are for the MVP (#11). This may be something that's more suitable for a second version (really depends how much time we have right now and if we want something to wow the community at the relaunch)
I think we should disentangle medium-term ideas/solutions and short term ideas/solutions. I generally agree that if we just want to get something up, a google custom search would probably be fine but we would need to configure it for a non-profit or otherwise we will get ads in the results (https://ziplineinteractive.com/blog/10-alternatives-google-site-search/). Moreover, it won't be a nice integrated experience at all, so I wouldn't want to keep this in the long-run. But for an MVP I would be fine with it if we start working on a better solution in the background.
Regarding the options, it wasn't meant as an exhaustive list but rather as an illustrative example of the different kinds of options out there. As you say we have the options from using lower to higher level building block, each with distinctive advantages as well as shortcomings. For the medium-to-long-term it will make sense to consider all of them. For example, if we think about the hub as a central repository for data crunching in EA, I do see a lot of value for going lower-level than "site search". But we certainly agree that this might not be feasible or desirable for an MVP.
@Richenda would you be fine with going for a really simple search for the MVP and then work on something more sophisticated in the background? If so, we could use this issue to focus on the MVP and make a new one for the future search.
Sorry for not spotting activity in Github. I am good to trial Algolia for the MVP with the idea of perfecting search for the longer term version.
In addition to the functionality of a search, where I come from is that the aesthetics of it are really important, and that is what I would want us to be able to improve on. It's not just what information a search pulls up that is important but also how those results are displayed. I think people are more likely to follow through on results, and experience them as user friendly, if those results are laid out in a pleasing way visually rather than just being a block of rows of text.
Before this is ready to pick up, we need to think about how to do this, what technology to use etc
I wonder if we could find an open source alternative to elastic search
Yeah our choice is probably limited to Elasticsearch vs Apache (https://lucene.apache.org/solr/). We want to have a search box in the navbar that searches through profiles and groups. It should work like:
Later:
@michaltrzesimiech @cafelow My initial estimate on this task is that it's quite a big job, which can easily take a net week of developer time (this is a very rough estimate, might be weeks more or days less). So my ETA on this, given our current velocity, is that it will take 3+ months too develop (and this + could be significant).
If we think we want this sooner and it has high value, it might be worth to onboard someone experienced in this or even apply for a grant to pay someone to do this.
I'm not too fussed about this feature. I am VERY keen on a resources search function though as that has been identified by several users as something they want or reasons why they preferred the old system of having all the resources on a google drive.
I am happy to help apply for funding and advertise for a dedicated engineer to help deliver this. Thanks for the detailed breakdown @michaltrzesimiech In my view the search is essential. When we set out, the intended MVP included resources, a good search, the profiles and projects. How I see it is that users and the community need those things in place for its potential to really be clear.
Just posting some possible cloud services:
What may be interesting is that with something like Kibana we could probably get a lot of the map application for free: https://www.elastic.co/elastic-maps-service