I agree that the other forms of search could be made a bit more convenient, though I've gone back and forth on the best way to solve it. For a few years I did what has been suggested, break the other options down into tabs. As a minimalist though, nowadays I instead built a "smarter" search bar that looks at the first character and changes search type accordingly. I just opened the code for AdvancedSearch and copy pasted it all into one search area. Now if my search bar starts with the:
- "[" character it acts like I'm in the filter area - "$" character it acts like I'm in the system area - "!" character it acts like I'm in the shadow area - else, treats as a regular search This kind of gets me to the same place, but is a little more keyboard friendly. It also kind of hides the advanced functionality for those that might be overwhelmed by it - until such time that they realize how valuable it can be. I know I'm not the first to think of it - just mentioning it for others who haven't thought that way. On another topic related to the search functionality (and I bring up since I mentioned greatly changing normal functionality), I like a persistent results area (rather than the standard semi-transient default one). I'm currently working on a theme/edition aimed at corporate Office workers like myself (currently calling Officey) and am taking opportunities to make it look/feel more like an Office365 web application to hopefully drive adoption at my company. A quick example screenshot is below. I envision there being 4 key ways of navigating content that happily have the acronym SORT - so I can call it the SORT area. The components are dedicated tabs for each: - S - Search: Where I house the "smart" search bar. - O - Open: I just transclude the normal open sidebar tab - R - Recent: I just transclude the normal recent tab (though like the idea below of separating / including system tiddlers!) - T - Tags: Kind of a mashup of the tags area, and some kind of global table of contents - still a work-in-process. Lots of CSS still to figure out (really not my strong suit), but I like the way it's coming together. I aim to pair this with some introductory videos etc. linking it to how to use it along-side other Office applications like Outlook, Excel, etc. [image: image.png] Anyways, sorry if that branches off too hard from your post David, but just adding thoughts. On Sat, Aug 14, 2021 at 10:17 AM ludwa6 <[email protected]> wrote: > Like you, @David : i rely heavily on $:/AdvancedSearch -but that is often > a 2nd step, after i first 'dump the search term' into the default > searchbar, i will then click the magnifier icon beside to look into the > other tabs provided by #:/AdvancedSearch. I guess this the search workflow > on which the UI design is predicated; works well enough for an "advanced > beginner" like myself (i.e. one who is usually looking for content, but > does fairly often need to retrieve the code behind it), but for a bonafide > developer like yourself, i can see how this 3-step workflow might be > suboptimal. > > /walt > > On Saturday, August 14, 2021 at 3:01:54 PM UTC+1 David Gifford wrote: > >> Hi everyone >> >> I am playing with the field-search plugin by PMario, and seeing how >> search results for a simple search come up in tabs one can pick from. >> >> This made me wonder, why couldn't there be something similar: do a search >> from the default searchbar, and have standard, system and shadow come up as >> tabs? >> >> This seems like it would be much more intuitive for users: search, then >> filter results. As it stands, $:/AdvancedSearch does the opposite: it makes >> you pick a type of search (standard, system, shadow, filter) first, and >> only then can you do the search. The search string you want to enter may or >> may not stay in your short term memory while you are figuring out which >> type of search you want to do. It seems like it would be a better user >> experience to 'dump' the search term first, then figure out which tab you >> want. >> >> On the same subject, Why is there no comparable "recent" tab for system >> tiddlers? It seems like developers would benefit greatly having something >> like that open as they work on macros, styling, buttons, etc. >> >> I would love to hear your input: >> Do you agree with me? Why or why not? If so, should this be core pull >> request or a plugin? >> What are the reasons $:/AdvancedSearch is set up backwards? Technical >> limitations? Workflow-related? >> What are the ways you work around these limitations? >> >> -- > You received this message because you are subscribed to the Google Groups > "TiddlyWiki" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/8a1a656e-a676-449b-965b-f17876705c1cn%40googlegroups.com > <https://groups.google.com/d/msgid/tiddlywiki/8a1a656e-a676-449b-965b-f17876705c1cn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CA%2B%2B2uhFUZPw7P-KZ5TpoCevSxXi%2B7BdbTo605zqjKV9O16V_VQ%40mail.gmail.com.
