feat: hide quick add magic help behind a tooltip #3353
No reviewers
Labels
No Label
area/internal-code
changes requested
confirmed
dependencies
duplicate
good first issue
help wanted
hosting
invalid
kind/bug
kind/feature
question
wontfix
No Milestone
No project
No Assignees
3 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/frontend#3353
Loading…
Reference in New Issue
No description provided.
Delete Branch "feature/hide-quick-add-magic-help"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR changes the behaviour of the quick add magic tooltip below the task input field. The tooltip is now shown all the time until hidden. When it was hidden, that status is saved in local storage so that it persists across reloads.
I'm not 100% sure about this, because once hidden there's no way to open the help text modal (at all) because the message will not be shown again until logging out and in again. We could either add this as another setting in the user settings to allow users to change this afterwards, or add a way to open the modal with the text somewhere else.
Resolves #3253
Hi konrad!
Thank you for creating a PR!
I've deployed the changes of this PR on a preview environment under this URL: https://3353-feature-hide-quick-add-magic-hel--vikunja-frontend-preview.netlify.app
You can use this url to view the changes live and test them out.
You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/.
Have a nice day!
@ -1,5 +1,5 @@
<template>
<div class="task-add" ref="taskAdd">
<div class="task-add">
<div class="add-task__field field is-grouped">
Add a square BaseButton with nice padding (full height of one text line) to the top right of the textarea wrapper div. It has an info "?" icon inside. It has a tooltip with the quick add magic hint from the expandable. The same message is also via
aria-label
on the BaseButton. On click it will open the explanation directly.Reuse the hover logic to show and hide the info button.
If I'm not mistaken the
quickaddmagic.vue
will be obsolete.That makes sense.
I've now changed it so that it does what you're describing, but kept it in the existing component. That way the modal (and all logic to show it) stays in there and does not pollute the add task component.
The new version doesn't hide the "?" icon when the add-task is not hovered or focused.
To simplify the logic the
delayEnter
option of useElementHover can be used (didn't exist before).I guess this could still be abstracted via a slot.
This way we would have an info component that shows the '?' always when focused or hovered.
Contrast of the icon is really bad
I've improved the contrast
IMHO it's fine to leave it like that. It's not in the way and would avoid flickering of another element when focusing
Fine with me. Flickering would be 'subtle' though, because I imagined a transition.
Now I think that the default is too strongly visible. What I head in mind was an alignment with e.g. the hover for lists / projects in the SingleLineInList task.
The color also needs a defined transition. If we add that transition we should add it for the icon in the front as well.
Added a transition, seems to reduce the flickering by a lot. I also added a hover effect to highlight the icon when the input field is hovered.
Only seems to work if the field is focused
It works for me when the input is not focused. Which browser and version are you testing in?
Might be that I didn't test the latest version. Works now
@ -3,6 +3,7 @@
<p class="help has-text-grey">
{{ $t('task.quickAddMagic.hint') }}.
<ButtonLink @click="() => visible = true">{{ $t('task.quickAddMagic.what') }}</ButtonLink>
<ButtonLink @click="() => emit('hide')" class="ml-1">{{ $t('task.quickAddMagic.hide') }}</ButtonLink>
Remove extra
() =>
@ -1,9 +1,13 @@
<template>
<div v-if="mode !== 'disabled' && prefixes !== undefined">
Remove wrapper div and use template instead
Ah, I thought you couldn't use a
template
as root node. TIL.I guess that changed in vue 3?
Now changed
Unsure, but yes might be!
@ -805,3 +805,2 @@
"quickAddMagic": {
"hint": "You can use Quick Add Magic",
"what": "What?",
"hint": "You can use Quick Add Magic. Click to learn more.",
Not happy with this last part of the text.
Don't like my current alternative:
I've changed it now.
@ -105,0 +117,4 @@
right: 0;
pointer-events: auto !important;
&.is-highlighted {
Is nesting even necessary if we already need to use
!important
for inheriting the color?It isn't, I added the nesting out of habit. Removed it now.
@ -805,3 +805,2 @@
"quickAddMagic": {
"hint": "You can use Quick Add Magic",
"what": "What?",
"hint": "Use magic prefixes to define due dates, assignees and other task properties.",
That's very good!
@ -104,2 +104,4 @@
}
}
// Global style, because the rest of this styling is imported from bulma
Define this in the component we actually need it. This way we don't have to move this style when we remove bulma.
Also: do we overwrite some styles here?
If not: couldn't we add a new class for these icons instead, where used?
AFAIK we don't override these styles. We do use these classes in two places however, so that would mean we have to duplicate it if I put it where it's used?
I think that would be better. We do import
$transition
globally, so there is already a common link.Another way could be to define the transition via a CSS-property, e.g.
--form-icon-transition
(and set the value via the$transition
), so the dependancy is solved via DOM hierarchy. Since CSS-properties are scoped by their nature it's also not polluting some global namespace.While having an animation on icons makes sense I would no like to increase of use of classes created by bulma. So if we want to change something I think it would be better to create new classes for these elements – even if they already have classes.
Maybe a way of thinking of it is similar to
js
-hook classes. Sometimes one uses classes likejs_is-open
where that prefix makes clear that the class was set during runtime (I saw that pattern mostly in context of vanilla dom libs in combo with SSR). So just imagine that all bulma classes havebulma-
prefixed and these are all of bulmas namespace. In order to decrease / minimise our dependency on bulma, which is generally a good thing todo we should not use those classes to add our styles, but instead add new ones.I've moved it to the components (duplicating it).
That makes perfect sense. Ripping bulma out and replacing it with something else entirely is a whole separate project though, but it's a good idea to decrease our dependency on it, not increase it.
@ -105,0 +115,4 @@
<style lang="scss" scoped>
.show-helper-text {
right: 0;
pointer-events: auto !important;
Why
pointer-events: auto
?Because in
BaseButton
we set that tonone
which makes the button unclickable (and unhoverable).That can't be it, because there it's set to
auto
as well: https://kolaente.dev/vikunja/frontend/src/branch/main/src/components/base/BaseButton.vue#L115Seems to be the
.control.has-icons-left .icon
class of bulma. Can you add a comment?It also seems that the textarea could profit from
has-icon-right
so that there is enough padding for the button.Added a comment and more padding.
@ -105,0 +114,4 @@
<style lang="scss" scoped>
.show-helper-text {
right: 0;
Positioning should happen from outside. Remove
right: 0
from hereDone
I had to use an unscoped style for this because I could not add a new class to the
quick-add-magic
component due to it being multi-node. Not sure if that's the best solution.cdc6886b17
to4b7a49a94a
4b7a49a94a
to25c3b7bcbf
feat: allow hiding the quick add magic help tooltip with a buttonto feat: hide quick add magic help behind a tooltip