UI exploration: consistent UI pattern for user confirmation
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- html
- Ambito
- design, documentation, frontend
Direzione di ricerca
Review app/templates/custom-elements/security-dialog.html and the linked Static IP change, then inventory confirmation behavior for the other listed dialogs and destructive actions. Define the desired confirmation pattern in the style guide and apply the agreed rules throughout the UI; completion should cover the listed operations consistently.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
I don’t think we follow a deliberate pattern in the UI as to when we require confirmation after button clicks in dialogs. E.g.:
- In the upcoming “Static IP” feature, we’ll have a separate confirmation prompt before removing the static IP address.
- In the
<security-dialog>component, we have a confirmation prompt when toggling off the auth requirement. - Apart from that, I don’t think we have such a confirmation in any of our other dialogs, including the ones that carry out destructive and potentially “harmful” operations, such as:
- Removing individual users
- Disabling the HTTPS enforcement
- Changing the hostname (which causes a device reboot)
- Removing disk images (which are potentially very slow to upload)
Not having any confirmation for these kinds of operations actually makes me feel slightly uneasy. (I’m not sure how e.g. customers feel about that, though, or whether we have ever received “angry” feedback about this.)
In any event, I think we should define our desired UX pattern for user confirmation in the style guide, and then roll out the rules in the entire UI.
UI-wise, there are different patterns for user confirmation. Apart from the aforementioned separate confirmation step/prompt, there are also more light-weight patterns we could consider.
- Lingua principale
- Python
- Stelle
- 3.5k
- Fork
- 291
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di tiny-pilot/tinypilot
-
bug medium
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
tiny-pilot/tinypilot#1419 ·
-
enhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
tiny-pilot/tinypilot#1929 · 3 commenti ·
-
bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
tiny-pilot/tinypilot#1899 · 1 commento ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
tiny-pilot/tinypilot#1896 ·
-
enhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
tiny-pilot/tinypilot#1882 ·
Tutte le issue di tiny-pilot/tinypilot
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
browser-use/browser-use#5905 ·
-
type: enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
ynput/ayon-python-api#363 ·
-
bug needs triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
modelscope/FunASR#3728 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
open-compass/opencompass#2655 ·