UX: search results filtering

[NotaInutilis]

I've been testing out using Indie Wiki Buddy. It is a neat idea, but I believe that the search experience and the redirection to indie wikis over fandom (which is the main purpose of this extension) fails to actually send the user to its destination and deserves to be improved.

It mainly has to do with the results filtering. It removes results fandom results but does a very poor job for user redirection. For well know indie wikis, who rank 2nd or 3rd in a web search, they might appear on the 1st page, below Wikipedia, and be easily accessible. But for more obscure ones... They don't even show up in the first Google search pages!

Removing the fandom link does not mean Google will show me the indie wiki, especially when I'm not using English. Let's take the example of the VVVVVV Wiki.

The only redirection to the wiki offered by the extension is a small, 4 letter link, in a very talkative infobox: if I installed the extension, I know I prefer indies over fandom. The problems are that the link is not visible enough, there is too much useless text, and it does only redirect to the home of the wiki. A more precise search, on a character name for example, is rendered useless.

As a user (with no idea of the complexity of the task at hand), I believe the approach that the Redirect to wiki.gg extension uses is more efficient. Instead of removing results, it replaces them. This is completely transparent to the user, there is no need for a verbose infobox. Moreover, their implementation also redirects article to article and language to language (see this example with a specific page in French).

As I said, I'm merely a user, so this ideal solution for me might not work for you. However, the problem is still here and I hope it can be fixed because man, fandom is awful.

[KevinPayravi]

@NotaInutilis thanks for opening this issue and the detailed thoughts! I think it's an excellent idea, and I do love wiki.gg's implementation.

For context: When I first made Indie Wiki Buddy, I debated replacing search result links, but ended up just hiding results for a few reasons:

• Hiding results seemed simpler and less likely to break over time. IWB currently supports 7 search engines, several of which have different UIs based on browser, OS, and device. So it's quite a technical and maintenance challenge to reliably replace links, change link text, account for sublinks, embedded images, Q&A, etc.
• Replacing results runs the risk of still sending positive click data to Google when a user clicks on what was originally a Fandom link, which may impact ranking. This should be avoidable, but adds to the challenge.
• I made a poor assumption that most independent wikis (even relatively new ones) will rank near Fandom.

That being said, replacing results has been a popular request since the Minecraft Wiki fork, and I've begun working on it this week! Very early sample screenshot:

It'll take some time as I'm trying to make it run as reliably as possible, as well as making sure click data isn't sent for the original Fandom wiki link. Any thoughts or ideas on how this feature should look are very welcome!

Until this feature is ready, users can disable search engine filtering for wikis that don't rank well, and then rely on the automatic redirection when clicking on a Fandom result (though I know this isn't ideal).

[NotaInutilis]

Nice! (again)

Until this feature is ready, users can disable search engine filtering for wikis that don't rank well, and then rely on the automatic redirection when clicking on a Fandom result (though I know this isn't ideal).

This is my current solution which works well enough.

I knew that feature was more than meets the eye, but boy this is a long list of stuff to do! I'm quite curious though, how is your implementation different from the wiki.gg redirector? And why? Is their project younger? Sorry, this is quite a big question so don't feel obligated ton answer. It's just curiosity.

You're dealing with a lot of search engines, I'm reminded another extension that does so: uBlacklist. Maybe there's something helpful for you in their code, although what they're doing is the same as the current IWB: hiding stuff. If you aleeady know about it, good! Hopefully someone else reading this discovered this tool.

I like the little banner you're putting next to the redirected link. It's unobtrusive, informative enough and right where the user is looking for information.

If you can manage to reliably insert this banner next to the fandom results, it could serve as an intermediate step before you can implement a full replacement. Just adding a clealy labeled link to the indie wiki's home (or better, the equivalent article) is good enough to redirect the user. It's visible and easy to reach.

[KevinPayravi]

If you can manage to reliably insert this banner next to the fandom results, it could serve as an intermediate step before you can implement a full replacement.

That's a great idea, I think I'll do this! Would be good to get that working and released ASAP, and then continue to build on it from there.

I'll respond to the other questions/notes soon.

[KevinPayravi]

I'm quite curious though, how is your implementation different from the wiki.gg redirector? And why?

I think the two implementations are largely similar, at a high level. I think I do try to design IWB's DOM detecting and manipulation to be a bit more generic, to maximize portability between browsers and desktop/UI. This generally makes maintenance and adding new search engines easier, but it does make it harder to do complicated tasks (like re-writing results).

[KevinPayravi]

Update! For the new search filtering experience, non-indie wiki results can be disabled, and a button will be inserted linking to the indie wiki article.

Example:

This works across all seven search engines that IWB supports. It's not as sleek as re-writing the results, but it's more portable and maintainable.

My plan is for this to be the new default search experience, while the old "result hiding" feature will still be available as an option.

Updated options menu:

Feedback is welcome! The plan is to release this early this week.

[NotaInutilis]

Great!

I think the options menu would be clearer if the options were shorter. Moving the repeated part before the option list makes them easier to read. Something like this:

Behavior in search engines for Fandom results that have indie counterparts:

• disable and add links to indie wikis
• hide/remove from results
• do nothing

[KevinPayravi]

@NotaInutilis great suggestion, thank you!

I tried using fieldsets to accomplish this, and I think the separate sections allow us to neatly display additional useful info, such as a list of supported search engines. What do you think?

[NotaInutilis]

Indeed it looks clearer! The two wording nitpicks that come to mind would be:

• it's not an indie counterpart, it's a Fandom/Fextralife counterpart! Indies are the "best product", they should be treated as the main wiki, not an alternative!
• "Ecosia, & Startpage" looks weird but I'm not an English native. After a quick search it seems like the oxford comma shouldn't be used before an ampersand though.

I'm also thinking that the link to the indie wiki can benefit from showing the full URL, like a regular search result.

When the extension is set to hide results, it should keep a small disclaimer and toggle to show/rehide results. When they are show, it would be nice to have hidden results be clearly highlighted, like uBlacklist does.

[NotaInutilis]

Some other nightly thoughts:

1. For the settings menu design, I think that, once again, the wiki gg redirector is a good reference. It's simple, concise and clear in its design and wording (and it's also talking of old vs new, Fandom is the past!)

2. Bring back the emoji! Their use in the current design (between the selector and the text) is a bit weird and not in line with current standards/sensibilities but they're still great visual indicators. I believe that with the new fieldsets you can put them in the title fields. For example "🔎 Search engines" or "🔔 Notification settings", like Android uses them to illustrate the settings categories but not the settings themselves. If you don't like their look, maybe some other unicode characters or open source icon set can be a better alternative.

[KevinPayravi]

@NotaInutilis More great feedback, thank you!

Here's what I have now, which includes re-wordings and restoring the emojis. Please let me know what you think!

---

I'm also thinking that the link to the indie wiki can benefit from showing the full URL, like a regular search result.

Are you thinking of something like this? (ignore that the favicon is misaligned, that would be fixed if this is implemented).

---

When the extension is set to hide results, it should keep a small disclaimer and toggle to show/rehide results.

Indeed, the "hide results" experience will remain as it is (banner inserted at the top of search results with option to show/rehide).

When they are show, it would be nice to have hidden results be clearly highlighted, like uBlacklist does.

Interesting idea, will experiment with this!

[NotaInutilis]

I still have a lot of thoughts!

Regarding the settings:

• is the "global settings" title still needed now that there are categories?
• "extension is on" does not clearly communicate it is a toggleable button. I just tested it, I had no idea I could click on it! maybe it should be its own big button, like uBlock Origin does
• "Enable notifications for redirections" (to indie wikis and BrezzeWiki) is easier to read
• Not quite sure it is best to put the 🔔 emoji between the toggle and the option text but I have no better suggestion for now.
• "Results filtering for Fandom and Fextralife counterparts to indie wikis" and plurals to the options (links, results) to be consistent
• There are two   between BrezzeWiki "settings (learn more)"! Typography crime!
• "BrezzeWiki host", no capitalization needed on host.

I was also wondering about accessibility and emoji, especially for screen readers. Since they are not essential, maybe you should give them a aria-hidden="true" attribute so they don't get in the way. (I'm no expert on accessibility and just did a quick google search so maybe there are better things to do here)

Yep, definitely thinking about something like this for the URL!

[NotaInutilis]

(Late) congratulations on the 3.0 release! You've done a great job!

[KevinPayravi]

@NotaInutilis Sorry I didn't follow up with you - thank you! And thank you for all your recommendations and advice, it's been a huge help for improving IWB. Please feel free to open new issues if you have further recommendations.