Moeten ongeautoriseerde acties in de gebruikersinterface worden verborgen, uitgeschakeld of resulteren in een fout?

Dit is een eeuwige vraag voor mij die ik nooit echt heb opgelost, dus ik zou graag uw input willen hebben. Als ik acties heb waarvan ik weet dat een gebruiker deze niet kan uitvoeren vanwege onvoldoende privileges of objectstatus, moeten de UI-elementen voor die acties dan voor de gebruiker verborgen, zichtbaar maar uitgeschakeld of zichtbaar zijn en resulteren in een fout als deze wordt geprobeerd? Wat zou de reden voor uw antwoord zijn? Indien uitgeschakeld, zou u dan de reden willen meedelen waarom en, zo ja, hoe?

Dit is een webinterface, dus ik weet al dat ik de inkomende post/toestemmingen moet controleren en daar hoe dan ook fouten moet afhandelen. Ik heb het vooral over het omgaan met de gebruikersinterface.

Dit is vergelijkbaar met Regels over het uitschakelen of verbergen van menu-items, hoewel ik geïnteresseerd ben in alle soorten UI-elementen, niet alleen in menu’s.

Voorbeelden:

1. Ik heb een nieuwe pagina waarmee een gebruiker een nieuw evenement kan maken. Gebeurtenissen kunnen hoofdgebeurtenissen of subgebeurtenissen zijn. Voor het maken van een hoofdgebeurtenis is het recht “EditMasterEvent” vereist, terwijl het maken van een subgebeurtenis alleen het recht “EditEvent” vereist. Ik heb een vervolgkeuzelijst waarmee je een bestaande gebeurtenis kunt kiezen als de bovenliggende (hoofdgebeurtenis) of geen bovenliggende gebeurtenis (dit is een hoofdgebeurtenis). Moet de keuze “Maak Master Event” worden weergegeven in de vervolgkeuzelijst of wordt weggelaten als de gebruiker alleen “EditEvent”-rechten heeft.

2. Voor het verwijderen van gebeurtenissen moet u applicatiebeheerder zijn of over de juiste bewerkingsrechten voor het gebeurtenistype beschikken. In dat laatste geval moet het evenement ook ouder zijn dan 5 jaar. Het verwijderen van een evenement leidt tot grote trapsgewijze verwijderingen van gerelateerde gegevens in het systeem en om juridische redenen moeten deze gegevens gedurende ten minste 5 jaar na het evenement worden bewaard. Aangezien deze bewerking zeldzaam is voor de normale gebruiker, is het typische geval dat de actie niet beschikbaar is. Moet het altijd worden getoond of alleen als het echt mogelijk is?

Antwoord 1, autoriteit 100%

Verborgen – Dit is de beste aanpak voor acties die nooit beschikbaar zijn voor de huidige gebruiker. Het heeft geen zin om de gebruiker mentale inspanning te laten verspillen om uit te zoeken waarom iets is uitgeschakeld als er geen actie is ondernomen om dit te veranderen.

Uitgeschakeld – Dit is de beste aanpak voor acties die soms wel beschikbaar zijn, maar niet op dit moment of in de huidige context. Een uitgeschakelde optie moet twee dingen overbrengen: ten eerste is de actie momenteel niet beschikbaar en ten tweede kan de gebruiker iets doen om de actie beschikbaar te maken (een instelling of toestemming wijzigen, een item selecteren, vereiste gegevens invoeren, enz. ). Als u in een tooltip kunt aangeven wat er moet gebeuren om de actie mogelijk te maken, des te beter. Het in-/uitschakelen van acties als de gebruiker gegevens invoert of de context verandert, geeft uitstekende feedback over wat het programma nodig heeft.

Fout met een fout – Dit is de slechtste keuze. U moet alleen een foutrapport gebruiken voor bewerkingen die mogelijk werken: u kunt niet zeggen dat het zal mislukken, behalve door het te proberen.

Antwoord 2, autoriteit 40%

Zoals bij bijna alle UI-vragen, is het antwoord “het hangt ervan af”.

Je moet vindbaarheid onder andere afwegen tegen gebruikerstevredenheid. Als u bijvoorbeeld een ongeldige actie toestaat, kunt u uitleggen waarom iets ongeldig is. Dit is vooral handig als het antwoord op “waarom is dit uitgeschakeld” niet duidelijk is. Voor een applicatie waar de meeste gebruikers beginners zijn, is dat belangrijk.

Aan de andere kant kan het erg frustrerend zijn om een ​​besturingselement te zien, erop te klikken en vervolgens te worden beloond met een “sorry, dat kan nu niet”-bericht. Een app die ik een paar jaar geleden heb geërfd, stond vol met dat soort dingen en het maakte het gebruik van de gebruikersinterface tot een frustrerende oefening.

Het volledig verbergen van functionaliteit is waarschijnlijk zelden een goed idee. Stel je voor dat je een functie kent “was er een minuut geleden” maar nu is het weg. Of het nu een menu-item is, een werkbalkknop of iets heel anders, het verbergen ervan kan een frustrerende oefening zijn voor de eindgebruiker.

Probeer wat bruikbaarheidstests uit te voeren, al was het maar door de volgende persoon die je ziet te vragen “hey, heeft het zin om dit uit te schakelen of je een informatieve dialoog te laten zien”. Vaak is één andere mening al voldoende om het probleem van een andere kant te bekijken.

Kortom: doe wat de gebruiker het beste dient. Alle scenario’s die u noemt zijn geldig onder bepaalde omstandigheden. Zoals met alle UI-vragen, vraag jezelf (of beter, je gebruikers) af wat het beste aan hun behoeften voldoet.

Antwoord 3, autoriteit 28%

Ik schakel de elementen uit in plaats van ze te verbergen. Op die manier weet de gebruiker dat de optie normaal gesproken beschikbaar zou zijn, en ik geef een tooltip om uit te leggen waarom het element momenteel niet beschikbaar is.

Antwoord 4, autoriteit 11%

Het hangt ervan af. Wil je dat de gebruiker weet dat de actie mogelijk is, alleen niet voor hen? Laat ze in dat geval de knop zien, maar schakel deze uit. Een voorbeeld kan zijn als een gebruiker geen verwijderingsbevoegdheid heeft, maar andere gebruikers wel. Ze moeten weten dat items KUNNEN worden verwijderd, zodat ze iemand kunnen vragen het voor hen te doen als ze de actie nodig hebben.

Aan de andere kant, als de gebruiker niet eens van de actie op de hoogte mag zijn (een gebruiker die bijvoorbeeld geen leestoegang heeft tot controlelogboeken zou waarschijnlijk niet moeten weten dat deze logboeken bestaan), zou dit niet moeten kunnen zie de knop, dus verberg hem volledig.

Antwoord 5, autoriteit 6%

Goede vraag!

Een paar overwegingen:

Als u de elementen op de pagina plaatst maar ze uitschakelt, is er nog steeds een kleine kans dat de gebruiker het systeem kan controleren en ze kan inschakelen met een javascriptlet.

Als je ze helemaal niet laat zien, kan de algemene functionaliteit een beetje verwarrend zijn voor de algemene gebruiker. “Moet hier geen edit-knop zijn?”

Als je de elementen wilt weergeven en uitschakelen of wilt weergeven en verifiëren, zou ik zekerserver-side validatie doen. Laat de validatie niet in handen van JavaScript; Ik denk dat de redenen hiervoor duidelijk zijn.

Antwoord 6, autoriteit 6%

Ik heb de neiging om de twee verschillende soorten situaties verschillend aan te pakken. Is dit een actie die wordt bepaald door privileges en door de status van het object.

Als de persoon niet genoeg rechten heeft om een ​​actie uit te voeren, verberg ik de optie, ze weten niet dat ze de actie kunnen uitvoeren.

Als de optie niet beschikbaar is omdat het object zich niet in een staat bevindt die die optie kan gebruiken, schakel ik deze uit, zodat de optie zichtbaar is voor de gebruiker, maar er kan geen actie worden ondernomen.

Van uw voorbeelden:

1. Ik zou “Maak Master Event” niet als optie hebben. De gebruiker heeft onvoldoende rechten om het te bekijken.

2. Ik wil dat de knop Verwijderen zichtbaar is voor de beheerders. Afhankelijk van hoe je de rest van de site doet (veel zichtbare tekst, tooltips, helppictogram, enz.), zou ik die conventie volgen om de gebruiker te informeren waarom de knop op dit moment niet bruikbaar is. En eventueel een timer aanzetten, hierboven, bij de knop met hoe oud het bericht is of hoe lang het duurt voordat het kan worden verwijderd.

Antwoord 7, autoriteit 2%

Afhankelijk van het item zullen we ze verbergen of uitschakelen. Als de gebruiker toegang heeft tot een groot kenmerk, maar niet tot een kleiner stuk erin, dan zullen we het kleinere stuk verbergen. Als de gebruiker echter toegang heeft tot verschillende grote functies, maar niet tot andere, laten we ze zichtbaar maar uitgeschakeld als een marketingtruc om hen eraan te herinneren dat de functies beschikbaar zijn voor aankoop als ze besluiten dat ze ze willen.

Antwoord 8, autoriteit 2%

Ik heb ook enkele programma’s gezien die het menu-item uitschakelen en de tekst ervan wijzigen in “Log in om blah…”

Ik vind dit leuk omdat het me niet achterlaat met de vraag “waarom werkt dit niet?” gevoel en vertelt me ​​meteen wat ik moet doen om het werkend te krijgen. Niet in alle gevallen van toepassing, maar dit is een mooie aanpak als je het kunt implementeren.

Antwoord 9, autoriteit 2%

De algemene regel is gebruik van uitschakelen als de gebruiker iets in de UI kan doen om het voorrecht te krijgen. Uitgeschakeld betekent “Je kunt dit commando doen, maar gewoon niet op dit moment de manier waarop dingen zijn.” De “Way Things zijn” omvat de huidige selectie, dus gebruik het inschakelen / uitschakelen als de gebruiker het EditEvent-privilege heeft voor oude objecten, maar niet voor nieuwe objecten. Er moet een duidelijke indicatie zijn welke objecten kunnen worden verwijderd, zodat gebruikers begrijpen waarom de bijbehorende opdrachten zijn uitgeschakeld voor sommige objecten (bijv. Als gebruikers over het algemeen weten dat er 5 jaar een eenvoudige leeftijdsbevoegdheid moet worden bewaard, is een eenvoudige leeftijd met een grafisch verschil voor records over 5 jaar oud).

Gebruik berichtvakken in plaats van uit te schakelen als er geen manier is om de reden te maken voor het uitschakelen van duidelijk aan de gebruiker die ervan uitgaande dat ze gemiddelde kennis van het domein hebben. Tooltips voor gehandicapte bedieningselementen, BTW, zijn een geweldig idee, maar misschien niet voldoende.

Gebruik het verbergen als de gebruiker nooit het voorrecht heeft, ongeacht wat ze doen in de UI gezien hun huidige positie in de organisatie (bijvoorbeeld, zij zijn geen applicatie-beheerder). Het rommelig en frustrerend om voor deze zaak uit te schakelen of berichtenvakken te gebruiken. Wat de gebruikers betreft, hebben acties waarvoor ze niet het voorrecht hebben, niet hun werk (anders zouden ze het voorrecht hebben), en dus moeten de bijbehorende bedieningselementen gewoon niet bestaan ​​in hun gebruikersinterface. Handleidingen voor documentatie- of organisatieprocedure kunnen gebruikers vertellen hoe dergelijke acties worden bereikt (bijvoorbeeld “, uw supervisor creëert nieuwe evenementen voor u.”).

Ik heb meer details op http://www.zuschlogin.com/?P=40 .

10, Autoriteit 2%

Ik zou zeggen uitschakelen met een zweven met de reden.

Het voorkomt dat de gebruiker zich afvraagt ​​wat er in vredesnaam aan de hand is, terwijl ze tegelijkertijd weten dat bepaalde acties onder de juiste omstandigheden mogelijk zijn.

11

Mijn persoonlijke gevoel is dat de elementen altijd aanwezig moeten zijn. Als de gebruiker niet genoeg machtigingen heeft om ze te doen, moeten ze een fout genereren wanneer erop is geklikt.

Ik weet dat vertalers niet echt van het creëren van een zillion verschillende “toestemming geweigerd” foutmeldingen, dus dit wordt vaak niet gedaan in gelokaliseerde toepassingen, die de neiging hebben om de elementen te verbergen.

In de praktijk hebben veel mensen de neiging om de opties te verbergen, zelfs in niet-gelokaliseerde apps.

12

Andere mensen hebben goede antwoorden gegeven met geldige suggestie om verbergende elementen te voorkomen en in plaats daarvan uit te schakelen en een aantal hints te geven om de redenen.

Dus, ik zou het vanuit verschillende perspectief willen bekijken – maar hoe u een aantal UI-elementen kunt verbergen in gevallen waarin de gebruiker ze niet hoeft te zien, ongeacht of hij geen rechten heeft voor bepaalde acties met betrekking tot de elementen ?

Laten we bijvoorbeeld zeggen, gebruikers van een rol krijgen toegang tot verkopersrecords in het systeem.

Maar dan zegt Business Analyst: “Kijk, er is een vervolgkeuzelijst met verkoperslijst in dit formulier en we mogen geen specifieke rollen toestaan ​​om het te zien”.

Developer vraagt: “Dus verwijder we de toestemming van de” leesverkopers “van deze rol, toch?” Maar de analist antwoordt: “Nee! Deze rol moet nog steeds de verkopers op de pagina Verkopers kunnen bekijken. Het is slechts deze enkele vorm waar we de lijst voor sommige rollen moeten verbergen en deze aan een andere rollen laten zien.”

Dus, de ontwikkelaar voegt toestemming toe met de naam “Show Sellers Dropdown op het formulier X”.

Oeps, nu hebben we een probleem. Toegang tot dezelfde gegevens wordt beheerd door twee afzonderlijke machtigingen. Nu moeten we uitzoeken hoe we beide kunnen combineren. En wat als er meer dan één formulier is waar de verkoperslijst voor sommige rollen verborgen moet zijn? Hoe combineren we het met “Lees de verkoperslijst”? Voor ons, ontwikkelaars, is het enigszins duidelijk dat de machtiging “Lezen” een hogere prioriteit moet hebben boven “Bekijken”, dus zelfs als een gebruiker een lijst kan “Bekijken”, zou hij deze nog steeds niet moeten zien (of leeg of uitgeschakeld zien met een handig hint) als hij geen “Lezen” toestemming heeft. Wij, ontwikkelaars en analisten van het systeem weten het. Maar hoe moet de systeembeheerder dat weten? Moeten we hem dit leren? Hoe kunnen we garanderen dat de beheerder niet al die “Bekijken” en “Lezen” voor de enkele gegevenslijst door elkaar haalt?

Zoals je ziet, wordt het allemaal om één reden rommelig: we combineren gegevensverwerkingsrechten met UI-gemakken in de lijst met rolrechten.

Ik heb veel projecten gezien waar het rommelig wordt omdat machtigingen aan de serverkant te veel worden gekoppeld aan de gebruikersinterface, wat om problemen en mogelijke beveiligingslekken vraagt ​​(omdat je meerdere items in je rolmachtigingseditor hebt voor dezelfde acties op de dezelfde gegevens).

Machtigingen hebben betrekking op toegang tot en bewerkingen op bepaalde specifieke gegevens. De gebruikersinterface kan alleen op een consistente manier reageren op machtigingen in het hele systeem (uitschakelen met hints, verbergen enz.). We mogen nooit nieuwe toestemmingsvermeldingen uitvinden alleen voor UI-doeleinden.

Nu blijft de vraag – maar hoe verbergen we UI-elementen voor sommige systeemgebruikers om te voorkomen dat ze worden overspoeld met enorme hoeveelheden altijd uitgeschakelde items? Een oplossing kunnen rolwerkruimten zijn. Als we duidelijk weten dat gebruikers van een bepaalde rol nooit toegang tot bepaalde gegevens nodig hebben, maken we een set UI-besturingsitems, vergelijkbaar met machtigingen, maar deze keer noemen we ze geen machtigingen. En we kunnen hier echt zin in hebben, zelfs gebruikers zelf toestaan ​​om hun werkruimte vrij aan te passen en te kiezen wat ze wel of niet kunnen zien. Toestemmingen hebben natuurlijk altijd de hoogste prioriteit, maar dit heeft alleen invloed op de gegevens en de status van UI-elementen en niet op de zichtbaarheid.

Dat zijn mijn twee cent. Helaas heb ik zelf nog niet op zo’n systeem gewerkt waar permissies en UI werkruimte opties netjes gescheiden zijn omdat ik op de een of andere manier altijd te laat op een project kom, als de “schade is geschied”. Maar ik hoop dat ik ooit een kans krijg. Ik hoop gewoon een goed voorbeeld te vinden hoe dit goed te doen, maar op de een of andere manier levert internetzoekwerk me niets nuttigs op. Betekent het echt dat niemand anders tot dezelfde conclusies is gekomen als ik? Ik geloof het niet, iemand in de wereld van ontwerppatronen voor ondernemingen had deze UI<->permissie-impedantie-mismatch al lang geleden moeten opmerken.