Here are some fun facts: Google Bites Bing back, Recovers All Usage Losses Since Spring > Comments rotfl!
> Really? On my IE (IE7) I just click on the “down” button on the right of
> the search box and chose the option “find more providers”. Then I get to a
> page where I can choose between half a dozen search providers and I can
> add my own. After selecting one, I then get asked whether I want that
> provider to be the default search provider.
> I can’t imagine how you can make ching the search provider even simpler.
I think on a design level it’s not very good requiring access to a
proprietary web page. It should be more of a matter of clicking, edit search
providers, put in a URL or name of the desired provider and have the search
site itself provide the add-on. For one, these central repositories make it
difficult to find any given add-on at a glance. Also, notice who is the
first ‘add-on’ on the IE8 page…Bing. Furthermore it behooves the
controlling site to accept fees to place add-ons near the top of the list.
Leaving the site you might prefer on page 104 of the add-ons. I don’t think
you’d see that behavior on Mozilla, but I would fully expect it on others.
Maybe subtle things like that are okay…maybe they aren’t. Unfortunately
the latest Firefox and IE8 have almost verbatim design features so we have
to live with it at this point.
I don’t know, this sounds like opposition for opposition’s sake. What if I don’t know the URL? What if the name is similar sounding to a different site? What if I only know the logo well?
Why would changing the design from visual/click-oriented to a text-oriented be an improvement?
Additionally, Firefox also uses a central repository for add-ons including search plugins. Not to mention that most Linux distros rely on repositories, and the concept has been made broadly understood via “App Stores”. A central repository gives users a single, trusted source for items in question. I agree that users should be able to get search providers from 3rd party sources, but I don’t see what’s so wrong or questionable about the design IE8 is using here.
As for Bing being at the top of the list…is AltaVista or AskJeeves in the list? Because if it is in alphabetical order, I don’t see how controversial having Bing on top of the list could be…given that the other two well-known search engines are Google and Yahoo. In any event, a user who even bothers to change the search provider probably already knows which one she wants.
> I don’t know, this sounds like opposition for opposition’s sake.
No, I don’t think it is. I have disliked the search provider setup from
day 1. It feels disjointed and cumbersome to me and I am offering
suggestions up for comment.
> What if I don’t know the URL? What if the name is similar sounding to a
> different site? What if I only know the logo well?
Then you’re in trouble. But this fact would not extend just to a text entry
method. If I only know a logo how do I input that into a search on the add-
ons web page, or shall I peruse 126 pages of add-ons looking for a logo?
What if I run into a similar sounding entry on the add-ons web page before I
get to the one that I actually meant to get? You can’t eliminate human
error, there has to be a place for personal responsibility.
> Why would changing the design from visual/click-oriented to a
> text-oriented be an improvement?
Visual click oriented is nice, but when the choices become overwhelming
so does any design centered around it, thus the move towards ‘usability’.
With programs like kickoff designers have tried to make sense of the morass
of menus and icons. Personally I like more of the interface of the run
command where I can start typing and it will find and display applications
with those letters. Simple and elegant. To me, that would be a nice way to
implement looking for search add-ons. The browser app could read the backend
repository at say Mozilla and display the results in the way the KDE run
command widget does. If you have no clue as to what the search engine name
is, the URL or the logo and you just have some faint foggy recollection of
some TV ad you saw, then put in *.search or some predetermined search string
that would display all of the search add-ons. You’re in no worse shape than
digging through add-ons on a web page but you aren’t basically dumped out of
whatever you are doing to fix your search engine listing which breaks the
user experience. Keep in mind as a visual tool, this presentation layer
could also break down if everyone suddenly decided to name their search
engine Goo something in order to jump in on the popularity of the beginning
‘Goo’ letters. Strictly speaking URL entry would be the most fool proof,
although understandably not suitable for everyone.
> Additionally, Firefox also uses a central repository for add-ons
> including search plugins. Not to mention that most Linux distros rely
> on repositories,
I don’t question the use or value of repositories or App Stores. I just
don’t see that redirecting to a website is the best way of implementing add-
ons to any product. YaST doesn’t dump you out to a repo webpage so that you
can find and install programs. Add-ons should be managed in the application.
SuperKaramba has a fine system of grabbing widget add-ons from a central
repository without exiting the user experience of the application.
> and the concept has been made broadly understood via
> “App Stores”. A central repository gives users a single, trusted source
> for items in question. I agree that users should be able to get search
> providers from 3rd party sources, but I don’t see what’s so wrong or
> questionable about the design IE8 is using here.
> In any event,
> a user who even bothers to change the search provider probably already
> knows which one she wants.
This is true, but if it is difficult to find or use they may not bother in
which case ‘default’ wins.
I should also mention that what makes it even more odd is
that Firefox already has a similar Karamba style method in place
for addons, yet somehow search is broken out for this web style interface,
which I am sure is part of what makes it feel out of place.
If I only know a logo how do I input that into a search on the add-ons web page, or shall I peruse 126 pages of add-ons looking for a logo? What if I run into a similar sounding entry on the add-ons web page before I get to the one that I actually meant to get? You can’t eliminate human
error, there has to be a place for personal responsibility.
Indeed there is a place for human error and personal responsibility. If the user knows a logo, then a visual interface gives them the opportunity to find it. A text interface does not. Further if the user knows the name then both a pure text system and the add-ons systems as currently implementmented allow the user to find what they want.
[As an aside: FF has 26 pages of search addons and IE8 has 2 with an option to "Create your own Search Provider](http://www.ieaddons.com/gb/createsearch.aspx) - even if they had 126 pages each, it seems odd to cite “personal responsibility” and yet also imply that one should not have to look at logos…even if that is all one has to work with.]
So really the difference is ‘how high should the barrier be’? And if the underlying discussion is about competition…then having an interface that privledges knowing the name only helps well-known incumbents - in this case that would be Google and Yahoo.
Visual click oriented is nice, but when the choices become overwhelming so does any design centered around it [edited…] I like more of the interface of the run command where I can start typing and it will find and display applications with those letters. Simple and elegant. To me, that would be a nice way to implement looking for search add-ons. The browser app could read the backend repository at say Mozilla and display the results in the way the KDE run command widget does. If you have no clue as to what the search engine name is, the URL or the logo and you just have some faint foggy recollection of some TV ad you saw, then put in *.search or some predetermined search string that would display all of the search add-ons. You’re in no worse shape than digging through add-ons on a web page but you aren’t basically dumped out of whatever you are doing to fix your search engine listing which breaks the user experience. Keep in mind as a visual tool, this presentation layer could also break down if everyone suddenly decided to name their search engine Goo something in order to jump in on the popularity of the beginning ‘Goo’ letters. Strictly speaking URL entry would be the most fool proof, although understandably not suitable for everyone.
I don’t think there’s any harm in having a built-in ‘add-on search box’. But this seems like a minor issue of implementation. If Firefox & IE8 opened their add-on search webpages in a new tab or window then the problem of breaking the user experience is solved. What separates a browser from YaST package management or some other app is that webpages are “the experience” in a browser. It doesn’t make sense for YaST to send you to a webpage because YaST is not a web browser.
I’m skeptical that diverting a typical user to another webpage, in a web browser, when they asked for an option about webpage search detrimentally breaks their experience in any serious way (if at all)…but I cannot establish the fact in either direction.
[edited…] if it is difficult to find or use they may not bother in which case ‘default’ wins.
Agreed. Where I’m confused is how raising the level of knowledge needed makes things easier on the whole. Especially since people who know what they want can still find it quickly, even under the current system.
It seems to me that adding suggestions to the search box of these add-on pages and opening them in their own window would resolve most of your objection to their current implementation without resorting to removing some of the features they have now. Sure a custom interface could be built for seaching add-ons in the app, but I don’t see how that is any better than a well designed website in its own tab/window. A web-based method should be easier to maintain at the least.