Site-wide Search
A search form that searches through all of the LearnWake content (Library, Forums, Videos).
A search form that searches through all of the LearnWake content (Library, Forums, Videos).
This will remove all of your current votes.
Remove your vote for this request?
Unfortunately, we can’t implement the search until Videos v2 is complete, because it’s a brand-new-system from the ground up, and search will work differently with it, than it will with the current Video section (which wasn’t built with search in mind).
More bad news… 2 days ago, I decided to convert our forums for PhpBB to bbPress. We will be moving forward with bbPress in the future. The reason why is because we will rely heavily on tags (keywords) for our Site-wide search, and PhpBB doesn’t implement tags (that is only one reason of many for the switch). I was trying to integrate “Forums” into our new Library v2, and that’s when I realized that our current solution isn’t going to work for accurate results. So onto bbPress we go. Obviously this will delay the site-wide search until the new Forums are done now too.
Good news…FINALLY! We’ll be rolling out Library v2 this week, and it’ll have a snazzy new “Quick Page Finder” feature. It only finds Library pages obviously, but the speed and technology behind it are similar to what I am thinking for the site-wide search.
All of our Library v2 pages are tagged, and all of our video and forum topics WILL be tagged with keywords when v2 rolls out for them. I’m thinking a similar type of implementation as our Library “Quick Page Finder” for our site-side search, except it’ll suggest tags instead of Library page titles. You’ll also be able to filter the sections you search (library, forums, videos) via the search form. So really, this wouldn’t be a site-wide search as much as it would be a “tagged content” search. By selecting a tag, you’ll be taken to a results page that’ll give you content that matches your tag.
The reason why I think this works is because I think 95% of our searches are probably for certain tricks (example search: “360″). If they are searching for a trick, then why not just be searching using tags (it would be much more accurate and efficient). Now, what would be lost is if someone wanted to search for something specific about a trick. Like, “how to get the handle on a 360″. Since that is too specific to be a tag, that wouldn’t work.
Maybe the correct implementation is a quick tag search that if they select one of the tags from the autocomplete, it searches for that tag. If the search doesn’t match a tag, it performs a standard-type search.