Gränssnittsdesign · område 7

Guide – Ljud, rörelse och mikrointeraktion

Här står det du behöver för uppgiften, och guiden fungerar utan att du varit på lektionen. Ett avsnitt per pass, och felsökningen sist. Slå upp i den när du fastnar.

1. Feedback och mikrointeraktion

Du trycker på Betala i en webbutik, och ingenting händer. De flesta trycker igen. Men om den första tryckningen faktiskt gick igenom har du nu betalat två gånger. Sajten gjorde rätt, den sa bara ingenting om det. Ett gränssnitt som inte svarar lär användaren att gissa, och gissningen är oftast att trycka en gång till.

Det här området tar fram det som saknas: sajten ska svara när någon gör något. Frågan är densamma som i heuristik 1, synlighet, från december: vet jag vad systemet gör just nu? Där hittade du bristerna. Här får du verktygen för att rätta dem.

Vad systemet måste svara på, och hur snabbt

Feedback, på svenska återkoppling, är gränssnittets svar på en handling. Varje handling ska få ett svar. Vilket svar avgörs av hur lång tid det tar:

Tidsgränserna är kända genom Jakob Nielsen, samme Nielsen som skrev heuristikerna. De bygger på forskning från sextiotalet om hur länge vi håller kvar uppmärksamheten.

• Snabbt är inte samma sak som tyst. En knapp som gör sitt jobb på 0,05 s men inte ändras alls lämnar ändå användaren i ovisshet. Svaret behöver synas, även när det går fort.
• En snurrande symbol, på engelska ofta spinner, säger bara att något pågår. Över tio sekunder räcker den inte, för den säger inte om det är nära klart eller har fastnat.

Laddar, lyckades, misslyckades

I oktober ritade du sex tillstånd för ett element: normal, hover, fokus, aktiv, inaktiv, fel. De beskrev hur knappen ser ut just nu. Här kommer tre till, men de är av ett annat slag: de beskriver vad som händer efter att någon gjort något, i tur och ordning.

Håll isär de två sorterna med en tidsaxel: de sex tillstånden beskriver ett ögonblick, de tre beskriver ett förlopp. Fel är hur ett fält ser ut. Misslyckades är vad som händer efter att man tryckt på knappen. Tre regler:

• Laddar hindrar dubbelklicket. Att knappen inte går att trycka en gång till är lika viktigt som att den visar att den arbetar.
• Lyckades säger vad som hände, inte bara att. Klart är bättre än ingenting. Din beställning är lagd, leverans torsdag är bättre än Klart.
• Misslyckades glöms bort. Den som designar tänker på när det går bra. Den som använder sajten minns när det gick fel.

Mikrointeraktionens fyra delar

En mikrointeraktion är ett litet, avgränsat svar på en enda handling: en knapp som visar att den skickar, ett fält som visar att det är rätt ifyllt, en kryssruta som bockas i. Ordet och modellen kommer från Dan Saffer, som delar varje mikrointeraktion i fyra delar:

En beställningsknapp, del för del:

1. Utlösare: klick på Lägg beställningen.
2. Regler: knappen går inte att trycka igen förrän svaret kommit. Är ett obligatoriskt fält tomt skickas ingenting.
3. Återkoppling: knappen byter text till Skickar …. När svaret kommer blir den grön, med en bock och texten Beställningen är lagd.
4. Loopar och lägen: tar det mer än tio sekunder visas Det tar längre tid än vanligt. När beställningen är lagd är knappen inaktiv, för en ny beställning är ett nytt läge.

Återkopplingen är den del man ser, och därför den du vill börja med. Men en grön bock utan regler säger ingenting om vad som händer om man trycker två gånger. De fyra delarna tvingar dig att tänka igenom det som inte syns. Loopar och lägen är den del de flesta förstår sist. Ett enkelt test: vad händer andra gången, och vad händer om det tar lång tid? Har du svar på det har du beskrivit delen.

Knapptexter och felmeddelanden

Återkopplingen är ofta bara ord, och två slags text bär nästan hela den: det som står på knappen, och det som står när något gick fel.

Knapptexten säger vad som händer när man trycker. Ett verb, och gärna vad det gäller:

Knapptexten och bekräftelsen ska höra ihop. Står det Betala 249 kr på knappen ska bekräftelsen säga Betalningen är klar, inte Tack. Då vet användaren att det hen bad om är det som hände.

Felmeddelandet har tre delar, och alla tre ska finnas:

1. Vad som gick fel, med användarens ord och inte systemets.
2. Var, alltså vid fältet eller knappen det gäller, inte högst upp på sidan.
3. Vad hen gör nu.

Fel 422: ogiltig indata har ingen av dem. E-postadressen saknar @. Skriv den som namn@exempel.se har alla tre. Två regler till: skyll inte på användaren (Du har angett fel blir Datumet finns inte), och töm inte formuläret när något är fel.

Ett undantag: vid inloggning säger man ofta Fel e-post eller lösenord utan att säga vilket, för att inte avslöja vilka konton som finns. Då är det tredje ledet desto viktigare, till exempel en länk till Glömt lösenordet?.

Fem tysta ställen

Det här är uppgiftens Kom igång, steg 1, och listan är råmaterialet till hela uppgiften. Ljuden och mikrointeraktionerna väljs ur den, inte ur vad som vore roligt att göra.

1. Skapa sidan 07 Ljud och rörelse i din designportfölj i Figma. Öppna din sajt och testrapporten från uppgift 6 bredvid varandra.
2. Leta i testrapporten efter ställen där en testperson klickade två gånger, väntade eller frågade gick det?. Skriv upp dem först. Det är ett bör-krav (C) att minst en mikrointeraktion kommer därifrån.
3. Gå igenom sajten själv, handling för handling: varje knapp, länk, fält och formulär. Var gör du något utan att få svar?
4. Skriv fem ställen i en lista. För varje: var (sida och element), vad du gör, och vad sajten borde svara.
5. Markera vilket tillstånd som saknas: laddar, lyckades eller misslyckades.

Formuläret är inte en plats. Knappen Skicka på kontaktsidan är det. Tycker du att sajten inte har fem ställen, leta efter felmeddelanden: vad händer om du skickar formuläret tomt?

2. Rörelse i gränssnitt

Tänk dig tre knappar som alla heter Lägg i varukorgen. På den första ändras siffran vid varukorgen direkt. På den andra glider en liten markering till korgen på 250 ms. På den tredje studsar den dit på 1200 ms. Den första säger att det hände, men inte var. Den tredje säger var, och tar sedan en sekund av din tid för att visa upp sig, varje gång du lägger en vara i korgen. Den mittersta säger var, och är klar innan du hunnit tänka på det.

En rörelse i ett gränssnitt ska förklara vad som hände. Allt utöver det tar tid från användaren. Rörelse är återkoppling, en av mikrointeraktionens fyra delar, och den svarar på samma fråga som en text eller ett ljud: vad hände när jag gjorde det här?

Rörelse som förklarar

Rörelse är bra på en sak som ingen annan signal är lika bra på: att visa att två saker hänger ihop. Varan i korgen, menyn som kommer från knappen man tryckte på, rutan som krymper tillbaka dit den kom ifrån. Två principer:

• Orsakssamband. Rörelsen ska börja där handlingen skedde. Trycker du på en knapp uppe till höger och en ruta dyker upp nere till vänster, finns inget som säger att du orsakade den. Växer den ut ur knappen syns sambandet.
• Riktning. Det som kom från höger går tillbaka åt höger. Nästa steg i ett formulär kommer från höger, föregående från vänster. En borttagen rad försvinner åt ett håll och raderna under flyttar upp. Riktningen blir en karta användaren bär med sig.

Varaktighet: 100–300 ms

Varaktighet är hur lång tid en rörelse tar, i millisekunder (ms). Tusen millisekunder är en sekund. Under 0,1 s känns omedelbart, som i avsnitt 1. En rörelse som ska synas behöver alltså lite mer än så, men inte mycket.

Två tumregler: ju längre sträcka, desto längre tid, men inom samma spann. Och det som försvinner kan gå fortare än det som kommer, för användaren behöver inte läsa det. Över 300 ms har en rörelse slutat förklara och börjat visa upp sig. Det är den vanligaste bristen i uppgiften.

Tidskurvor

En tidskurva, på engelska easing, bestämmer hur farten ändras under rörelsen. Ingenting i verkligheten startar eller stannar på en gång, och en rörelse med jämn fart ser därför mekanisk ut. Tänk dig kurvorna som diagram med tid på x-axeln och sträcka på y-axeln: en rak linje och tre böjda.

Ease out är vanligast eftersom svaret börjar direkt och användaren ser att klicket togs emot. Mjukheten kommer i slutet, när det redan är klart.

En egen kurva går att ställa in i Figma. Den beskrivs med fyra tal, som Figma visar när du drar i kurvan. Använder du en egen kurva ska alla fyra talen stå i tabellen. I tabellen skrivs namnet som webbläsaren använder, ease-out och inte Ease out.

När rörelse hjälper, och när den stör

Testfrågan till varje rörelse: vad förstår användaren som hen inte förstått utan den? Är svaret ingenting ska rörelsen bort.

Utan rörelse

Vem som valt bort rörelse, och varför, läste du om i januari, under reducerad rörelse: yrsel, illamående och migrän vid stora rörelser. Här är det ett designbeslut per interaktion, och det är en kolumn i överlämningstabellen. Det finns tre svar, och ingenting är inte ett av dem:

• Ändringen sker direkt. Siffran vid korgen byts, utan att något glider dit.
• En kort toning i stället för en förflyttning. Rutan tonar fram på plats i stället för att glida in från sidan. Toning är inte rörelse i den mening som besvärar.
• Något annat bär beskedet. En text, Tillagd i varukorgen, gör det rörelsen gjorde.

Informationen ska finnas kvar. Det är bara rörelsen som tas bort.

Smart Animate i Figma

Ramar har du ritat sedan hösten. Det nya är fliken Prototype längst upp i högerpanelen, och Smart Animate, en animation som räknar ut rörelsen mellan två ramar åt dig.

1. Två ramar, före och efter. Samma lager i båda, men flyttade, färgade eller förstorade i den andra.
2. Lagren ska heta likadant i båda ramarna. Det är så Smart Animate vet vad som är samma sak. Byt namn på ett lager i den ena och rörelsen blir ett hopp.
3. I Prototype-fliken: markera knappen och dra pilen till den andra ramen.
4. Välj utlösare: On click (klick), While hovering (medan pekaren är över) eller After delay (efter en viss tid, bra för att visa laddar som går över i lyckades).
5. Välj animation Smart Animate.
6. Välj tidskurva och skriv varaktigheten i millisekunder.
7. Spela upp med Present, uppe till höger.

Från prototyp till tabellrad

Uppgiftens Kom igång, steg 3: skriv tabellen medan du prototypar. Varje gång du ställer in en tid i Figma är det en rad. Kolumnerna för rörelse, exakt som i uppgiften:

Skriv raden för din återhållsamma övergång innan du stänger Figma. Det tar en minut samma dag. Den 8 mars tar det en halvtimme att minnas. Bör-kravet (C) är att varaktighet och kurva är motiverade, inte bara angivna: varför 200 ms här och 120 ms där.

3. Ljud i gränssnitt

Hör du datorns felljud utan att titta på skärmen vet du att något gick fel. Men inte vad. Ett ljud är bra på att dra uppmärksamheten till något, och dåligt på att säga vad det är. Det måste skärmen göra. Hela avsnittet bygger på den skillnaden.

Här spelar du inte in något än. Du bestämmer vilka tre händelser som ska låta, och varför. Inspelningen är avsnitt 4.

Vad ljud är bra på

Ljud har en egenskap som text och rörelse saknar: det hörs fast man tittar någon annanstans.

Tre exempel ur vardagen, och alla fungerar av samma skäl. Betalterminalen piper när kortet godkänts, medan du tittar på kassören. Inloggningen på telefonen ger en kort vibration och ett ljud när koden är fel, innan du hunnit läsa. Ett skickat meddelande låter, så att du vet att det gick iväg fast du redan lagt ifrån dig telefonen. Ljud är återkoppling, precis som rörelse och text.

Ljud får aldrig vara den enda signalen

Det här är ett ska-krav, och det viktigaste i avsnittet. Ljudet hörs inte av den som inte hör eller hör dåligt, den som har ljudet av på bussen, i klassrummet eller på jobbet, den som har telefonen på ljudlöst, och den som redan lyssnar på något annat eller har en skärmläsare som pratar.

Därför har varje ljud en kolumn i överlämningstabellen: synlig motsvarighet. Det är det som syns på skärmen samtidigt som ljudet hörs, och det ska säga samma sak:

Kontrollen är enkel: stäng av ljudet och använd sajten. Förstår du fortfarande allt som händer har varje ljud en synlig motsvarighet.

Längd, frekvens och volym

Tre egenskaper bestämmer vad ett ljud säger, och det är samma tre som du redigerar i avsnitt 4.

Längd. Ett gränssnittsljud ska vara kortare än en sekund, och oftast mycket kortare. Samma tider som för rörelse gäller: 100–300 ms för att bekräfta något. Ljudet ska vara slut innan användaren gör nästa sak. Ett ljud på två sekunder hörs fortfarande när hen redan klickat vidare, och då låter det som ett svar på fel sak.

Frekvens är hur ljust eller mörkt ljudet är, tonhöjden. Den mäts i hertz, men här räcker ljust och mörkt.

• Ljust och stigande uppfattas som positivt, som klart eller ja. Två toner där den andra är högre är det vanligaste ljudet för lyckades.
• Mörkt och fallande uppfattas som avslut eller fel. Samma två toner baklänges.
• Mycket ljusa ljud skär, och många hör dem sämre med åren.
• Mycket mörka ljud försvinner i en telefonhögtalare, som inte kan spela bas. Lyssna alltid på ljudet i den högtalare det ska spelas i.

Volym. Användaren har ställt in volymen för något annat: musik, en video, ett samtal. Ett gränssnittsljud ska därför vara lägre än man tror, och ljuden på sajten ska vara lika starka som varandra. Ett ljud som är dubbelt så starkt som de andra säger att något är dubbelt så viktigt, fast det kanske inte är det. Hur nivån jämnas ut står i avsnitt 4, under normalisering.

Ljudfamilj och ljudlogotyp

Ljuden på en sajt ska höra ihop, som färgerna i stilguiden gör. Du valde en färgskala där varje färg hade en uppgift, men alla hörde till samma sajt. En ljudfamilj är samma sak, och det är bör-kravet (C): du ska kunna säga vad som gör ljuden släkt och vad som skiljer dem åt.

Ett exempel: tre ljud inspelade med samma glas och en penna. Ett kort slag för att något tagits emot. Två slag, det andra högre upp på glaset, för att det lyckades. Ett slag lågt ned, dovt, för att något gick fel. Tre ljud från tre olika håll låter som tre olika sajter.

En ljudlogotyp är en kort ljudsignatur för sajten, som ett ordmärke fast för örat. Den är en utmaning (A) och får vara upp till två sekunder. Den ska bära sajtens karaktär: en lugn sajt för ett bageri och en snabb sajt för en elektronikbutik ska inte låta likadant. Den används sällan, en gång vid ett viktigt tillfälle och aldrig vid varje klick, annars slutar den vara en signatur. Den är inte ett av de tre ljuden: gör familjen först och logotypen sist.

Händelser där användaren stannar kvar

Ett ljud på något som byter sida hinns inte höras. Trycker användaren på en länk eller skickar ett formulär som laddar en ny sida, försvinner ljudet med den gamla sidan innan det hunnit spelas klart. Det är ett designkrav på överlämningen, och det avgör vilka händelser som kan få ljud:

Av samma skäl ska ljud bara spelas som svar på något användaren gjort, aldrig av sig själv när sidan öppnas. Varför det är så tekniskt tas i Webbutveckling den 10 mars. Här räcker det att veta att det är så, och att välja därefter.

Ljudet ska gå att stänga av

Det är ett designbeslut, och användaren väntar sig fyra saker av det:

• en synlig knapp, på samma plats på alla sidor, inte gömd i en meny
• att det syns på knappen om ljudet är på eller av
• att sajten kommer ihåg valet till nästa sida och nästa besök
• att sajten fungerar lika bra med ljudet av, och det är den synliga motsvarigheten

Om ljudet ska vara på eller av från början är ditt beslut. Skriv det och varför i dokumentationen. Knappen byggs i Webbutveckling; här bestämmer du var den sitter och vad den säger.

Välj dina tre händelser

Ta fram listan med fem tysta ställen från avsnitt 1 och välj de tre händelser som ska få ljud. Tre frågor till varje:

1. Stannar användaren kvar på sidan när det händer?
2. Är det en viktig händelse, eller bara ett klick bland många? Tre ljud på tre viktiga händelser säger mer än tjugo.
3. Vad är den synliga motsvarigheten?

Skriv de tre på 07 Ljud och rörelse, med ett föreslaget filnamn som säger vad ljudet gör: skicka-klart.mp3, inte ljud1.mp3. Leta efter länkar och formulär som byter sida innan du går vidare. Det är lättare att byta händelse nu än den 8 mars.

4. Spela in och redigera ljud

Uppgiften säger att första inspelningen ska vara gjord senast den 4 mars. En råinspelning har tystnad först, brus, ett knäpp i början och för låg nivå, och i WAV ligger den ofta över en megabyte. Den färdiga filen är kortare, starkare, utan sus och knäpp, och ligger på några kilobyte. Ett gränssnittsljud är mest redigering. Inspelningen är råmaterialet.

Samma steg fungerar i två program. Audition finns på skolans datorer genom licensen. Audacity är gratis och går att använda hemma. Stegen är desamma, menyerna olika, och den som kan stegen kan byta program. Menynamnen står på engelska, som programmen oftast är installerade.

Inspelningen

Fyra råd, och alla fyra sparar tid i redigeringen:

• Ett tyst rum. Det är det enda i uppgiften som kräver det. Stäng fönster, stäng av fläktar, gå bort från datorns egen fläkt.
• Nära, men inte för nära. Tio till tjugo centimeter från mikrofonen. Närmare ger knäppar och andning, längre bort ger rummet.
• Två sekunder tystnad först. Håll tyst innan du gör ljudet. Den biten är det brusreduceringen lär sig bruset från.
• Många tagningar. Gör ljudet tio gånger i samma inspelning. Det bästa väljs sedan, och det är nästan aldrig det första.

Det som låter bra är ofta vardagligt: en penna mot ett glas, ett knäpp med fingrarna, en nyckel mot en kopp, ett kort mm med stängd mun. Spela in alla tre ljuden med samma källa, så hör de ihop redan från början. Datorns mikrofon fungerar, och telefonens fungerar ofta bättre. Båda är tillåtna.

Mono, en kanal, räcker för ett gränssnittsljud och ger halva filstorleken jämfört med stereo, två kanaler. Ställ in det innan du spelar in:

Redigera: brus, klippning, toning, nivå

Fyra steg, i den här ordningen:

Vad varje steg är till för:

1. Brusreducering tar bort det jämna suset som finns under allt: fläktar, rummet, mikrofonen själv. Programmet lyssnar på tystnaden, ett så kallat brusprov, och drar bort samma ljud överallt. Drar du för hårt låter resten metalliskt; då är det bättre att spela in igen i ett tystare rum.
2. Klippning betyder här att skära bort det som inte är ljudet: tystnaden före och efter, och alla tagningar utom den bästa. Ljudet ska börja direkt. Tystnad i början gör att ljudet kommer efter klicket, och då känns det som ett svar på något annat.
3. In- och uttoning, på engelska fade in och fade out, är när ljudet glider upp från tystnad eller ner till tystnad. Mycket korta toningar räcker: några millisekunder i början tar bort knäppet, lite längre i slutet gör att ljudet inte klipps av tvärt.
4. Normalisering höjer hela ljudet så att den starkaste punkten hamnar på en bestämd nivå. Välj −1 dB, strax under taket. Går ljudet över taket klipper det, och det hörs som ett sprakande. Normalisera alla tre ljuden till samma nivå, så låter de lika starka.

Ordningen spelar roll: brus först, för brusreduceringen behöver tystnaden som klipps bort i steg 2.

Export och filstorlek

Kravet: MP3, 44,1 kHz, mono, under 50 kB. Tre ord att hålla isär:

• MP3 är ett format som packar ljudet och kastar bort det örat ändå inte hör. WAV, som programmen spelar in i, sparar allt och blir stort.
• Samplingsfrekvensen, 44,1 kHz, är hur många gånger per sekund ljudet mäts: 44 100. Det är samma som på en cd-skiva, och det räcker för allt örat hör.
• Bithastigheten, i kbit/s, är hur mycket data varje sekund får ta. 128 kbit/s räcker för ett gränssnittsljud.

Talen är lätta att räkna på:

Ett ljud under en sekund i MP3 ligger alltså långt under 50 kB. Är din fil större har du exporterat fel format, eller glömt att klippa bort tystnaden.

• Kontrollera storleken i Utforskaren: högerklicka på filen, Egenskaper, raden Storlek.
• Filnamnet: gemener, bindestreck, inga å, ä eller ö, och det säger vad ljudet gör. fel-i-faltet.mp3, inte Fel i fältet.mp3.
• Lyssna på den exporterade filen, inte på ljudet i programmet. Exporten kan ändra ljudet, och det är filen som lämnas över.
• Skriv upp filstorleken före och efter, och vad du gjorde med brus, toning och nivå. Det är bör-kravet (C) om dokumenterad redigering.

Egen inspelning eller ljudbank

Uppgiftens tre ljud ska vara egna. Men ett bör-krav (C) är att jämföra ett av dem med ett ur en ljudbank, en samling ljud som andra lagt upp, och motivera varför du valde ditt eget.

Använd Freesound (freesound.org). Att lyssna kräver inget konto, att ladda ner gör det. Sök på samma sak som ditt ljud, till exempel glass tap, och filtrera på licens. Bokstäverna känner du från licenserna i december, och ljudet är det strängaste. Två licenser är de enkla:

Läs licensen vid ljudet, precis som med bilderna i december. Licensen gäller också ljudet du jämförde med, även om du inte använder det: källan och licensen ska stå där jämförelsen står.

Vad jämförelsen ska säga: vilket låter mest som sajten, vilket passar familjen, vilket är kortast och renast. Ett ljud ur en ljudbank är ofta bättre inspelat. Ditt eget passar ofta bättre ihop med de andra två. Båda svaren är motiveringar.

5. Överlämningen

Vilken av de här två raderna kan du bygga utan att gissa?

• En mjuk animation.
• Knappens bakgrund byter färg på 150 ms med ease-out.

Det är samma sak som med stilguiden i oktober: ett hex-värde gick att bygga, en ljusblå gjorde det inte. Skillnaden nu är att byggaren är du själv, två dagar senare, och du kommer inte att minnas vad du menade med mjuk. En överlämning är tal, inte ord. Formen känner du från överlämningen av stilguiden.

Överlämningstabellen

Två tabeller, med kolumnerna exakt som i uppgiftens tekniska krav.

Ljud: fil, händelse (vilket element, vilken handling), längd i ms, synlig motsvarighet.

Rörelse: element, utlösare, vad som ändras, varaktighet, tidskurva, utan rörelse.

Tabellen ligger på portföljsidan 07 Ljud och rörelse och ingen annanstans. En kopia i ett dokument blir två tabeller som säger olika saker den 11 mars. Håll kolumnerna till vad som syns, hörs och rör sig, hur länge och med vilken kurva. Hur det blir kod är Webbutvecklings.

Fyra frågor till varje rad

1. Står det tal? Millisekunder och kurvans namn. Snabb och mjuk går inte att bygga.
2. Står det vilket element och vilken handling? Knappen är inte ett element. Skicka-knappen i kontaktformuläret är det. Klick räcker inte heller: klick på vad, var, och när i förloppet.
3. Stannar användaren kvar på sidan? Ett ljud på något som byter sida hinns inte höras. Se avsnitt 3.
4. Säger sista kolumnen något? Den synliga motsvarigheten ska säga samma sak som ljudet. Utan rörelse är aldrig ingenting: beskedet finns kvar, bara utan rörelse.

Det som ska vara klart den 8 mars

Filerna och tabellen. Prototyperna och dokumentationen får fortsätta efteråt och fram till den 11 mars. Putsa alltså inte en Figma-prototyp medan tabellen är tom.

• Saknas ett ljud, skriv raden ändå: filnamnet, händelsen och den synliga motsvarigheten. Då kan det byggas, och filen kommer efter som en ändring. Hellre tre rader och ett ljud än ett ljud och ingen tabell.
• Saknar tabellen tal, läs av dem i Figma, där du ställde in dem.
• Saknar en mikrointeraktion någon av de fyra delarna, är det oftast reglerna eller loopar och lägen. Fråga dig: vad händer om man trycker två gånger, och vad händer om det tar lång tid?
• Kontrollera filerna: MP3, under 50 kB, filnamn i gemener utan å, ä och ö. En WAV-fil i zip-filen går inte att bygga in.

Så lämnar du över

Överlämningen görs under passet måndag 8 mars, inte på kvällen. Tre steg:

1. Ljudfilerna i en zip-fil. Bara MP3-filerna, med de namn som står i tabellen. Inga projektfiler från Audition, inga råinspelningar.
2. Tabellen på portföljsidan 07 Ljud och rörelse. Den ligger där och ingen annanstans.
3. I itslearning, Överlämning 8/3: ladda upp zip-filen och klistra in länken till portföljsidan, med behörigheten kan visa.

Överlämning 8/3 är en egen inlämning, skild från inlämningen av hela uppgiften den 11 mars. Är du sjuk den 8 mars har du inte missat överlämningen, men du har bråttom: lämna över så snart du kan, och senast före onsdag 10 mars. Annars bygger du i blindo.

Ändringar efter 8 mars

Från och med överlämningen är varje ändring en rad sist i tabellen, med datum och vad som ändrats. Då vet du den 10 mars vilken version som gäller, och Webbutveckling tar in ändringar fram till den 16 mars. Hur raden ser ut står i avsnitt 6.

Efter överlämningen

• De fyra delarna beskrivna bredvid varje prototyp på 07 Ljud och rörelse: utlösare, regler, återkoppling, loopar och lägen.
• Dokumentationen, ungefär 500 ord: varför varje ljud och varje interaktion finns, och vilket problem på sajten den löser. Se avsnitt 6.
• Utmaningen (A): en mikrointeraktion med alla tre tillstånd, laddar, lyckades och misslyckades, eller ljuden prövade på någon som inte sett sajten.

6. Innan du lämnar in

Inlämning torsdag 11 mars kl 23:59. Paketet är överlämnat sedan den 8 mars och byggt i Webbutveckling den 10. Det som återstår är kontrollerna, och tabellen ska säga vad som gäller nu, inte vad som gällde den 8 mars.

Sista kontrollen

Uppgiften har kontrollistan med kryssrutor: Uppgift 7 – innan du lämnar in. Gå igenom den i tur och ordning. Tabellen här säger vad som fäller varje punkt:

• Punkt 1 avslöjar mest. Ett ljud som lät bra i redigeringsprogrammet kan klippa i högtalaren. Lyssna på den exporterade filen, inte på den i programmet, och i datorns högtalare på låg volym, inte bara i hörlurarna. Hoppa inte över den för att ljuden hördes den 8 mars; det var då de exporterades första gången, inte sista.
• Punkt 3: utloggad betyder ett privat fönster. Ctrl + Skift + N i Chrome och Edge, Ctrl + Skift + P i Firefox. Klistra in länken där. Det du ser är det läraren ser. Inloggad fungerar prototypen alltid, för du äger filen.
• Punkt 5: licensen gäller också ljudet du jämförde med ur ljudbanken, även om det inte används.

Ändringsraderna

Den 10 mars byggde du in paketet, och de flesta ändrar något när det inte går att bygga som det stod. Det som ändrades ska stå som en rad sist i tabellen, med datum och vad som ändrats:

• Låt den ursprungliga raden stå. Då syns vad som lämnades över och vad som ändrats, och det är det utvärderingen på A-nivån handlar om. Har du redan rättat i raden, skriv tillbaka det ursprungliga värdet och lägg ändringen sist.
• Skriv varför, i en halv mening. Kortare säger vad. Hördes efter texten säger varför, och det är ett designbeslut.
• Håll raden till ljudet eller rörelsen. Vad som var fel i koden hör hemma i Webbutvecklings egen dokumentation.

Webbutveckling tar in ändringar fram till tisdag 16 mars. Det som ändras efter kl 23:59 den 11 mars bedöms inte i den här uppgiften, men det kan byggas.

Dokumentationen

Ungefär 500 ord, tabellerna räknas inte. Ska-kravet: varför varje ljud och varje interaktion finns, och vilket problem på sajten den löser. Läs din dokumentation och leta upp varje ljud och varje interaktion. Står det vilket problem den löser? Det blir tydligare är inte ett problem. Testpersonen klickade två gånger på Skicka för att inget hände är ett.

Dokumentationen motiverar, den beskriver inte. Ett kort pip på 150 ms står redan i tabellen. Dokumentationen säger varför. Skriv också om ljudet är på eller av från början, och varför.

Utvärderingen av överlämningen (A) skriver du medan den 10 mars är färsk: vad som ändrades mellan prototypen och det byggda, och vad du skulle skriva annorlunda nästa gång. Ändringsraderna är underlaget. En annan utmaning är att pröva ett ljud eller en rörelse på någon som inte sett sajten, med ljudet av och reducerad rörelse på: förstod hen utan förklaring?

Lämna in det du har, även om det inte är klart. Ett ofullständigt paket går att bedöma, ett uteblivet gör det inte.

7. Felsökning