Nettside for borettslag som styret kan drive selv.
Et borettslag trenger tre ting av en nettside: at dokumentene lar seg åpne, at nyheter kan legges ut uten en utvikler, og at fellesutstyret kan bookes uten at noen fører liste. Alt annet er pynt.
Hva et borettslag faktisk trenger
Dokumentene, og de må åpne seg. Vedtekter, husordensregler og søknadsskjemaer er grunnen folk kommer. En beboer som skal søke om å bygge terrasse leter ikke etter en nyhet, hun leter etter ett skjema.
Nyheter styret legger ut selv. Et infoskriv som må innom en utvikler blir ikke lagt ut. Da havner det i en gruppe på et sosialt nettverk i stedet, og en side ingen oppdaterer slutter folk å besøke.
Booking av det som deles. Tilhenger, festlokale, vaskeri. Uten et system er det en tråd, og en tråd er ingen oversikt.
Og én adresse som overlever et styrebytte. Et styre sitter i noen år av gangen. Nettstedet skal ikke tilhøre en person.
Hva som er vanskelig akkurat her
Et borettslag har ingen driftsavdeling, og det er hele forskjellen fra et vanlig kundeoppdrag.
Passordet er problemet, ikke løsningen. Det er ingen som administrerer brukere. Et delt passord som skal vare i fire år sirkulerer i en e-posttråd, og et passordfelt i frontend-koden er ingen sperre i det hele tatt: hvem som helst kan lese det i nettleseren.
Alle skal kunne bruke det som deles, men ingen skal måtte ha en konto. En nabo som vil booke tilhengeren i tolv minutter kommer ikke til å opprette en bruker. Krever du det, blir tilhengeren booket i en meldingstråd igjen.
Det som legges ut, blir liggende. Et infoskriv fra i fjor som fortsatt står øverst sier mer om laget enn innholdet gjør.
Og dokumentlenker råtner stille. Ingen får en feilmelding når en lenke slutter å virke. Beboeren finner bare ikke det hun leter etter, og ringer styret i stedet.
Hvordan grensene settes
To avgjørelser gjør resten enkel, og begge handler om hvor en regel bor.
Innlogging uten en konto å administrere. En engangslenke sendt til en adresse som står på en liste er en innlogging ingen kan glemme passordet til, ingen kan dele videre, og ingen må opprette. Lista er styrets adresser, og den endres når styret endres.
Tilgang som ligger i databasen. Skal en nabo kunne slette sin egen booking og ingen andres, kan ikke den regelen bo i grensesnittet: en tilgangsregel som bare finnes i frontend er en anbefaling, og den kan leses og omgås av hvem som helst med en nettleser. Ligger den på radnivå i databasen, er den en grense uansett hvem som spør og hvordan.
Det er den samme regelen studioet bruker overalt ellers, og den er grunnen til at et borettslag kan la naboer røre data uten å ansette noen til å passe på det.
Prosjektet som bevis
Varingskollen Borettslag er et kundeoppdrag. Setningene under er registerets egne, hentet fra prosjektlista og ikke skrevet om for denne sida.
Dokumentlenkene til vedtekter, husordensregler og søknadsskjemaer pekte på ingenting. Nyhetene lå i nettleserens eget minne, bak et passordfelt i frontend-koden. Fellestilhengeren hadde ingen bookingløsning.
Jeg portet siden til Next.js og bygde styreverktøyet: innlogging med engangslenke, låst til styrets fem adresser, adminpanel for nyheter og infoskriv, og tilhengerbooking mot en database med sikkerhet på radnivå, der naboen sletter sin egen booking med en nøkkel i stedet for å måtte logge inn. Forholdene øverst på siden hentes fra tre kilder: Fnugg gir heiser, løyper og snødybde, MET gir varselet, og Frost gir målingene fra stasjonen. Fnuggs betingelser krever at krediteringen står sammen med dataen, så den rendres bare på siden som viser forholdene, og forsvinner hvis en kilde er nede.
Databaselaget er bygget, men venter på at styret slår det på.
Legg merke til at ingenting av dette er et resultattall. Studioet fører ikke trafikk, tidsbruk eller besparelser på dette nettstedet, for noe prosjekt.
Veien videre
Kartleggingen er gratis, og den er en samtale om hva laget faktisk trenger framfor en gjennomgang av hva en side kan inneholde. Tilbud etterpå, skriftlig.
Book kartlegging