Tillbaka till start

flowweaver · Filosofi

Redaktören förväntades anpassa sig till mjukvaran

Bakgrunden

Johan Furuskog

Utvecklare, och den som står bakom Flowweaver

Jag har i flera år byggt saker som redaktörer sedan ska använda. Det som står här nedanför är ingen åsikt jag kom på vid ett skrivbord — det är mönstret jag såg återkomma, arbete efter arbete, tills jag till slut gjorde något åt det. Flowweaver är vad som blev av det.

Varför det här finns

Efter många år av att bygga lösningar för redaktörer och innehållsteam återkom ett mönster. Det var redaktören som fick ändra sig.

De lärde sig utvecklarens ord för sådant de redan förstod. De fyllde i fält som speglade en databas i stället för deras arbete. De var försiktiga med verktyget i stället för trygga i det — och försiktighet är dyrt: det betyder att ändringar som borde ta en eftermiddag får vänta på någon som inte är rädd för systemet.

Inget av det är ett tekniskt problem. Det är ett beslut, fattat tidigt och oftast utan att någon märker det, att bygga runt vad tekniken tycker är bekvämt. Flowweaver är ett försök att fatta beslutet åt andra hållet och se hur långt det bär.

Redaktören först. Sedan funktioner som gör det lätt att göra rätt. Så att du känner dig trygg när du redigerar ett flöde.

Den ordningen är hela argumentet. Trygghet är inte en funktion man lägger till på slutet — det är vad som blir kvar när det rätta är det lätta, och när verktyget säger vad det gör i stället för att låta dig upptäcka det.

Principerna, och vad som gör var och en sann

En princip ingen kan peka på är en slogan. Varje princip nedan följs av det i produkten som gör den sann — något du kan öppna och kontrollera.

Löftena, och vad som skulle bryta dem

Startsidan räknar upp vad ni får. Det här avsnittet säger något annat: vad vi har bundit oss vid, och vad som skulle göra det osant. En egenskap beskriver hur det ser ut i dag; ett åtagande säger något om i morgon, och det är bara det senare någon kan väga in i ett beslut.

Det här är inte en funktionslista, för en funktion kan tas bort en fredag. Tre ändringar skulle göra löftena osanna, och ingen av dem är en funktion:

Var och en av dem vore en ändring av vad produkten är, inte en ny funktion i den. Föreslås någon av dem ska den argumenteras som just det, i öppen dager — inte glida in i en release. Flowweaver får aldrig bli det som produkten finns för att slippa.

Provet är en enda fråga, och någon måste fortsätta ställa den: kan en kund gå härifrån med det de byggt, och använda det med något som inte är vårt? I dag är svaret ja. Det förblir ett svar bara så länge frågan ställs.

Språk är tre saker, inte en

Det här är den skarpaste skillnaden och den minst uppenbara. De flesta verktyg har en språkinställning. Flowweaver har tre, och de rör sig oberoende av varandra.

InställningVemsTill exempel
Verktygets språk värdsystemets paletten och menyerna på engelska
Guidens innehåll redaktörens och översättarens frågorna på arabiska
Vilka språk som erbjuds värdens svenska, engelska, finska, somaliska
Att översätta innehållet till ett språk får aldrig kräva att verktyget översätts till samma språk.

Det spelar roll på grund av vem det är till för. En svensk kommun i ett finskt förvaltningsområde kan vara skyldig att erbjuda en tjänst på finska. Med en enda inställning betyder det att någon måste översätta editorn först. Här betyder det att en översättare öppnar guiden och börjar skriva.

Du kan se alla tre röra sig på språksidan, som kör de riktiga anropen och skriver ut vad de gav.

Vad vi valde att inte bygga

En roadmap säger vad vi tänker göra. Det här säger hur vi tänker, vilket oftast är mer användbart.

Vart det är på väg

En lista över vad som ska byggas åldras på ett kvartal. Riktningen gör det inte, och den är det enda av de två som går att väga in i ett beslut.

Det började som en editor för guider. Samma motor ska bära e-tjänster med fler fält, villkor och kopplingar till era egna system — och editorn är byggd för att inte behöva göras om när det steget tas. Det är därför vissa saker ser överarbetade ut för en guide med fyra frågor: de är inte byggda för den.

Prioriteringen följer av var värdet sitter. Att visa en färdig guide är ett löst problem. Det svåra, och det enda som är värt något, är att en redaktör utan teknisk kunskap kan bygga ett korrekt beslutsflöde utan att skriva kod — så ett arbete som gör redaktörens dag begripligare går före ett som gör en sida vackrare. Besökarens sida har ändå ett hårt krav på sig: den ska vara liten, tillgänglig och klara sig själv, för den är det enda besökaren faktiskt laddar ned.

Målet är att vara det enklaste sättet att bygga vägledning som går att lita på, oavsett vilket publiceringssystem ni kör.

Alltså något som kopplas till system ni redan har i stället för att ersätta dem — SiteVision i dag, andra sedan — och som får vara kvar när allt runt omkring byts ut. Ett verktyg man behåller genom en plattformsupphandling är ett annat slags verktyg än ett man byter tillsammans med den.