Tre antipatterns i webinteraktionsdesign

Ett antipattern är ett sätt att göra något på, som vid första anblicken verkar vara en vettig approach, men som egentligen gör saker värre. Inom webbutvecklingsvärlden finns det en rik flora av dessa. Här är några exempel:

Pagers som visar ett löjligt litet antal saker åt gången
En pager är alltså den gränssnittskonstruktion som visar ett visst antal saker åt gången – exempelvis sökträffar eller bloggkommentarer. Eftersom det är mycket bökigare att konstruera ett pagingsystem än att helt enkelt visa alla saker på en gång vill folk förstås använda det, och sätter därför gränsen för antal saker som ska visas alldeles för lågt. Bredband är billigt, och moderna webbläsare klarar numera sidor över 15 kb. Minst 100 saker åt gången, tack.
För korta sessionstimeouts
Alla moderna webbprogrammeringsramverk har någon typ av sessionshanteringssystem, så att programeraren ska kunna spara ner en massa information om vad en viss användare gör i steg 1, så att man kan läsa upp det igen i steg 2. Att spara denna information tar förstås lite minne i webbserverprocessen, och har man många användare vill man förstås se till att rensa bort sådant som aldrig kommer användas, eftersom användaren lämnat webbplatsen och inte kommer göra något steg 2-request. Så alla webbprogrammeringsramverk har en sessionstimeout – om inte användaren begär en ny sida på x minuter rensas den data som associerats med användaren. Och eftersom minne var dyrt under förra årtusendet är denna timeout vanligtvis löjligt lågt satt. Vilket får till effekt att den som skickar in ett långt och genomarbetat webbforuminlägg upptäcker att sessionen timat ut, och att de senaste 21 minuternas arbete gått upp i rök. Minne är billigt, men användares tid är det inte. Sätt upp sessionstimeouten till minst 24 timmar, tack.
Reset-knappar på formulär
HTML-standardens avsnitt om hur man gör formulär innehåller ett antal olika typer av formulärelement – textfält, radioknappar, selectmenyer, submit-knappar samt, av någon outgrundlig anledning, en knapp som tar bort allt man mödosamt skrivit in i formuläret, och återställer det till sitt ursprungstillstånd. Risken för att råka klicka på denna knapp är visserligen inte stor, men det lär ändå inträffa mångdubbelt fler gånger än att någon faktiskt har nytta av det. Det första exemplet i standarden använder denna vansinniga funktion, vilket får till effekt att folk som inte tänker efter tror att det är en bra idé att ge användaren tillgång till något som bara kan användas till att skjuta sig i foten. Sluta med det, tack.

Måste det vara så komplicerat?

Förra helgen samlades ett gäng svenska webbutvecklare för att se om de i små team kunde skapa ett gäng kompletta webbtjänster, från start till mål, på 24 timmar. Det verkar som det gick riktigt bra.

Den här helgen hålls istället Global Game Jam, ett globalt event för spelutvecklare som hålls på massor av fysiska ställen, där enskilda spelutvecklare försöker skapa ett gäng kompletta spel, från start till mål — vilket kan låta mer komplicerat än webbtjänster, men de får å andra sidan 48 timmar på sig.

Ett liknande initiativ, med något längre tidsram är NaNoWriMo — ett årligen återkommande projekt där målsättningen är att skriva en roman (50 000 ord) på en månad.

Jag tror det här är en riktigt bra arbetsform för att förnya sin yrkesroll. Om man är van vid projekt som tar tusentals, kanske hundratusentals, mantimmar, och sen försöker få något gjort på fyrtio timmar måste man ifrågasätta de flesta delar av sitt arbetssätt och rensa bort all onödig komplexitet för att hitta den avskalade, essentiella kärnan i vad det nu är man gör. Jag inbillar mig att det ger mest för den som redan har erfarenhet — om jag satte mig ner och försökte skriva en uppsats om något juridiskt på 24 timmar skulle jag varken jag eller mina läsare bli särskilt mycket klokare.

Global Game Jam inleddes med en sevärd keynote presentation av Kyle Gabler:

Kyle utgör hälften av 2D Boy, som skapade förra årets stora indiespelsucce, World of Goo. Jag är ingen inbiten datorspelare, men efter att ha kört demon var jag tvungen att beställa spelet (som är oförskämt billigt). Sen spelade jag igenom det hela ända till slutet, vilket jag bara gjort med en handfull spel tidigare i mitt liv. Så bra är det.

I keynotepresentationen visas även Crayon Physics, som jag testade en demo av i förra helgen, och som jag just nu funderar på att köpa, eftersom det dels är supergulligt, dels är det första spel jag sett som verkligen är gjort för att spelas på en Tablet PC.

Nostalgia

By accident, I ended up at the original Netscape
cookie specification
. It’s now over eight years since I read that
one for the first time. Notice the 1996-style formatting of the headers:

<h2>
<font size="+3">P</font>ERSISTENT
<font size="+3">C</font>LIENT
<font size="+3">S</font>TATE<br>
<font size="+3">HTTP C</font>OOKIES
</h2>

Other classic web tech specs: The Common
Gateway Interface
, Hypertext Markup Language – 2.0,
Hypertext
Transfer Protocol — HTTP/1.0
. I’ve referenced those a lot of times,
back in the day.

Smalltalk and Seaside for web applications

So, after debating at length with Göran about pros and cons of Smalltalk as a platform for real world development, I came to the conclusion that Smalltalk was worth looking into in greater detail, and since I’ve been wanting to write my own blog/wiki hybrid, it was suggested that I check out Seaside, a Smalltalk-based framework for web development comparable to ASP.NET or Java Server Faces.

At first look, Seaside doesn’t look much different than ASP.NET. It’s all about modelling your application’s interface in terms of objects and methods (”messages” for you Smalltalkers). Pages are built up of components, inheriting from System.Web.UI.Control (ASP.Net) or WAComponent (Seaside) that can include other components. When the user does things with any component, it results in events being fired (ASP.NET) or messages being sent (Seaside). Both frameworks seem to strive to abstract away the request/response nature of the web, and to allow the programmer to use a more event-driven approach to developement. In addition, seaside uses at it uses continuations to make it possible to, for example, ask the user something (similar to how a modal dialog would do it in a normal GUI enviroment), and then do something with the provided answer — all within the context of a
method.

The main difference is that programming in the Seaside framework results in a lot less housekeeping code. The object is really a ordinary object, except that it’s executed through the web. The difference didn’t really dawn on me before I tried to recreate WACounter as a ASP.Net Server component — it did involve a whole lot of code to handle events, manage viewstate and so on.

From a security perspective, Seaside has problems with the fact that the session id is present in the URL, and it seems harder to make applications RESTful, but apart from those issues, Seaside is definitly a framework worth looking closer at. From my own perspective, I hope that the ASP.NET developers do 🙂

Unfortunately, things elsewhere has been chaotic (and not in a good way), so I have not had any further time for experimentation with Seaside. As always, further progress will be reported here.

Update: This is a much better explaination of what continuation-based, or synchronous, web programming is.