Feature Request: Search and Date View
badcat opened this issue · comments
While I love navigating by Tags, perhaps adding Search would be a good idea? Would also like the ability to have another View, such as By Date/Newest vs the Alphabetical view presented now.
thank you!
I'd be happy to attach a PR for search.
@stefanjudis Given the current technology stack of this project (static 11ty site), I think a relatively simplistic approach (not too fully-featured, as little JS as possible) would be appropriate?
@loilo thanks for jumping in here. 🙇♂️
Honestly, I'm not convinced that search offers much value (I'm happy to be convinced though :) ). The data available is name, tags and a short description. Often, the description includes the tag name. I have the feeling the tags could be enough. What do you think?
For the tech-stack, yeah let's discuss this when we agreed on something? :)
another View, such as By Date/Newest
This is WIP and I'll release it hopefully soon. :)
I think that search could be valuable in a very narrow case: When somebody returns to the site and looks for a tool they found on a previous visit. They may not exactly know what it was, but maybe they remember fractions of the title or something.
This happened for me (which is why I looked for an issue requesting search functionality), and it's also the only use case I personally can imagine — but maybe someone wants to chime in and explain theirs? @badcat?
Ja I don't know. This narrow use case doesn't convince me. 🙈 The site targets developers, so I think it's fair to say that the majority knows about CMD/CTRL+f (which is what you did on the All category, I guess?).
If there'll be pagination at some point, I think search could make more sense, but for now, I'd rather not implement it to save complexity and JavaScript. Is that reasonable? @loilo
I think assuming knowledge about on-site search is reasonable. It didn't come to my mind when I wanted search because I didn't realize the home page literally has no tag filters and shows all helpers. 😅
Sparing JavaScript would not be that big of a deal, the implementation would probably be about 10 LOC with an approach utilizing a dynamically filled <style> tag (using data-xxx attributes on the list elements and ad-hoc-generated [data-xxx*="search-query"] CSS rules). I've used this approach before and it works like a charm with basically no JS bloat and no external libraries. But I agree that even that little additional code is hardly justified if you could just hit CMD/CTRL+F.
Still, any other aspects/arguments for search, @badcat?
I'd recall that when I first came to the site I saw a handful of tools and less tags.. but now there are 60+ tools and nearly 20 tags and it keeps growing. How many tools will comfortably display on the ALL view without needing to paginate?
- Search seemed like a possible solution for finding things I may have previously seen and now are lost to a long or paginated view.
- By Date / Newest seemed like a nice thing to have for folks that come back every so often and want to see what was added - currently the alpha view makes this a chore.
FWIW, I'm now using RSS to keep track of what's been added. :)
By date will come soon.
Ja, ok – so I think we can agree on adding search until we have pagination. :)
Thanks for the feedback!
I kinda missed search too, yet cmd+f on the home page works, too 😉
Just read about pagination and stuff so yea then cmd+f won't be of much help 😅
For me personally, I think search / filter functionality would be a great addition.
As there are now 161 tools, if I remember this site has handy "PWA" or a "Hash" generator tools, it would be great to filter all the tools down to just showing those that match a keyword (rather then a use cmd+f / find next approach across the whole page)
Thanks for your response. :)
it would be great to filter all the tools down to just showing those that match a keyword
How is that different from the tags? The description most likely will match the one keyword and as by design every tool only has one sentence a full-text search doesn't offer additional discoverability because it's not matching variants anyways. :)
I understand why people are thinking of a search in the first place, but I doubt that with the current data set it'll will offer more value than the tags already do. :)
To be honest, I didn't really notice the tags menu items on the left but do see your point.
As there are 161 items though, for me it feels natural to have a search / filter in the top right hand corner.
A scenario I had was that that I knew this page had a hash tool to generate a SHA hash. There is no tag "Hash" so I had to search the whole page to find the tool I wanted out of the 2 that deal in some capacity with hashes. If there was a search / filter on the tool names, both "Hashler" and "CSP Hash Generator" would have matched and immediately I could have reviewed the 2 tools for the one I want to use.
for me it feels natural to have a search / filter in the top right hand corner
I understand. I'm more the cmd+f guy obviously though... :) And I really want to keep tiny-helpers very lean and minimal. I still think that optimizing the tags will solve the problem. :)
For your case of the hashing tools they're both under Data transformation. Would it help to give more info for every tag? I'm thinking of a subline or a ? that would have told you that hashing tools are included in there?
Or they could even have their own tag Hashing?
As a comparison, if you look at this page: https://frontendmasters.com/courses/
For me it's very handy to search / filter by keywords like "JavaScript", "Jest" & "GraphQL" etc.
Having said that, I can navigate your site using cmd+f fine and find the tools I'm after.
I like this site's Live search too. Hmm.. what if searching populated with existing tags by default. Of course the reason I like search was that my expectation is that the results would return MORE than just tags, perhaps including the helper's (Product) Name as well as the unique words in the description. IMO, FrontEndMaster's live search results that reveal only what's available is far superior to using CMD+F on a page only to have to still see all of the non-relevant content.
I love the conversation here and I'm totally up for being convinced.
For me it's very handy to search / filter by keywords like "JavaScript", "Jest" & "GraphQL" etc.
I agree that this is handy, this search is not great though. It's not reflected in the URL bar and it is not working without JS (yes, I'm one of these people 🙈).
Okay friends, after thinking this through I'm ok with adding one, if it's well done and accessible. :) I'll create a new issue for this and will link to this discussion.
For me though, my next thing to work on is to implement a login mechanism so that you can star helpers to keep track of them and offer a listing which is sorted by popularity. :) If anyone wants to give it a spin, I'm happy to review it. :)
Here we go #203. 🎉