Search results in a tab of the Sidebar

[gernert]

From the discussion started at 'Provisionally extend search results to list title matches separately ' [1]:

The fact that search results obscure the tabs below it in the Sidebar brought me to make a 'Search' tab which contains the 'Advanced search' directly. For me the Advanced search is very handy; for newbies the Standard search with '…' is better?

For an example see [2]

pmario commented:

I think, the search should never remove the tabs below. It should switch to a "search" tab, so it is possible to switch between the tabs. ... I really don't like the need to remove the search results, just to get the tabs back. Opening the advanced search tiddler imo is a hack.

[1] https://github.com/Jermolene/TiddlyWiki5/commit/4d061d0fee959fdc5ab470dc8f8379bedfa946d9#commitcomment-8477557

[2] http://tw5custom.tiddlyspot.com/

[Spangenhelm]

Hey @tobibeer welcome back! what hapend to you ?? Thanks @sukima for the links, now i need to take the time to investigate and put it in place..

[felixhayashi]

back from the un-dead

seems like it :)

[danielo515]

I don't know if I have expressed how much I love this proposal or it's implementation, but: I love it! It's now installed on all my Wikis.

[tobibeer]

I took the time to read through all the comments of this issue again.

The consensus of all participants, except @Jermolene, is that this solution significantly improves over the status quo. Comparing both solutions as of this day, imagining neither having been implemented yet, the winner would be clear, at least by votes.

The "win" of only showing search results is its biggest problem, hiding everything else. If you superimpose that on the whole wiki, it would mean you could not move on with whatever you do until you click a search result or remove your search. I think, a good tenet is to have search be as little intrusive as possible... while also providing as informative results as possible.

That is why I very much appreciated Eric's GotoPlugin as my default for TW2. It was by far the quickest and least intrusive way to get to a tiddler, even compared to this here treat. Try tbGTD, type #, hit down key, select, enter, go. Or enter nex and see the results shown automatically (I restricted it to only show the dropdown with >=3 characters to not have TiddlyWiki rush into search already with the first character).

As for a user not finding the search results using this method, I cannot follow that reasoning, at all. It is just as obvious what is happenening as it is with the current implementation.

So, please have a green light for a PR of this much appreciated improvement. :+1:

[pmario]

That is why I very much appreciated Eric's GotoPlugin as my default for TW2. It was by far the quickest and least intrusive way to get to a tiddler, even compared to this here treat.

Yea, but it's much bigger than the SimpleSearch plugin. That's why its a plugin, so users have the choice.

Extended search "what ever" should be a plugin too. The core already provides a mechanism to create the search tabs.

TiddlyWiki should build a stable ground, that can be used by users to be creative. Not everything that is useful for some, should be part of the core. If there are different possibilities, that can be easily achieved with plugins, that's fine for me.

[felixhayashi]

@pmario It is not just an extension, it is a complete different way of searching. That is why the plugin is also forced to override core tiddlers. So the plugin is really just a showcase because a plugin that overrides core tiddlers cannot stay alive by itself because somebody constantly has to check whether core tiddlers have changed once a new TW version is released and adjust the plugin.

While I like the tab-based searching better for several reasons already described above, I respect and accept Jeremy's opinion (I mean while we all feel responsible for TW, in the end TW is Jeremy's program and he kindly invited/allowed us to work on it and to make contributions and I am happy he did). So if the "EnhacedSearch" does not make into the core, it's no problem for me, but maybe @Jeremy could somehow allow us to make this tab-search possible without overwriting core tiddlers? For more information on the current plugin code, see https://github.com/Spangenhelm/TW5-EnhancedSearchResults.

-Felix

[twMat]

Sensei Hayashi just wrote:

but maybe @Jeremy could somehow allow us to

"Jeremy"? Who on earth might you be referring to??? I must go ask @Jermolene if he has heard of this stranger.

[tobibeer]

Extended search "what ever" should be a plugin too. The core already provides a mechanism to create the search tabs.

I do remember the initial reluctance of putting search results in the sidebar at all, and then it caught on rather quickly. I also remember just how very long it took for SimpleSearch to finally make it into the TW2 core, putting an end to just forcefully opening all tiddlers considered as search results, while closing what was open before.

GotoPlugin for TW2 indeed provides an alternative to the core search in TW2, with quicker access to tiddlers for wiki authors, but being slightly less intuitive for just-visitors — hence, a plugin.

In the end, the here developed solution is technically a rather minor change (when implemented at the core), brought about with plenty engagement of contributors (=> interest), providing more benefits over the current state in terms of ui and workflow than there are discernible (potential) problems.

So, I am inclined to not see this as an "alternative" in a plugin sense, although eventually it will be one if so decided ...as @felixhayashi says, still begging for core support to being upgrade-friendly.

If some truly found it confusing, there could be a simple checkbox that reads "open search results in a tab", which I would think most everyone will tick off with every empty.html downloaded, provided they knew.

Taken one step further, this could even be a list of options that goes:

Open search results in...

• sidebar
• sidebar tab
• a search results tiddler
• one search results tiddler per search

...whereas the latter would perhaps better be a "pin to saved searches".

[Jermolene]

Just to clarify my position: I don't like having a sidebar tab that dynamically appears and disappears.

My counter proposal is to move the search results into a dropdown, with an arrow next to the search box for showing/hiding the dropdown.

[tobibeer]

@Jermolene, with "dropdown", would you mean what you see when you...

1. open http://tbgtd.tiddlyspot.com
2. type "test" into the search box
3. select "Search for 'test'..." from the, well, dropdown ^_^

?

The usability problem for a non-tw-visitor with that could be: "Now that the I have clicked on that result, and the search results are closed, where did they go? ...because it wasn't what I was looking for." ...but yes, perhaps a toggle button can be made prominent enough (green?) so as to minimize confusion.

Or, better still, the "dropdown" / popup would when one hovers over some search area, the one holding the input and the magnifying glass.

[Jermolene]

No that's a select element; I meant a drop down like the one displayed by "more" toolbar button

[tobibeer]

@Jermolene, I was not talking of the select that opens when you type "test", but at what comes after having selected "Search for 'test'...".

[danielo515]

What is the difference between a tab that appears and a drop down that collapses and hides it's content? Tiddlywiky is full of things that suddenly appear, or is the clear search button present all the time? People is used to things that appears when they search. Or is Google interface the same when you just opened it as when you have searched something ?

[felixhayashi]

"Jeremy"? Who on earth might you be referring to??? I must go ask @Jermolene if he has heard of this stranger.

Haha @Mat you got me there :D Sorry for this, it won't happen again ;)

What is the difference between a tab that appears and a drop down that collapses and hides it's content?

I agree, plus a tab is more powerful. With a tab you can quickly leave the search results and go to a different tab and then go back to your search results. That's not possible with a dropdown…

My counter proposal is to move the search results into a dropdown, with an arrow next to the search box for showing/hiding the dropdown.

Would this still allow us to include different search result visualizations (https://github.com/Jermolene/TiddlyWiki5/issues/1066#issuecomment-75978323)? What if a visualization needs more space, like with a graph, or a context search? In a sidebartab we can use the whole sidebar as space to display results, but in a dropdown this would be problematic I expect. It would be really sad if that functionality was lost. I mean the concept of different result visualizers is very beneficial. All major search engines have different visualizers that react differently to the same search term (e.g. google's tabs "news", "images", "maps", "shopping", "videos").

[tobibeer]

It would be really sad if that functionality was lost.

Well, you can always add the tabs to the "dropdown", but the problems remain...

1. sidebar and page are partly covered => no access to what's underneath, unless you close it first => more clicks
2. it needs to have a toggle => more clicks => more fiddly => less obvious => visual reorientation needed with every new opening of the results "dropdown"
3. unless it closed by clicking elsewhere on the page (or a search result), it needs a close button => more clicks

The one issue of a dynamic tab seems to rather multiply when replaced with a dynamic popup / dopdown.

With usability being the big concern, wouldn't it by far be better to just give the a ''Search Results'' tab some form of visual highlighting, e.g. a text- or background-color?

Quick and dirty:

[Jermolene]

I've just pushed a first pass at moving the search results into a dropdown. Please let me know what you think:

http://tiddlywiki.com/prerelease

The dropdown can be summoned by clicking on the search field. It will only appear if the search field is not empty. When the search field is not empty the dropdown can be also be summoned by clicking on the arrow or search result count.

There are still some wrinkles where the dropdown doesn’t appear when expected; I’d appreciate feedback to help reproduce those cases.

This change should still work with custom search result tabs.

[pmario]

I'm not a fan of the dropdowns. They don't work well with mobile screens. I'll remove all of them from my own TWs.

[Spangenhelm]

Sorry but i'll stick with our proposal! Not only because i like it better than dropdown (that's personal taste), but what disturb me here is that this system needs more click this way for no advantage, when a search is done and you want to access another tab you need to:

1. Hide the results
2. Click on a tab
3. Redisplay the results

With our proposition you just click on the tab you need. And i will be curious to know if, in the future, we would want to allow multiple search at once ? I can see how we can pin a tab for each search easily for example but with a dropdown...

[tobibeer]

@Jermolene, before considering the below, I still very much prefer the tabs version due to the above mentioned benefits as well as concerns regarding a popup.

The main usability gain of this popup (compared to the current version) appears to be that one doesn't have to clear the search input just to see the tabs again. Therefore, for consistency and in order to not introduce another ui, I would prefer to simply introduce the same toggling behavior and toggle button with the current UI, rather than a popup.

If this was to become the next search-ui nonetheless, here are some issues concerning the prerelease version...

1) I think it needs to close when clicking a result, especially considering mobile.

2) It introduces a horizontal scrollbar and is covered by the story river when doing so, whereas I think it should flow entirely independently on top of everything else, i.e. possibly be wider than the sidebar to avoid any horizontal scrolling. Otherwise its max-width should be set to the sidebar width and then have too long titles show up on multiple lines

3) Have the toggle button's arrow change depending on whether the results are folded or not.

[felixhayashi]

@Jermolene

The idea to toggle a show hide search button is fine (it is similar to a tab; but still requires one more click). But showing search results in a dropdown looks a bit strange and there are several disadvantages (see below).

The dropdown can be summoned by clicking on the search field

1. IMO search results should be visible at the beginning. My first thought was this is not working.
2. The dropdown creates extra width (has a min-width; requires extra padding ~28px).
3. Clicking outside hides the dropdown list, but usually I still want to see the search results list UNTIL I decide to close/hide it! Sometimes I just wanted to see if a result contains the thing I was searching for and if not, I want to open another result. Now I need to open the dropdown again. Really cumbersome.
4. I still cannot switch to tabs without hiding the search again. This situation is almost the same as before.

This change should still work with custom search result tabs.

In any case, thanks for considering this. I noticed that click events in the dropdown body do not close it. Did you implement https://github.com/Jermolene/TiddlyWiki5/issues/1497?

@tobibeer

With usability being the big concern, wouldn't it by far be better to just give the a ''Search Results'' tab some form of visual highlighting, e.g. a text- or background-color?

Yeah, good point! but we should use css to make the color fade away after e.g. 5 seconds. Otherwise, if the tab is left open, it becomes too distracting.

2) It introduces a horizontal scrollbar and is covered by the story river when doing so, whereas I think it should flow entirely independently on top of everything else, i.e. possibly be wider than the sidebar to avoid any horizontal scrolling. Otherwise its max-width should be set to the sidebar width and then have too long titles show up on multiple lines

Because they are positioned absolute, making the dropdown width adjust to the window size to make text wrap will not be possible with mere css – another huge drawback of dropdowns; with tabs it is very easily done with pure css. Dropdowns would require a javascript solution (hacky and the code would only make sense for the search results dropdown instance) PLUS a window resize listener to ensure the dropdown is shrinked/enlarged when the window is resized… how difficult.

With tabs you could simply add the css rule and you would have everything displayed wrapped.

.tc-search-results .tc-menu-list-item {
    white-space: normal;
}

[tobibeer]

Yeah, good point! but we should use css to make the color fade away after e.g. 5 seconds. Otherwise, if the tab is left open, it becomes too distracting.

:+1: ...so, something like that flashing tiddler of yours, only a little more prominent, e.g. a flashing tab-border(-color) ;-)

[gernert]

When I submitted this feature request, the two main reasons were:

1. Circumvent hiding the the tabs when searching.
2. Combining standard search and advanced search in one tab.

Everybody agrees about 1: search should not hide the tabs.
About 2 there can be different opinions. Newbies and 'standard' users are not that interested in the advanced search, so clicking the advanced search icon suffices. More advanced users will use it more so a combined search is easier and can be combined with extended search (like the context search plugin from @danielo55).

Following the discussion, most people agree that the plugin/demo made by FelixHayashi & Spangenhelm (F&S) is a very good solution.

After playing some time with mentioned demo and the dropdown demo in the prerelease, I must say I am in favour of the F&S solution.

Without repeating all arguments against the dropdown solution (@pmario, @tobibeer, @danielo515, @Spangenhelm and @felixhayashi did a very good job but I miss the comments of @Mat about the dropdown ;-) ), my main arguments are:

1. Both the advanced search and the extended search are tab based. I think a strong argument to make the standard search tab based as well.
2. The dropdown hides the tabs as does the current search; you have to dismiss it (for a newbie not clear how to dismiss it; tag and field dropdowns disappear after selecting).
3. In general you need more clicks than with the F&S solution.

[twMat]

Ton wrote

...but I miss the comments of @Mat

Flattering. Please note my name here is twMat. I fear the fella who nicked "Mat" before me, and who is not involved in TW, is getting spammed. (I did still get an alert because of previous participation in this particular thread.)

---

First of all; I'm happy that concrete steps are taken in this, and @Jermolene 's version is an improvement compared to current functionality. Still, the points brought up and summoned in Tons post reflect my own opinion.

That said, given the disagreement, I think there are things worth consideration: A popup //must// not be positioned directly over the tabs. @Jermolene , are you positioning it there so to have it in the immediate vincinity of the search field? ...But the search field also doesn't necessarily have to sit there.... Actually, that is a bit of an odd place for a search field to start with! Normally a search field is upper-right. (...and so are Cog wheels, btw). This point is further reinforced if we consider that the search field is hidden if you hide the sidebar.

Sorry if bringing up something that doesn't seem to be directly on topic but our issue here is probably a consequence of the overall page layout. The sidebar, and particularly the sidebar tabs area, is crammed and I think the topic of changes to the page layout has been raised (no?), for instance to introduce a left bar and make more use of the top bar(s). Specifically, the sidebar is a bit funny in that we happily devote a large chunk of it to the TW title+subtitle. I don't have any particular proposals, just bringing it up because all of these matters are connected.

...

A thing I think should be picked up from Jeremys proposal - which might be what Felix and Tobias are referring to about colors - is the background color in the popup. Jeremy has, if I recall, previously expressed concern that the "F&S" version separates the search field from the result. I think using the same background color for the search results as in the search field would soften this disconnect. This may be incidental with popups, but if we could apply this to search results even if in the tabs, it would make it clearer it is a "special" list.

Regarding the demo, the result list stays open after selecting. IMO it should close because after selecting a title you're more likely to want tab access rather than access to previous search results. Maybe use Ctrl+click or similar for click-open multiple titles, i.e to prevent the results from folding.

And reopening the results would be (is) simple by clicking the search field again, rather than clicking the downarrow. I.e the downarrow can be omitted to declutter a bit. If downarrow is considered necessary I'd say it's better placed inside the searchfield, next to the searched term or at far right.

(And a crazy one to round things off: Both a tab and a search field is a "small rectangle". Imagine a set of tabs where one list is based on what is typed into the "tab" for it. Too "odd" to be usable, at last publically, but interesting ;-)

[gernert]

@twMat
Sorry for the confusion; I saw somewhere above the - wrong - 'at-signMat' used.

Sorry if bringing up something that doesn't seem to be directly on topic but our issue here is probably a consequence of the overall page layout. The sidebar, and particularly the sidebar tabs area, is crammed and I think the topic of changes to the page layout has been raised (no?), for instance to introduce a left bar and make more use of the top bar(s). Specifically, the sidebar is a bit funny in that we happily devote a large chunk of it to the TW title+subtitle. I don't have any particular proposals, just bringing it up because all of these matters are connected.

That brings me to $:/core/ui/SideBarLists which combines the search and the tab set.

@Jermolene
Is it wise to separate search and tab set? To make it easier to change the search box position, e.g. in the top bar(s).

[danielo515]

If I have to make a summary of one sentence it would be: the popup solution is visually offensive. If I have to choose between the popup and nothing at all I think I will go for nothing at all.

The popup totally breaks the aesthetics of the sidebar. Actually it can be taken as a tiddler more than a set of results. Having something that pops in and pops out each time I click it's very distracting. There is another problem with style that comes from the fact that it is a popup: it does not fit inside the screen, even with results that are not long enough to require extra screen space.

Regarding narrow window usability, not only mobile, also half screen window, it is absolutely horrible. The popup not only hides the tabs, but the tiddlers also, so it is even worse.

Just to clarify my position: I don't like having a sidebar tab that dynamically appears and disappears.

@Jermolene if you were worried about something that pops in and pops out you have chose the worst counter proposal :smile: Just name includes the word pop. I don't know if you have think about it, but all the solutions requires something that suddenly appear:

• Currently if you have search results, and you clear them, tabs magically appear again
• The popup suddenly appears, and with an unexpected look and feel
• F&S solutions just adds another ui element of a collection of ui elements (tabs). It's the less disruptive.

The only difference between all the solutions is that, the second is the worst while the third is the best. If you want to avoid things that appears suddenly then you should separate the search functionality from the sidebar. But seriously, we are so used to things that are hidden (sliding menus, paginated results, carousels ) that I think it is quite natural.

Also it almost requires 50% more clicks for the same functionality.

Maybe we can trigger this on the google group and see what community prefers?

@Jermolene I feel a bit bad about this because seems that someone is against you, but it not!

Regards