Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tooltips or static help texts? #21321

Open
delvh opened this issue Oct 2, 2022 · 7 comments
Open

Tooltips or static help texts? #21321

delvh opened this issue Oct 2, 2022 · 7 comments
Labels
type/question Issue needs no code to be fixed, only a description on how to fix it yourself.

Comments

@delvh
Copy link
Member

delvh commented Oct 2, 2022

We need clarity on when to use tooltips versus when to use static help texts to describe features.
We certainly need at least one of them for many things that aren't immediately obvious (see i.e. #21306).

PRO tooltips

  • only shown when actually necessary
  • they don't shift user focus from the most important UI components to the mostly irrelevant help text
    whenever you navigate on the page
  • easy to implement (class="tooltip" data-content="Tooltip content")

CONTRA tooltips

  • Requires JS to work

PRO static help text

  • does not require JS
  • -> no unexpected errors

CONTRA static help text

  • (for me) unclear, what you need to do to add one
    (do you only need class="help", or do other fomantic UI classes need to be present as well?
    In parent elements?)
  • Always grabs user focus, even on pages/screens where you have to be selective on what to present
  • Slightly larger HTML response size
@delvh delvh added the type/question Issue needs no code to be fixed, only a description on how to fix it yourself. label Oct 2, 2022
@delvh delvh added this to the 1.18.0 milestone Oct 2, 2022
@lunny lunny removed this from the 1.18.0 milestone Oct 17, 2022
@lunny
Copy link
Member

lunny commented Mar 29, 2023

Maybe a clarify documentation under development could resolve the problem?

@delvh
Copy link
Member Author

delvh commented Mar 29, 2023

Yes, but so far there hasn't been any discussion under this forgotten issue, so I don't know which to choose.

@wxiaoguang
Copy link
Contributor

I guess the answer is: use "tooltip-data-content" as much as possible, because it shows faster than title. If the tooltip doesn't fit (like the DiffTreeItem), then fallback to title.

@delvh
Copy link
Member Author

delvh commented Mar 29, 2023

Yes, but that is only part of the question.
This was especially intended with regard to the setting pages, as we often show helper texts there.
Or should the definition be as follows?

  • settings use the static help text
  • else if tooltip is possible (so no Vue yet), use a tooltip
  • else fallback to title

@wxiaoguang
Copy link
Contributor

wxiaoguang commented Mar 29, 2023

settings use the static help text (comment: if it looks good)
else if tooltip (comment: if it looks good)
else fallback to title

I could agree, if the "each" looks good.


... (so no Vue yet), use a tooltip

Vue already supports tooltip transparently. See my #23574

@lunny
Copy link
Member

lunny commented Apr 12, 2023

I vote to use static text as possible. It's clear and with no hidden. Tooltip likes a detailed explanation of a UI element. i.e. when hovering a #111, Gitea will pop up a floating window.

@delvh
Copy link
Member Author

delvh commented Apr 12, 2023

Hmm, as I said: I only partially agree.
From a UX perspective, tooltips are a great invention: They don't take away any of the sparse space on the screen, and subsequently only attract attention when hovered over.
On normal pages, we simply don't have the space to display help texts.
So yes, using static help texts seems most applicable to describe what setting boxes do.
For individual settings, however, I recommend normal tooltips as seen in #21306.

lunny pushed a commit that referenced this issue Apr 12, 2023
Previously, this setting was pretty confusing for users, especially the
difference between "reference" and "issue reference".
Related: #21321.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/question Issue needs no code to be fixed, only a description on how to fix it yourself.
Projects
None yet
Development

No branches or pull requests

3 participants