Add an option to show in the tree a bookmark and/not open it then on a tab

[NicolasWeb]

Quote from issue #3

An other option could be to add an option to the addon (is that possible with WebExtensions ?), like in Firefox Tabs preferences to let the user choose if a (any, right, left, middle) click should open the bookmark (and that could be the default, then).
@aaFn and @JohnLukeBentley , if you agree, let's open an new issue for that.

On the option for behavior, yes I like it. Let's discuss that on the new issue you opened then :-)

[aaFn]

Accepting it.
Remains now to define what is the default ...
Arguments for the current value (click on favicon+text opens + show, instead of show only, and click elsewhere show only):

1. This is matching the native bookmark behavior
2. This is matching the old "Sidebar Bookmark Search Plus" extension behavior ... Now, this is a "fake" second argument, because the old (S)BSP1 was just a layer above the native sidebar ..

Once we decide, we also have to discuss how to name the option and its 2 values to make it obvious :-)

[JohnLukeBentley]

I'd suggest something like:

Search results bookmark left click behaviour:

• Finds in tree only (default).
• Finds in tree plus opens web page in current tab.

I don't think it will be necessary to mention clicking outside V inside icon plus text.

Another argument for " Finds in tree only" as the default is that BSP2, and ancestor tools, are introducing new functionality. Users will be motivated to download that add-on precisely for this new functionality. So I suspect users will be expecting default behaviour clicking behaviour that puts in front this new functionality. That is, yielding a search result that allows the user to go to the right part of the tree, rather than also open a web page (if they just wanted to open a webpage after a search they'd use the native bookmark manager).

Moreover, I could well be wrong but my intuitions would be that most users, after having been returned bookmark search results, will want to use a particular bookmark either to:

• Open the web page up, without also finding in tree; or
• Find in the tree, and then open the web page from there (the user allows that they may open up other bookmarks nearby in the tree); or
• Find in the tree, to find another bookmark nearby. And possible from there open the target bookmark in as a web page.

That is, my intuitions are that it is unlikely that a user would simultaneously open a web-page and find in tree. To me that seems like vying for the users attention in two different directions.

Evidently this does not apply to all users. You, @aaFn, for example have gravitated to this simultaneous behaviour. But does the current simultaneous behaviour exist because you are a developer anticipating what users want; or, as a user, is the functionality that you prefer?

[aaFn]

Hello @JohnLukeBentley , good question, as a matter of fact I gravitated to my current behaviour of clicking "outside" or "inside" since years because of the old (S)BSP1 (Sidebar Bookmark Search Plus"), which is itself using the native Bookmarks sidebar way (try clicking outside the favicon/text in native Bookmarks == nothing happens).

So that now seems natural to me ... and I coded it like that without thinking ... but I see I am just accustomed to something peculiar and this is not natural to most or many.

What I initially added to overcome that ambiguity (which I did perceive) is the change in the mouse pointer image. This does make the click action difference discoverable .. but I agree this is really a tiny indication noticeable only by exercised users .. so not many at all.

Consequence is that this addition is not sufficient to make it the default = you are two already expressing you didn't find it, and so this is inconvenient.
Of course, I could make it more obvious with more visuals/different highlights, but I don't like overcharging signals, I prefer to keep it simple.

Therefore I believe you convinced me:

Search results bookmark left click behaviour: 
- [Radio, default selection] -> Simple: Finds in tree only
- [Radio]                    -> Advanced: <click blank> = Finds in tree | <click icon/text> = Opens in current tab

(not mentioning the find in the second part of the "Or" for simplicity, because it is a side effect which will be visual and immediately noticed).

How does that sound :-) ?

[NicolasWeb]

When I first tough about an option for that, I had an idea more like a check box, as it is an added behaviour and because native preference UI in Firefox use it (so I got used to it)

Search results bookmark behaviour:
[ ] Always open the search result in a/the current tab when I click on it

That give a simplier UI. Preferences UI are too complex to watch at usually, and like that Firefox made it more simple years by years

[aaFn]

Ok, simpler indeed. If you don't mind, I'd still like to present it as "Advanced", and the fact that this is varying (it won't be "always"):

Search results bookmark behaviour:
[ ] Advanced clicks: Show in tree <img1> | Open result in active tab <img2>

wth img1 and img2 showing where to click for each effect

[JohnLukeBentley]

Some great ideas there. Given the above I'd suggest:

Search results bookmark behaviour:
[ ] Advanced clicks: Show in tree <img1> and open result in active tab <img2>.

@NicolasWeb, yes I think a single checkbox probably simpler than an option group.

@aaFn, yes presenting it as "Advanced" seems helpful. That sot of advertises its unusual behaviour that, nevertheless, you may want so long as you wrestle with the consequences.

(not mentioning the find in the second part of the "Or" for simplicity, because it is a side effect which will be visual and immediately noticed).

That would just be misleading, I'd suggest. The intended behaviour is not X or Y but X and Y. Better to speak about what the behaviour truly is.

I've been using "Find" in "Find in tree". But "Show" is reasonably synonymous and if you have a (possibly largely arbitrary) preference for "Show": that'd be fine. But I think you should commit to one term or the other and use it consistently throughout your add-on (and any documentation or settings description).

I'm not yet sure if it should be Advanced clicks (plural) or Advanced click (singular). Do you have in mind that this checkbox will effect left click and middle click?

I'm not sure what if using and is desirable. But if you went ahead inserted icons or images you'll be better able to see if that works.

[aaFn]

@JohnLukeBentley , I like the "and", I take it :-)

Yes, for now I am consistently saying "Show" where I can .. I guess this is more or less in line with "Show parent folder" ... I'll review all docs and messages to make sure I am not mixing the two terms.

Indeed, not sure about the 's' of advanced clicks. As you guess, English is not my mother tongue, so I will defer to anybody more expert than me on this. Keeping it simple, stupid (KISS), I guess I will remove the 's'.

Let's go with that then. Thank you.

[JohnLukeBentley]

As you guess, English is not my mother tongue,

I did not guess, because your English seems fine :) But I'll keep this in mind and point out any advanced English mistakes that might trip you up.

Ok "Show" it is!

It looks like we are all of one mind in this threads. So we'll wait for your implementation (at your leisure) and verify against current intentions.

[aaFn]

@NicolasWeb, @JohnLukeBentley, implemented in 2.0.5, I will close that issue as resolved unless there is still something to adjust. Thank you.

[JohnLukeBentley]

@aaFn. The behaviour now works as desired, thanks.

However, the second line is incoherent ... it doesn't convey what you intend. Now that I see the thing before me I do think an option group is necessary to convey the choices and behaviour to the user. E.g. Something like ...

(*) Simple. Click anywhere on line: "Show bookmark" in tree.
( ) Advanced. 
        Click before icon and text <img1>: "Show bookmark" in tree.
        Click on icon or text <imag2: "Show bookmark" in tree and "Open" in active tab.

It's good that the Simple option is the default (as you have it currently).

[aaFn]

@JohnLukeBentley , you are correct, that better conveys the choices and behaviour.
I will defer to @NicolasWeb who has a better experience on UI simplification.

However, we have an illustration of that in FF itself, in the Search Preferences page:

which militates for what you suggest.

[JohnLukeBentley]

Well, it will be good to get @NicolasWeb's view.

But the essence of what I'm illustrating is that there are three, not two, kinds of app behaviour the user needs to know. That is, one behaviour for the simple option and two sub-choices with respect the advanced option (and those sub-choices play out in the main UI).

So it will be a matter of deciding the best way to convey the three app behaviours. With something like: my suggestion; the FF search bar options you've imaged; or another solution.