- Esa
- Medlem ●
- Göteborg
de berömda kommano under alla tider... kopiera klista in....och sedan är det ju klippa ut.. hur kommer det sig att man inte kan trycka ctrl + x (förlåt appleknappen + x) för att klippa ut en fil ? :S.. den funktionen är skuggad... känns som att Steve jobs sitter o flinar åt en i bakrunden och säger Boom varje gång jag slår i bordet... kan ni hjälpa mig så han slutar flina?
Sök på forumet så kommer du hitta en hel hög med diskussioner i ämnet com också tar upp förklaringar till varför det är så.
visst man kan kopiera men det tar längre tid och sedan måste man ta bort dem gamla har precis bytt ifrån windows till mac och jag klipper runt mycket hehe.. sen att dra från ruta till ruta kan man också göra men då borde likaväl apple+x funka
ok så det går inte aså? konstigt att det finns som alternativ fastän man inte kan använda det då?
Som sagt, detta finns det femtioelva diskussioner om redan. Där ges också sjuttiotolv (kanske inte så många, men många i alla fall) alternativa tillvägagångssätt.
Exempel på ett par av de diskussioner som man får fram när man söker:
Knep för att Klippa ut / Klistra in filer i Finder
Varför går det inte att "klippa ut"?
"Riktig" filhanterare?
Saker jag retar ihjäl mig på samt saknar på Macen!
Äpple +C
jo jag förstår men är det inte lite konstigt att de har ett alternativ där det står klipp ut fast de alltid e skuggat varför har am nde där då ? ine konstigt att man tror något e fel
Det är aldrig bra att skugga alternativ utan att berätta varför de är skuggade. Det är ett av generalfelen nästan alla programvaru-makare gör. Dock är det ett bättre alternativ än att helt enkelt ta bort alternativet och därmed förstöra möjligheten till ett konsekvent beteende, utseende och spatial användning.
Rent tekniskt rett är det bara att sätta upp en sanningstabell som är minst ett subset, helst ett superset av den sanningstabell som används för att gråa ut alternativet från första början. Ur den tabellen kan man sen hämta information som beskriver varför villkoren för att använda det alternativet inte är uppfyllda. Dock är det jobbigt och icke-trivialt att göra i stora applikationer, därför görs det helt enkelt inte.
Att berätta något behöver inte göras explicit med text. Det handlar mer om de möjligheter och begränsningar som gränssnittet kommunicerar. Obs. inte har, utan de som användaren kan uppfatta. Om ett system har begränsningar som inte användaren kan förstå ligger irritation eller i alla fall förvåning och kanske konfundersamhet eller besvikelse nära till hands när man väl stöter på dem. Till exempel som med gråa menyalternativ.
För att slänga mig med fina ord: Människa-dator-kommunikation är en speciell gren av tvåsam datormedierad metakommunikation. Med andra ord: Designern ska kommunicera sin bild av hur systemet fungerar till användaren, via systemet. Detta är en nyutveckling av MDI. Inom MDI har man tidigare försökt sig på att som designer skapa något som ligger så nära användarens modell av systemet som möjligt, alltså den klassiska användarcentrerade designmetoden (UCD).
Problemet är att användarens modell av systemet aldrig blir detaljerad, om den ens existerar. Och i Esa-fallet med gråa menyalternativ så finns det inget bra tillvägagångssätt inom användarcentrerad design (och framförallt när det inte används design alls ) att påverka användarens modell. Vad man behöver göra är att i varje situation som kan uppstå bistå användaren med dels information om vad som händer och dels våga fråga användaren om mer information så att systemet kan fortsätta arbeta.
Interaktion är alltså kommunikation.
Vidare kan vi kombinera det vi har med klassisk gestaltpsykologi från Gibson. Vad behöver användaren veta i form av led för att förstå att det behövs och går att klicka [här]? Som designer är man inte begränsad eftersom digitala artefakter saknar egenskaper från början. Det är då man ska ge sådana egenskaper så att de egenskaperna beskriver för användaren vad den kan göra. Vilket också är ett av problemen, världens vanliga lagar gäller inte längre, det är därför så många längtar tillbaka till en spatial Finder - vanliga fysiska lagar som miljoner år har lärt oss att känna igen är vi snabba på att använda och lära oss.
Hoppas det var ett svar du var ute efter och att jag inte flummade iväg för mycket akademika.
Mer i ämnet finns att läsa i t.ex. The Semiotic Engineering of Human-Computer Interaction av De Souza och Design av informationsteknik av Löwgren och Stolterman. För lite kunskap i periferin: Using Language av Clarke.
Du svarade inte på frågan
Tror du skämtar med mig aprillo.
Jogin, jo jag vet att det bara gäller text ich man ska dra filerna, men nu har man fått det uträtt nu vet jag att det faktiskt är en funktion som man kan använda, men man får lära sig o dra filer med musen istälelt för kommandon hehe
Som designer är man inte begränsad eftersom digitala artefakter saknar egenskaper från början. Det är då man ska ge sådana egenskaper så att de egenskaperna beskriver för användaren vad den kan göra.
Nja. Du är förstås begränsad till den mentala och konceptuella bild av systemet som dina användare genom erfarenhet redan har inom systemet. Något "från början" existerar väl ändå inte så ofta?
Att formge sina program enligt helt egna principer alá Kai Krause fungerar som bekant om du är briljant, men annars fungerar det förstås inte alls.
Designern ska anpassa sin bild (och förstås även systemet) till hur användaren förväntar sig att systemet ska fungera. Om något inte fungerar som användaren tror att det ska göra så ska det 1. gå att ångra och 2. gå att få en förklaring till varför det inte gick och 3. gå att fortsätta använda systemet utan större problem.
Det är alltså 3 som gör att det inte dyker upp rutor som berättar om allt som inte går att göra. Ett sånt system skulle sluta fungera pga sina egna storebrors fasoner.
Jämför gärna med Microsofts olika "…Det ser ut som om du skriver ett brev", BOB, och alla de andra varianterna som driver folk till vanmaktens närhet. Vårt favoritföretag har tillochmed gjort en film om just det här beteendet.
Varför stanna vid James Gibson? Vart tog Gombrich vägen? Varför inte backa bakåt till Helmholtz och Fechner? Eller åtminstone nämna Merleau-Ponty? Fast du kanske läser vid Uppsala, där är väl Gibson omhuldad husgud…
Nja. Du är förstås begränsad till den mentala och konceptuella bild av systemet som dina användare genom erfarenhet redan har inom systemet.
Både ja och nej. Problemet är, som jag skrev ovan, att konceptuella modeller är svåra att ta reda på hur de är, om de ens existerar. Existerar de så är de ändå så luddiga och breda att de är svåra att använda.
Att formge sina program enligt helt egna principer alá Kai Krause fungerar som bekant om du är briljant, men annars fungerar det förstås inte alls.
Precis. Designmönster är extremt underskattade och borde användas oftare.
Designern ska anpassa sin bild (och förstås även systemet) till hur användaren förväntar sig att systemet ska fungera. Om något inte fungerar som användaren tror att det ska göra så ska det 1. gå att ångra och 2. gå att få en förklaring till varför det inte gick och 3. gå att fortsätta använda systemet utan större problem.
Det är alltså 3 som gör att det inte dyker upp rutor som berättar om allt som inte går att göra. Ett sånt system skulle sluta fungera pga sina egna storebrors fasoner.
Jämför gärna med Microsofts olika "…Det ser ut som om du skriver ett brev", BOB, och alla de andra varianterna som driver folk till vanmaktens närhet. Vårt favoritföretag har tillochmed gjort en film om just det här beteendet.
Det är ett av problemen med UCD att designern ska anpassa sin bild av systemet när designern egentligen vet mer om hur systemet fungerar än användaren. Istället ska designern kommunicera via systemet (kommunikation via gränssnittet) vad användaren kan göra. Det var till exempel så Adobe gick tillväga när de gjorde panelerna i Lightroom.
Varför stanna vid James Gibson? Vart tog Gombrich vägen? Varför inte backa bakåt till Helmholtz och Fechner? Eller åtminstone nämna Merleau-Ponty? Fast du kanske läser vid Uppsala, där är väl Gibson omhuldad husgud…
Nja, Gibson är inte det mest omhuldade här i Linköping, här är nog Hollnagel mer av en husgud (enligt tjejen i alla fall, jag hade tänkt skriva Gardner), men jag tog Gibson som exempel eftersom det är antagligen hans forskning som flest känner till.
Kul med en massa (intetsägande) teori om mjukvara-människa interaktion, verkligen, men svara gärna på frågan.
Mitt långa utlägg var på grund av att detta är ett generellt problem som behöver en generell lösning.
I det här specifika fallet hade det räckt med att göra som Tognazzini skriver: Direkt beskriva varför det inte tillåts.
I det här specifika fallet hade det räckt med att göra som Tognazzini skriver: Direkt beskriva varför det inte tillåts.
Jaha? Så vad skulle det stå då? "Filen kan inte kopieras?" Filen kan ju kopieras! Bara inte via just den funktionen? Ska det kanske stå "Filen kan kopieras, fast inte med den här menyfunktionen? Utan gör så här [förklaring hur man drar och släpper filer samt håller alt-knappen intryckt]". Känns som att i många fall så skulle dessa så-kallade förklaringar inte direkt bringa mer klarhet... (Varför låter den inte mig kopiera filen via det här menyvalet om den ändå vet exakt vad det är jag försöker göra???)
Att förklara hur/varför vissa saker fungerar eller inte fungerar skulle i många fall förmodligen kräva en hel del text och kanske även bilder och rörliga bilder för att förklaras, och dessa spridda "förklaringar" skulle förmodligen bara göra systemet mer rörigt. För egen del är jag glad att gränssnittet är helt nerplottrat med förklaringar överallt. Därtill så skulle ju då dessa utspridda förklaringar fokusera på varför vissa saker inte går att göra (i och med att de är associerade med icke-applicerbara menykommandon), istället för att i huvudsak förklara hur man gör saker. Att överallt läsa "du kan inte göra så här" tror jag inte skulle bidra till en bättre upplevelse.
Att samla alla dessa utspridda förklaringar under en speciell Hjälp-sektion känns som ett smartare val.. och titta, det har de ju gjort!
Jaha? Så vad skulle det stå då? "Filen kan inte kopieras?" Filen kan ju kopieras! Bara inte via just den funktionen?
Filen kan kopieras. Det är klippa ut man inte kan göra.
...Att förklara hur/varför vissa saker fungerar eller inte fungerar skulle i många fall förmodligen kräva en hel del text och kanske även bilder och rörliga bilder för att förklaras, och dessa spridda "förklaringar" skulle förmodligen bara göra systemet mer rörigt. ...
Vista är det så...
Att förklara hur/varför vissa saker fungerar eller inte fungerar skulle i många fall förmodligen kräva en hel del text och kanske även bilder och rörliga bilder för att förklaras, och dessa spridda "förklaringar" skulle förmodligen bara göra systemet mer rörigt.
Precis:
Dock är det jobbigt och icke-trivialt att göra i stora applikationer, därför görs det helt enkelt inte.
För egen del är jag glad att gränssnittet är helt nerplottrat med förklaringar överallt. Därtill så skulle ju då dessa utspridda förklaringar fokusera på varför vissa saker inte går att göra (i och med att de är associerade med icke-applicerbara menykommandon), istället för att i huvudsak förklara hur man gör saker. Att överallt läsa "du kan inte göra så här" tror jag inte skulle bidra till en bättre upplevelse.
Precis. Det är därför UCD inte fungerar när man gör applikationer och större system.
Att samla alla dessa utspridda förklaringar under en speciell Hjälp-sektion känns som ett smartare val.. och titta, det har de ju gjort!
Att ha en utförlig hjälpfunktion är inte fel. Hjälpen ska dock komplettera gränssnittet och inte helt och hållet förklara det. Dessutom är hjälpen dum och när man öppnar den måste man hela tiden söka på något som inte innehåller naturligt språk.
rhesus: My thought exactly.
Niklas: Kul med en massa (intetsägande) teori om mjukvara-människa interaktion, verkligen, men svara gärna på frågan. Jag frågade inte hur informationen skulle lagras, i tabellform eller inte, eller teorier runtikring det, utan hur det skulle berättas för användaren.
Att funktionen inte går att använda är redan "berättat" i och med den skuggade funktionstexten, så utförligare förklaring skulle ju kräva en utförligare textförklaring, något som jag inte alltid tror skulle bringa mer klarhet för användaren. Exempelvis inte i detta fall; textförklaringen "filen kan inte kopieras" vore ju t.ex. rejält missvisande. Instruktioner för hur man kopierar en fil med dra-och-släpp plus alt-knapp vore kanske inte heller så praktiskt då de allra flesta redan vet detta, faktiskt. Att lära användaren om hur grundläggande funktioner fungerar skulle göra sig bättre i en introduktionsdemo än i spridda små hjälptexter intill icke-applicerbara menyfunktioner.
Då är det ju inte bara "jobbigt och icke-trivialt" som du sa tidigare, utan även rörigt och oanvändarvänligt... Du fick det åtminstonde att låta som att utvecklare undvek dessa utförliga "förklaringar" överallt berodde på lathet, när det snarare beror på att det vore drygt och oanvändarvänligt. Först säger du att det är ett "generalfel" att inte "berätta" varför det inte går att använda vissa menykommandon, sen säger du att det är rätt, om det gäller en applikation eller ett stort system?
Jag var säkert lite otydlig i vad jag syftade på tidigare. Att hela tiden lägga till en massa förklaringar i ett gränssnitt byggt med hjälp av UCD eller liknande metoder går i längden inte och blir säkert precis som du beskriver rörigt och kontraproduktivt.
Om man däremot bygger in dessa förklaringarna direkt i systemets beteende (därmed kommunicerar vad systemet gör, tillåter och vill) så minskar man mängden explicita förklaringar i form av rutor med "Denna knapp är grå eftersom det inte är möjligt att klippa ut filer. [klicka här för att veta mer...]" eller andra visuella ledtrådar som beskriver hur det hela hänger ihop.
Va? Bygger in "förklaringar i systemets beteende", "vad systemet gör, tillåter och vill"? T.ex. genom att gråa ut menyvalen då eller? Vad är det som saknas??? En förklarande text var det ju tydligen inte frågan om...?
Vad är "generalfelet" som alla begår egentligen? Och om det inte är applicerbart på applikationer eller stora system, vad är det applicerbart på då? Vad förutom applikationer är det vi snackar om här?
Du läste Tognazzinis beskrivning antar jag?
Nej, vart står den? "Direkt beskriva varför det inte går" skrev du. Men samtidigt var det ju inte en mer utförlig förklaring det var frågan om för då blir det ju rörigt, plottrigt och oanvändarvänligt, kom vi ju överens om. Hur "beskriver man direkt varför det inte går" utan att skriva en mer utförlig förklaring?
Länken finns här:
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.