Page, Template, Script, Style Pickers, hm?

Ideas
1

Once upon a time, there was the page picker. Life was simple. Life was good.

Then, I thought: hey, templates are a good idea. We can use that for snippets, page templates and queries. Those templates can just be pages.

Life was still ok.

Then, I thought: you know what, I can eliminate a lot of built-in stuff like slash commands, daily note templates etc. with moar templates. We can then build Libraries of these.

And the page picker became a mess.

You know what, I then thought, let’s just start to split these things. All these templates will appear in a special template picker (anything tagged with “template”), and the rest in the page picker. They’re kind of different things anyway, right?

Things became more clean again. Although slightly more confusing. I still often ask myself, “where did that template go” only then remembering I should look for it in the template picker.

Hmm.

Then… we got space script. Where should you put space scripts? Well, the answer is on pages. When you have 1 or 2 pages with space script, maybe things are fine. But what (and this is definitely in the cards) we push the idea of redistributing these in libraries as well. You may end up importing a ton of space script pages into your space from various sources, making your page picker a mess again.

And then in the morning I merged Space Styles Implement space-style by onespaceman · Pull Request #796 · silverbulletmd/silverbullet · GitHub Nobody’s using this yet, but this lowers the barrier to things like themes and such. So your page packer may also contain a bunch of pages that contain space styles soon.

So… what now? Should each get its own picker? A template picker, a script picker, a style picker and then a page picker for actual content? A content picker?

:thinking:

I don’t know what to do here. The other radical approach would be to throw our hands in the air and say: let’s just go back to the page picker that includes everything, and accept that perhaps 50 of these pages are actually templates, 10-20 space scripts, and a few are styles.

What do you all think, any ideas or creative solutions?

2

Would be possible to cycle the pickers once the main picker is visible without losing the current search?

So first C-k opens the regular page picker… I start typing gruvb then I realize that it’s an space script page … So I press a couple of times C-k until I’m on the space script’s picker and find my page: Gruvbox… not sure if that would work , I’m terrible with UX.

1 Like
3

Not sure I’ve fully thought it out yet, but another option is to add filters to the search. I know that, with Discord’s search, for example, you can do simple filters like has:file or in:general. Could we default to the page filter (or deprioritize the ranking of non-page results), and let the user filter if they need to further refine the results?

For example, I could search for “main” and the results would be something like this:

  • Main (page)
  • The Main Thing (page)
  • /Themes/Dark/Main (style)
  • /SpaceScript/Utils/Main (spacescript)

And if I wanted to further refine (say, because I was looking for the script), I could add (or maybe prefix?) a filter, and my search would become “Main type:script”, and the results would be

  • /SpaceScript/Utils/Main (spacescript)

This’d also enable other filters in the future (a tag filter :eyes: ).

4

Right, the direction of having a single picker, but then filter results down can make sense. What already works I think is putting tags in your page picker. If you type hank #person it will only show pages with hank tagged with #person. So if we’d use tags for this, e.g. suggest putting #script on page script pages etc. that could be a way to filter things down. And anything tagged with something special, like #template and #script we can deprioritize.

For new users this may still be overwhelming though. You create an empty(ish) space, you think. Open the “anything picker” and see a ton of stuff you don’t (yet) understand. Even if content pages would appear at the top, there won’t be any. All you’ll see is a bunch of slash templates etc. This is an experience I wanted to avoid, which is where the template picker concept comes from. It may be too early to be exposed to all that complexity/power/whatever you want to call it during your first run.

5

What if you add weight (numeric) to tags in the settings page, and use it for prioritizing results?
If you do that and provide some default ones for templates, scripts, etc… in a new instance those results could be thrown to the bottom from the beginning.
And this way you could also allow the user to tweak the tags and weights as they see fit

6

Is the main issue that the picker(s) become too crowded? What about having the ability to exclude certain things from the picker by default?

e.g. maybe exclude Libraries/ by default from showing up? Or exclude notes tagged with #archived (or in an Archived/ folder).

Another idea would be to expand on the current recently-used feature the picker already has. Instead of it being per session(?), save a list of the most recently or maybe just the most common pages and use that to calculate better weights to sort with.

I like having a separate page picker and template picker, but maybe template picker could become “everything else picker” where templates, space scripts, space styles, etc show up, and the page picker would only show actual note pages. space script isn’t necessarily a template, but I would consider it different than a normal note. I’m not really sure what to call them, but it’d make sense imo to still have a “normal note page picker” and a “notes that do stuff picker”

1 Like
7

This is exactly the way I’d like to keep using it

A proposition I have would be to have One Picker To Rule Them All, but the button or command to open it could pre-fill the query (One Syntax To Find Them All)

If the selected result is a command, it is run, and if it’s a page it’s navigated to.

To keep the current user experience, I imagine that the application installs with “a button that opens the picker with not-template page query”, “a button that opens the picker with commands query” and “a command that opens the picker with template query”. Not even in the Core Library, shipped in default SETTINGS for actionButtons (And In The Settings Bind Them).

Completely different suggestion to consider: some programs (notably Visual Studio Code), can open a single text box on top, and if you start the content with > it will look for commands, with just text – look for files, with : it’s line number etc. I like it less, since it’s still a predefined set of choices, but seems popular and relevant to the discussion.

8

I started looking into this, and have it partially working.
artistic rendition:

omnibar
omnibar1834×1101 71.4 KB

Feels natural to have search in there as well instead of hidden away as a separate command.

@zef If this seems like a good idea, let me know so I can finish it

3 Likes
9

I’m an absolute newbie to SilverBullet so take it for what it’s worth, but I think content is different from code. Users who open the page picker expect to see their content (well, I would anyway). I’d make that the default, and use either a separate menu, or filters, or tabs or something to remove that default filter.

2 Likes
10

New idea while on the way home from vacation:

I agree that keeping content and “meta stuff” separate is a good idea. Either you’re in “development mode” or in “content mode”. So here’s my idea:

  1. We consider all pages tagged #template or #meta (new) as “meta content”. #template would obviously be specific to templates, and anything else you consider non regular content, including pages like SETTINGS, PLUGS, as well as pages where you keep your space scripts, you can tag with #meta which would make those pages disappear from the regular “Page Picker” (Content Picker?). This would also keep the page picker clean for newcomers.
  2. We rename the “Template Picker” into a “Meta picker”, only showing pages tagged with either #template or #meta

Thoughts?

11

On the current Edge builds I’ve now made this change by rebranding the “Template Picker” to “Meta Picker” see CHANGELOG for more details.

12

I see, this is kind of a good seperation I think. Everything else than the content are classified in the meta, so no need to make more pickers.

13

That’s my thinking, yes

1 Like