[ui] FR: a tile for searching

[madduck]

It would be great to have a tile to start a search from the dashboard, rather than having to first navigate to the documents/items view.

Bonus points if this tile could

1. keep a history of searches for quick access (just clicking on one will run it), with the ability to remove wrong searches;
2. list a couple of pre-defined searches, e.g. bookmarks.

[madduck]

Alternatively: maybe the header should have a search field anyway…

[v6ak]

My opinion: Maybe the header would be a more common and more useful place for the search bar.

Should I start working on it?

[eikek]

Hey there! I'd prefer a tile over the header (it's more flexible to use). But I'm also fine with only the header - just be aware of the mobile version. If it is the header, I think it would be nice to then have a toggle in the user settings to switch it off. @v6ak if you like to work on that, very great and much appreciated!!

[madduck]

a header has the benefit that it's accessible from everywhere, and search is the most common usage isn't it? why make the user return to the dashboard for every search?

regarding mobile client, it needs to be done responsively for sure so as to not be in the way.

[eikek]

a header has the benefit that it's accessible from everywhere, and search is the most common usage isn't it? why make the user return to the dashboard for every search?

I guess this always depends on how you use it and your visual preferences. Search is very much not my most common usage. For example, I also have one overview screen that I would like to stay cleaner. I would be also fine with both versions 😏 But it's fine to add it to the header, as I said. I think a toggle to have it optionally disappear is not a big thing to add (and perhaps make it very distraction free).

[madduck]

sounds sensible. i have seen ui where the search can be unfolded and then that is the preference, ie. then it stays unfolded until the user folds it again. No need to hide another setting in the preferences...

[v6ak]

I am a bit tempted to put the search phrase to URL. Maybe it would make invoking the search from other pages easier. Is there a fundamental reason it is not in the URL?

[eikek]

I am a bit tempted to put the search phrase to URL. Maybe it would make invoking the search from other pages easier. Is there a fundamental reason it is not in the URL?

There is no real reason. I didn't need a bookmarkable search page and it is some work. Also, once you do the query, it is tempting to do all the state of the page - otherwise it is not really bookmarkable… and this is even more work 😄 Anyways, I'd say this is another issue, no? I don't think it makes it easier to invoke the search page from pages inside the application (not sure if that is what you meant).

[v6ak]

With my knowledge of the code, the two-stage solution looks easier, or maybe at the same level.

[madduck]

@v6ak what is the "two-stage solution"?

[v6ak]

Now, it somehow works (needs some polishing), but there is one weird UX thing – duplicated search input on the search page:

Even if they are synced, it looks weird and confusing. Potential solutions:

a. Remove the search input from the search page and leave just the one in the header bar. This would be consistent with some other UIs (Github, Google Docs, …), but it goes against the optionality of the input in headerbar. Still doable (e.g., disabling search input in headerbar would show the old one), but not sure if this is the way to go. b. Ditch the search in headerbar and create a tile. c. Accept two separate inputs, just sync them properly. (Almost done.) d. Something else I haven't thought of.

[eikek]

I don't understand why a) goes against making it optional? But I think it would be good when the header bar has a little icon (next to the user icon) that would open the search bar (and it should look better 😄). Then it can stay everywhere. On the items page, the two boxes can be synced or the header search bar can be opened automatically and the current search bar removed. The app can store the last state (open/close) of the header search bar, perhaps. Would that make sense?

[v6ak]

I don't mean it was impossible to use solution A with optional searchbar, just not sure if it would result in a good UX. This scenario would look a bit weird to me:

1. Open search page.
2. Search something.
3. Expand the search in headerbar using the little icon.
4. The second searchbar collapses.

Still, I am not an UX expert and if both you and @madduck are OK with that, I can implement it.

Anyway, if we want to go for A/C, I should ~~finish proper bidirectional synchronization of those two inputs. (It is unidirectional ATM, likely easy to adjust it.)~~ EDIT: done.

[v6ak]

Progress:

• Bidirectional sync
• Buttons for showing and hidding search
• Settings persistence

Screenshots:

Missing:

• Focus – the field should be autofocused after search button is pressed, but not in other cases (e.g., when page is loaded). Autofocus seems to be quite clumsy for this task (EDIT: plus it is ignored), maybe I'll need to assign an id (EDIT: It seems that Task.attempt (\_ -> NoOp) (Dom.focus "header-search-input") is performed too soon).
• Input height / margin.
• Mobile devices?
• Optionally: hide the search input on search page, as it is duplicated.

[v6ak]

Thinking about the mobile devices:

Google Docs on Android:

• no logo
• denser and fewer buttons on the right side
• When searching, it shows only close (arrow left) and clear (cross) buttons. Other buttons are inaccessible. It doesn't even allow the user to open left sidebar (unless you use 𝝘 gesture or L gesture; the L gesture is tricky to do; I guess just few users are aware of that).

What could we do

• Hiding the logo might be controversial, as it gets the user home.
• Two buttons on the right: Do we really need two separate buttons?
• Hiding buttons when searching might be controversial a bit.

Potential quick solution

Just disable those items on small screens. (And ensure the old search field isn't hidden in those cases.)

[eikek]

cool. so for mobile etc I don' mind reorganizing the menu items a bit if that makes more sense. It is also ok for me to remove the logo on small screens. the menu can still be used to navigate around.

I still don't like the styling so much 😅 The button could look the same as the other two buttons (no border for example). The search input could be more integrated, perhaps sharing the background or making it slightly lighter/darker etc

[v6ak]

Style

I've adjusted the style:

• Remove logo on small screens when headerbar search is enabled.
• Some style adjustments (background, border) as you've suggested.

Drawbacks

• The search input is still quite small (IMHO minimum acceptable), there is still some room for improvement.
• I've hardcoded the input height (height: 2.4rem; margin-top: 0.3rem; or height: 38px; margin-top: 5px;), not sure how to do it better.

Focus

I've failed with autofocus. Anyway, this would be hacky and could potentially lead to focus stealing when redrawn.

~I've succeeded delayed Dom.focus. I originally hoped for something like setTimeout(…, 0) (even zero timeout enqueues the function call), but it isn't enough. It works with hardcoded 100ms delay:~

            , Cmd.batch
                [ Api.saveUserClientSettingsBy model.flags newSettings ClientSettingsSaveResp
                , Task.attempt (\_ -> NoOp) (
                    (Process.sleep 100)
                    |> Task.andThen (\x -> Dom.focus "header-search-input")
                )

Of course, this is awful. ~I need a proper way to enqueue the focus just after redraw, rather than hoping that the hardcoded timeout is fine in all cases on every client.~

EDIT: I've done it in a better way, see next comment.

[v6ak]

I've found a better way to handle the focus. Moreover, it is more responsive when network is slow or temporarily disconnected, as the UI change is performed without waiting.

There is probably still something to improve in the code style, but at least I've got rid of the awful hardcoded timeout.

So, maybe the input height (I don't want just to hardcode height: 2.4rem; margin-top: 0.3rem;) is the only remaining thing for an acceptable implementation. (Just my guess; I am not the one who decides what's acceptable.)

[v6ak]

It seems that items-center can do the job for input height. However, there is one more thing – the “New items arrived!” message. In desktop, just adding proper spacing seems to be enough.

On mobile, it doesn't look well:

OTOH, not sure if it should be task for this issue, as it doesn't seem to have been handled well before. EDIT: Maybe “New items arrived” could be handled by red dot on small devices, like there: https://imgur.com/usaARQy

Anyway, I can probably create a PR.

[eikek]

This message could be a floating one maybe on small devices? The red dot is also ok, it won't allow to click on it to get to the items view, but that is a good compromise probably. I think it should be done in this issue, because searching on small devices was working well before. If the search bar is gone on the other view this is the only way one can search now. Before we had the complete width of the screen for the search bar.

[v6ak]

I find the red dot to be more universal, but it might be overkill for Docspell at the moment. Not sure what you mean by floating message. Do you mean https://149366088.v2.pressablecdn.com/wp-content/uploads/2016/04/updates-available.jpg ?

The problem isn't is searching on small devices. It is in “New items arrived” message, even if the searchbox is hidden. But I can work on it anyway.