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/

[tobibeer]

(perhaps also a reply to https://github.com/Jermolene/TiddlyWiki5/commit/4d061d0fee959fdc5ab470dc8f8379bedfa946d9#commitcomment-8477557 but thought it better here)

Perhaps you have seen findr already.

Personally, I much appreciate search results in the sidebar. I also like findr's ability to have the search results replace only the tabContents in the sidebar, which allows me to access tabs without being forced to clear the search first.

An aditional (/optional) button might be good to have the query and corresponding results pop out as a temporary tiddler that won't be saved back to the server unless one choses to edit and save it, if that's even possible.

Here's my quick shot for what I'd consider ideal:

Independent sliders or sections for...

• in titles
• in tags
• in text
• in field-contents

Using sliders, the title section should be displayed by default, the open-state of the other three stored via states.

To me, any title matches "starting with" the desired term are quite easily found assuming the result-list is alhpabetically ordered, so no need for anything extra.

[twMat]

Detail: If search is put into a tab then please set focus to the search field right away as tab is opened. This way it's actually as quick as current solution, ie where you must first click on search field to write there.

<:-)

[gernert]

Just as a further illustration of what was requested and how I use it:

You do not need to clear the search box to have access to the Sidebar buttons. So the search results will stay after doing other things with the Sidebar tabs.

@tobibeer welcome back!

Yes, in TWc I use different Search plugins depending on the content. One TWc uses your findr: simple but effective.

[twMat]

How about this - as you start to type, instead of search results covering/replacing everything, a new (temporary) Search tab appears, pushing the other tabs to the side.

Clearing search closes (removes) the tab and, vice versa, close the tab clears search.

In the image I've omitted the clearing "X" because I'm not 100% sure where it would sit best. Maybe inside the tab so it reads "X Search". Perhaps without tab borders around this then?

Having this appearing search tab to the very left would also make it look good if we have the advanced search alternatives as vertical tabs inside, like in @gernert 's image just above here.

I'm not really keen on having the actual search field inside a tab because I want immediate access to it all the time.

[twMat]

Illustration for my last comment about including the advanced search:

(Because this is an older thread, I'm not sure if "the usual suspects" get alerted unless I ping them, so: @Jermolene @pmario )

[tobibeer]

I like this. I did some preliminary testing...

http://mockup-sidebar-search.tiddlyspot.com

Haven't found a way yet to have the search tab opened and focused simply by typing into the search box.

[twMat]

@tobibeer - that is terrific! BTW I was surprised to see how well the popping up of a new tab works.

The Standard search should probably be the default tab showing.

Also, while the "open tab on focus" issue is not resolved, I suggest that clicking your preliminary "(open search tag)" should re-focus the search tag even if it already exists. Currently if you have old search results in there but using another tab (e.g Recent), if you type in a new search quesry and press the "open search tag" it does not set focus to Search tab..

[tobibeer]

I really don't want to put anymore logic into that button as it's cleary not achieving the desired goal... which is a solution without a button, imho. Not?

Or is it in any way problematic not to have one? Right now, there is none either.

What's needed for that to work is that keyboard input is allowed to do the required messaging.

What's also not so nice is that making the tab pop up requires tagging... which puts the wiki in a dirty state.

[twMat]

No, no button of course.

[twMat]

There seems to be a consensus that the current search layout is not so good - and that the latter design ideas expressed here might be. Are there arguments against implementing the latter? Or is it the technical problem shown in Tobias' mockup stopping this?

And, while at it, would it be a bad idea to use Tobias mockup 'for real' in a TW of my own, i.e could it cause problems?

Thank you!

[Jermolene]

@twMat if you're asking why this ticket hasn't been implemented yet, there are several reasons, including the new feature moratorium.

@gernert's proposal at https://github.com/Jermolene/TiddlyWiki5/issues/1066#issuecomment-62536872 seems doable, but I don't like that it hides the search box within a tab.

I'm not keen on the two proposals where we have the search box outside the tabs but acting to control them. It feels like a non-standard usage.

One solution that I'm surprised hasn't come up is to put the search results in a dropdown, like the new tag chooser.

[Jermolene]

And, while at it, would it be a bad idea to use Tobias mockup 'for real' in a TW of my own, i.e could it cause problems?

I'm not familiar with the guts of @tobibeer's prototype, but I'd imagine that it just overrides a couple of shadow tiddlers. You would always be able to revert them if you did run into problems.

[Spangenhelm]

Hi @Jermolene

...put the search results in a dropdown.

Is it not going to "hide" the sidebar tabs under your dropdown list ?

+1 for:

• Leaving the searchfield where it is now (for immediate access)
• Doing a research display results and advanced options in a regular temporary tab in the sidebar
• Clearing the field erase/hide the temporary tab

Question: what do you guys think about multiple searches at a time ? I'm not personnally interested but some might be so...

[Jermolene]

Is it not going to "hide" the sidebar tabs under your dropdown list ?

Yes. Like the "add tag" dropdown, you'd be able to click on an arrow or outside to hide the dropdown, and then you could bring it back up by clicking the arrow again.

Doing a research display results and advanced options in a regular temporary tab in the sidebar

@Spangenhelm I think the problem with that solution is that it establishes a non-standard behaviour between the search box and the tabs; it's not usual for typing in a search box to switch tabs somewhere else on screen.

[twMat]

@Jermolene, thank you for your answers.

@twMat if you're asking why this ticket hasn't been implemented yet, there are several reasons, including the new feature moratorium.

Yes, I'm asking out of curiosity because I think we're onto a good idea. (Side note about the moratorium: in a hangout you briefly mentioned possibly extending the moratorium but I don't think it's been brought up on the boards. Might be a good idea.)

Regarding the dropdown idea, I have the same objection that Spangenhelm does i.e that it would block the other tabs which basically is the same problem as with the current solution.

Further, adding a dropdown there would be adding a new thing in an already crammed area - whereas the "searchresults in tab" actually feels very consistent(!) to me in that the sidebar is a place for tabs.

Also the dropdown would, other than opening the selected tiddler, maybe close up and go blank again? Or still show the half finished search string? Or the clicked at title? (Either way it's not the standard behaviour for the tag dropdown and I'm not sure if either way adds much - or?)

Compare this to "searchresults in tab" where the results would feel more 'stable and referable' because you can continue your work and the result stays even if you switch tabs! it becomes a list among the others.

[Spangenhelm]

@Jermolene:

...it's not usual for typing in a search box to switch tabs somewhere else on screen.

I kind of agree but to me, as long as the result tab is displayed by default when researching (meaning that we don't need to "look for it"), it makes more sense to have a new tab that no more tabs at all (the actual behavior). I'm not sure that this is the perfect solution but imo it would be the most logical one unless someone comes up with a better idea.

+1 @twMat since "most of us" seems to think that the actual behavior is being problematic i'd be inclined to change it quickly as you suggest but since we are not sure of the solution to use we could wait a bit more and integrate it in the pre-release for testing maybe? Since there is no more test release we have to be sure before making a final version.

[twMat]

@Spangenhelm

change it quickly as you suggest but since we are not sure of the solution to use we could wait a bit more and integrate it in the pre-release for testing maybe? Since there is no more test release we have to be sure before making a final version.

I just hope we find something everyone is happy with. However, in this case we could probably implement it as a plugin and over time it should be clear whichever solution is considered better (by the community, I guess). Maybe someone can take a look at Tobias' code and see if the knots there can be solved? I sure wish I could help out but my strenghts lie elsewhere...

(Off topic: There shoudl be a "testing ground" for these things. I might start a discussion on the boards but I'm behind in a lot of other things so if anyone feels an urge...)

[Spangenhelm]

...there should be a "testing ground" for these things.

Well my bet is that the pre-release version is made for it.

I have just realised that there are no mentions (apart from in "versioning") to it in main site.. It must be made on purpose but if not what about adding a link to this special version in the "Releases" section of the main site ? Of course with an advice that this is for "beta-testers" only to avoid any risk of confusion. The advantage i see is the possibility for interested users to have a concrete "preview" of what is going on in the next version. (already the case but some may not know it exists!)

If Jeremy agrees i will be glad to propose a pull-request (i think i start to like it.. or it is just to have my name in the contributors page ;-)

Little edit: forgot the http in the link above.

[tobibeer]

Added some more explanations...

http://mockup-sidebar-search.tiddlyspot.com

Personally, I don't see anything wrong with having the search results shown in a dynamic tab directly below the input. It's pretty clear what is happening and the tab cannot be said to be too far away from the search input. Anyhow, to make its function a little more clear, I added a headline to the search tab reading "Search Results..."

[gernert]

@gernert's proposal at #1066 (comment) seems doable, but I don't like that it hides the search box within a tab.

@Jermolene With Search as default tab I think it works very well.

Having this appearing search tab to the very left would also make it look good if we have the advanced search alternatives as vertical tabs inside, like in @gernert 's image just above here.

@twMat Excellent idea. I changed http://tongerner.tiddlyspot.com/ this way so everybody can play with it.

Well my bet is that the pre-release version is made for it.

@Spangenhelm +1, after the moratorium ;-)

[davidjade]

I'm not too keen on hiding the search box within a tab as I think it should always be accessible without having to switch tabs. I do like the dynamic search results tab idea though. I don't think this is too non-standard as I can think of several apps that dynamically open search results in a sidebar, tab, etc... MS OneNote (desktop app) is one example that comes to mind.

[Jermolene]

With Search as default tab I think it works very well.

But if we make "search" be the default tab, it will also be empty by default. That seems a waste of the sidebar.

I don't think this is too non-standard as I can think of several apps that dynamically open search results in a sidebar, tab, etc... MS OneNote (desktop app) is one example that comes to mind.

Interesting. I think it's still uncommon.

[gernert]

But if we make "search" be the default tab, it will also be empty by default. That seems a waste of the sidebar.

True, but once you use Search, the search results stay there until you do a new search.

[Spangenhelm]

Hi @Jermolene,

..if we make "search" be the default tab, it will also be empty by default. That seems a waste of the sidebar.

Right, but atm the fact that the search results "hide" the other tabs is a non-sense so the solution of the tab in the sidebar is way better than the actual behavior.

What about making it appear dynamically when there is a search going on like proposed by @tobibeer ? The other good side of gernert's idea is that we could possibly do and keep different searches at the same time (for example kept as vertical tabs in the search tab with a "plus" button)

[tobibeer]

The other good side of gernert's idea is that we could possibly do and keep different searches at the same time (for example kept as vertical tabs in the search tab with a "plus" button)

Not so easy as there are a number of possible search tabs. A better option would be to chose from a search-history, imho... could well be "pinned" / saved searches.

[Spangenhelm]

Not so easy as there are a number of possible search tabs

I don't understand what you mean by that..

..could well be "pinned" / saved searches.

The terms can be different as long as the idea is the same (to me the "plus" button would "keep/save/pin")

[felixhayashi]

@Spangenhelm

I don't understand what you mean by that..

[Spangenhelm]

@tobibeer thanks for your explanation, you get a point !

@Jermolene after checking the prerelease version of the 5.1.8 i see that this issue has not moved any further, instead there are new optionnal "features" (the help panel, the sidebar explorer...) and i don't understand, to me this kind of features are certainly needed but were not, and still not are, a priority (please keep in mind that there are clever issues raised that are still opened after two years!)

Thank you

[Jermolene]

@Spangenhelm I think you're suggesting that fixing this issue (#1066) should have been more of a priority than adding the help panel or the sidebar explorer? The best way to raise the priority of an issue is to create a pull request. Rearranging the sidebar is just a matter of rearranging some wikitext shadow tiddlers, and is therefore not very advanced as TW5 development goes.

As an aside, just to be clear, the sidebar explorer is part of the prerelease but won't be included in the 5.1.8 release.

[Spangenhelm]

Hi @Jermolene

..fixing this issue should have been more of a priority than adding the help panel or the sidebar explorer?

Reading the previous comments we all agree on the fact that the actual behavior is being problematic so yes, but as long as you do not decide how and if you want to correct it i don't see which pull-request we could propose ??

[Jermolene]

actual behavior is being problematic

I guess that is indeed the nub. While I acknowledge the imperfections of what we've got (I use it every day after all), I don't think I've seen a specific proposal that improves matters without having other disadvantages.

The medium-term approach I favour to this issue would take a couple of steps:

1. Make the sidebar tabs be individually switchable in the same way as tiddler and page toolbar buttons
2. In the same way, make the individual elements of the sidebar be switchable
3. Add a new, optional "search" sidebar tab that contains both the search box and the results listing (in tabs if so configured)

Then it would be possible for people to disable the default search box (which is always visible), and instead use the search tab.

[Spangenhelm]

+1 for your two first propositions

About your third option as @twMat said earlier:

I'm not really keen on having the actual search field inside a tab because I want immediate access to it all the time.

Until then (as it might take a long time) can't we try to display the search results in a dynamic tab and see ? Even if it is not perfect it would still be better than now ;-)

[Jermolene]

can't we try to display the search results in a dynamic tab and see

I'd encourage such experiments :)

[Spangenhelm]

I have done some experiment with my new tiddlyspot, take a look: http://spangenhelm.tiddlyspot.com/

I don't know if the one of twmat was dynamic but this one is (it hides the result tab when not needed) no button or anything special to do to use it.

This config allow the user to keep the search input always accessible and allow access to the other tabs.

[danielo515]

I want to give my opinion on this because I also use tiddlywiky in a daily basis and I use search a lot (in fact I did a plugin for that!).

My feel is that @jermolene it's being too conservative with this. As most of the community I agree that the current behavior is one of the worst. I like the idea of having a dynamic tab appearing and opening with search results. The opening part is mandatory, without that is totally useless and even worse than the current behavior. I don't think that searching opening some kind of results set is unstandard in any way. This is how searching works in 99% of Web pages and programs and there is nothing wrong in tiddlywiky replicating this.

[Spangenhelm]

Hi @danielo515 I would like your feedback on the link i have provided if you agree.

The goal was to keep access to the tabs when doing a standard search in the sidebar. (advanced options were not added on purpose because it was not the goal and it can easily be added later)

The differences with the other demos are that:

• the search form stays where it was for immediate access, the one of @gernert was put with the results inside a tab.
• based on the work of @tobibeer i have found a way where there is no need to click on a button to open the results tab.
• clearing the search remove the tab

@twMat did not provided a link to his demo but it looked promising !

Ps: i have not found a way to "focus" on the new tab (i don't think there is any yet so if you have previously clicked on another you will have to click on the results tab to switch to it)

[felixhayashi]

Hi @Spangenhelm

I like your demo!

I have to say, I find it often confusing, that the sidebar is suddenly gone when I searched for a tiddler. Sometimes, I forget to remove a letter from the search and it irritates me that the sidebar is not displayed. When I show TW to newbies, they are usually confused as well. So I favour your solution.

Only one piece to the puzzle is missing in my opinion: Once a user starts a search, the currently displayed tab needs to change to the search tab.

Unfortunately the problem here is, this cannot be done with any existing widget at the moment. We would need to set the text of <<qualify "$:/state/tab/sidebar"> to $:/core/ui/SearchResults when the a character is entered and the search tab is not yet displayed.

However, this can be done using js of course but it would require some programming.

In any case, any solution should acknowledge that search results themselves may be displayed in different ways, as it is the case since 5.1.6 (see my screenshot showing @danielo515 's context search next to the standard result list https://github.com/Jermolene/TiddlyWiki5/issues/1066#issuecomment-75978323).

-Felix

edit

Ps: i have not found a way to "focus" on the new tab (i don't think there is any yet so if you have previously clicked on another you will have to click on the results tab to switch to it)

sorry, I overread this. But you are right, there is no solution for that at the moment.

[danielo515]

Hello @Spangenhelm, I like your example a lot. For me is nearly perfect. The only thing that I miss, as @felixhayashi said, is the focus on the new tab. If a new widget or listener is needed for this we should think about creating it.

Regards.

[felixhayashi]

If a new widget or listener is needed for this we should think about creating it.

Yes, I think this is worth it. We need a startup module that registers a change listener that only looks

• whether $:/temp/search changed and
• whether its value is non-empty
  • if it is empty and the search tab is displayed, then hide the tab
  • if it is non-empty and the search tab is not displayed, then show the tab

[Spangenhelm]

Hi @felixhayashi, @danielo515 thank you guys !

We would need to set the text of <qualify "$:/state/tab/sidebar"> to $:/core/ui/SearchResults when the a character is entered and the search tab is not yet displayed.

Actually we can, but with a trigger ! (like a button) <$button><$action-setfield $tiddler=<<qualify '$:/state/tab/sidebar'>> $field="text" $value="$:/core/ui/SearchResults"/>Click</$button>

Imo we need an other way to trigger events, like the revealwidget or macro \define do_action() <$action ...../> <<do_action>> but i guess it can't be that easy ;-)

[felixhayashi]

Hi @Spangenhelm

Actually we can, but with a trigger ! (like a button)

Hehe, yes, I know, but as you pointed out, we need a button :) However, I like the idea of tw immediately starting to search (without a "go" button). But using a startup module that does the things I described above is pretty straight forward. I will see what I can do and paste the code so you can add it to your example.

[felixhayashi]

I really hate the fact, that I cannot set a tab from outside a widget chain since I cannot create the qualifier hash. That is a real dealbreaker. So we need to insert a hidden widget into the same tiddler that holds the sidebar stuff (= $:/core/ui/SideBarLists) so the widget can call getStateQualifier to access the tabs state and perform the calculations.

Alternatively we could use the macrocall widget to update a self written macro by setting one of its params to $:/temp/search.

[felixhayashi]

Hi @Spangenhelm,

no need for that. I now added the following behaviour to your original:

• If search is started, change to search tab and backup old tab
• if search is empty restore old tab (if existed).

See demo here: http://wkpr.de/hosting/tmp/searchdemo/tw.html

So please update your demo with the following:

add this macrocall to $:/core/ui/SideBarLists (preferably somewhere near the edit text widget):

<$macrocall $name="checker" searchTerm={{$:/temp/search}} />

Now add the following tiddler to your wiki: http://wkpr.de/hosting/tmp/searchdemo/searchdemo-macro.tid

edit (first save the *.tid file and then dragndrop it to your wiki so the fields are parsed correctly and do not make it into the macro body)

@danielo515 you like it now? :)

-Felix

[danielo515]

Hello @felixhayashi ,

I really love the behavior. Sadly the search doesn't seems to work. It does not find any result, at least on my iPad .

[felixhayashi]

@danielo515

yes, I know, I just copy pasted @Spangenhelm 's original wiki where it also didn't work. I think @Spangenhelm can fix this now while adding my code...

-Felix

[danielo515]

Here you have an example of what I mean:

[felixhayashi]

Danielo! Hay una nueva version disponsible. aora actualizar amigo!!

[danielo515]

Hello @felixhayashi ,

I just read your last post. Sorry for the unnecessary picture. Regards

[felixhayashi]

will try to adapt.. give me a minute

no problem, take your time

[felixhayashi]

http://spangenhelm.tiddlyspot.com/ looks great :+1:

Question: why couldn't i drag n drop directly from your tw to mine? why the need to download/upload the.tid ??

Ehm, yes, simply forgot about that option :dancers:

Do you guys think that we should add the advanced search options in it or leave it "as is"?

I once did a "pull request" (https://groups.google.com/forum/?hl=en#!searchin/tiddlywikidev/visualizer/tiddlywikidev/UafAzk5Bt7k/q0afSTIR5AAJ) to allow different search results. It got integrated since 5.1.5 So the same way, I added @danielo515 's context search to the search result list on the tiddlymap demo site (http://bit.ly/tiddlymap ), we could add the "filter search" or the "system search" as searchResult visualizer tab... I strongly favour this approach instead of a advanced search tiddler that opens and spams my story river.

-felix