Hoppa till innehållet

InPublix

Byråns SaaS-plattform för digitala årsredovisningar, som jag initierade och ägde i helhet i mer än tio år.

Byrån behövde flytta årsredovisningarna från tryck till webben, och PDF-korrekturen var flaskhalsen. Jag initierade InPublix för att lösa det och ägde plattformen i helhet, från krav till support. Kunder som Peab har tagit fram sina rapporter i den sedan 2016.

Börsnoterade, statligt ägda och kommunalt ägda bolag har förlitat sig på den för års-, kvartals- och hållbarhetsredovisningar: affärskritiska leveranser med lagkrav och fasta deadlines. Plattformen byggde jag tekniskt, men rapporterna var alltid ett lagarbete, där jag var experten på teknik och produktion.

  • Mer än tio år i oavbruten drift med betalande kunder, flera relationer som sträcker sig över ett decennium
  • De flesta förmågorna växte fram ur kundarbetet och fördes sedan tillbaka in i den gemensamma plattformen, till nytta för alla
  • Ägde hela produkten: arkitektur, utveckling, hosting, säkerhet, support och utbildning, och tog fram avtal och säljmaterial tillsammans med teamet

Kommunikation & UX

Användare, innehåll och kommunikation

För redaktörerna

De flesta som arbetar i InPublix är redaktörer, korrekturläsare och rapportteam, inte utvecklare. Med åren formades plattformen kring deras arbete: tvåspråkiga tabeller där redaktören ser vilka rader och kolumner som visas på respektive språk, PDF-mallar som byggs med dra och släpp, korrektur direkt i webbversionen, spårade ändringar mellan versioner och en Excel-import som behåller formateringen.

Förbättringarna kom delvis från uttalade önskemål, men ofta från samtal med kunderna och från att flera personer fastnade på samma ställe.

För kundernas uttryck

Varje kund har sin egen visuella identitet, men plattformen är en kodbas. I stället för ny kod per kund erbjuder editorn kombinerbara format (till exempel H1 + liten, eller Knapp + intern) och en färgpalett som definieras en gång per projekt i Customizer. En ändrad färgdefinition når alla moduler utan kodning. Grunddesignen för varje rapport kom från AD:erna, och min del var att göra den byggbar och konfigurerbar.

För nya kunder

Vid en senare uppdatering av plattformen, 2022–2023, tog jag fram Figma-skisser för grunden i InPublix: olika navigationssystem, grundläggande rubriknivåer och färgschema. Menyer och hela gränssnittet gjordes som komponenter, så att de enkelt kunde uppdateras på alla sidor när en ny kund kom in. Syftet var att göra processen enklare och knyta designen till den färdiga koden, med samma navigation, gränssnitt, moduler, typsnitt och färgschema i båda. Filerna finns inte tillgängliga att visa här.

För läsarna

Det tydligaste UX-beslutet är navigeringen, och den har vuxit fram i tre steg.

Problemet. En årsredovisning läses på två sätt. En del läsare går igenom den från början, som en tryckt rapport. Andra letar efter en viss siffra eller ett visst avsnitt och vill dit direkt.

Grundlösningen. Därför fick varje rapport en början och ett slut, med bläddring mellan sidorna i ordning, kombinerat med en översiktsmeny för den som letar efter en viss sida.

Ett alternativ när förutsättningarna ändrades. Beckers Groups hållbarhetsredovisning hade färre sidor och en kund som delvis inte ville bläddra. Det öppnade för en navigering där bilder och länkar ligger direkt i menyn och läsaren rör sig via toppmenyn och sidorna själva. Skisserna gjordes tillsammans med AD. Varianten blev ett val för alla rapporter på plattformen, som slås på i inställningarna i stället för att byggas som en engångslösning.

Utvärdering och justering. Kollegor på byrån som inte ingick i projektgruppen fick gå igenom rapporten och svara på vad de tyckte och hur den fungerade. Det var en enkel intern genomgång, inte ett uppgiftsbaserat användartest. Den visade att det var otydligt vad som var en story, och det förtydligades i nästa version.

Tillgänglighet. För LKF, som är ett kommunalt bolag, byggdes ett tillgänglighetsläge för navigeringen med skip-länk, tangentbordsnavigering och tydligt fokus. Det slås också på per rapport. Exemplet visas under LKF bland projekten.

Process

Hur arbetet gick till

Från ett produktionsproblem till en produkt

InPublix startade på Bysted som svar på ett konkret affärs- och produktionsbehov: förflyttningen mot finansiell kommunikation och helt digitala rapporter. Den öppnade också för merförsäljning. Plattformen har varit i drift sedan 2014 och fortsatte under Hallvarsson & Halvarsson, där den främst förvaltades, med fokus på stabil och säker drift för befintliga rapportkunder.

Utveckling i två spår

Utvecklingen gick alltid i två spår. Det ena var reaktivt: specifika kunddeadlines och önskemål. Det andra var proaktivt: funktioner jag förde in i färdplanen innan behovet uppstod, utifrån mönster jag såg hos kunderna. Diagramgeneratorn och de tvåspråkiga tabellerna formades till exempel av år av nära arbete med Peabs rapportteam, och fördes sedan tillbaka in i den gemensamma plattformen.

Arbetet med projektteamen

Struktur, moduler och användarflöden togs fram i workshops med AD:er och projektledare. I kundprojekten gav jag råd om hur man arbetar med digital rapportering, ofta i kombination med tryckta PDF-rapporter, och föreslog nya lösningar när de befintliga inte räckte, från säljdialogen och uppföljningen till utveckling och support.

Teknik

Arkitektur och förmågor

Arkitekturprinciper

  • En kodbas i WordPress multisite som betjänar många kunder, där varje rapport är en publikation med eget tema och egna behörigheter
  • Ett återanvändbart modulbibliotek (tvåspråkiga tabeller, diagram, trycktmallar) som delas med systerprojektet Dbase, i stället för engångsbyggen per kund
  • Tryckversionen genereras från samma HTML-källa som webbvyn, så det finns ingen parallell PDF-mall att förvalta

Förmågor

  • Behörighetsstyrning per publikation med separata läs- och skrivnivåer, som kan slås av och på per rapport
  • Konfigurerbara trycktmallar: sidurval och ordning sparas per språk, med flera mallar per rapport
  • Flöde till och från InDesign för korrektur: HTML förbehandlas och konverteras via Pandoc till Word, och egna InDesign-skript lägger på formaten vid importen, med spårade ändringar för redaktörerna
  • /print-all: ett tryck som genereras direkt från strukturen, utan att en trycktmall behöver byggas
  • Behörighetsstyrning och tidig tvåfaktorsautentisering, så att ingen kommer åt en rapport innan den är publicerad

Diagram

  • Ett separat WordPress-tillägg som jag byggde för InPublix och vidareutvecklade löpande tillsammans med Peab
  • Varje diagram har en egen datatabell och egna inställningar för diagramtyp, färger, staplar, förklaringar och så vidare, så att redaktörerna ändrar ett diagram utan kod
  • Ritas dynamiskt med Highcharts, på webben och i den PDF som genereras från samma sida
  • Samma diagramkod återanvändes senare i Dbase

Språkversioner

  • Rapporterna publiceras på svenska och engelska, och WPML hanterar språkversionerna
  • Översättningen går via WPML:s export och import av XLIFF: innehållet går ut till översättarna som XLIFF-filer och kommer tillbaka in i rapporten som den andra språkversionen
  • Varje sida är kopplad till sin motsvarighet på det andra språket, så att språkväxlingen leder till samma sida i stället för till startsidan, och sökmotorerna får språkalternativen
  • Trycktmallarna sparas per språk, och de tvåspråkiga tabellerna formaterar siffrorna per språk, så att båda versionerna kan tryckas och korrekturläsas var för sig

Designbeslut

Vad Varför Lösning
Behörighetsstyrning Ingen standardlösning i WordPress klarade gruppbaserade behörigheter per publikation i ett multisite-nätverk Ett färdigt medlemstillägg kombinerat med egna Hooks/Actions
Generering av tryck-PDF Tidiga versioner speglade webbstrukturen 1:1, vilket förstörde tryckets layout En egenbyggd tryckmotor: sidväljare + sparade mallar → HTML → webbläsarens utskrift till PDF
Tvåspråkig sifferformatering Att för hand förvalta formaterade siffror per språk skalade inte Siffrorna matas in en gång och formateras automatiskt per språk vid rendering och export