Tema: Användaren & samhället

Hittills har du byggt för dig själv. Nu bygger du för någon annan.

Gapet mellan kod och mjukvara

Ge ett av programmen du byggt under kursen till någon som inte är programmerare, en förälder, ett yngre syskon, en kompis som aldrig öppnat en terminal. Be dem använda det.

De vet inte vad en terminal är. De vet inte att de ska navigera till en specifik mapp och skriva python main.py. De har aldrig sett en kommandoprompt och vet inte vad den förväntar sig av dem. Om de mot alla odds lyckas starta programmet och ser en rad text som frågar något, skriver de förmodligen fel på första försöket, och vet inte om de ska trycka Enter eller vänta.

Koden fungerar. Programmet är korrekt, välstrukturerat, felsäkrat och sparat. Det spelar ingen roll. Det är inte tillgängligt.

Det här gapet, mellan kod som kör och mjukvara folk faktiskt använder, är vad det här temat handlar om. Gapet stängs inte med mer Python-syntax. Det stängs med ett gränssnitt: det visuella lager som gör din kod åtkomlig för en människa som aldrig tänkt en tanke om kompilering, stackramar eller fillägen.

Hur datorn fick ett ansikte

Innan 1984 krävde alla persondatorer att användaren lärde sig ett specifikt textkommandospråk. Du ville öppna en fil? Du skrev kommandot för det. Du ville radera? Ett annat kommando. Varje fabrikat hade sin egen syntax. Det var inte intuitivt, det var inlärt, och inlärningströskeln höll de flesta människor borta.

Laboratoriet Xerox PARC i Palo Alto utvecklade under 1970-talet något radikalt annorlunda: ett gränssnitt med fönster, ikoner, en muspekare och knappar. Idén var enkel men kraftfull, representera filer som objekt du kan se och manipulera direkt, i stället för abstrakta namn du måste komma ihåg. Steve Jobs besökte PARC 1979 och förstod omedelbart vad han såg. 1984 lanserades Macintosh, den första brett tillgängliga persondatorn med ett grafiskt gränssnitt. Inte den tekniskt mest avancerade datorn vid den tidpunkten. Men den som fler människor faktiskt kunde använda.

Det grafiska gränssnittet demokratiserade datorn. Det togs ur händerna på dem som lärt sig dess hemliga språk och gavs till alla som kunde peka på något.

Windows 95 gjorde det till standard för hela världen, och sedan tog telefonen över och gick ännu längre. Där finns inget tangentbord som alltid är framme, inget filsystem att navigera i, ingen kommandorad någonstans. Du trycker på en bild och något händer. De flesta människor som lever i dag har aldrig sett en terminal, och de kommer aldrig att behöva se en.

Du har sett en. Du har dessutom lärt dig dess språk, och det gör dig till en av ganska få som står på båda sidor av det gapet. Det är precis därför du är den som kan bygga broar över det.

Gränssnittet är ett argument

Varje designbeslut i ett gränssnitt är ett påstående om vem mjukvaran är till för.

En knapp som är för liten att trycka på med ett finger hävdar att användaren är yngre än 60 och inte har nedsatt motorik. En färgkombination som är beroende av att skilja rött från grönt hävdar att användaren inte har den vanligaste formen av färgblindhet, som åtta procent av alla män har. Ett formulär som kräver för- och efternamn i separata fält hävdar att alla namnger sig på det sättet.

Dessa påståenden görs sällan medvetet. De görs när en designer eller programmerare inte aktivt tänkt på vem de bygger för. I introduktionen läste du om hur Amazon byggde ett AI-system som systematiskt diskriminerade mot kvinnor, inte för att någon programmerade in det, utan för att ingen aktivt förhindrade det. Samma mekanism verkar i gränssnitt: det du inte tänker på bygger du ändå in.

Nu när du faktiskt kan bygga saker som andra människor kan använda, inte bara skript du kör själv, är den frågan inte längre hypotetisk.

Din kod möter en riktig användare

Du får ett nytt bibliotek här, tkinter, som låter Python skapa fönster, knappar och textfält. Och du får ett designuppdrag: ta ett av programmen du byggt under kursen och gör det användbart för en människa som inte är programmerare.

Men det viktigaste som händer är inte tekniskt. Det är att du för första gången frågar dig: Vem är det här för? Vad behöver de kunna göra? Vad kan de inte förväntas veta?

Att kunna något om användbarhet och tillgänglighet är ingen dekoration ovanpå programmeringen. Det är det som avgör om någon annan än du får ut något av det du byggt, och vill du att någon ska använda det du gör har du inget val: du måste veta vem det är och vad de klarar.

De frågorna förändrar hur du skriver kod. En funktion som är elegant för dig kan vara obegriplig för din användare. En feltext som är informativ för en programmerare, ValueError: invalid literal for int() with base 10: '', är meningslös för någon som bara ville ange sin ålder. Gränssnittet är inte ett lager ovanpå koden. Det är ett löfte till den som ska använda den.

Vägen dit går genom fyra sorters ansvar, och de bygger på varandra. Att inte tappa bort det användaren gjort. Att skydda det de anförtror dig, och att veta vad du inte borde ha frågat efter från början. Att ge dem något de kan använda utan att veta vad en terminal är. Och till sist det svåraste, att faktiskt lämna ifrån sig något färdigt.

Det sista steget är kursens slutprojekt, och där lägger du undan instruktionerna. Du väljer ett av dina egna program, bestämmer vem det är för och gör det till något den personen kan öppna och använda. Ingen talar om för dig hur.

Att bygga för någon annan än dig själv är den röda tråden i det här temat.