Gebruik van Messageboxen

[Sebazzz]

Soms zijn de simpelste dingen in het leven al een dilemma. Zo ook het laten opkomen van een MessageBox.

Mijn twijfels heb ik bij het gebruik van type iconen en type knoppen. Waarom zou je een 'OK/Cancel' knop gebruiken en wanneer een 'Yes/No' knop. Wanneer een asterisk en wanneer een error icon?

Tuurlijk, error voor fatale fouten. En een asterisk voor niet fatale fouten of waarschuwingen. Maar als een proces niet wil starten omdat er al een zelfde proces draait, is dit dan een fatale fout of een waarschuwing dat de gebruiker het andere proces moet afsluiten?

En je kan met het 'Ok/Cancel - Yes/No" probleem ook twee kanten op.
- "Dit schrijft het huidige bestand over. Deze actie kan niet meer ongedaan gemaakt worden." (Ok/Cancel)
- "Dit schrijft het huidige bestand over. Deze actie kan niet meer ongedaan gemaakt worden. Doorgaan?" (Yes/No)

Op MSDN en Google kan ik geen artikelen vind die scenario's geven wat betreft dit en wat qua usability het beste is. Kijkend naar diverse OSS projecten zijn programmeurs nou niet de beste qua usability (en ook UI design ). Tips en trucs?

[ Voor 5% gewijzigd door Sebazzz op 07-12-2008 03:05 ]

[Atmosphere]

Licht er maar aan hoe je er naar kijkt...
Als het proces niet kan functioneren is het een 'fatal'

Als je de vraag anders stelt maakt het niet veel meer uit
"Het bestand bestaat reeds. Wilt u het huidige bestand vervangen?" Ja/Nee (of Ok/Cancel)

[ Voor 25% gewijzigd door Atmosphere op 07-12-2008 03:16 ]

[LauPro]

Het zou verboden moeten worden imo. In KDE hebben ze het in veel programma's opgelost door in veel programma's (AmaroK bijv.) een soort delayed message queue te gebruiken waar je ook zelf kan instellen wat je wel/niet wil zien. Tevens is er een notificatiesysteem waarbij je bij sommige programma's kan kiezen welke meldingen een geluidje, vlaggetje of desgewenst een messagebox moet komen.

Eerlijk gezegd vind ik de messagebox uit de tijd en deze zou niet meer toegepast moeten worden. Veelal is de informatie in de box te karig om er wat verder mee te kunnen en is het een soort van kluitje in het riet. Je kan toch nooit gebesluiten op basis van een naam of een bestand overschreven mag worden? Hier moet op zijn minst een bestandgrootte, mime-type en eventueel een preview bij.

Ik vraag me dan ook af of dit anno 2008 nog hoeft te worden ontwikkeld, zijn al vele implementaties van?

Verder: dat een schijf vol is is gewoon geen reden voor een messagebox imo. Ik erger mij in ieder geval groen en geel aan messageboxen omdat ze vaak ook nog eens de focus stelen. Gelukkig zijn ze in KDE dus grotendeels uit te zetten.

[To_Tall]

LauPro schreef op zondag 07 december 2008 @ 03:29:
Het zou verboden moeten worden imo. In KDE hebben ze het in veel programma's opgelost door in veel programma's (AmaroK bijv.) een soort delayed message queue te gebruiken waar je ook zelf kan instellen wat je wel/niet wil zien. Tevens is er een notificatiesysteem waarbij je bij sommige programma's kan kiezen welke meldingen een geluidje, vlaggetje of desgewenst een messagebox moet komen.

Eerlijk gezegd vind ik de messagebox uit de tijd en deze zou niet meer toegepast moeten worden. Veelal is de informatie in de box te karig om er wat verder mee te kunnen en is het een soort van kluitje in het riet. Je kan toch nooit gebesluiten op basis van een naam of een bestand overschreven mag worden? Hier moet op zijn minst een bestandgrootte, mime-type en eventueel een preview bij.

Ik vraag me dan ook af of dit anno 2008 nog hoeft te worden ontwikkeld, zijn al vele implementaties van?

Verder: dat een schijf vol is is gewoon geen reden voor een messagebox imo. Ik erger mij in ieder geval groen en geel aan messageboxen omdat ze vaak ook nog eens de focus stelen. Gelukkig zijn ze in KDE dus grotendeels uit te zetten.

Niet mee eens

Message box dient ter info aan de gebruiker.
Maar aan de andere kant heb je ook weer gelijk soms worden mssg te vaak en te snel weergeven. zonder dat er echt duidelijke info in staat.

Je moet jezelf de vraag stellen. Wat is het nut van deze box. Vind je het belanrijk bij onvoldoende schrijf ruimte dit te vermelden?

[LauPro]

To_Tall schreef op zondag 07 december 2008 @ 03:35:
Message box dient ter info aan de gebruiker.
Maar aan de andere kant heb je ook weer gelijk soms worden mssg te vaak en te snel weergeven. zonder dat er echt duidelijke info in staat.

Het is hetzelfde met overwegen, elke messagebox is er een teveel.

Je moet jezelf de vraag stellen. Wat is het nut van deze box. Vind je het belanrijk bij onvoldoende schrijf ruimte dit te vermelden?

Ik denk dat we na 20 jaar messageboxen wel kunnen stellen dat het rijkelijk is mislukt om deze rol aan de developer over te laten. Hoe vaak heb jij een server moeten messageboxen voordat die weer wat ging doen? Ik heb echt alleen maar ellende en negatieve ervaringen aan messageboxen en ik denk dat het over het algemeen gebruikers alleen maar frustreert, getuige ook sites als deze.

Dus mislukt idee, kappen. Zorg er gewoon voor dat er voldoende informatie in een dialog staat en neem dan ook even de moeite er zelf wat moois van te maken.

[To_Tall]

LauPro schreef op zondag 07 december 2008 @ 03:41:
[...]
Het is hetzelfde met overwegen, elke messagebox is er een teveel.
[...]
Ik denk dat we na 20 jaar messageboxen wel kunnen stellen dat het rijkelijk is mislukt om deze rol aan de developer over te laten. Hoe vaak heb jij een server moeten messageboxen voordat die weer wat ging doen? Ik heb echt alleen maar ellende en negatieve ervaringen aan messageboxen en ik denk dat het over het algemeen gebruikers alleen maar frustreert, getuige ook sites als deze.

Dus mislukt idee, kappen. Zorg er gewoon voor dat er voldoende informatie in een dialog staat en neem dan ook even de moeite er zelf wat moois van te maken.

ik las de vraag meer als user dan beheerder een windows gebruiker die bij gebruik van zijn pc een message box krijgt ivm te weinig ruimte is goed.

bij server beheer word ik soms echt zat als windows maar even 100x een ok of ok+cancel box laat zien omdat i service is afgesloten

[LauPro]

To_Tall schreef op zondag 07 december 2008 @ 04:12:
ik las de vraag meer als user dan beheerder een windows gebruiker die bij gebruik van zijn pc een message box krijgt ivm te weinig ruimte is goed.

Volgens mij zijn er maar weinig gebruikers die dat lezen. Van de week nog een laptop een reinstall moeten geven omdat men het voor elkaar kreeg om een servicepack-installatie af te breken wat ook met dergelijke messageboxen ging.

bij server beheer word ik soms echt zat als windows maar even 100x een ok of ok+cancel box laat zien omdat i service is afgesloten

Nouja je geeft het zelf al toe. Terroriseer je users dan niet langer en los het met een andere methode op.

[CoolGamer]

Op MSDN staat een en ander toegelicht over het gebruik van de iconen:
http://msdn.microsoft.com...1277.aspx#evaluatingIcons

De rest van die guidelines zijn ook wel eens interessant om een keer door te nemen: http://msdn.microsoft.com/en-us/library/aa511258.aspx

[ Voor 32% gewijzigd door CoolGamer op 07-12-2008 13:00 ]

[kenneth]

Dat hele Yes/No is sowieso een kansloos verhaal. Apple heeft dat al opgelost en in MSFT-producten zie je dat ook steeds meer.

Do you want to save your changes? Yes / No / Cancel
Do you want to save your changes? Save / Don't Save / Cancel

Bij een simpele vraag als deze kan je nog twijfelen over het nut, maar bij ingewikkeldere vragen weet je bij het klikken gelijk wat er gebeurt, je kiest expliciet voor de actie.

[Snake]

MessageBox is dan ook al verouderd.

Beter kan je kijken naar TaskDialog en TaskDialogIndirect. Deze zijn wel nog niet rechtstreeks op te roepen vanuit .NET, maar er zijn al heel wat wrappers beschikbaar

[compufreak88]

Een mooi artikel wat ik hier op wel van toepassing vind is Never Use a Warning When you Mean Undo.

Soms kun je beter ervoor zorgen dat een handeling ongedaan gemaakt kan worden, dan de gebruiker ervoor te waarschuwen dat een actie tot iets onherstelbaars leidt.

[Sebazzz]

Snake schreef op zondag 07 december 2008 @ 15:41:
Beter kan je kijken naar TaskDialog en TaskDialogIndirect. Deze zijn wel nog niet rechtstreeks op te roepen vanuit .NET, maar er zijn al heel wat wrappers beschikbaar

Maar alleen voor Vista Dat is zonde, zoveel mensen - ik ook - gebruiken nog XP.

@hieronder: Dat was een typo. Trouwens, dat Vista slecht is, dat neem ik niet klakkeloos over, 99% van de mensen denk ik ook niet Vista is idd wat langzamer maar dat is het probleem ook niet zozeer. Ik vind dat Vista slecht is vanwege de totaal verklote UI. Maar die discussie wil ik niet starten nu (daar gaat dit topic ook niet over toch?) Als je pre-Vista OS'en uitsluit, sluit je makkelijk 70% van de markt uit.

[ Voor 29% gewijzigd door Sebazzz op 07-12-2008 20:31 ]

[Snake]

Sebazzz schreef op zondag 07 december 2008 @ 20:02:
[...]
Maar alleen voor Viesta Vista Dat is zonde, zoveel mensen - ik ook - gebruiken nog XP.

Ik kan goed begrijpen dat je een afkeer hebt voor Vista, maar ik zal er wel duidelijk bijzetten dat mijn applicatie dan niet niet voor Pre - Vista - OS'en is.

99% van de mensen die klaagt dat Vista slecht is neemt dat gewoon over van anderen.

[Hydra]

LauPro schreef op zondag 07 december 2008 @ 04:17:
Volgens mij zijn er maar weinig gebruiker die dat lezen.

Er zijn gebruikers die als een GUI applicatie een messagebox tevoorschijn tovert met de melding "Helaas pindakaas, maar je hardeschijf zit vol!" dit NIET lezen? Dat een service meldingen in de eventlog weg hoort te schrijven is niet meer dan logisch, daar hebben we het nier niet over, het gaat over alerts in GUI applicaties v.z.i.w.

[ Voor 20% gewijzigd door Hydra op 10-12-2008 14:33 ]

[alienfruit]

De ontwikkelaar is dan natuurlijk ook niet echt de toegewezen persoon om te bepalen hoe de GUI en interactie van de applicatie is. Daarvoor heb je de interactie ontwerpers, experience designers e.d. voor die na een studie van de doelgroep (bijv. middels personas) en interviews een beeld vormt van de wensen van deze gebruikers om zo tot een gebruiksvriendelijk product te komen. De ontwikkelaar moet gewoon code kloppen

[RobIII]

alienfruit schreef op zaterdag 13 december 2008 @ 00:01:
De ontwikkelaar is dan natuurlijk ook niet echt de toegewezen persoon om te bepalen hoe de GUI en interactie van de applicatie is. Daarvoor heb je de interactie ontwerpers, experience designers e.d. voor die na een studie van de doelgroep (bijv. middels personas) en interviews een beeld vormt van de wensen van deze gebruikers om zo tot een gebruiksvriendelijk product te komen. De ontwikkelaar moet gewoon code kloppen

Helaas is in de praktijk vaak de ontwikkelaar meteen de interactie ontwerper, projectmanager en architect in één

[MSalters]

En helaas zijn er nog steeds interactie ontwerpers die te snel naar een mededeling grijpen. De eerste vraag is hoe je het probleem voorkomt. Om het voorbeeld van de TS aan te halen: Zorg dat de actie wel ongedaan kan worden.

[compufreak88]

MSalters schreef op woensdag 24 december 2008 @ 15:54:
En helaas zijn er nog steeds interactie ontwerpers die te snel naar een mededeling grijpen. De eerste vraag is hoe je het probleem voorkomt. Om het voorbeeld van de TS aan te halen: Zorg dat de actie wel ongedaan kan worden.

Dat is de strekking van het artikel waar ik een link naar plaatste.

[MrBucket]

Toevallig staat er in de MSDN Magazine uitgave van deze maand een artikel over foutmeldingen en messageboxes:
http://msdn.microsoft.com....usabilityinpractice.aspx

[Sebazzz]

Zo'n TaskDialog lijkt mij de beste optie. Het 'altijd ongedaan kunnen maken' is niet altijd reëel

Een mooie manier om deze ook in XP te laten werken:
http://www.codeproject.co...a_TaskDialog_Wrapper.aspx

[RobIII]

Sebazzz schreef op vrijdag 23 januari 2009 @ 21:30:
Een mooie manier om deze ook in XP te laten werken:
http://www.codeproject.co...a_TaskDialog_Wrapper.aspx

Klein detail / mierenneuken: dit is niet "ook in XP laten werken" maar gewoon "na-apen in XP". Nadeel daarvan is dat je niet profiteert van zaken die MS in de toekomst gaan bijschaven noch dat het geheel zich zal houden aan allerlei theme-afhankelijke zaken. Niet dat het geen leuk initiatief is of netjes uitgevoerd is (voor zover ik aan de oppervlakte kan zien, heb niet verder gekeken dan dat).

Edit: en *boem*; daar heb je 't al
Ik zat wat te klikken (kan het niet meer reproduceren, weet niet precies wat ik deed) en toen kreeg ik dit:
^{<< *click*}
Dus 't ding kan niet helemaal lekker overweg met mijn dual monitor setup Benieuwd wat 'ie op de zaak zou hebben gedaan met mijn triple monitor setup

[ Voor 26% gewijzigd door RobIII op 23-01-2009 22:01 ]

[LauPro]

RobIII schreef op vrijdag 23 januari 2009 @ 21:52:
Klein detail / mierenneuken: dit is niet "ook in XP laten werken" maar gewoon "na-apen in XP". Nadeel daarvan is dat je niet profiteert van zaken die MS in de toekomst gaan bijschaven noch dat het geheel zich zal houden aan allerlei theme-afhankelijke zaken. Niet dat het geen leuk initiatief is of netjes uitgevoerd is (voor zover ik aan de oppervlakte kan zien, heb niet verder gekeken dan dat).

XP zal toch met een paar jaar dood zijn en de paar zakelijke gebruikers waar deze problemen het meeste spelen hebben waarschijnlijk geen moeite met deze beperking. Sterker nog, ik heb in diverse zakelijke omgevingen thema's gewoon uit staan.

[RobIII]

LauPro schreef op vrijdag 23 januari 2009 @ 21:59:
[...]Sterker nog, ik heb in diverse zakelijke omgevingen thema's gewoon uit staan.

Thema's zet ik ook meestal uit, maar los van thema's heb je nog zaken als "hoog contrast" en weet ik veel die doorgaans ook door 'user drawn controls' over het hoofd worden gezien. Los van het feit dat bijvoorbeeld shortkeys en andere subtiliteiten vaak niet (of niet goed) worden geïmplementeerd. Het is dus niet alleen "looks". In dit geval, zag ik zo vlug op codeproject onder 'Known Limitations', mist bijv. ook nog de progressbar en inderdaad; zolang je 'm niet nodig hebt boeit het niet. Je moet alleen oppassen dus dat je 't niet als een 'replacement' of 1:1 alternatief gaat zien. Dat was eigenlijk waar ik op doelde.

[ Voor 38% gewijzigd door RobIII op 23-01-2009 22:12 ]

[LauPro]

RobIII schreef op vrijdag 23 januari 2009 @ 22:01:
[...]
Thema's zet ik ook meestal uit, maar los van thema's heb je nog zaken als "hoog contrast" en weet ik veel die doorgaans ook door 'user drawn controls' over het hoofd worden gezien. Los van het feit dat bijvoorbeeld shortkeys en andere subtiliteiten vaak niet (of niet goed) worden geïmplementeerd. Het is dus niet alleen "looks". In dit geval, zag ik zo vlug op codeproject, mist bijv. ook nog de progressbar en true; zolang je 'm niet nodig hebt boeit het niet. Je moet alleen oppassen dus dat je 't niet als een 'replacement' gaat zien. Dat was eigenlijk waar ik op doelde.

Je hebt gelijk. Maar ik zie persoonlijk de messagebox dus al als een work-a-round en iets dat dus verbannen moet worden. Elke eventuele vervanger valt in hetzelfde rijtje. Verder zijn er voor mensen die visueel gehandicapt zijn of iets in die orde gewoon voldoende budgetten om recente spullen te kopen.

[OKA]

Als je dan toch meer info in een messagebox kwijt wilt, en je wilt (of kunt) de Taskdialog niet gebruiken, waarom dan niet Microsoft Exception Messagebox gebruiken. Ik vind dit meer mogelijkheden bieden dan de standaard messagebox, en komt aardig in de buurt van Taskdialog.

Trouwens zijn er meerdere varianten van Taskdialog voor XP, w.o. deze en deze. Er zullen ongetwijfeld nog meer zijn.

[ Voor 26% gewijzigd door OKA op 23-01-2009 22:49 . Reden: Andere Taskdialog's gevonden ]

[LauPro]

Die Exceptionbox is helemaal hilarisch en imo het toonbeeld van slechte en gefaalde softwarearchitectuur.

Ik hoop niet dat ik het verder hoef toe te lichten, maar exceptions van een service horen imo toch echt in een log thuis en niet in gebruikersinteractieve grafische omgevingen. De Veritas back-upsoftware heeft imo een hele mooie architectuur voor beheer van services en interaction design.

[RobIII]

LauPro schreef op vrijdag 23 januari 2009 @ 23:09:
Ik hoop niet dat ik het verder hoef toe te lichten, maar exceptions van een service horen imo toch echt in een log thuis en niet in gebruikersinteractieve grafische omgevingen.

Wie heeft het over een service?

[Verwijderd]

Dit is een grappig artikel omdat ik zelf namelijk (een tijdje terug) met precies dezelfde gedachte zat als jij in je titel omschrijft

Ik denk dat de Yes/No voor gebruiker keuzes bepaald moet worden bij:
- Bestand vervangen?
- Weet u zeker dat...

En Ok/Cancel meer een optie is voor:
- Weet u zeker dat u wilt sluiten zonder op te slaan

Nou kan het voor beide ook omgedraaid worden natuurlijk maar is denk ik een kwestie van "smaak/gewoonte" mja dat bepaald de programmeur zelf > Ja/Nee

Vincent

[ Voor 6% gewijzigd door Verwijderd op 31-01-2009 13:43 ]

[Sebazzz]

Niet alleen voor jezelf maar ook voor de gebruiker vind ik de commandbox de ideale oplossing. Simpel, mooi en gebruiksvriendelijk.

Wil u het bestand verwijderen?
Ja, verwijder xxx.txt
Nee, verwijderd xxx.txt niet
(in de footer) Deze actie kan niet ongedaan gemaakt worden!

[alt-92]

Verwijderd schreef op zaterdag 31 januari 2009 @ 13:15:
Nou kan het voor beide ook omgedraaid worden natuurlijk maar is denk ik een kwestie van "smaak/gewoonte" mja dat bepaald de programmeur zelf > Ja/Nee

Nou, Cancel is niet hetzelfde als Nee of Ja.

Cancel is "vergeet alles tot mijn laatst bevestigde actie in deze dialoog" - ik mag aanvinken en invullen wat ik wil, maar als ik op [cancel] druk verwacht ik als user/tester/whatever dat al die settings dan ook niet doorgevoerd worden.

Daar heb je [OK/Yes] voor.