allan ebdrup bloghoved ny

Hvad blev der af fortryd?

Fortryd-funktionalitet er ikke nyt

Hvorfor kan man ikke fortryde alle handlinger i en web 2.0 applikation som fx facebook?

I starten af 1980erne var det noget nyt, at Microsoft og andre software-leverandører havde produkter, hvor fortryd-funktionaliteten var implementeret fuldt ud. Man kunne simpelthen fortryde alle ændringer, man lavede i sine dokumenter.

Fortryd har været en uadskillelig del af desktopprogrammer lige siden. Nu sidder jeg her i 2008 og bruger alle mine Web 2.0- og Ajax-applikationer og jeg spørger mig selv: 'Hvad blev der af fortryd''. Der er en smule fortryd i applikationer som Flickr, Google docs, Gmail og andre, men det kunne være meget bedre. Hvis jeg for eksempel sletter et billede på Facebook, hvorfor kan jeg så ikke fortryde det'

Den eneste måde at få det tilbage på er at uploade det igen. Ups, hvor blev alle kommentarerne af? Eller ups, jeg har ikke billedet mere. Derudover bør alle udviklere tænke på fortryd-funktionalitet i deres applikationer - ikke kun de store spillere.

Video af hvordan fortryd burde virke

Hvorfor skal vi have fortryd?

Når man først har prøvet at have muligheden for at fortryde en handling, synes det at være indlysende, at vi har brug for fortryd. Studier har vist, at omkring 70 procent af alle menneskelige fejl bliver opdaget med det samme de er begået. Mennesker kan godt lide at udforske og afprøve applikationer ved at prøve sig frem. Og vi ved alle, at fejl er uundgåelige.

Fortryd og udviklere

At implementere fortryd-funktionalitet virker som en meget stor opgave for de fleste udviklere. Der findes ingen programmeringsmiljøer, jeg kender til, der direkte understøtter implementation af fortryd-funktionalitet. Som udvikler er du på egen hånd; du skal implementere det hele selv.

Fortryd på webbet

En af grundene til at fortryd er forsvundet, er den måde de fleste web 2.0-applikationer virker. Hver gang vi som brugere vil lave en ændring, gemmer programmet den med det samme. Programmet gemmer ændringen i databasen på serveren. Det er godt, for derved mistes brugerens arbejde ikke, hvis hans/hendes browser går ned.

At implementere fortryd betyder altså, at fortryd skal implementeres hele vejen til databaseoperationer. Det virker som en stor mundfuld.
Og så er der hele problemet med samtidighed. Hvad hvis vi vil fortryde, det vi har indsat, og det i mellemtiden er blevet brugt i sammenhæng med noget andet af en anden bruger? Ja, udfordringen virker for stor, og så vi dropper det.

Hvad gør vi så i praksis' Måske spørger vi brugeren: 'Er du sikker på, at du vil slette'' - Og bryder derved en gammel usability regel. Alle udviklere har gjort det, men det er ikke den bedste løsning. Vi har brug for fortryd.

Fortryd direkte understøttet på vores udviklingsplatform

Fortryd er forskellig fra transaktioner i en database. Når man udfører en handling, man senere ønsker at kunne fortryde, skal den eksekveres med det samme. Vi har ikke lyst til at have en database med en masse åbne transaktioner, der venter på, at en bruger skal trykke gem. Og vi har ikke lyst til at bekymre os om at få ryddet op, hvis brugerens browser crasher. Derudover vil vi kunne fortryde, annullere fortryd og fortryde igen osv.

Jeg så gerne, at det at implementere fortryd-funktionalitet var understøttet direkte af vores udviklingsplatform, så man kun ville behøve at tilføje få linjer kode. Jeg er sikker på, at det kan gøres på en generisk og genbrugbar måde, der vil virke for 90 % af alle handlinger i webapplikationer.

Hvordan får vi fortryd tilbage?

I nogle webapplikationer vil det være en god idé at gøre som i desktopapplikationer. I min applikation, obsurvey, en gratis webapplikation til at lave spørgeskemaer med, har jeg implementeret en fuld, uendelig fortrydelseshistorik på feltniveau, når man retter i sit spørgeskema. Det tog kun tre dage at implementere. Du kan nemt selv gøre det, hvis du har en rimelig tyk klient. Hvis browseren crasher, mister brugeren dog sine ændringer. Dette kan dog løses med en automatisk gemmefunktion. Det er ikke så svært, bare kom i gang.

For webapplikationer der ikke er så tykke, må vi tænke os godt om for at få implementeret fortryd. Det ville være godt med nogle best practices på området og en metafor, der er lige så god som indkøbskurven på et shoppingsite. Vi har selvfølgelig papirkurven fra operativsystemer til slettede filer, men virker papirkurvmetaforen også på webbet? Jeg tror faktisk, den ville virke ret godt i nogle applikationer.

En anden idé kunne være at bruge browserens tilbageknap. I eksemplet med at slette Facebook-billedet, kunne det at klikke på browserens tilbageknap gendanne billedet.
Vi har brug for noget, der er nemt at forstå for brugeren og nemt at implementere for udviklerne. Så del ud af jeres ideer og viden, for vi skal have fortryd tilbage.

Sidst men ikke mindst har vi brug for udviklingsplatformenes elementer som dotNet, Java, Ruby, Silverlight og Flex der understøtter fortryd direkte. Hvis jeg tænker virkeligt stort, vil jeg sige, at vi har brug for databaser, der understøtter fortryd-funktionalitet. Man kan jo altid drømme.

Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Mogensen

Hvorfor i alverden ville du også bruge "-r" til rm samtidig med at begrænse det til *.o ?
Hvor mange af dine .o filer er directories?

Det plejer at være en god ide at vænne sig til at bruge "-r" med respekt og ikke bruge den unødvendigt.

  • 0
  • 0
Allan Ebdrup

Klavs
Ja, fortryd på sletninger betyder, at man skal lade være med at slette og bare "markere" som slettet i stedet. Det der er spørgsmålet, er om facebook også gemmer alle de kommentarer der er til billedet, eller alle de tags der er af hvem der er på billedet osv. De skulle jo gerne dukke op igen når du fortryder du har slettet.

  • 0
  • 0
Jakob Veje Hansen

Hejsa,

Velkommen til, og sikke et spændende emne du lægger ud med.

Hvis alle applikationer og databaser understøtter distribuerede transaktioner, kunne en løsningsmodel være simpelthen at vente med at committe transaktioner, indtil brugerne er helt sikre på at de ikke vil fortryde. Men det kolliderer kraftigt med de fakto standarden for både sessions håndtering i webapplikationer og brugsmønstre i almindelighed. Web applikationen kører uden connection, og kan som sådan ikke vide om brugeren er forsvundet eller stadig hænger på. Ved nedlæggelse af en session, er der heller ikke praksis for persistering af data.
Iøvrigt er applikationer sjældent transaktionelle, og det er forskelligt hvordan forskellige databasermærker håndterer at synliggøre data, der indgår i åbne transaktioner for connection x, overfor connection y og z.

Jeg tror mere på at tænke reversible aktioner ind i brugergrænsefladen. Til hver handling en bruger foretager, skal designes den reversible handling. Når en bruger udfører en handling committes den med det samme, og den reversible handling pushes på en stack, og en fortryd vil i så fald være et spørgsmål om at udføre den reversible handling. Det lyder nemt, men er garanteret komplekst i virkeligheden.

Jeg kan kun gisne om mængden af problemer med konflikter der opstår, når der er tale om et kompleks af flere systemer med mange samtidige brugere.

Måske er fortryd ikke for alle :)

  • 0
  • 0
Allan Ebdrup

Jakob, tak for velkomsten.
Ja, som jeg også skriver i artiklen er transaktioner ikke gode til at implementere fortryd funktionalitet. Det du beskriver med reversible aktioner har et pattern kaldet "Command"
http://en.wikipedia.org/wiki/Command_pattern
Hvis du kigger på de problemer der kan opstå med fortryd, er de ikke meget anderledes end de problemer du har uden fortryd. Brugeren ville højst sandsynligt kunne udføre nøjagtigt de samme handlinger som ved at trykke fortryd, uden der var en fortryd-funktionalitet. Derfor skal du tage højde for disse concurrency problemer alligevel. Men for rigtigt mange applikationer er det ikke så komplekst som det kan lyde. Vi har allerede ting som optimistic locking og andre teknikker til at håndtere, at flere brugere kan rette i samme data på samme tid.
Min opfordring er: Prøv det! Dine brugere vil elske dig for det.

  • 0
  • 0
Daniel Møller

I forhold til at opbevare brugernes data efter de har bedt om at få dem slettet, så kan der også være nogle juridiske problemer herved. Der kan selvfølgelig søges om tilladelse, men om "undo-funktionalitet" er en god nok grund kunne man måske godt have sine tvivl om.

Der er selvfølgelig stor forskel her på hvad det er for nogle data vi taler om, samt hvor længe undo skal være tilrådighed, men f.eks. undo af sletning af profil-billeder kunne være et problem.

Det er altså ikke kun på den teknologiske front at undo er problematisk at håndtere på websites.

  • 0
  • 0
Allan Ebdrup

Hej Daniel
Ja, spørgsmåler er jo hvor lang tid du skal kunne fortryde.
Jeg ligger op til en undo der virker sammen med din session, lidt som når du åbner et word dokument. Hvis du laver ændringer i dokumentet, lukker og åbner dokumentet igen, så er din fortryd historik væk. Det er folk vant til.
Men det kræver at man sørger for at rydde op.
Jeg vil ikke kalde det problematisk, det er en mindre teknisk udfordring der let løses og kan i mine øjne, på ingen måde bruges som undskyldning for ikke at lave fortryd.

  • 0
  • 0
Log ind eller Opret konto for at kommentere