Then I clicked to show more, because I know there are a lot more tags and want to make sure that if I tag a post it has all of the proper tags (because if I don’t it’ll be marked as tagged and it’s likely that no one will return to it to add the proper tags):
But this view isn’t organized well like the concepts portal is (below), so I felt the need to skim through each individual tag, which took a long time. Seems like it’d be a good idea to organize the above view to look more like the below view.
I don’t think this issue would go away with replacing algolia. The problem is a sort of generic “algolia is faster than making a database query, but that speed comes with some default settings that require re-wiring, which I’m sure is possible but requires some upfront costs that aren’t part of my usual workflow. I think any search engine would come with the same issue.”
(Don’t know how much the rest of LW wants to hear our internal dev discussions, but) it’s also things like Algolia, at least on our current plan, doesn’t have personalization, e.g. to recommend tags a person previously used or tags we algorithmically guess would apply this post but would want a human you check.
Mostly going off Oli saying leaving Algolia is would be the way forward here. You might be right that no other solution will be better for this particular thing.
I am pretty confused what any of this has to do with Algolia. The primary problem to me appears to be that we don’t actually have a large fraction of the tags categorized in the tag hierarchy displayed on the All Tags page. We could show you a copy of the tag page table, but that would omit a lot of new tags, and also probably not be dense enough. We could develop some custom UI for that menu to group them, but that’s mostly a bunch of work (and doesn’t have super much to do with Algolia).
The site search will probably always have somewhat different constraints than normal database operations (in particular if we want to stay within the autocomplete paradigm), so I don’t think anything about this would get easier if we switch away from Algolia (things like this are actually a domain where Algolia is pretty great).
I stand corrected and I hope Algolia is accepts my apologies for the slight. The actual table I don’t think is much a possibility, if desirable at all, but structured things are good. The alternative is just ordered things, if we can accurately predict which things are likely.
Yeah, ok. I do think personalization is blocked on Algolia, and I didn’t really think about this as a potential solution to this (but it totally is). So yeah, maybe slighting Algolia was the right call.
When I click “Add Tag”, this is what I see:
Then I clicked to show more, because I know there are a lot more tags and want to make sure that if I tag a post it has all of the proper tags (because if I don’t it’ll be marked as tagged and it’s likely that no one will return to it to add the proper tags):
But this view isn’t organized well like the concepts portal is (below), so I felt the need to skim through each individual tag, which took a long time. Seems like it’d be a good idea to organize the above view to look more like the below view.
Agreed. It’s just actually a bit annoying to get it to work right, due to how the algolia search function works.
I think that adds to the reasons to perhaps replace Algolia.
I don’t think this issue would go away with replacing algolia. The problem is a sort of generic “algolia is faster than making a database query, but that speed comes with some default settings that require re-wiring, which I’m sure is possible but requires some upfront costs that aren’t part of my usual workflow. I think any search engine would come with the same issue.”
(Don’t know how much the rest of LW wants to hear our internal dev discussions, but) it’s also things like Algolia, at least on our current plan, doesn’t have personalization, e.g. to recommend tags a person previously used or tags we algorithmically guess would apply this post but would want a human you check.
Mostly going off Oli saying leaving Algolia is would be the way forward here. You might be right that no other solution will be better for this particular thing.
I am pretty confused what any of this has to do with Algolia. The primary problem to me appears to be that we don’t actually have a large fraction of the tags categorized in the tag hierarchy displayed on the All Tags page. We could show you a copy of the tag page table, but that would omit a lot of new tags, and also probably not be dense enough. We could develop some custom UI for that menu to group them, but that’s mostly a bunch of work (and doesn’t have super much to do with Algolia).
The site search will probably always have somewhat different constraints than normal database operations (in particular if we want to stay within the autocomplete paradigm), so I don’t think anything about this would get easier if we switch away from Algolia (things like this are actually a domain where Algolia is pretty great).
I stand corrected and I hope Algolia is accepts my apologies for the slight. The actual table I don’t think is much a possibility, if desirable at all, but structured things are good. The alternative is just ordered things, if we can accurately predict which things are likely.
Yeah, ok. I do think personalization is blocked on Algolia, and I didn’t really think about this as a potential solution to this (but it totally is). So yeah, maybe slighting Algolia was the right call.