BetaBreak/voxit-project
BetaBreak/voxit-project
1
0
Fork 0
Code Issues 22 Projects 2 Releases Wiki Activity

Empty, one state visualisation enhancements #50

New issue
Closed
opened 2025-06-23 09:25:11 +00:00 by RaoulKramer · 11 comments
RaoulKramer commented 2025-06-23 09:25:11 +00:00 (Migrated from gitlab.com)
Copy link
  • no toggle with one state
  • empty state should not be visualised

This cause of the stock polis api / DB

- [ ] no toggle with one state - [ ] empty state should not be visualised This cause of the stock polis api / DB
RaoulKramer commented 2025-06-23 09:30:18 +00:00 (Migrated from gitlab.com)
Copy link

changed title from Empty state should not be visualised to Empty, one state visualisation enhancements

<p>changed title from <code class="idiff">Empty<span class="idiff left right deletion"> state should not be visualised</span></code> to <code class="idiff">Empty<span class="idiff left right addition">, one state visualisation enhancements</span></code></p>
RaoulKramer commented 2025-06-23 09:30:18 +00:00 (Migrated from gitlab.com)
Copy link

changed the description

changed the description
RaoulKramer commented 2025-06-30 15:29:57 +00:00 (Migrated from gitlab.com)
Copy link

changed the description

changed the description
RaoulKramer commented 2025-08-05 15:14:41 +00:00 (Migrated from gitlab.com)
Copy link

assigned to @gberh

assigned to @gberh
gberh commented 2025-08-19 07:52:35 +00:00 (Migrated from gitlab.com)
Copy link

This is not so straightforward because groups and even the majority results can appear or disappear again at any time. What should we do e.g. if the results view is open and then all groups disappear again and there are no majority results? Should we automatically close the results view and hide the button? Or should we leave the empty view open and hide the button once the user has closed it? I would find either quite confusing behavior as a user.
Another option would be to have an inactive button state but then we also need to handle the case that the results view is already open and results disappear again.

This is not so straightforward because groups and even the majority results can appear or disappear again at any time. What should we do e.g. if the results view is open and then all groups disappear again and there are no majority results? Should we automatically close the results view and hide the button? Or should we leave the empty view open and hide the button once the user has closed it? I would find either quite confusing behavior as a user. Another option would be to have an inactive button state but then we also need to handle the case that the results view is already open and results disappear again.
RaoulKramer commented 2025-08-28 14:28:35 +00:00 (Migrated from gitlab.com)
Copy link

assigned to @AdriaanTV and unassigned @gberh

assigned to @AdriaanTV and unassigned @gberh
RaoulKramer commented 2025-08-28 14:39:17 +00:00 (Migrated from gitlab.com)
Copy link

assigned to @gberh and unassigned @AdriaanTV

assigned to @gberh and unassigned @AdriaanTV
RaoulKramer commented 2025-09-01 13:24:50 +00:00 (Migrated from gitlab.com)
Copy link

Screenshot_2025-09-01_at_14.27.22

@gberh @AdriaanTV suggested this solution.

![Screenshot_2025-09-01_at_14.27.22](/uploads/1f7de4756a4633e3442710a71e8c30e9/Screenshot_2025-09-01_at_14.27.22.png) @gberh @AdriaanTV suggested this solution.
gberh commented 2025-09-03 06:37:26 +00:00 (Migrated from gitlab.com)
Copy link

Currently it looks like this:

particiapp-no-results

Possible states are:

  1. no majority and no groups results: a message is shown under majority and all group tabs are hidden (the above screenshot)
  2. majority results but no groups: majority results visible and all group tabs are hidden
  3. no majority results and but some group results: a message is shown under majority and group tabs are visible with the respective results
  4. majority results and group results: results are visible under their respective tabs

For state 1. I can use the above design, what about 3.? Should the panel be "tab-specific" rather than a something like modal dialog and switching to available group results still be allowed?

Currently it looks like this: ![particiapp-no-results](/uploads/38e5922cf735473b9cacdbb4105b1d2a/particiapp-no-results.png) Possible states are: 1. no majority and no groups results: a message is shown under majority and all group tabs are hidden (the above screenshot) 2. majority results but no groups: majority results visible and all group tabs are hidden 3. no majority results and but some group results: a message is shown under majority and group tabs are visible with the respective results 4. majority results and group results: results are visible under their respective tabs For state 1. I can use the above design, what about 3.? Should the panel be "tab-specific" rather than a something like modal dialog and switching to available group results still be allowed?
AdriaanTV commented 2025-09-03 09:20:14 +00:00 (Migrated from gitlab.com)
Copy link

Hi,

I would suggest the following:

  • Always show the tabs of visualisations (whether something is available or
    not), don't hide them
  • Show a message explaining why that particular visualisation is currently
    unavailable (so yes, tab specific)

This way, tabs won't disappear and reappear which would be confusing,
because you don't have any feedback why they suddenly vanish. The most
important rule of thumb is to provide the participants an explanation as to
why it's not available atm, but will become available if conditions are
met. Hope this helps!

PS this is different from showing buttons/actions when the corresponding
action is not available btw. Disabling buttons is frustrating when it's
unclear why the buttons doesn't work.

Grt, Adriaan

...

On Wed, Sep 3, 2025 at 8:37 AM Guido Berhörster (@gberh) < gitlab@mg.gitlab.com> wrote:

Guido Berhörster https://gitlab.com/gberh commented
https://gitlab.com/betabreak/polisnl/polisnl-project/-/issues/50#note_2725893492:

Currently it looks like this:

[image: particiapp-no-results]
https://gitlab.com/-/project/53019818/uploads/38e5922cf735473b9cacdbb4105b1d2a/particiapp-no-results.png

Possible states are:

  1. no majority and no groups results: a message is shown under
    majority and all group tabs are hidden (the above screenshot)
  2. majority results but no groups: majority results visible and all
    group tabs are hidden
  3. no majority results and but some group results: a message is shown
    under majority and group tabs are visible with the respective results
  4. majority results and group results: results are visible under their
    respective tabs

For state 1. I can use the above design, what about 3.? Should the panel
be "tab-specific" rather than a something like modal dialog and switching
to available group results still be allowed?

—
Reply to this email directly or view it on GitLab
https://gitlab.com/betabreak/polisnl/polisnl-project/-/issues/50#note_2725893492.

You're receiving this email because of your account on gitlab.com.
Unsubscribe
https://gitlab.com/-/sent_notifications/REDACTED/unsubscribe
from this thread · Manage all notifications
https://gitlab.com/-/profile/notifications · Help
https://gitlab.com/help Notification message regarding
https://gitlab.com/betabreak/polisnl/polisnl-project/-/issues/50#note_2725893492
at 1756881447

Hi, I would suggest the following: - Always show the tabs of visualisations (whether something is available or not), don't hide them - Show a message explaining why that particular visualisation is currently unavailable (so yes, tab specific) This way, tabs won't disappear and reappear which would be confusing, because you don't have any feedback why they suddenly vanish. The most important rule of thumb is to provide the participants an explanation as to why it's not available atm, but will become available if conditions are met. Hope this helps! *PS this is different from showing buttons/actions when the corresponding action is not available btw. Disabling buttons is frustrating when it's unclear why the buttons doesn't work.* Grt, Adriaan <details><summary>...</summary> On Wed, Sep 3, 2025 at 8:37 AM Guido Berhörster (@gberh) < gitlab@mg.gitlab.com> wrote: > Guido Berhörster <https://gitlab.com/gberh> commented > <https://gitlab.com/betabreak/polisnl/polisnl-project/-/issues/50#note_2725893492>: > > > Currently it looks like this: > > [image: particiapp-no-results] > <https://gitlab.com/-/project/53019818/uploads/38e5922cf735473b9cacdbb4105b1d2a/particiapp-no-results.png> > > Possible states are: > > 1. no majority and no groups results: a message is shown under > majority and all group tabs are hidden (the above screenshot) > 2. majority results but no groups: majority results visible and all > group tabs are hidden > 3. no majority results and but some group results: a message is shown > under majority and group tabs are visible with the respective results > 4. majority results and group results: results are visible under their > respective tabs > > For state 1. I can use the above design, what about 3.? Should the panel > be "tab-specific" rather than a something like modal dialog and switching > to available group results still be allowed? > > — > Reply to this email directly or view it on GitLab > <https://gitlab.com/betabreak/polisnl/polisnl-project/-/issues/50#note_2725893492>. > > You're receiving this email because of your account on gitlab.com. > Unsubscribe > <https://gitlab.com/-/sent_notifications/REDACTED/unsubscribe> > from this thread · Manage all notifications > <https://gitlab.com/-/profile/notifications> · Help > <https://gitlab.com/help> Notification message regarding > https://gitlab.com/betabreak/polisnl/polisnl-project/-/issues/50#note_2725893492 > at 1756881447 > </details>
gberh (Migrated from gitlab.com) closed this issue 2025-09-18 14:39:10 +00:00
gberh commented 2025-09-18 14:39:11 +00:00 (Migrated from gitlab.com)
Copy link

Fixed in particiapp/particiapp-reference-frontend@7c520dcd2d.

Fixed in particiapp/particiapp-reference-frontend@7c520dcd2d59765e242fc5a62be99ef6982ebc62.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
BZK

   
Backlog

   
Bug

   
Prio 1

   
Prio 2

   
Prio 3

   
RC

   
Testing

   
WIP

   
auth

   
doc

   
feature

   
frontend

   
idea

   
integration

   
math

   
ops
  
bug
Something is not working

  
duplicate
This issue or pull request already exists

  
enhancement
New feature

  
question
More information is needed

  
testing

   
verify

   
wontfix
This won't be fixed

No labels
BZK
Backlog
Bug
Prio 1
Prio 2
Prio 3
RC
Testing
WIP
auth
doc
feature
frontend
idea
integration
math
ops
bug
duplicate
enhancement
question
testing
verify
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
BetaBreak/voxit-project#50
No description provided.