Lars Gunthers blogg på keryx.se

Vad är diskreta domskript?

gunther@keryx.se (Lars Gunther) — Tue, 11 Oct 2011 21:02:25 +0200

För betygen A-C i kursen Webbutveckling 1 så står det I produkten infogar eleven enkla diskreta domskript. Så kan det bli när reglerna förbjöd mig använda engelska. Annars hade det stått unobtrusive DOM-scripts. Jag skall här försöka reda ut de tre nycklarna som finns för att förstå skrivningen, vilket enklast görs bakifrån genom att vi tittar på orden (3) DOM-skript, (2) diskreta och (1) infogar.

Testa dig själv

Finn (minst) fem fel (utöver att koden inte är komplett).

<div id="a">Lorem ipsum.</div>
<button onclick="hideme()">Dölj</button>

<script language="javascript">
<!--// Dölj från gamla webbläsare
function hideme() {
    the_div = document.getElementById("a");
    the_div.style.display="none";
}
-->
</script>
<noscript>Din webbläsare måste stödja JavaScript
för att denna sida skall fungera.</noscript>

Du kan också titta på det kompletta kodexemplet.

DHTML

JavaScript i kombination med CSS salufördes under 90-talet under namnet DHTML. Och till allra största delen var det av ondo.

Man blandade ihop olika slags kod: HTML, CSS och JavaScript blandades huller om buller.
HTML användes fortfarande till att styra utseendet.
Skripten ändrade i dokumenten med metoden document.write som är en mardröm ur varje tänkbar aspekt. Metoden borde aldrig ha uppfunnits enligt Brendan Eich (språkets upphovsman).
Programkoden var oftast ostrukturerad och grötig. Globala variabler användes och ett skript kunde skriva över variablerna från ett annat skript.
Olika webbläsare hade olika DOM-funktioner och för att skilja mellan Netscape och Internet Explorer så sniffade man efter vilken det var och forkade (förgrenade) koden för att hantera skillnaderna. Ibland nöjde sig utvecklarna med att bara stödja den ena och uppmanande besökarna att byta webbläsare om de använde fel.
Om JavaScript inte fanns i webbläsaren eller inte var aktiverat så fick man ofta meningslösa meddelande genom <noscript>.
Man hade tabeller i tabeller i tabeller ner till 7-8 nivåer för layout och ramar för att skapa layout. Och spacer-gif-bilder. (Om du inte vet vad jag pratar om är du en lyckans ost!)
Man hade popups och popups och fler popups

Resultatet var måttligt roande:

Sidornas kod blev svår eller omöjlig att felsöka och underhålla.
Koden var sällan robust och framtidssäker. Nya versioner av webbläsare kunde innebära att den slutade fungera.
Mindre vanliga och nya webbläsare, som Opera och sedan Firefox och Safari exkluderades i onödan.
Användarvänligheten på sidorna förbättrades sällan utan blev snarare sämre. Meningslösa animeringar och löjliga skrollande effekter irriterade användarna.
Sidorna tog onödigt lång tid att ladda och blev tröga att använda.
Sidornas tillgänglighet förstördes och sökmotorerna kom att indexera dem dåligt och ranka dem lågt.

Till utvecklarnas försvar skall det sägas att man inte hade mycket att jobba med. Webbläsarna hade groteska buggar, ofullständiga implementeringar och lanserade proprietära tekniker i syfte att just tvinga utvecklarna att utveckla för den egna webbläsaren. Men ärligt talat så berodde det främst på att sidorna utvecklades av utvecklare som saknade nödvändig kompetens och att de som hade kompetensen inte tyckte webbutveckling var fint nog.

Begreppet DHTML är namnet som användes för att beskriva katastrofen.

Standardernas segertåg

De fyra viktigaste standarderna som en webbsida bygger på är:

HTML
CSS
EcmaScript
DOM

Under slutet av 90-talet började äntligen medvetenheten om att följa standarder vinna ett visst fotfäste. Från och med HTML 4 har vi haft en ganska stabil bas att stå på för HTML-koden. Under år 2003 kom det stora genombrottet för CSS-baserad layout. Inte minst genom att Netscape Navigator försvunnit från marknaden. Då slapp vi skilja mellan <layer> och <div> och kunde använda i vart fall merparten av CSS 1.

Att använda standarder blev ofta en synonym för att använda CSS för designen, men i själva verket var det tre saker som standardbaserad utveckling bestod av:

Att inte använda proprietär kod.
Att skriva validerande och semantisk HTML.
Att separera designen från innehållet och använda CSS för den.

Men JavaScript förblev ett bekymmer. Skillnaderna mellan DOM-standarderna, som nu började implementeras i Opera och Firefox och Microsofts egen DOM i Internet Explorer förblev stora. Det var i den här situationen som bl.a. Web Standards Project DOM Scripting Task Force identifierade en möjlig väg att börja använda skript på ett vettigt sätt. Först behövdes ett nytt namn som signalerade det nya tänkandet.

(3) DOM-skript

Only the adoption of unobtrusive DOM scripting will do away with outdated, uninformed, and inaccessible development methods. Only the adoption of unobtrusive DOM scripting will allow JavaScript, and thus web development in general, to attain its full potential.

The DOM Scripting Manifesto

Så som ordet här används handlar det om mer än att rent tekniskt använda DOM-funktioner. Det handlar om att ha en helhetslösning för välskriven kod, god praxis, användbarhet, och tillgänglighet. JavaScript skall användas för att förbättra en webbplats användbarhet, men med undantag för regelrätta applikationer som Google Docs, så skall den fungera på en basnivå även om JavaScript inte har aktiverats i webbläsaren. Precis som man kan se om HTML-koden är bra om man kör naket, så skall ingen funktionalitet vara omöjlig att använda utan skript.

Fler än man tror saknar JavaScript: Det kan vara användare som blockerar det av säkerhetsskäl, företag som strippar ut skript i sina proxies och mobilsurfare som använder Opera Mini pga hög kostnad för överförd data eller dålig bandbredd.

Däremot finns det ingen absolut ingen som använder en så gammal webbläsare att skripten måste döljas från dem med HTML-kommentarer. Det finns fortfarande guider som föreslår att du använder dem, trots att det inte behövts på snart 15 år. Det var ett av felen i kodexemplet ovan.

JavaScript bör infogas som progressive enhancement. Då behövs ingen fallback med <noscript>. Noscript-koden ovan hade även ett dåligt innehåll, men rätt utfört behövs alltså inte noscript-taggarna alls!

Andra viktiga principer för DOM-skript

Man bör koda för standarder först, och hantera enskilda webbläsares brister bara när det behövs.
I stället för att browsersniffa så bör man kapacitetsdetektera eller bug-detektera. Kan Jquery kan du!
All kod bör vara self contained och inte förpesta den globala namnrymden med globala symboler. Såväl funktionen hideme som variabeln the_link i koden ovan bryter mot denna princip.

(2) Diskreta = Unobtrusive

Det ord jag ville använda i kursplanen, men som definitivt inte finns på svenska är unobtrusive. Jag skrev en uppsats (PDF) om detta på Högskolan Väst för ett par år sedan och myntade då själv begreppet diskreta skript.

Ett skript som är diskret tränger sig inte på (obtrude), utan är helt separerat från HTML och CSS-koden. Det styr inte designen, men kan aktivera ändringar och animeringar. Detta kräver några saker:

Allt bruk av document.write måste upphöra! Du vinner dessutom prestanda och en massa andra fördelar, så förlusten är inte tung att bära.
Alla inline event handlers måste bort. De har flera nackdelar. Dels så inkräktar de på HTML-koden och är alltså lika illa att använda som inline CSS. Dels så tolkas de som eval. Och eval is evil av en mängd skäl, inte minst prestanda och scoping som kan lura de bästa. Dessutom förutsätter de ofta globala symboler för att fungera. Alla dessa problem finns i kodexemplet ovan. (target)

Var skall skripten placeras?

Först och främst gäller samma regel som för CSS: Skripten skall placeras i egna filer, externt, och laddas in via src-attributet. Det är grundregeln som bara får brytas om du arbetar på expertnivå och måste trycka ut några mikrosekunders bättre prestanda ur din webbplats.

När webbläsare ser en vanlig script-tagg med src-attribut, så avbryter de tolkningen av sidan, hämtar hem skriptet vilket tar tid och tolkar skriptet vilket tar ännu mer tid. Sedan fortsätter de tolka resten av HTML-koden.

Av det här skälet är det bäst att placera skripten allra sist i body-elementet, precis före dess sluttagg. Då har man dessutom fördel av att hela DOM-strukturen hunnit laddas in i datorns minne och är åtkomlig för skripten. Man kan ju inte göra en getElementById("a") innan elementet med id="a" har lästs in.

Alternativet är att placera skripten i head-delen av dokumentet och sedan aktivera dem med en händelse, men det har några nackdelar:

Man kan få parallell nedladdning av skripten genom attributen async eller defer, men de stöds inte ännu av alla webbläsare och måste betraktas som överkurs på en nybörjarkurs.
Man kan använda händelsen load, men den triggas först när också alla bilder och all annan media laddats ner, vilket ofta är för sent.
Man kan använda händelsen DOMContentLoaded, men den stöds ännu bara i vissa webbläsare.
Man kan trigga skripten genom pollning, vilket definitivt är överkurs på gymnasienivå, eller på grundläggande högskolenivå.

Däremot kan man använda sig av färdiggjorda expertlösningar i form av kodbibliotek som Jquery, Motools eller YUI. Vilket för oss till sista steget.

(1) Eleven skall infoga skript

För kursen Webbutveckling 1 förväntas inte eleverna skriva några egna längre skript. Däremot bör de kunna infoga väl valda skript som andra utvecklat. Kanske vill de ha en slideshow för sina bilder och då kan den JQuery baserade lösningen Nivo slider vara lösningen. Kanske vill de ha en enkel visa/dölj effekt, eller en rullgardinsmeny.

När elever väljer en lösning så måste de kunna bedöma kvalitén eller ställa rätt frågor. De måste i vart fall ha såpass mycket terminologi och förståelse med sig så att de kan söka på nätet eller ställa rätt frågor på ett forum. Dessutom bör de känna igen de viktigaste varningstecknen på dåliga DHTML-liknande lösningar.

Slutligen behöver de känna igen mönstret för hur man fäster händelser på objekt. Här visar jag hur man kan göra om koden från det dåliga exemplet ovan och lägger till en aning överkurs. Jag gör mitt skript självexekverande, så att inte en enda symbol läggs till den globala namnrymden.

Hur skall det då göras?

Så här kan man göra i ren JavaScript när man löser samma sak som i det dåliga exemplet:

<div id="a">Lorem ipsum dolor sit amet.</div>
<!-- Knappen infogas med javascript -->

<script>
// Ja detta borde vara externt men ligger här
// för att spara lite möda för dig kära läsare
(function () {
    "use strict";
    var the_div = document.getElementById("a");
    // Med var-deklarationen görs variabeln lokal
    var btn = document.createElement("button");
    btn.innerHTML = "Dölj texten";
    btn.onclick = function () {
        // Anonym funktion för enstaka ad hoc bruk
        // DOM 0 event handler är enklast för nybörjare
        // Inre funktion kommer åt variabel från
        // yttre funktion
        the_div.style.display="none";
    }
    // Av utrymmesskäl gör vi det osäkra antagandet
    // att the_div har efterföljande syskon
    the_div.parentNode
        .insertBefore(btn, the_div.nextSibling);
    
})(); // self executing closure
</script>

Några ytterligare kommentarer:

Vi använder use strict för att hålla skriptet rent från somliga dåliga delar av JavaScript-standarden, som aldrig borde ha uppfunnits.
Knappen hoppar runt lite, men det kan lösas om detta exempel vore på riktigt.
HTML-koden validerar (nästan) för både den dåligt skrivna sidan. Men JSHint larmar om problem för den dåliga skriptkoden.

Så här kan man göra i JQuery och detta är vad jag förväntar mig att elever skall kunna:

<div id="a">Lorem ipsum dolor sit amet.</div>
<!-- Knappen infogas med javascript -->

<script>
(function () {
    "use strict";
    var the_div = $("#a");
    var btn = $("<button>Dölj/visa texten</button>")
    .click( function () {
        the_div.toggle("slow");
    });
    btn.insertAfter(the_div);
})(); // self executing closure
</script>

Felen i det dåliga exemplet

Knappen skapades inte med JavaScript.
Knappen hade en inline event handler.
Inline event handlern har en underförstådd eval.
Attributet language skall inte användas.
Kommentarer för att dölja skriptet är så 1995.
Variabeln the_div deklarerades inte med var och är därför global.
(Funktionen hideme är också global, men på nybörjarnivå kan man leva med det.)

Bonustips

Attributet language är ett säkert tecken på att ett skript är föråldrat. Det var det sista felet som jag nämner i koden ovan. I HTML 4.01 och XHTML 1.x så krävdes attributet type, men i HTML5 så är det frivilligt och det har alltid varit onödigt. Jag har inte med det i min förbättrade kod.

P.S

Min egen webbplats har inte fått något designlyft på flera år. Jag har inte tid! Vill någon göra något åt detta så kontakta mig.

Framtidens programmeringsundervisning = patterns and paradigms first (del 3)

gunther@keryx.se (Lars Gunther) — Sun, 22 May 2011 07:00:09 +0200

De elever jag undervisar kommer vara aktiva i utvecklingen av olika slags mjukvara från år 2011 till kanske år 2055. Vi kan inte hålla på och diskutera som om det fortfarande vore 1993. Vi lärare måste blicka framåt. Jag är inte så värs bekymrad över att dagens elever inte lär sig assembler eller ens sorteringsalgoritmer. Ytterst få kommer jobba på den nivån. 99 % av alla utvecklare på morgondagens arbetsmarknad kommer jobba på en högre abstraktionsnivå.

Sortering är inte (längre) svårt

Alla moderna språk har tillgång till högoptimerade bibliotek med färdiga sorteringsfunktioner. Att sortera är inte svårare än att skriva sort i sin kod. Den som kan läsa manualen kommer alltid vinna över den som återimplementerar redan befintliga funktioner i sin egen kod.

Varför fokuseras då sorteringsalgoritmer så mycket? För att dagens lärare har fått lära sig dessa och fått intutat i sig att de är viktiga.

Ett annat exempel: Jag och mina kollegor som började med datorer på 70-talet – jo, jag är så gammal – är uppvuxna med en programmering som fokuserat frågor om maximalt nyttjande av hårdvaran. Peek och poke blandades in i Basic för att öka farten! Kort sagt, vår Basic hade inslag av assembler. Men varför skall dagens nya utvecklare gå igenom våra utvecklingsfaser?

Paradigmskiften

Programmerare är ett konservativt släkte. Detta säger en av mina gurus, Douglas Crockford. Det är som om varje förbättring i våra arbetsmetoder och vårt sätt att programmera kräver ett generationsskifte:

Who was most enraged by this suggestion [to drop goto]? Programmers. This debate went on for literally a decade, for two decades, for a generation, arguing about whether GOTO should be eliminated or not. Ultimately we got rid of it, and that was the right thing to do. I think it's not coincidental that it took a generation to do it, because basically we had to come up and train a whole new set of people who were not stuck in the previous idea. Again, who better should have understood the value of structuring your programs in such a way that they could scale better? Only programmers should understand the value of that argument, and programmers were least able to understand that argument. (Mina betoningar.)

Att få en överblick om olika programmeringsparadigm och att kunna ta till sig de paradigm som kommer få störst betydelse i framtidens utveckling ser jag som en klart viktigare kunskap, än att återskapa alla algoritmer som forskades fram på 60- och 70-talen. Åtminstone inte på gymnasienivå.

Somliga programmerare kommer behöva djup förankring i datavetenskapen, så som den presenteras på högskolan, men det gäller inte alla. Och speciellt inte de som kommer få jobb efter ett fjärde år på gymnasiet. Branschen var mycket tydlig med detta. Det är inte gymnasiets jobb att utbilda framtidens programmerare i klassisk mening. Från början var uppdraget inte ens att utbilda något annat än webbutvecklare, men som jag tidigare skrivit, så menar jag att disciplinerna konvergerar och att en sådan utgång skulle därför bli för snäv.

Att förstå patterns är viktigare algorimer

I det arbete jag förutser för gymnasieingenjörer, så ingår alltså inte problemen att skapa perfekta, sökalgorimer optimerade simuleringsflöden eller program för data-mining. Däremot tror jag de kan jobba med lokalisering, att skriva tester utifrån buggrapporter, porta en iOS app till Android, skapa en webbplats med Drupal och JQuery och komplettera ett sådant kodbibliotek med några inte alltför komplicerade egna funktioner.

För den sortens arbete är det viktigt att man förstår applikationsarkitektur och designmönster. Att kunna känna igen, använda och skapa singletons, factorymetoder, active record eller en front end controler, det är saker jag tycker är grunder!

Historia och framtid

Specifikt för gymnasiets teknikprogram är att eleverna skall få helhetsbilder inom sina teknikområden. Yrkeshögskolorna utbildar med stor specialisering mot enskilda arbetplatser. De kan ge en utbildning som bara fokuserar exempelvis Flash eller RIA. Universitet och högskolor skall soms sagt fokusera på datavetenskap. Gymnasiet skall däremot ge en bredare kunskap.

Som en konsekvens av detta tror jag på att lära eleverna historisk kunskap om hur programmeringen har utvecklats från Eniacs dagar till våra. Jag tror bara inte att vi skall låta dem i detalj återuppleva historien. Men den sortens kunskap som Douglas Crockford framför i detta föredrag är klart väsentlig. (Föredraget inleder en serie om JavaScript, men handlar till 80 % om programmering i allmänhet.)

Douglas crockford föreläser om programmeringens historia. (Flash krävs.) Källa

Om du har det allra lilla minsta intresse för programmering, så skall du lyssna på detta föredrag av the Crock. Allt annat är tjänstefel!

Ett liknande synssätt finns i denna artikel av Gary pollice, med den talande rubriken Beyond an objects-first approach.

I also noticed that people who were competent with functional languages, such as LISP, could adapt to the OO languages and methods with greater ease than I could.

…

Students who come from an objects-first program have learned the hard part of software development. They understand design principles and how to manage complexity. (Min betoning.)

Nej. Våra elever måste inte vandra igenom den utveckling vi som lärare gjort. De måste inte börja med radbaserad imperativ programmering, för att gå vidare till strukturer och sedan objekt – och stanna där!

Vad det sista stycket i citatet ovan illustrerar är att det svåra som måste bemästras är inte syntax eller kommandon, utan att kunna bygga ihop ett program, enligt en funktionell och modulär arkitektur.

För 2010-talet så måste vi ställa oss frågan vad kommer efter OO? Vad för landskap skall våra elever vandra igenom när deras karriär kommer vara mellan år 2015 och år 2055? Historia är alltid bra, men att föra vidare grälen från 90-talets början mellan objektorienterad och strukturerad programmering, det känns som att utvärdera huruvida våra fordon skall dras av hästar eller drivas med bensinmotorer, just när vi borde leta efter något annat än bensin.

Funktionell programmering

Gary Pollice drar en lans för aspektorienterad programmering. Själv tror jag att funktionell programmering kommer ta en stor del av marknaden. På minst tre sätt:

Befintliga språk utökas med funktionella möjligheter. Exempelvis har PHP 5.3 såväl lambda som closures.
Tydligt funktionella språk, som OCaml, Haskell, Clojure, Erlang, F#, Scala och inte minst Ruby vinner terräng. (Många av dessa kan användas i hybridläge mellan OO och funktionell programmering.)
JavaScript är redan världens mest använda programmeringsspråk, och växer snabbare än något annat. JavaScript är baserat på Self och Scheme och i grunden alltså ett funktionellt språk, med många drag av Lisp, alla funktionella språks urmoder.

Ett exempel ur verkligheten

Jag har precis skaffat mig en LiveScribe penna. Jag älskar den! Men det finns inget stöd för Linux och jag är en Linuxälskare av stora mått, så när jag sökte efter ett program för Linux, så hittade jag LibreScribe. Och det här citatet:

Even small things, such as documenting functions, adding comments, ensuring source code style consistency, and making it easier to maintain the source code are incredibly important.

Som taget ur mina kursplaner och min idé om att göra praktik i öppen källkodsprojekt:

Dokumentera funktioner – finns i kursen mjukvarudesign.
Kodstandarder – finns i kursen mjukvarudesign.
Projektet finns på Github – versionshantering finns i kursen mjukvarudesign.
Projektet skall följa riktlinjerna för tango! i gränssnittet – att kunna skapa bra gränssnitt är en av mina käpphästar och har fått en kurs som obligatorisk förkunskap till fjärde året och en ytterligare kurs att läsa under det året.
Projektet använder wxWidgets – min föreslagna kurs Mjukvarudesign 2 innehåller just api:er som ett viktigt centralt innehåll.

Här har vi alltså någon som efterlyser hjälp på lämplig svårighetsnivå och med konkreta uppgifter.

Hur kan ni hjälpa till?

Hitta fler bra exempel på FOSS-projekt som kan ta emot bidrag på rätt nivå.
Tala väl om mina idéer (förutsatt att du gillar dem) för alla du möter.
Deltag i samtalet på Dela!
Hitta på uppgifter, illutrationer, stolpar till föredrag och liknande, anpassat till gymnasienivå och dela dem.

Framtidens programmeringsundervisning = web first (del 2)

gunther@keryx.se (Lars Gunther) — Sun, 08 May 2011 14:35:47 +0200

(Detta är del 2 av 3 i en serie om programmering på gymnasiet, med anledning av ett seminarium där jag deltog för ett par veckor sedan. Läs gärna del 1 först om du inte gjort det.)

En annan av föreläsarna uttryckte följande ståndpunkt i ett samtal med mig: För mig är webben bara ett gränssnitt. Ju mer jag tänkt på kommentaren, desto tydligare kommer skillnaden mellan våra synsätt i dagen. För mig är webben en revolution, en transitional teknik, som påverkar systemens arkitektur, deras förutsättningar och möjligheter i grunden.

Webben ändrar allt

Webben demokratiserar data och applikationer som ingen annan teknik. Spelfält utjämnas och nya tekniker och idéer kan slå sig fram enklare än på någon annan plattform.
Webben har just blivit en körmiljö för applikationer av flera slag: Kontorsprogram, utvecklingsmiljöer, anteckningar (typ Evernote), projekthantering, konferens- och kommunikation och inte minst spel. Beräkning och exekvering sker för dessa applikationer till stor del i klienten, för närvarande i Flash men alltmer i HTML5 (med spinofftekniker).
Webben är den körmiljö som man först måste etablera sin produkt inom. Sedan kan den kanske kompletteras med appar eller regelrätta program, men webben kommer först! Facebook hade aldrig kunnat börja som en iPhone app.
Webbens tekniker erövrar område efter område också i systemens arkitektur. Exempelvis så används ReST (som bygger på http) exempelvis för kommunikation mellan program och databaser i många noSQL system. Och program skrivna för traditionella miljöer är ofta klienter till webbtjänster.
Webbens tekniker används alltmer inom traditionell programmering. Gränssnitt för desktop och mobiler byggs med deklarativa tekniker som XAML eller QML. Data utväxlas med XML eller JSON.

Samtidigt som detta händer, så plockar webbutvecklingen in alltfler verktyg, tekniker och metodik från traditionell programmering. De två disciplinerna närmar sig helt enkelt varandra.

Exemplet luffarschack

Strunta i exemplet och hoppa till det fortsatta resonemanget.

Det första föredraget på träffen för programmerare hölls av André Jaoui och han visade hur han använt luffarschack som ett exempel för att introducera olika begrepp i undervisningen. Självklart började min hjärna genast skriva om hans idé till JavaScript. Du kan view sourca mitt work in progress för se hur det skulle kunna funka. Här visar jag bara själva skriptet.


// SVG som bakgrund kan inte detekteras
// Vi hoppas att det sammanfaller med stöd för SVG som img
function SVGSupported() {
    var testImg = 'data:image/svg+xml;base64,…';
    var img = document.createElement('img');
    img.setAttribute('src', testImg);
    var svgok = img.complete;
    // Catch annoying bug in Firefox 4 that makes SVGSupported sometimes fail
    if ( !svgok  && $.browser.mozilla && +$.browser.version.slice(0,3) >= 2.0 ) {
        svgok = true;
    }
    return svgok;
}

if ( SVGSupported() ) {
    // Generera tabell
    var table = $("<table></table>");
    for (var i = 0; i < 25; i++) {
        var row = $("<tr></tr>");
        for (var j = 0; j < 25; j++) {
            var cell = $("<td id='" + j + "_" + i + "'></td>");
            cell.appendTo(row);
        }
        row.appendTo(table);
        // table.append(row); // Alternativ syntax
    }
    $("#spelplan").append(table);

    // Vems tur är det?
    var inturn = "kryss"; // Global

    $("td").click( function makemove() {
        if ( $(this).hasClass("cirkel") || $(this).hasClass("kryss") ) {
            alert("upptagen");
            return false; // Stops both propagation (bubbling) and default action
            // Must be used with care
        }
        inturn = (inturn === "cirkel") ? "kryss" : "cirkel"; // Överkurs
        $(this).addClass(inturn);
        var winning = detect_winning_move(inturn, this);
        if ( winning) {
            alert(inturn + " vann");
        }
    });
} else {
    $("#spelplan").append("Gammal webbläsare");
}
/**
 * Funktion som kontrollerar om ett vinnande drag gjorts
 *
 */
function detect_winning_move(inturn, cell) {
    var directions = [
        [-1,  0], // väster
        [-1, -1], // nordväst
        [ 0, -1], // norr
        [-1,  1]  // nordost
    ]; // Array literal som innehåller 4 andra arrayer
    var winning = false; // Sätts till true om segrande drag gjorts
    // Testa alla 4 riktningar
    var curcell   = cell.id.split("_");
    for ( var i = 0; i < 4; i++ ) {
        // Gå till ena änden - börja alltid med kryssad ruta
        // Akta sig för konkatenering - vi vill ha addition -
        // så byt från sträng till Number med plustecknet
        var nextpoint = [ +curcell[0], +curcell[1] ];
        do {
            nextpoint    = [ nextpoint[0] + directions[i][0], nextpoint[1] + directions[i][1] ];
            var nextid   = "#" + nextpoint.join("_");
            var nextcell = $(nextid);
        } while ( nextcell.hasClass(inturn) );
        // Gå till andra änden och räkna antal
        var inrow = -1;
        do {
            // Byt håll = subtraktion
            nextpoint = [ nextpoint[0] - directions[i][0], nextpoint[1] - directions[i][1] ];
            nextid    = "#" + nextpoint.join("_");
            nextcell  = $(nextid);
            inrow++;
        } while ( nextcell.hasClass(inturn) );
        if ( console ) {
            console.log(inrow);
        }
        if ( inrow >= 5 ) {
            winning = true;
        }
    }
    return winning;
}

För att dölja komplexiteten i DOM-funktionerna, vilket ligger utanför programmeringsämnet, så använder jag JQuery. Det första som jag märker är med vilken lätthet jag kan presentera konceptet för mina elever och få in olika moment:

Loopar: Spelplanen görs som en tabell i HTML, vilken genereras med en dubbel loop.
Funktioner: Första funktionen är till innehållet ganska avancerad, men dess syfte är lätt att förklara. Stödjer webbläsaren SVG som bild? Eleven kan använda den utan att förstå exakt hur den funkar.; Kryss och cirklar som bakgrundsbilder i CSS aktiveras genom att man i funktionen makeMove kontrollerar om rutan är ledig och i så fall sätter klasser på cellerna. (Alternativt skulle jag kunna göra så att kryss och cirklar sattes som bokstäverna x och o med en specialdesignad webfont.); Funktionerna SVGSupported och detect_winning_move Funktionen makemove definieras som en function expression, också kallad lambda. Den skulle kunna vara namnlös.
Logiska villkor: I funktionen makeMove finns en logisk eller-konstruktion och en ternär operator. Den sista är överkurs.
Variablers räckvidd: I sin första tappning så är den variabel som håller reda på vems tur det är global: Deklarerad utanför men använd inuti en funktion. På enklaste nivå låter jag detta passera, men påpekar att det längre fram är en felkälla som bör undvikas.; Också buggfixen för SVGSupported bygger på en global variabel. Det skulle kunna vara en uppgift till eleverna att flytta in den logiken in i funktionen och göra variabeln överflödig.
Händelser: Klicka på en ruta för att sätta kryss eller cirkel – en busenkel introduktion till händelsedriven programmering.
Namngiving: Funktionen SVGSupported inleds med en versal. Detta kan ge mig anledning till att diskutera bättre namn. Versal som första bokstav reserveras traditionellt i JavaScript för funktioner som skall instaniseras med operatorn new.
Hoisting: Inte alla vet att JavaScript normalt tolkas i 2 omgångar. Funktions- och variabeldeklarationer flyttas upp automatiskt, så man kan anropa en funktion innan den deklarerats. Detta kallas hoisting, och är en smidig sak rätt använd. Det är också en felkälla för ovana programmerare eller vid arbete i team.; Crockford förbjuder detta i JSLint och det finns fler stilistiska fel som man kan upptäcka med den sortens verktyg. (Jag rekommenderar numera JSHint!)

Händelsedriven programmering

Ett av skälen till varför undervisningen fortsätter lära ut modellen exekvera - vänta - exekvera - vänta och data skickad via STDOUT och STDIN är att i traditionella språk är det ett jättearbete att sätta upp händelsehantering. Exempelvis måste man i Java instansiera klasser som i sin tur implementerar interface. Detta är begrepp som eleven möter på allvar först i den sista kursen (Programmering C idag, Programmering 2 i Gy-11.)

Men i JavaScript med JQuery är det enkelt och lättbegripligt. Identifiera objektet till vilket händelsen kopplas, sätt en funktion som händelsehanterare. Klart!

Redan på programmering A nivå (med nuvarande kursplaner) kan man alltså skapa ett spel där två spelare möter varandra sittandes vid samma dator. Algoritmer för att automatiskt kontrollera om endera spelaren har vunnit, som i exemplet ovan, kan introduceras för Programmering B.

Programmering C (2 i Gy-11) skulle kunna introducera en enkel spelmotor för att spela mot datorn, men det jag verkligen ser fram emot är att skapa funktionalitet för att spela över Internet mot andra människor. För fjärde året har jag föreslagit en kurs i nätverksprogrammering och som en spinoff till HTML5 finns det en teknik som heter WebSockets som passar perfekt för detta.

Det jag försöker visa är att JavaScript funkar precis lika bra som Java för att lära ut programmering. JavaScript är inte en lättversion av Java!

Min erfarenhet av att köra Programmering A med JavaScript

Jag har kört kursen Programmering A med JavaScript några gånger nu. Dels med elever som inte läser webbdesign alls och dels med en grupp som läser kurserna parallellt. Eftersom man måste lära ut ett minimum HTML och CSS så är det inte givet att det blir bättre i första fallet. Det är få timmar man har till förfogande och elever som inte direkt få blodad tand och blir självlärande kommer sällan upp till mer än knappt G-nivå. Men jämfört med att jobba i konsollmiljö så är sannolikheten för att de skall tycka att kursen är kul betydligt större. Och då så att de blir just självlärande. För dessa tycker jag alltså att för- och nackdelar tar ut varandra.

För elever som läser kurserna parallellt, så funkar de som varandras förstärkning. Nästan allihop vill ha med JQuery-effekter och vågar använda JQuery widgets för sina inlämningsarbeten för webbdesign. Detta i sin tur inskärper kunskaperna om CSS-selektorer, skillnaden mellan klass och id, värdet av välskriven, semantisk HTML och andra moment webbdesignen.

Det bör tilläggas att jag lär ut en aning Java också. Jag använder kontrastverkan mellan dessa två språk, som är så väldigt olika att de utöver C-syntax och fyra bokstäver i namnet knappast har något gemensamt. Saker som jag tycker blir tydliga genom kontrasten är:

Värdetyper och skillnaden mellan statiska och dynamiska värdesystem.
Skillnaden mellan att jobba i sekvensiella flöden och händelsedrivet.
(Längre fram:) Skillnaden mellan klassisk objektorientering och funktionell programmering.

Notera att jag inte emulerar STDOUT och STDIN med document.write(). Den metoden är totalförbjuden på mina lektioner och jag säger åt mina elever att om de ser en sida som använder den, så skall de tvätta ögonen med såpa!

Att lära sig grunderna

Genom att börja med webben som körmiljö, så introducerar man på ett naturligt sätt flera begrepp som ofta kan bli svåra att lära ut. Grundläggande begrepp och principer, som borde komma in tidigt i undervisningen!

Applikationslogik

Tredelningen…

HTML för struktur och innehåll.
CSS för design och layout.
JavaScript för beteende.

…är en naturlig introduktion till olika slags logik och separation of concerns. På webbservern lär jag eleverna tidigt skilja ut presentationslogiken från bearbetning och databashantering. I vanlig programmeringsundervisning så ser jag exempel efter exempel på hur olika slags logik blandas, så att när detta moment dyker upp så måste eleven lära sig av med dåliga vanor. Och elever som redan skrivit ganska så omfattande program tappar sugen när de inser att de måste skriva om det från grunden, då dess arkitektur inte håller måttet.

De flesta jag sätt som börjar med vanlig programmering lär sig skriva spagetti-kod, där bearbetning blandas huller om buller med in- och utmatningar. Detta därför att metoderna för de senare är såpass avancerade att man måste lära sig programmera på (gymnasiets) C-nivå, innan de kan användas med någon slags behållning. Kort sagt, man behöver stora förkunskaper för att kunna separera logik. Men på webben kan man börja göra det från dag noll!

Mitt stridsrop webben först är inte nödvändigtvis detsamma som att ämnet Programmering på gymnasiet skall börja med JavaScript – även om jag försökt göra gällande att det är ett bra val av förstaspråk för undervisningen. Webbutveckling och programmering kan som ämnen korsbefrukta varandra även om man jobbar med ett annat språk.

Java applets är däremot inte en möjlighet för sådan korsbefruktning. Det finns massor av vettiga saker att göra med Java, mängder av körmiljöer som språket är lämpligt för: Desktop, mobiler, inbäddade system, servrar… Applets är helt enkelt bara inte en av dem.

En bra introduktion till objekt

Ett av problemen som presenterades på seminariet med att lära ut objects first är att studenterna inte verkar riktigt förstå vad de lär sig… De använder klasser och objekt, men kan inte på ett tillfredsställande sätt förklara vad det egentligen är.

Jag ser två sätt på vilket en web first metodik kan råda bot på detta:

Dels så bekantar sig eleven tidigt med systemens arkitektur, enligt ovan, vilket gör objektens sammanhang tydligare. Objektorientering utan kunskaper om designmönster blir sällan annat än onödig komplexitet. (För fjärde året har jag föreslagit en kurs med designönster som ett av sina huvudsakliga innehåll.)
Objekt i webbmiljö blir ofta konkreta och manipulering av deras egenskaper skapar ett omedelbart visuellt resultat.

Ett av problemen i objektorienterad programmering är att de första exemplen som eleven får lära sig är ofta väldigt fiktiva. Klasser och arv illustreras med biologin eller fordonsindustrin:


class monkey extends Mammal {}
class sportscar extends fourwheelcar {}

Så gjorde jag också förut, eftersom det var vad jag hade läst mig till från andra. Nu börjar jag med:


   document.getElementsByTagName("h1")[0].innerHTML = "Alternativ text";
   document.getElementById("foo").style.backgroundColor = "fuchsia";

Resultatet syns direkt!

Ett element som har egenskaper som textinnehåll, bredd, höjd, färg och x/y/z position och metoder för att finna och ändra på deessa gör objektorienteringen konkret och användbar. JavaScript ihop med DOM funkar superbt här, men för att visa eleverna ett väldesignat api, så lär jag dem relativt snabbt JQuery. DOM-metoderna i sin grundform är ju tyvärr rätt åbäkiga. (Utvecklarna var för påverkade av Java, tror Douglas Crockford och jag, och missade att föra över elegansen i JavaScript till DOM.)

Samlingar av HTML-element är array-liknande och ger mig som lärare snabbt naturliga exempel på när man just kan använda arrayer, hur man loopar igenom dem, etc.

Andra vinster

Ett av skälen till att man ofta dröjer med grafiska metoder i traditionell programmering är att det blir så komplext. Java Swing kan användas genom monkey sees, monkey does programmering, men eleven måste läsa flera kurser innan det som har kodats blir begripligt. Men med JQuery kan en elev på några minuter göra detta:


$("#btn1").click(function () {
    $("foo").hide("slow").
});

Webben är också en bra introduktion till SOA och SaS. Och om man lär sig XHR först, gärna med JQuerys förenklade api, så kan CORBA bli mindre avskräckande.

Sammanfattning

Web first är dels en teknisk nödvändighet. Världen går åt detta håll.

Dels är det en pedagogisk möjlighet. Inget att beklaga, utan en möjlighet att ta vara på.

Epilog 1

Jag uppmuntrar till diskussion om denna artikel på dela.

Epilog 2: Finn fem fel

JavaScript är en förenklad variant av Java som nästan uteslutande används på webbsidor på samma sätt som applets. Ett JavaScript kan alltså bara köras inbakat i en webbsida med hjälp av en webbläsare.
… Rent språkligt ligger den största skillnaden i att JavaScript inte är renodlat objektorienterat… men du kan inte skapa egna klasser.

Citatet kommer från Erik Ronnes bok Avancerad Pocket Java (Docendo läromedel) och har några år på nacken.

JavaScrip är inte en variant av Java, utan har sitt ursprung i Self, Scheme och Lisp. Fast det har fått en C-syntax likt Java.
JavaScript är inte enklare i betydelsen har mindre kraft. Det är bara enklare i betydelsen har en smidigare och enklare syntax.
Till skillnad från Java applets, så körs JavaScript inte inbakat i webbsidor, utan är en integrerad del av dem. Applets är (oftast) otillgängliga och isolerade från webbsidan. JavaScript kan göras tillgängliga och är en del av webbstacken.
JavaScript tillåter såväl procedurell, objektorienterad som funktionell programmering. Arv genom prototyp är kraftfullare än arv genom klasser. Man kan enkelt emulera klasser i JavaScript, men det är en plåga utan dess like att emulera prototyp i klassbaserade språk.
Jag skulle dock vilja påstå att den största skillnaden är att Java har strikt typsystem och JavaScript ett dynamiskt typsystem.

Ronne är tyvärr inte ett undantag. Den sortens desinformation har nått åtskilliga årskullar av elever. Om du inte gör någon annan förändring i din undervisning, så tag åtminstone med dig detta till dina elever:

Java och JavaScript är två skilda språk, med olika förmågor, men språkligt är Java det svagare, mindre kapabla språket, som dock har två andra fördelar: Det kan köras på fler olika system och det får en något högre prestanda när man kompilerat det. Alla andra påstådda fördelar är ljug eller personliga preferenser.

Epilog 3: MDC och Stackoverflow

Utöver JQuery-manualen ocj Wikipedia, så går nästan alla länkar i min artikel till antingen Mozilla Developer Center eller Stack Overflow. Det första är nätets auktoritativa resurs om JavaScript. Det senare en plats för utbyte av frågor och svar, som utmärks av kunniga och engagerade deltagare.

De absolut största svagheten för JavaScript är att nätet vimlar av dålig information. Föråldrade och usla exempel finns det gott om.

Varningstecken på dåliga sidor:

document.write()
Inline event handlers (blandar HTML och skript), typ <body onload="foo()">
Eval

Tecken på att sidorna är uppdaterade och ger bra information:

Hänvisningar till JSHint (eller JSLint)
Begreppet unobtrusive används.
Begreppet progressive enhancement används.
Begreppet dom script används.

Framtidens programmeringsundervisning = user first (del 1)

gunther@keryx.se (Lars Gunther) — Tue, 19 Apr 2011 13:38:57 +0200

När jag träffade ett 50-tal programmeringslärare häromveckan blev jag påmind om att det är ett ämne med en frustrerande spänning mellan historia och framtid. Jag tror nämligen inte att nya programmerare måste göra samma resa som jag eller branschen i stort gjort. Jag tror inte att man måste börja procedurellt och hårdvarunära. Jag tror inte ens på objects first. Jag tror man kan börja funktionellt och dynamiskt, men det är inte min huvudpoäng. Den allra första boken man borde läsa när man lär sig programmering skall varken behandla syntax eller problemlösning, utan användarnytta. Börja gärna med boken Jävla Skitsystem. Gå sedan in på programmeringen som sådan. Huvudmålet med programmering är inte att lösa matematiska problem, utan användarnas problem.

Ett inspirerande möte

Innan jag återkommer till frågeställningen om hur och vad som bör ingå i undervisningen i programmering, låt mig börja med att tacka Lennart Rolandsson som arrangerade träffen och alla kollegor som jag verkligen uppskattade att träffa. Att jag dessutom fick höra mycket beröm för de ämnes- och kursplaner jag skrivit gjorde ju knappast saken sämre. Är du gymnasielärare i programmering, så gör det till en prioritet att komma till nästa träff! Detta var den fjärde träffen i denna seminarieserie och intresset växer hela tiden. Efter mitt forsta deltagande förstår jag varför.

Lennart har skrivit ihop en sammanfattning av det som sades av oss föreläsare, så jag tänker inte göra om det. Mitt eget föredrag om utvecklingen i branschen finns på Slideshare och den del som behandlade det fjärde året finns på Prezi.

I stället skall jag utveckla mina åsikter i (troligen) tre blogginlägg:

Användarens behov kommer först och inte matematiken.
Webben är mer än ett gränssnitt.
Det finns fler paradigm än strukturerad och objektorienterad programmering.

I dessa inlägg kommer jag beskriva mitt tänkande ifrån tre aspekter:

Några tankar om min grundsyn på ämnet och branschens utveckling, delvis hämtade från mitt föredrag.
Hur det påverkat mina vägval när jag jobbat med fjärde året på teknikprogrammet.
Vad slags stöd kollegor kan ge mig för de ideer jag har om detta.

Och jag kommer tänka mig en slags antagonist som omhuldar följande åsikter:

Riktig programmering är tillämpad matematik, algoritmer och annat vi lärt oss av Donald Knuth.
Riktig programmering är baserad på manuellt kompilerade språk med statiska typsystem.
Riktig programmering är strukturerad och/eller objektorienterad.

Enligt Lennarts sammanfattning från träffen, så skall en av lärarna på BTH uttryckt följande åsikt om gymnasiets programmeringsundervisning:

skit i grafik och annat, se till att de kan programmera de mest grundläggande sakerna, helst i mindre i flera olika språk, men att de verkligen behärskar grunderna.

Om detta har jag en enda sak att säga:

Not on my watch!

Jag gillar såväl Donald Knuth som matematik, men detta synsättet är för snävt. Det kommer att vara dåligt för rekryteringen av elever till programmeringen och det kommer inte gagna industrin.

Programmering som en del av fjärde året på Teknikprogrammet

När jag tänkte på det fjärde året så var ett ord viktigare än alla andra: Anställningsbarhet. En klassisk programmerare med goda kunskaper om datavetenskap och algorimer behöver normalt studera ämnet i flera år. Det är högskolans sak att få fram dessa. Jag tror inte att gymnasiet skall utgöra en lättversion av detta. Branschen var mycket tydlig att den inte såg möjlighet att anställa studenter med en sådan utbildning. Från början ville man därför inte ha någon annan inriktning på fjärde året än webbutveckling.

Delvis tror jag detta beror på att få fattat hur komplex modern webbutveckling kan vara. Testa dig själv med dessa frågor:

Om du vill åstadkomma asynkron nedladdning av JavaScript, men ordningen i vilken de laddas och körs är viktig, hur gör du det?
Vad har TCP:s slowstart algoritm för påverkan på frågan om man skall använda progressive enhancement eller inte och vilka parametrar skall jag testa för att säkerställa bäst resultat utifrån den frågeställningen?)

Annorlunda uttryckt: En webbutvecklare måste kunna programmera och en programmerare måste kunna webbutveckla. Och såväl utvecklongsverktyg som projektmetodik sammanfaller till stora delar mellan dessa två discipliner. I slutändan kom profilen att heta mjukvarudesign och den rymmer såväl webb som vissa moment ren programmering.

Att lösa rätt problem

Traditionellt har kopplingen mellan programmering och tekniska beräkningar varit stark. Att bygga goda användarupplevelser är inte computer science och inte lika fint. Eller så kan man lära sig det senare. Problemet med detta tänkande är att det i längden leder till dåliga produkter.

Den invändning som främst kommer fram är att man missar grunderna om man börjar för tidigt med grafiska gränssnitt och försök att göra snygga program. Min motfråga är varför det skall anses som icke-grundläggande att skapa just det som användare efterfrågar?

To the user, the interface is the product.

Det köps idag in s.k. affärssystem för miljardbelopp i Sverige, som inte används eller när de används så driver man användarna till vansinne. Det är system skapade av programmerare som låter användarna anpassa sina rutiner till datan och inte tvärtom. Det är system som är så fula i estetisk bemärkelse att de kan anses vara ett arbetsmiljöproblem. Det är system som användarna undviker och som i extremfallet inte alls används. I stället används vanlig mejl och vanliga officeproduktertil sådant som de egentligen borde vara sämre på. Men på grund av sin generella goda användbarhet så används de i stället.

Nu finns det ett problem med frågan om gränssnitt, nämligen att den lätt reduceras till färdighet att använda ett visst verktyg. Jag är allergisk mot kurser i Dreamweaver. Likaså mot okunniga ASP-utvecklare som använder verktygen i Visual Studio utan att ha den blekaste aning om att de producerar gräslig och dåligt fungerande skräpkod, fylld av monstrositeter som viewstates och annan sörja. Hur man bygger en modal dialogruta i just ditt favoritverktyg är ointressant. Frågan är när du skall använda modala dialoger, hur du utformar dem så att användaren inte missar dem, etc. (Hur ofta har man inte varit med om att dialogrutan ligger dold bakom ett fönster…)

För att lyfta frågan om gränssnitt, så har det blivit ett eget ämne och grundkursen i gränssnittsdesign är dessutom ett förkunskapskrav för fjärde året. Notera att ämnet fokuserar såväl interaktionsdesign som visuell design. När eleven sedan fortsätter med att konkret programmera, så är det problem som han/hon har att lösa hur just en optimerad användarupplevelse åstadkoms.

Först kommer inte flödesschema och UML-diagram. Först kommer en storyboard!

Exemplet WordPress

Jag vet inte hur många gånger jag hört erfarna programmerare klaga på Wordpress. Och vad jag förstått, så görs det med rätta. Ur programmeringsteknisk synvinkel så lämnar nämligen produkten mycket att önska. Under dess första tid uppvisade den alla tänkbara problem: tight coupling, bristande säkerhet, ineffektiva algoritmer, bristande arkitektur, etc. Trots detta blev produkten en succé och frågan är varför?

Därför att produkten, när den kom, bättre än någon annan tillgodosåg ett konkret behov. Den kunde installeras utan att man behövde vara alltför teknisk och den gav avändarna just de funktioner man önskade. Under skalet var det skrot men likväl lyckades produkten då det som efterfrågades var ett bra skal!

Användarens upplevelse är grunden för allt

Det är rimligt att just tekniska högskolor skall utbilda programmerare som är djup förankrade i datavetenskap och matematiskt tänkande, men det jag värjer mig mot är att all programmering skall passas in i den mallen.

Jag säger det igen: Att utveckla fungerande gränssnitt har sina egna utmaningar. Jämför en applikation som löser en uppgift på tre (3) sekunder, men under tiden är programmet fryst. Med touch interface så kanske inte ensett timglas visas, utan användaren hinner peka på skärmen flera gånger. Sedan när programmet reagerar så händer det en serie av oönskade händelser. I värsta fall hinner användaren inte ens se det hett efterlängtade resultatet, innan skärmbilden försvinner.

Ett annat program har kanske mindre optimerade algoritmer och uppgiften tar fem (5) sekunder att lösa, men under tiden fortsätter programmet att svara. Sämre datavetenskap, men bättre produkt!

Responsiveness is more important than speed.

Alltså, jag köper att programmering är problemlösning, men vad för slags problem skall vi lösa? Inte bara det slags problem som återfinns i programmeringsolympiaden. Jag tror vi gör oss en otjänst genom att stirra oss blinda på den mycket snäva definitionen av problem.

Jag är helt frankt mer intresserad av att se mina elever skapa användbara mobila appar, webbplatser och nyttoprogram, än att se dem ta medaljer i en artificiell tävling.

Nu har jag skrivit ett skarp blogginlägg. Jag tror diskussionen mår bra av skärpa. Men missta inte den skärpan för antipati. Jag uppskattar mötet med kollegor som har avvikande åsikt. Jag välkomnar sådana på Delas forum för programmering.

Mina tankar och resurser om gy11 kurserna

gunther@keryx.se (Lars Gunther) — Thu, 17 Mar 2011 20:46:02 +0100

Det var en givande dag tyckte deltagarna på seminarierna om teknikprogrammet i Gy-11 [PDF] i Göteborg torsdag förra veckan. Översvallande positiva reaktioner i utvärderingarna. Jättekul för Gunilla, Tibor, Karin och mig. Här kommer en kort rapport och utlovade länkar från mina pass. Jag kommer fortsätta bevaka #grgy11 på Twitter månaden ut. Använd den hashtaggen om ni vill föra diskussion utan att behöva prenumerera på mina inlägg.

Mitt pass började här

Snabb översikt om de olika webbkurserna på Prezi.
Presentation av ämnet webbteknik på Slideshare.

Jag har gjort en PDF på 27 sidor med mitt bakgrundstänkande som jag redovisat för Skolverket. Jag lägger ut den här, så slipper ni skriva till myndigheten och åberopa offentlighetsprincipen. Huvudsakligen så är det samma tankar och delvis samma text som jag tidigare har skrivit i den här bloggen.

Jag har också samlat alla länkar jag tycker är av intresse på min sida på Delicious (vars framtid är osäker, men än så länge ligger länkarna uppe).

Något om framtidens datorlandskap

HTML5 demos som illustrerar nya kapaciteter i webbläsarna. Mozilla har som princip att anstränga sig för att visa upp webben och inte just något som bara råkar fungera i deras webbläsare, så jag koncentrerar mig på deras demon. Motsatsen är Apple, som browser sniffar och i onödan stänger bort konkurrenterna från sina demos. Det är ett paradexempel på hur man får låga betyg enligt kunskapskraven i de nya kurserna!

Firefox 4 Web Demos: announcing Web O Wonder
Web O'Wonder demos
Mozilla Demo Studio
Wilderness Downtown (funkar bäst i Chrome)

Vad är det för nya tekniker som kommer? Allt är ju inte HTML. Mozilla har en snygg överblick.

Mozilla HTML5 and Friends Dashboard

Ubiquitous computing kan också kallas ambient computing. En demo av detta från glastillverkaren (sic!) Gorilla Glass: A day made of glass.

Resurser jag nämnde

InterACT-boken som jag är medförfattare till. Sök på Google för länkar till Bokus, AdLibris, etc.
InterACT-kurserna (kompetenstabeller och frågor.
Web Standards Project
Forum kring programmering på Dela!

Bra böcker om gränssnitt och användbarhet

Jävla Skitsystem. Följ också bloggen.
Designing Web Interfaces.
A Project Guide to UX Design.
Min vän Aarron Walter kommer skriva en bok om "Emotional Design" för webben. Till dess kan ni läsa en bra artikel av honom.

Eftersom jag inte hade något manus när jag talade om gränssnittsdesign, så ger jag här bara några få exempel på vad jag talade om.

Exempel på god interaktionsdesign

Feedly är ett bättre gränssnitt för mina nyheter på Google reader
Man kan stänga flera tabbar i följd i Chrome. Denna detalj till trots, så tycker jag dock personligen att Chrome överlag är sämre på användbarhet än Firefox.
App tabs (programflikar) + Panorama är en fantastisk grej för alla oss som har tjogtals tabbar igång samtidigt.

Begrepp jag nämnde

Programvara för kursen gränssnittsdesign

BlueGriffon är troligen det bästa alternativet till Dreamweaver som bygger på öppen källkod.
Pencil är ett verktyg för att skapa skisser och prototyper.

Material jag håller på att utarbeta

Thelin – material för kurserna Webbutveckling 1 och Webbserverprogrammering 1
Thelin – kurser i juni

Saker som jag påbörjat, men ännu inte vet hur det slutar

DVD-läromedel för gränssnittsdesign i samarbete med Moderskeppet.
Fortbildning på Högskolan Väst

P.S. Min blogg har inget kommentarfält. Använd kontaktformuläret om ni vill mig något eller adressera @itpastorn på Twitter.

Alternativ utformning av arbetsplatsförlagt lärande

gunther@keryx.se (Lars Gunther) — Sun, 07 Nov 2010 07:16:28 +0100

Mitt konsultarbete för Skolverket har under hösten gått in i en ny fas. Nu jobbar jag med utformningen av det fjärde året på Teknikprogrammet. Närmare bestämt tittar jag på IT-profilen, med en specialisering jag föreslår skall heta mjukvarudesign. I detta arbetet har jag ett mycket radikalt förslag.

OBS! På grund av min klantighet med phpMyAdmin har detta blogginläggs originlatext raderats. Jag återskapar det så gott jag kan från mina anteckningar. (Och jepp, numera använder jag phpMyAdmin som min CMS…)

Det är inte alla gymnasieskolor förunnat att ha företag på orten som jobbar inom området. Dels av denna orsak, samt av det enkla skäl att just utveckling av mjukvara är ett område som lämpar sig väl för distansarbete, så kan det vara skäl att titta på en alternativ modell.

En förebild till detta kan vara Googles Summer of Code, där universitetsstudenter får jobba med ett projekt inom öppen källkod (FOSS). Dessa projekt ligger på en avancerad högskolenivå och behöver skalas ner till svensk gymnasienivå, men de innehåller alla väsentliga delar av vad som krävs:

Konceptet är väldefinierat av Google. Medverkande parter, dvs. lärosäte, FOSS-projekt och student, har en given ram att följa.
Varje student har en erfaren handledare som kan såväl tekniken som arbetsmetodiken för det öppna källkodsprojektet.
Varje student skall skriva noggrann dokumentation av sitt arbete och redogöra för dess fortlöpande utveckling i en blogg.
Projektet skall leda till ett konkret resultat.
Alla projekt granskas och godkänns av såväl lärosäte, FOSS-projekt och Google centralt, innan arbetet får påbörjas.

Det som utmärker dessa projekt är inte bristande ambition, utan i den mån de misslyckas så beror det på att ribban lagts för högt. För svensk gymnasieskolas del, så gäller det naturligtvis att finna en lämplig ambitionsnivå, men rätt utfört behöver detta inte på något sätt vara ett andrahandsalternativ jämfört med traditionellt arbete sittandes på ett kontor.

Nationella riktlinjer kan utformas av Skolverket och bör innehålla moment som:

Eleven förväntas arbeta på regelbundna och bestämda tider, vilket kontrolleras av skolan.
Eleven skall ha en handledare från FOSS-projektet, och får inte bidra med arbete efter eget gottfinnande.
Elevens arbete skall syfta till incheckning i det officiella projektet, av tester, buggrapporter, patchar, moduler, dokumentation, etc. Eleven skall alltså inte skriva enbart på sin egen blogg eller göra arbete där projektets kod återanvänds. En elev skall inte bara använda en JQuery modul (som exempel) utan förbättra modulen.

Alla berörda parter agerar utifrån ett skrivet avtal, enligt en mall som Skolverket tillhandahåller. Alla projekt kan bli föremål för granskning av skolinspektionen eller andra myndigheter, så att kvalitén säkerställs. Däremot är det nog inte realistiskt att Skolverket granskar varje enskilt projekt.

Att tillåta medverkan i FOSS-projekt är ett avsevärt bättre alternativ till att låta eleverna driva egen firma eller jobba med helt påhittade projekt, som kan bli konsekvensen av att enskilda skolor inte lyckas tillhandahålla nog med praktikplatser, eller att de ppga. brist på praktikplatser tvingas dra ner på antalet som går utbildningen, trots att elevintresse finns.

Detta kommer att kräva att lärare på skolan tar ett aktivt ansvar för att kvalitetskontrollera FOSS-projekten och den kontakt som eleven har med sin handledare, så det är inte ett sätt för skolor att slippa jobb!

Kort politiskt mellanspel

gunther@keryx.se (Lars Gunther) — Sun, 05 Sep 2010 18:34:20 +0200

Ordinarie sändningar (om webbteknik) avbryts för en kort reflektion om valet. Varning för spydigheter!

Sällan har så mycket korkat sagts i en valrörelse:

USA skall utrymma sina baser i Tyskland, Japan och Sydkorea, och på Grönland!
Afghanistan åter till talibanerna! (Visste du förresten om att fler civila dog innan USAS:s invasion än efter?)
Barnen skall inte kunna tas om hand av sina föräldrar hemma, men gärna lämnas till en butler i tunnelbanan.
Om kvinnorna fortfarande ammar när deras kvoterade dagar är slut, ja då skall det användas bröstpump. (En bra bransch att vara verksam inom, i händelse av en rödgrön valseger…)

Jag vet inte om jag skall skratta eller gråta. Detta kommenteras nog bäst av Monthy Python:

Någon slags allvar finns det dock. Med Ohly i regeringen, så riskerar vi att se en helt ny (eller öststatsgammal) rättslig tradition införas.

Tyck till om mina kursplaner och köp min bok!

gunther@keryx.se (Lars Gunther) — Mon, 31 May 2010 16:00:18 +0200

Nu har mitt arbete publicerats mitt arbete, för Skolverket och för Interact. Kursplanerna för gy11 är ute på remiss på Skolverkets webbplats. Dessutom har boken Interact with Web Standards nu kommit ut till försäljning. Jag har skrivit ett av kapitlen och hjälpt till med ett och annat i övrigt. För någon månad sedan lades också kursen Server Side Scripting upp för Interact

Skolverksarbetet

Sedan någon vecka så finns mina ämnes- och kursplaner i webbteknik och gränssnittsdesign ute på remiss. Nu behöver jag din hjälp. Gå till diskussionsforumet, försök ignorera att dess gränssnitt är horribelt, och ge konstruktiv kritik eller uttryck ditt stöd. Det sistnämnda är minst lika viktigt. Jag förväntar mig kritik från en grupp lärare som inte fortbildat sig på flera år, utan fortfarande harvar runt i Frontpage-träsket. Av detta skäl är det jätteviktigt att du som ser värdet av standarder och tillgänglighet också uttrycker ditt stöd.

Mina vänner inom OWEA tittar också på kursplanerna. Låt mig citera ett mejl jag fått från Virginia DeBolt, som är typiskt för deras feedback.

I've looked at the courses that are under consideration in Sweden, and wanted to express my enthusiastic support for the inclusion of web standards. To be truly universal in reach, web education must include usability, accessibility and standards. If these courses are implemented in Sweden, it will make Swedish web education a leading example for other countries.

Är du intresserad av andra IT-relaterade ämnen, så tyck gärna till om dem också. Programmering diskuteras i Teknikprogrammets forum, liksom mina ämnen, och de övriga IT-ämnena diskuteras i Elprogrammets forum. Titta också gärna på digitalt skapande, som diskuteras i Estetprogrammets forum.

Interact with Web Standards

Så är jag då också författare, åtminstone till ett kapitel i boken. Jag är omåttligt stolt över resultatet. Jessi och Leslie har gjort ett helt fantastiskt jobb med designen. Innehållet är också superbt!

Boken funkar utmärkt som fortbildning inför Gy11. Kapitel 1-4 kan alla läsa, även icke-webbutvecklare. Kapitel 4 (mitt kapitel) hjälper till med ämnesmål 10 (Förståelse av hur gränssnitten finns i och påverkar vår vardag samt hur de kan användas för att förbättra den) i ämnet gränssnittsdesign och ämnesmål 1 (Kunskaper om internets historia, betydelse, terminologi och grundläggande funktionalitet) i ämnet webbteknik.

Projektmetodik (som passar båda ämnena) behandlas i kapitel 5-9. Dessa täcker dessutom kanske 50 % av stoffet för ämnet gränssnittsdesign. Kapitel 10 och framåt går igenom ungefär det man bör kunna om HTML och CSS efter kursen Webbutveckling 1.

Lärare och elever på gymnasienivå har alltså stor nytta av boken, liksom högskolestudenter på A-nivå. Men dessutom fungerar den som grund- eller uppfräschningsbok för alla som är intresserade av webbdesign eller webbutveckling. Tolle, lege!

Gy -11 webbkursernas inbördes relation

gunther@keryx.se (Lars Gunther) — Fri, 26 Feb 2010 09:13:33 +0100

I arbetet med Gy -11 så har jag föreslagit och fått respons för en kursstruktur baserad på kurser i gränssnittsdesign, (Front End) webbutveckling och webbserverprogrammering. Till detta kommer två ämnen som berörs: Digitalt skapande och programmering. Jag skall försöka reda ut hur dessa förhåller sig inbördes och hur de förhåller sig till dagens kurser. Det förslag som snart kommer ut på remiss innebär att webben ses som den huvudsakliga plattformen för all slags media. Kurserna i webbteknik kommer därför fungera som spindeln i nätet.

Relativt idag

Dagens problem

Idag finns det en kurs som heter digitalt skapande, vars innehåll enligt kursplanen är till 80 % identisk med dagens ämne multimedia. Skillnaden är mer en fråga om tradition. Digitalt skapande ligger på estetiska lärares bord, medan multimedia hamnar på IT-sidan. De enda reella skillnaderna är att multimediakursen handlar om att sammanfoga text, ljud och bild, samt att förse resultatet med ett mått av interaktivitet. Om man vill skulle man kunna säga att digitalt skapande idag utgör en delmängd av multimediakursen — så som det beskrivs i kursplanerna.

Multimediakursen å sin sida är skriven för ett tänkande runt Director eller Encarta, med CD-skivan som tänkt plattform. Dagens enda relevanta plattform är webben, även om man inte nödvändigtvis gör en traditionell webbplats. Youtube-spelaren i iPhone är exempelvis ett paradexempel på webbteknik och inget annat.

Ämnet webbdesign har jag sågat i tidigare inlägg och skall som jag skriver där delas upp i två delar, ett som fokuserar design och ett som fokuserar kod och annan teknik. Detta reflekterar verkligheten både i dagens undervisningssituation, där lärare väljer inriktning efter intresse och kompetens, och i dagens arbetsliv, där en helt ny yrkeskategori har uppstått på 2000-talet: Front End Engineer, på svenska ofta kallad gränssnittsuvecklare. Jag undviker dock det ordet i kursplanerna för att tydliggöra skillnaderna mellan de nya ämnena.

Slutligen finns det en kurs i databashantering, som i alla läromedel blir en slags fördjupad officekunskap, där eleverna slösar bort sin tid med att designa formulär och rapporter i MS Access. Jag vill renodla detta till databasutveckling, som en del av webbserverprogrammering och samtidigt öppna upp för möjligheten att titta på alternativ till traditionella relationsdatabaser.

Vägen framåt

I bilden ovan synliggörs hur ämnena i dagens gymnasium relaterar till förslagen i Gy-11. Det särskiljande för multimedia kontra digitalt skapande (sammanfogning och interaktivitet) gär till webbutvecklingskursen. Resten till digitalt skapande.

Lägg märke till att webbutveckling och webbserverprogrammering är kursnamn, inte ämnesnamn. De ryms båda under ämnet webbteknik.

Designaspekterna av multimedia och webbdesign går till gränssnittsdesign — som ju har sitt fokus på att göra attraktiva och användbara gränssnitt för just interaktion. Lägg märke till att ämnet gränssnittsdesign också är användbart för spelutveckling, gränssnitt på telefoner eller surfbrädor (slates) och annan mjukvaruutveckling.

Teknikaspekterna av multimedia och webbdesign går till i webbutveckling. Detta är spindeln i nätet-kurser, där allt skall vävas samman.

De användbara delarna av databashantering, alltså de som fokuserar databasteori, klient/server, normalisering, SQL, etc, går till webbserverprogrammering. Resten slipper framtidens gymnasieelever helt!

Ämnenas inbördes områden

Ett av våra uppdrag som ämnesexperter är att klargöra hur de olika ämnena avgränsas och skiljer sig från varandra. Nästa bild klargör detta förhoppningsvis:

Som jag nu ritar ämnena så syns också den självklara överlappningen som måste finnas.

Digitalt skapande

Detta ämne handlar om att framställa digital bild, ljud och video. Det kan utgå från något inspelat/fotograferat eller skapas helt i datorn (digitalt måleri, animering, etc). Slutprodukten är enskilda bilder, animeringar, ljudklipp, etc. Kanske kan här också ingå ljud och ljuseffekter för konserter, TV-program eller som offentlig konst.

Gränssnittsdesign

Frågor om färgteori, komposition, typsnitt och liknande kommer överlappa till digitalt skapande. Dessutom kommer man att behöva anpassa bilder, ljud och video till sin produkt, så viss redigering finns också här. Men den övergripande frågan är nu hur användaren skall interagera mot det som visas. Det som visas skall kommunicera ett budskap eller en upplevelse. Här ställs frågan om hur text skrivs för att fungera på valt medium och hur den skall sammanfogas med bild, ljud och video. Vilka widgets skall användas, vilken feedback skall användaren få på klick, knapptryck eller pek på skärmen. Det som skapas är en upplevelse och därför ingår också användbarhetstestning i ämnet.

Slutprodukten är en prototyp som ger en realistisk grund för bedömning av designen som helhet och en guide till implementering, exempelvis i form av en stilguide till webbutvecklaren. Bygger man en webbplats så är det OK att använda Dreamweaver i grafiskt läge på den här kursen.

Webbutveckling

Fyra förkortningar summerar detta ämne: (X)HTML, CSS, DOM och ECMAScript. Här skall alltså ett gränssnitt utvecklas från prototyp till användbar produkt. Här skall eleverna koda! Validerande (X)HTML, semantisk (X)HTML, effektiv CSS, icke-inkräktande (unobtrusive) DOM-skript, progressive enhancement, etc. Allt för att åstadkomma applikationer som fungerar både på pyttesmå skärmar med touch-gränssnitt och gigantiska skärmar med konventionell muspekare plus tangentbord, tillgänglighet också för blinda, sökmotoroptimering, korta nedladdningstider och minimal latens.

Här skapas inga bilder, men vi ställer frågor om hur man kan optimera dem så att de skickas så effektivt som möjligt över nätet. När är JPEG bättre än PNG? Vilka tröskelvärden skall jag ha på mina JPEG-bilder? Vilka färger skall ingå i paletten på PNG-bilderna? Är SVG eller Canvas det bättre alternativet för en viss animering?

Sedan designern valt typsnitt skall webbutvecklaren få dem att funka. Skall de vara nedladdningsbara webbfonter? Skall man använda någon ersättningsteknik?

I denna kurs skall det sväras över bristande funktionalitet i vissa webbläsare — fast MSIE 6 kommer vara död till år 2014, tack och lov.

Eftersom tekniken återverkar på designen kommer det självklart finnas viss överlappning mot gränssnittsdesignen.

Slutprodukten i detta ämne kan vara en statisk webbplats, men jag ser gärna att den är en mall för Wordpress eller en annan CMS.

Webbserverprogrammering

Hade jag fått använda engelska skulle denna kurs heta Server Side Scripting. Jag förutspår att PHP och .NET med VB kommer bli de två mest förekommande undervisningsvarianterna. JSP, Ruby on Rails, Python, JavaScript på servern, etc, är naturligtvis alternativ. I första kursen bygger eleven en enkel CMS, eller anpassar en befintlig CMS till egna önskemål. Det sistnämnda innebär inte att skriva mallar och CSS till Wordpress — det är ju Front End utvecklarens uppgift! För de lägre betygen tillåts det att eleven bygger dynamiska påhäng som kontaktformulär och gästböcker på en i övrigt statisk webbplats.

I den andra kursen skapar eleven en mer multifunktionell CMS, som helst bör erbjuda en webbtjänst eller hämta sin egen information från en sådan.

Programmering

Det förslag som nu legat ute på remiss i ämnet programmering talar om att skapa mjukvara med användbara gränssnitt. Här finns alltså en viss nödvändig överlappning.

När dessa gränssnitt skapas, så kan det mycket väl vara så att man använder deklarativ eller funktionell programmering, helt eller delvis med rena webbtekniker. Också där finns det alltså en överlappning. Likaså sker ju de mer avancerade inslagen i webbutvecklingen med hjälp av programmering. Jag tänker främst på JavaScript, men också ActionScript för Flash eller JavaFX kan dyka upp här.

(Kursen webbutveckling 2 tillåter att man fokuserar på insticksprogram, med sina skriptspråk. Även om jag är en anhängare av standarder inser jag att dessa fortfarande kommer ha sina nischer.)

Att webbserverprogrammering överlappar med det allmänna programmeringsämnet är självklart. Många moment kommer vara identiska, just för att man programmerar i båda ämnena! Skillnaden är att ämnet programmering fokuserar mer på allmän programmeringsteori, algoritmer och att den inte får fokusera på webbläsaren eller webbservern som enda körmiljö.

Den kanske mer dolda överlappningen mellan dessa två ämnen är att man i programmering 2 kan implementera ett API mot en webbtjänst, på hög nivå eller på socket-nivå.

Om detta haft mer genomarbetad webbfunktionalitet…

Så skulle jag i kursen gränssnittsdesign tittat på bilden ovan och funderat på några frågor som:

Hur kan jag göra ellipserna och deras text tydligare? Fler färger? (Nu skrevs detta för tryck från början.)
Typsnittet i ellipserna
Kanske skulle förklaringarna jag skrivit om ämnena och om överlappningarna dyka upp som en förklarande text när man klickar/pekar.
Då måste den klickbara utan markeras när muspekaren hovrar.
Och varje klickbar punkt skall kunna kommas åt via tabbtangenterna fär de som inte kan styra en mus.
Har jag nog kontrast för användare med nedsatt syn eller nog färgavstånd för alla oss färgblinda?
Vill jag att förklarande text snyggt tonar in och ut när den aktiveras?
Vill jag ha något annat bling? Kanske kan man animera bilden? Men är det något som användarna skulle uppskatta eller bara onödigt? Låt mig göra en A/B test!
Etc.

I kursen webbutveckling skulle jag ställt mig frågan hur detta skall bli verklighet på ett sätt som är optimalt:

Kan bilden vara SVG? Vad händer med MSIE-användarna? Skall de få en fallback genom en PNG-bild som funkar som en imagemap?
Hur kan jag få förklarande text att snyggt tona in och ut när den aktiveras? Kan jag använda JQuery för detta eller skall jag koda allt själv?
Och hur funkar det när JavaScript är avslaget eller blockerat?
Och hur gör jag bilden begriplig för de som ser den via talsyntes? Det lär ju inte räcka med ett alt-attribut, men kanske title-attribut på alla klickbara ytor?

I kursen webbserverprogrammering kanske jag hade gjort så att texten låg i en databas och att den kunde enkelt redigeras genom en redigeringsfunktion som endast är åtkomlig för behöriga användare.

Om jag hade en utbildning med spelutvecklingsprofil

Så skulle jag låta eleverna designa monster och andra karaktärer, landskap och byggnader i kursen digitalt skapande.

I kursen gränssnittsutveckling hade jag funderat på frågor som hur skall figurerna röra sig? (Vad är spelidén?) Skall jag styra med accelerometern eller med knappar, eller både och? Vilken fakta skall synas på skärmen hela tiden och vilken skall finnas tillgänglig med kommando och i så fall vilka kommandon?

Om spelet skall vara webbaserat så går jag vidare till kurserna inom ämnet webbteknik för att åstadkomma detta, annars så blir det en progression till det vanliga programmeringsämnet. I båda fallen kan spelen vara multiplayer och kommer då att skicka data via sockets (HTML5) eller api:er.

Hej då webbdesign!

gunther@keryx.se (Lars Gunther) — Wed, 28 Oct 2009 06:01:45 +0100

Gymnsieskolan idag har ett ämne som heter webbdesign. Ämnesnamnet leder mångas tankar till grafisk design enbart, och många läroböcker utgår fortfarande från Frontpage. Samtidigt skall eleven kunna satser, funktioner och syntax i beskrivningsspråket, vilket gör att man inte kan ignorera handkodning av HTML och CSS. Det blir mer och mer klart att detta är två delvis skilda kompetenser i yrkeslivet, att olika lärare behandlar kursen med olika innehåll och att eleverna ofta förvånas över delar av innehållet. Koppla detta till undervisning som i värsta fall inte ändrats på 10 år och vi har problem, samtidigt som datorindustrin som helhet genomgår ett paradigmskifte. Ämnet måste så i grunden ändras att kontinuiteten med dagens kurs inte är självklar. Ett första steg är att dela det i två ämnen. Med ord och filmer skall här jag försöka förklara varför och hur.

webbtekniken används alltmer till att skapa applikationer. Detta ställer två krav på kunnande som inte stod i fokus på 90-talet, när dagens kursplan skrevs. För det första måste det finnas kunnande om tekniken: HTML, CSS, JavaScript, DOM, SVG, XHR, etc. Front End utveckling måste bli ett eget ämne, med fokus på teknik. Samtidigt måste designsidan utvecklas till att omfatta såväl interaktion som utseende. Faktum är att gränsen mellan att utveckla en webbapplikation och en annan slags applikation är så upplöst att det snarare går att utveckla designämnet till att omfatta alla slags gränssnitt: Webbplatser, widgets, desktop-program, mobilprogram, TV-spel — ja, varför inte CNC-maskiner? Jag förutspår en kraftig förändring av deras gränssnitt de närmaste åren. Bort från att omständigt koda banor för verktygen, till att beskriva det slutliga utseendet och låta datorn göra resten.

Vi är också på väg in i en tid av total datorisering (ubiquitous computing, se filmer nedan), där man inte längre sitter vid datorn. Datorerna bäddas in prylar och hus och vår interaktion mot dem kommer ske utan tanke på att det är just en dator vi agerar mot. Gester och tal kommer vara självklara sätt att styra vår genomdatoriserade vardag.

Gränssnittsdesign

Jag föreslår alltså att gymnasieskolan får ett nytt ämne. Webbdesign ersätts av gränssnittsdesign, ett nytt ämne för en ny era inom datortekniken! Ämnet kommer bla. ha följande ledord:

Användbarhet: I slutändan finns det inget viktigare än att användaren kan uträtta sin uppgift, interagera på önskvärt sätt med andra användare eller finna sökt information.
Skönhet: Estetiskt tilltalande applikationer är förtroendiingivande och skapar trivsel. Undersökningar visar att en av anledningarna till att affärsapplikationer inte blir använda, utan bakom ryggen på ledningen ersatta av användarnas egna program, är att dessa är mer tilltalande estetiskt.
Tillgänglighet: Nya framsteg är ofta resultatet av forskning som ursprungligen gjordes för att hjälpa de som har funktionsnedsättningar, samtidigt kan de ironiskt nog också bli det som utestänger dessa. Man måste därför lära sig tänka på tillgängligheten från första början.

Gränssnittet omfattar såväl in-enheter som ut-enheter. Såväl Playstation 3 som Nintendo Wii hade rörelsesensorer i sina kontroller, men det var Wii som utnyttjade dem till att skapa en ny spelupplevelse, och blev den överlägset mer sålda konsollen. I fråga om funktioner låg iPhone långt efter konkurrenterna, och gör så delvis än idag, men succé blev det likväl. Tack vare att man omsatte touchskärmens möjligheter i ett användarvänligt och tilltalande gränssnitt, i stället för att bara låta den ersätta musen rakt upp och ner.

Varianter

Jag tänker mig att detta ämne skall vara oberoende av körmiljö och plattform. Gymnasieskolorna kan variera det utifrån tillgänglig lärarkompetens och skolans profil. Exempel på hur det kan genomföras:

Utveckling av prototyper till webbplatser, med hjälp av Dreamweaver, Expression Web eller liknande. (Frontpage är fortfarande förbjudet. Det skräpprogrammet kan inte användas ens för det grafisk webbdesign längre. Så föråldrat är det.)
Utveckling av gränssnitt för dataspel.
Utveckling av gränssnitt för mobiltelefonapplikationer.
Utveckling av gränssnitt för det intelligenta rummet, hemmet, fabriken eller staden.

Det kan låta på den första punkten som om dagens webbdesignämne trots allt lever kvar. Så här tänker jag mig skillnaderna, som är viktiga även om den ges enligt alternativ ett ovan:

Tydligt fokus på användbarhet och tillgänglighet. Ingendera aspekten syns i dagens kursplan.
Tydligt fokus på interaktion. Dagens kursplan talar om länkar och animeringar. Man riktigt ser framföre sig broschyrsidor med ett Flash-intro…
Klargörande om att eleven inte förväntas ta fram en fullt fungerande webbplats, utan att det måste till arbete med kod och servertekniker också. (Dessa områden täcks upp av ämnena webbutveckling och webbprogrammering, i mitt förslag. Kuserna kan naturligtvis vävas in i varandra!)
Klargörande om designelement eleven förväntas känna till och kunna använda. (Mindre snömos!)
Klargörande om att produkten skall i slutändan fungera på en mängd olika slags enheter, med skärmar som varierar i storlek från någon tum, till flera meter — tabs, pads and boards (Mark Weiser). Redan 2011 kommer det kanske vara så att fler surfar från sin telefon än från en dator.

En positiv bieffekt är att eleven befrias från kravet på att gränssnittet skall funka i alla gamla och dåliga webbläsare, för det är utvecklarens ansvar, inte designerns!

Bakgrund och inspiration

Jag har samlat på mig ett antal resurser som demonstrerar gränssnittens utveckling och betydelse, eller som beskriver övergången från dagens era (en dator per person), till morgondagens era (flera datorer per person, datorer överallt). Nedanför alla dessa filmer ger jag också fortbildningstips.

TED 2006 — världen upptäcker multitouch

Jeff Han är det största namnet inom multitouch. Här presenteras konceptet första gången för en stor publik.

Mer från Jeff Han.

iPhone lanseras

Världen får sin första revolutionerande multitouchprodukt. Kinetisk scrollning får allt annat att verka tråkigt.

Microsoft plockar upp den kastade handsken

Microsoft Surface är multitouch, multiuser, multidevice. Och produktplacerad i CSI Miami.

Mer Microsoft: Courier, en ny slags produkt som kanske kommer börja säljas år 2010.

Multitouch är redan här

I Mac OS X Snow Leopard, speciellt ihop med den magiska musen och i Windows Vista, vilket fått bl.a. Lenovo att stopp in multitouch i sina Thinkpads. Linuxentusiaster som jag skall inte vara oroliga. Det finns stöd för multitouch också i X:

Se också: Ett långt klipp (över en timme) med tekniska förklaringar om multitouch och hur det implementerats i öppen källkod.

Miniräknarens dagar är räknade

Nokia visar ett mycket bättre gränssnitt än dagens knappsatser. Sätt sedan Wolframalphas svarskraft på detta och alla elever har MVG (förlåt A menar jag) på all gymnasiematematik…

Kommer vi i framtiden behöva kurser i CAD?

Mer på samma tema. Kommer programmen vara så intuitiva att man kan koncentrera sig på själva uppgiften? SpaceClaim MultiTouch 720p är en produkt som indikerar det senare.

Luftgitarrens comeback

Guitar hero är en stor hit, men vem säger att man måste hålla något i händerna? Vem säger att vi måste röra en skärm? No touch gränssnittet är inte här ännu, men det kommer!

Denna film hittade jag på en sida som också visar hur tangentbord av idag kan samverka med touchskärmar på ett finurligt sätt. Tag gärna en titt på det med.

Jag skulle vilja berätta om augmented reality och de militära tillämpningar som mycket av detta har sitt upphov inom, men tiden räcker inte. Det får bli sitt eget blogginlägg.

Den stora bilden

En ny era är på väg, ubiquitous computing. Xerox PARC som en gång i tiden gav oss dagens GUI är också de som upptäckt detta koncept. Men bästa introduktionen får du nog av Adam Greenfield, som också pekar på farorna. Han kallar paradigmet everyware, en ordlek, bildad från orden för överallt och (hård-mjuk-)vara.

Titta gärna på denna film på Youtube, där den fortsätter igenom alla 8 delarna. Tiden det tar att titta är extremt välinvesterad!. Här kommer också slides från Rob Manson, som mer kortfattat förklarar detta under namnet pervasive computing.

Var skall detta sluta?

Det vet vi inte, men innan våra kursplaner för Gy -11 har slutat vara i bruk, så antar Microsoft att vår värld skall ta sig ut enligt följande:

Detta skrivs på kvällen den 27 oktober. Jag har nyss tittat på TV-serien Navy CIS. I den hade de väggar med multitouch skärmar, med gränssnitt mycket snarlika vad Microsoft hade i filmen ovan. Tillämpningsprogrammen som de sedan faktiskt använder (i TV-serien) är ännu science fiction, men helt klart så indikerar detta att utvecklingen är på väg.

Tillägg 5 nov: Jag har hittat denna sida med fler exempel på nya gränssnitt, inklusive att använda hela kroppen eler bara hjärnan.

Fortbildning

Denna bok kan hjälpa dig en bit på vägen: Designing Interfaces: Patterns for Effective Interaction Design.

WaSP Interact kommer till våren (2010) lansera kurser för interaktionsdesign och användbarhet. Redan nu finns det en kurs om informationsarkitektur, som är ett relaterat område. Interact har ett helt spår planerat under rubriken User Science.

Diskussion

Skolverkets diskussionsforum för Gy -11 är nu uppe. Använd Teknikprogrammets sektion.

Dessutom finns, som vanligt, följande sätt att diskutera mina tankar:

Skolverkets projektplats, för mina kollegor inom det specifika arbetet.
Fortsatt kommunikation med mina svenska och internationella referensgrupper via mejl.
En tråd startad på webForum.
Via mejl eller kontaktformuläret på denna webbplats.

Att annat sätt att hålla sig informerad är att följa mig på Twitter. Varje gång jag gör något relaterat till mitt arbete med Gy -11 så märker jag mina notiser på Twitter med hash-taggen #skolverket.