- Niklas Brunberg
- Medlem ●
- Linköping
Tognazzini (eller vad han nu hette) skriver ju där att lösningen vore att göra de gråa menyvalen klickbara. Då skulle man kunna klicka på det för att få upp en förklaring om varför det inte går.
Problemet, som jag ser det, är att du ju då tillåter val av något som inte ska vara valbart? De gråa menyvalen ska ju inte gå att välja. Om jag plötsligt kan välja dem för att få en förklaring till varför jag inte kan välja dem så blir åtminstone jag förvirrad... Fast det är klart, det kanske är bättre än ingenting.
Precis, visst är det bättre att få upp information om varför det inte fungerar, men vi är ju redan överens om att bygga upp någon slags databas för varför vissa saker inte går att göra i större system inte är lätt. Därför måste man förhindra att den situationen uppstår från första början.
Sånt går ju alltid att lösa med visuella indikationer, exempelvis kanske inte hela menyalternativet är klickbart, utan bara en symbol av något slag i högerkanten..
Det större problemet är förmodligen att man inte alltid vet varför det inte går att välja. Ett villkor av något slag har ej uppfyllts, men det är inte säkert att det går att förklara särskilt tydligt, framförallt inte pedagogiskt. I vissa fall kan det t.ex. bero på att det markerade objektet, vad det nu må vara för något, saknar nödvändiga metoder eller attribut. Det behöver inte vara något problem med det specifika objektet som är markerat, utan att funktionen helt enkelt inte är applicerbar på det. Varför kan du inte veva ned fönstret i köket på samma sätt som du vevar ner fönstret i bilen? Därför att det inte går. Varför öppnas inte ytterdörren inåt? Därför att den inte gör det. Varför går det inte att snurra på köksstolen på samma sätt som på kontorsstolen? För att den saknar snurrfunktion. Varför saknar köksstolen snurrfunktion? Därför att den gör det. En utförligare förklaring på dessa problem kan mycket väl jämföras med funktioner som inte är applicerbara på ett markerat objekt. Det går inte för att objektet saknar egenskaper för att göra det möjligt. Att leverera meningslösa och intetsägande förklaringar av detta slag skulle inte göra systemet mer användarvänligt. Snarare tvärtom, det skulle bli mer förvirrande. Ibland är faktiskt "det går inte" mer begripligt än "det går inte för att det är inte gjort på ett sätt så att det går".
Vissa designval har gjorts för att upplevelsen av applikationen ska förbättras i det stora hela, även om man vet vad användaren försöker göra och skulle kunna tillåta det.
I exemplet att "klippa ut" en fil så är ju inte skälet till att det inte går att filen inte får tas bort. Anledningen är inte heller att filen inte får kopieras via lagring i urklipp. Båda dessa funktioner är tillåtna och möjliga på annat vis, framförallt av skäl som berör användarvänlighet. En "förklaring" som säger mer än "det går inte" (vilket det utgråade alternativet redan säger) skulle ofta innebära en djupdykning i användarvänlighetsprinciper och teori som inte skulle göra användaren det minsta klokare. Snarare förargad eftersom systemet mer eller mindre säger "jag förstår vad du vill göra men du får inte göra det på det här sättet, gör det på det här andra sättet istället". - Om systemet vet vad jag vill göra, gör det då, för i helvete, istället för att gagga om principer. Liksom.
Problemet är dock oftast inte att systemet vet exakt vad det är vad du vill göra och kan förklara varför det inte går, utan att menyvalet inte är applicerbart på det valda objektet.
Sånt går ju alltid att lösa med visuella indikationer, exempelvis kanske inte hela menyalternativet är klickbart, utan bara en symbol av något slag i högerkanten..
Inte bara visuella indikationer, beteendet är minst lika viktigt. Bäst är ju som sagt att aldrig försätta användaren i den situationen att den vill handla på ett sätt som den sen upptäcker är omöjligt. Vad som händer. Vad det gör. Det finns en anledning till att det hela tiden rekommenderas att man använder verb i t.ex. dialogrutor.
Vissa designval har gjorts för att upplevelsen av applikationen ska förbättras i det stora hela, även om man vet vad användaren försöker göra och skulle kunna tillåta det.
Precis, Linux-sjukan att det är bra att kunna ställa in varenda variabel i systemet är jobbig när den drabbar sånt man faktiskt vill jobba med.
I exemplet att "klippa ut" en fil så är ju inte skälet till att det inte går att filen inte får tas bort. Anledningen är inte heller att filen inte får kopieras via lagring i urklipp. Båda dessa funktioner är tillåtna och möjliga på annat vis, framförallt av skäl som berör användarvänlighet. En "förklaring" som säger mer än "det går inte" (vilket det utgråade alternativet redan säger) skulle ofta innebära en djupdykning i användarvänlighetsprinciper och teori som inte skulle göra användaren det minsta klokare.
Användaren av systemet behöver veta lika mycket om användbarhetsprinciper som bilisten som kör över Öresundsbron behöver veta om betonggjutning.
Snarare förargad eftersom systemet mer eller mindre säger "jag förstår vad du vill göra men du får inte göra det på det här sättet, gör det på det här andra sättet istället". - Om systemet vet vad jag vill göra, gör det då, för i helvete, istället för att gagga om principer. Liksom.
Varför har du fått för dig att systemet ska berätta om användbarhetsprinciper för användaren? Det låter ju galet.
Problemet är dock oftast inte att systemet vet exakt vad det är vad du vill göra och kan förklara varför det inte går, utan att menyvalet inte är applicerbart på det valda objektet.
Jag återkommer till det jag hela tiden sagt: Man ska undvika den situationen från första början.
Inte bara visuella indikationer, beteendet är minst lika viktigt. Bäst är ju som sagt att aldrig försätta användaren i den situationen att den vill handla på ett sätt som den sen upptäcker är omöjligt. Vad som händer. Vad det gör. Det finns en anledning till att det hela tiden rekommenderas att man använder verb i t.ex. dialogrutor.
...
Jag återkommer till det jag hela tiden sagt: Man ska undvika den situationen från första början.
Men det är ju i praktiken omöjligt. Man kan ju aldrig förutse vad olika användare vill göra i olika situationer. Det borde leda till antingen ett väldigt begränsat system eller en massiv "behemoth" där man kan göra allting, alltid. Inget av alternativen är optimalt.
Ja, vad sägs om vad du själv tror och tycker? Det försvinner liksom i textmassan bland alla citat och länkar.
Okej.
Men det är ju i praktiken omöjligt. Man kan ju aldrig förutse vad olika användare vill göra i olika situationer. Det borde leda till antingen ett väldigt begränsat system eller en massiv "behemoth" där man kan göra allting, alltid. Inget av alternativen är optimalt.
Det går visst utmärkt. Det går bra att förutsäga hur människor reagerar i olika situationer, vad de kan koncentrera sig på, vad de kan hålla i minnet och hur man fångar uppmärksamhet på olika sätt. Dessutom kan man på olika sätt ge information utan att man för den delen gör ett gigantiskt system.
Det går visst utmärkt. Det går bra att förutsäga hur människor reagerar i olika situationer, vad de kan koncentrera sig på, vad de kan hålla i minnet och hur man fångar uppmärksamhet på olika sätt. Dessutom kan man på olika sätt ge information utan att man för den delen gör ett gigantiskt system.
Jag är med på teorin, men det är oerhört svårt att få till det i praktiken. Och tro mig, jag är intresserad av detta. Jag jobbar som utvecklare och har försöker ha dessa saker i bakhuvudet när jag designar gränssnitt.
Egentligen är det ju vansinnigt att vi utvecklare som har väldigt lite utbilidning i detta ska designa gränssnitten men det flesta företag begriper inte att det behövs särskild kompetens utan tycker att "Det kan väl ingenjörerna fixa. Hur svårt kan det vara".
Läs vad jag skriver ordentligt. Jag har inte påstått det du skriver att jag påstått.
1. Hur "undviker" du att användaren hamnar i situationen att han vill välja valet "klipp ut" eller "ångra" i menyn, fast det inte går?
2. Hur förklarar du för användaren varför det inte går att klippa ut filen? Det går ju att flytta den, och den går att ta bort. Varför går den inte att klippa ut?? Och, som sagt, vi vill ju inte gå in på användbarhetsprinciper...
3. Skriv en förklaring till användaren varför det inte går att välja "ångra" i menyn. Den programmatiska anledningen är att undo/historik-kön är tom. Hur förklarar du det så att användaren blir klokare?
Läs vad jag skriver ordentligt. Jag har inte påstått det du skriver att jag påstått.
Vad syftar detta på då?
[...] innebära en djupdykning i användarvänlighetsprinciper och teori som inte skulle göra användaren det minsta klokare.
1. Hur "undviker" du att användaren hamnar i situationen att han vill välja valet "klipp ut" eller "ångra" i menyn, fast det inte går?
Vill du ha ett specifikt svar för endast detta problemet eller ett generellt svar för denna typ av problem?
2. Hur förklarar du för användaren varför det inte går att klippa ut filen? Det går ju att flytta den, och den går att ta bort. Varför går den inte att klippa ut?? Och, som sagt, vi vill ju inte gå in på användbarhetsprinciper...
Jag trodde det var precis det vi diskuterade: Användbarhet.
3. Skriv en förklaring till användaren varför det inte går att välja "ångra" i menyn. Den programmatiska anledningen är att undo/historik-kön är tom. Hur förklarar du det så att användaren blir klokare?
Det är inte den bästa lösningen.
Jag vill ha ett specifikt svar på hur du "undviker att användaren hamnar i situationen" att han vill välja ångra i menyn men det inte går. Samt, hur du "undviker att användaren hamnar i situationen" att han vill välja klipp ut på en fil, fast det inte går.
Jag vill ha ett specifikt svar på hur du förklarar för användaren varför det inte går att klippa ut filen, samt varför det inte går att ångra.
rhesus, eftersom du tydligen inte gillar min kurslitteratur och annan litteratur jag har här, vad för forskning accepterar du att jag citerar för att lägga fakta bakom mina argument?
rhesus, eftersom du tydligen inte gillar min kurslitteratur och annan litteratur jag har här, vad för forskning accepterar du att jag citerar för att lägga fakta bakom mina argument?
Ja, vad sägs om vad du själv tror och tycker? Det försvinner liksom i textmassan bland alla citat och länkar.
Ge mig ett svar då, Niklas. Berätta hur man gör för att undvika att användaren hamnar i situationen att han/hon vill Ångra eller Klippa ut, trots att det inte går.
Sen kan du även berätta hur man förklarar varför det inte går att Ångra en åtgärd eller Klippa ut en fil.
Jag vill alltså inte få mer kurslitteratur citerad kring generella fall, utan förklara dessa två specifika fall. Jag vill mena att det inte går att undvika dem, och de kan inte förklaras så att användaren begriper mer än han/hon redan gör av att menyalternativen är utgråade. Nå?
1986 mötte jag den första Macen. Den stod i ett gemensamt "datarum" på mitt första jobb. En Mac SE med den gamla klassiska Macintosh-karossen. Man fick boka tid på en lista utanför datarummet. När det var ens tid att testa maskinen satt man där en timme och klickade försiktigt... jaha en mus... och menyer... Kopiera, Klistra in... coolt.
Det som varit utmärkande för alla Mac OS har varit vikten av igenkänningsfaktorn. Alla program har sedan första Mac OS haft en Arkiv-meny och en Redigera-meny. Ångra, Klipp ut, Kopiera, Klistra in finns genomgående i alla program. Kommandot Inställningar finns på samma ställe i alla program osv.
Med det här igenkänningstänkandet är det mer logiskt att ge grå färg på kommandon som inte för stunden kan användas. Det ger mer lugn och ro i menyerna. Om man tog bort det som var grått så försvinner igenkänningsfaktorn och användaren måste leta efter kommandona, för inget klick i menyerna blir likt det föregående klicket. Windows idé om att krympa ihop menyer är väl skräckexemplet. "Undrar om det finns något intressant kommando bland de gömda? Bäst man klickar och kikar..."
Det grå menykommandot betyder "Går ej att utföra just nu".
Det grå betyder inte "Det här borde väl gå? Försök igen..."
Det grå menykommandot säger allt man behöver veta. Jämför med om man tog bort kommandot för att det inte funkar just nu. Vilken fråga skulle uppstå då? Exakt samma fråga som nu! "Kan man inte klippa ut?" Skillnaden i det senare fallet är att frågan inte blir "besvarad" av systemet. Den grå säger "Jag är inte tillgänglig just nu". Ta bort kommandot och du har en användare som kommer att fladdra runt i menyerna och leta som galen efter Klipp ut.
Varför Apple valt att inte bygga in Klipp ut i Finder kan ha många orsaker. Det har inte funkat på det viset tidigare i Mac OS. Det går inte hand i hand men Apples grundfilosofi för gränsnitt osv... Diskussionen känns dock inte så motiverad. Vi har inget Klipp ut på filer hur mycket vi än skriver på det här forumet. Det finns så många lösningar på det här att den här diskussionen blir ändå rätt meningslös.
Jogin, den här diskussionen går runt i cirklar.
Lösningen finns där för detta specifika problem, det handlar om att använda den logik som användes för att objektet ska bli grått för att förklara varför. Därefter kommer vi till argumentet att det är jobbigt, blir plottrigt och så vidare. Då kommer vi diskutera om en lösning på hur man får det o-plottriggt och så vidare. Och lösningen på att få det o-plottrigt är en generell metod som från början ser till att användaren inte hamnar i den situationen då den ställer sig frågan "jag vill göra X, men X går tydligen inte att göra och det finns inget som förklarar varför." När jag lägger fram det argumentet så vill du tillbaka på det specifika igen och hela karusellen börjar om från början. Underbart! Är det inte?
Anders Täpp.
Om du ser mina första ilägg i diskussionen så har jag länkat till de lösningarna och min argumentation har alltid handlat om varför det är dåligt med alternativ som inte fungerar utan någon förklaring varför de inte fungerar.
Om du ser mina första ilägg i diskussionen så har jag länkat till de lösningarna och min argumentation har alltid handlat om varför det är dåligt med alternativ som inte fungerar utan någon förklaring varför de inte fungerar.
Jo jag ser... grejen är bara att jag inte direkt bryr mig...
Jag är nöjd med de utgråade menyerna som är en utmärkt kompromiss som ger mig all info jag behöver.
Jogin, den här diskussionen går runt i cirklar.
Lösningen finns där för detta specifika problem, det handlar om att använda den logik som användes för att objektet ska bli grått för att förklara varför.
Om du hade minsta lilla förståelse för hur programmering går till så skulle du förstå varför detta inte går. Anledningen till att Ångra inte går är att historik-kön är tom. Det finns inga "inspelade" händelser att backa till, om man säger så. Precis som när det inte går att backa i webbläsaren för att fönstret i fråga inte har några tidigare webbsidor att backa till. I fallet med Ångra-funktionen så kan ju dock användaren anse att han/hon har utfört någon åtgärd, även om det han/hon utfört inte registrerats i historik-kön (massor av åtgärder registreras inte i historik-kön). Så, berätta, hur förklarar du för användaren varför det inte går att Ångra den okända åtgärden som inte registrerades till historik-kön? Allt du vet är att historik-kön är tom. Det finns inget att ångra. Hur förklarar du detta för användaren på ett sätt som gör denne klokare än att alternativet bara är utgråat?
Och lösningen på att få det o-plottrigt är en generell metod som från början ser till att användaren inte hamnar i den situationen då den ställer sig frågan "jag vill göra X, men X går tydligen inte att göra och det finns inget som förklarar varför." När jag lägger fram det argumentet så vill du tillbaka på det specifika igen och hela karusellen börjar om från början. Underbart! Är det inte?
Det är för att du vägrar svara på frågan. Du vägrar berätta hur du förtydligar för användaren varför det inte går att välja Klipp ut på en fil. Kom igen nu då, förklara det. Varför går det inte att klippa ut en fil?
Du vägrar också svara på hur man ser till att "användaren inte hamnar i den situationen". Hur gör man det? Hur gör man så att användaren inte vill välja Ångra i menyn fast historik-kön är tom? Hur gör man så att användaren inte vill välja Klipp ut ur menyn på en fil? Hur förhindrar du att dessa situationer uppstår? Berätta nu då istället för att bara repetera teori som du själv inte ens begriper dig på. Du har uppenbarligen ingen förståelse eller kunskap om programmering, och därför förstår du inte varför eller när denna teori inte kan appliceras.
Om du hade minsta lilla förståelse för hur programmering går till så skulle du förstå varför detta inte går.
Jag kan bara sex olika programmeringsspråk varav tre objektorienterade (html/css inte inräknade). Jag har gjort CMS-system och talsyntes, parsat naturligt språk och ocr med neurala nät och så vidare. Hur många språk ska jag kunna för att förstå hur programmering går till?
Anledningen till att Ångra inte går är att historik-kön är tom. Det finns inga "inspelade" händelser att backa till, om man säger så. Precis som när det inte går att backa i webbläsaren för att fönstret i fråga inte har några tidigare webbsidor att backa till. I fallet med Ångra-funktionen så kan ju dock användaren anse att han/hon har utfört någon åtgärd, även om det han/hon utfört inte registrerats i historik-kön (massor av åtgärder registreras inte i historik-kön). Så, berätta, hur förklarar du för användaren varför det inte går att Ångra den okända åtgärden som inte registrerades till historik-kön? Allt du vet är att historik-kön är tom. Det finns inget att ångra. Hur förklarar du detta för användaren på ett sätt som gör denne klokare än att alternativet bara är utgråat?
Längden av historik-kön == Noll -> "Du har inte gjort något som kan ångras."
Men det är ju inget bra svar. Det löser ju inte användarens egentliga problem. Eller hur? Användarens problem är ju att den försökte göra något som inte gick. Alltså ska man inte försätta användaren i den situationen från första början.
Det är för att du vägrar svara på frågan. Du vägrar berätta hur du förtydligar för användaren varför det inte går att välja Klipp ut på en fil. Kom igen nu då, förklara det. Varför går det inte att klippa ut en fil?
Därför att som jag skrev i inlägg #13, något du höll med om: Det är för jobbigt och blir för mycket.
Jag kan bara sex olika programmeringsspråk varav tre objektorienterade (html/css inte inräknade). Jag har gjort CMS-system och talsyntes, parsat naturligt språk och ocr med neurala nät och så vidare. Hur många språk ska jag kunna för att förstå hur programmering går till?
Eftersom du vägrade svara på frågan antog jag att det var för att du inte kunde.
Längden av historik-kön == Noll -> "Du har inte gjort något som kan ångras."
Men det är ju inget bra svar. Det löser ju inte användarens egentliga problem. Eller hur?
Exakt, en "utförligare förklaring", säger ingenting alls mer än det redan utgråade icke-klickbara menyalternativet gör. Avsaknaden av denna intetsägande förklaring kan väl då knappast beskrivas som ett "generalfel" eller som en "bugg"?
Du påstod inledningsvis att detta var ett "generalfel", men tydligen så går det inte alltid att skriva begripliga förklaringar, även om man har all tid och all energi i världen. Eller hur? Faktum är ju att om man visste exakt vad det var som användaren försökte göra så skulle man bara göra det istället för att förklara varför det inte går! Det är på grund av avsaknad av denna information som menyalternativet är utgråat.
Användarens problem är ju att den försökte göra något som inte gick. Alltså ska man inte försätta användaren i den situationen från första början.
Svara då nu hur "undviker man att användaren hamnar i situationen" att han vill Ångra trots att historik-kön är tom, och att han vill Klippa ut en fil. Alltså, jag vill veta hur man undviker det, jag menar inte att du ska repetera att man ska undvika det ytterligare en gång. Beskriv hur. Hur. H-u-r.
Jag vill mena att avsaknaden av utförliga förklaringar vid utgråade menyalternativ inte alls har ett skit med att göra med funktionens omfattning eller hur lång tid den tar att göra; det beror på att det är en dålig lösning som inte gör någonting ett dugg bättre. Vidare går det inte att undvika att användaren vill använda menyalternativ som inte är applicerbara i den nuvarande situationen. Det är inte på något sätt ett generalfel. Du kan citera hur mycket kurslitteratur du vill, men fortfarande så går detta inte att undvika.
man ska högerklicka på en fil och sedan i menyn välja kopiera eller flytta
- i en trädstruktur under respektive val, väljes vilken mapp man vill lägga den i (självklart går det att låta spara senaste x antal mapparna man senast kopierat eller flyttat till eller ange egna snabbval... punk och klart om det e musen som gäller...
Exakt, en "utförligare förklaring", säger ingenting alls mer än det redan utgråade icke-klickbara menyalternativet gör. Avsaknaden av denna intetsägande förklaring kan väl då knappast beskrivas som ett "generalfel" eller som en "bugg"?
Gråa alternativ är dåliga eftersom dom inte berättar för användaren varför det inte går att göra något eller alternativa sätt att göra det på, de berättar bara att det inte går att göra.
Varför är ett problem. Det går (som vi är så slående överens om) inte att spika fast en massa varför på dagens menyalternativ, knappar och don på ett bra sätt.
Du påstod inledningsvis att detta var ett "generalfel", men tydligen så går det inte alltid att skriva begripliga förklaringar, även om man har all tid och all energi i världen. Eller hur? Faktum är ju att om man visste exakt vad det var som användaren försökte göra så skulle man bara göra det istället för att förklara varför det inte går! Det är på grund av avsaknad av denna information som menyalternativet är utgråat.
Generalfelet ligger i att man ställer användaren i en mental återvändsgränd ur vilken den måste back-tracka, ibland väldigt långt och ibland fruktlöst. Det är inte bra. Lösningen är att se till att användaren inte går in i gränden från första början.
Svara då nu hur "undviker man att användaren hamnar i situationen" att han vill Ångra trots att historik-kön är tom, och att han vill Klippa ut en fil. Alltså, jag vill veta hur man undviker det, jag menar inte att du ska repetera att man ska undvika det ytterligare en gång. Beskriv hur. Hur. H-u-r.
Så som menyn ser ut idag? Ett förslag är att faktiskt tillåta att användaren klipper ut filen. Ett annat förslag kan se ut såhär (ursäkta stavfelet, såg det först efter jag tog skärmavbildningen):
Jag vill mena att avsaknaden av utförliga förklaringar vid utgråade menyalternativ inte alls har ett skit med att göra med funktionens omfattning eller hur lång tid den tar att göra; det beror på att det är en dålig lösning som inte gör någonting ett dugg bättre.
Dit har jag försökt komma hela tiden. Skönt att vi är överens på den punkten också.
Vidare går det inte att undvika att användaren vill använda menyalternativ som inte är applicerbara i den nuvarande situationen.
Jodå, det går alldeles utmärkt, jag har redan beskrivit det så många gånger att jag inte orkar upprepa mig ännu en gång.
Jodå, det är ett generalfel.
I hear you loud and clear.
Och det vet du eftersom... ?
Jag hävdar att det går mycket bra att undvika bara man utgår ifrån hur människor reagerar på saker och ting, hur de minns, vad saker och ting betyder och hur man manipulerar det.
Gråa alternativ är dåliga eftersom dom inte berättar för användaren varför det inte går att göra något eller alternativa sätt att göra det på, de berättar bara att det inte går att göra.
Ditt förslag på förklaring var "Du har inte gjort något som kan ångras", vilket du själv medgav inte var något bra svar. Din lösning på problemet löser inte problemet och det förklarar ingenting för användaren. Du har fortfarande inte presenterat en lösning på detta problem som gör det du påstår; det vill säga "förklarar varför" eller "beskriver alternativa sätt att lösa problemet på". Du repeterar bara att något bör göras, och på frågan hur det ska gå till så repeterar du att det bör göras.
Generalfelet ligger i att man ställer användaren i en mental återvändsgränd ur vilken den måste back-tracka, ibland väldigt långt och ibland fruktlöst. Det är inte bra. Lösningen är att se till att användaren inte går in i gränden från första början.
Förklara hur man gör det. Är det oklart vad jag menar med "hur", för den enda förklaring du kommer med är att det bör göras.
Du har fortfarande inte förklarat hur man bättre än med den nuvarande lösningen med utgråade menyalternativ förklarar för användaren varför det inte går att Ångra den okända åtgärden.
Du har fortfarande inte heller förklarat hur man undviker att användaren hamnar i en situation där användaren vill Ångra när historik-kön är tom.
Så som menyn ser ut idag? Ett förslag är att faktiskt tillåta att användaren klipper ut filen. Ett annat förslag kan se ut såhär (ursäkta stavfelet, såg det först efter jag tog skärmavbildningen):
Så ditt förslag på lösning på problemet är att förklara för användaren att "jag vet exakt vad du försöker göra, jag vägrar göra det, gör på ett annat sätt istället". Du tror att användaren blir mindre frustrerad då? Mac - datorn som vet vad du vill göra men vägrar göra det, av principskäl.
Så som menyn ser ut idag? Ett förslag är att faktiskt tillåta att användaren klipper ut filen.
Men hur gör vi om användaren markerar hårddisken och vill klippa ut den? Eller papperskorgen? En nätverksenhet?
Ett annat förslag kan se ut såhär (ursäkta stavfelet, såg det först efter jag tog skärmavbildningen):
/bild/
.
Där undviker du ju inte att användaren hamnar i den situationen att han/hon vill klippa ut en fil trots att det inte går, du ger bara en förklaring till varför.
Där undviker du ju inte att användaren hamnar i den situationen att han/hon vill klippa ut en fil trots att det inte går, du ger bara en förklaring till varför.
Precis. Det har jag försökt säga hela tiden.
Vill du inte förstå eller trollar du? Du verkar inte på något sätt vara dum, därför jag stryker det alternativet.
Du kan ju alltid skriva hur? i fetstil sjutton gånger, då blir det lite tydligare. En tatuering i pannan så att om jag träffar dig så blir det ytterligare lite tydligare. Skicka lite personliga meddelande där du skriver hur? på spanska hjälper definitivt.
Så vi är överens om att utförliga förklaringar är en dålig lösning som inte gör någonting ett dugg bättre - MEN avsaknaden av dem är ändå ett generalfel?
Fortfarande har du inte heller förklarat hur man undviker att användaren hamnar i situationen där han/hon vill använda ett icke-applicerbart menyalternativ. Att det bör göras har du skrivit jättemånga gånger, men inte hur. Inte hur.
Så vi är överens om att utförliga förklaringar är en dålig lösning som inte gör någonting ett dugg bättre - MEN avsaknaden av dem är ändå ett generalfel?
Fortfarande har du inte heller förklarat hur man undviker att användaren hamnar i situationen där han/hon vill använda ett icke-applicerbart menyalternativ. Att det bör göras har du skrivit jättemånga gånger, men inte hur. Inte hur.
Precis så, därför måste man ju ha en metod där man från början berättar för användaren vad den kan göra i systemet (metakommunikations-grejjen). Finns det alltid naturliga tillvägagångssätt kommer man aldrig i den mentala återvändsgränden. Mitt svar på hur? är alltså, för femtioelfte gången:
Gör rätt från början, fråga dig själv: "Vad behöver jag berätta för användaren om det den kan göra här?"
Kom igen nu Brunberg... nu blir jag lite lätt trött...
Vi kör Mac OS X för att slippa de där jämrans popuperna överallt!
Bara för att det går att fylla i en massa extra info överallt så betyder inte detta att det ger en mer optimal upplevelse för användaren. Tvärtom ökar det bara stressen framför skärmen. Hela tiden något att läsa som jag inte fattade. Oj oj oj... jag måste vara jätteklantig som ska få så här mycket råd hela tiden... Det är just sånt här som får mig att bara klara av 30 minuter av Windows i stöten.
Det går inte att klippa ut. I get it, m'key?
Apple hade i OS 9 ett alternativ där man kunde välja en förenklat Finder (morfar-mode). Detta vore en bättre väg att gå om man tror att vissa användare har svårt att förstå allt.