En grensesnittsprogrammerer er en som behersker webstandarder så som (X)HTML, CSS og WCAG og som jobber med å implementere brukergrensesnitt med nevnte teknologier samt Javascript, og kanskje også noe av “view”-delen av serverside-kode (JSP, PHP, ASP.NET osv). Hvordan kan en slik ressurs hjelpe ditt prosjekt?
Desverre har ikke alle nettprosjekter en eller flere personer hvis eneste oppgave er å jobbe med grensesnittet og dermed liggder denne oppgaven ofte på designere eller utviklere. Dette viser seg igjen og igjen å ikke være helt heldig; en uformell undersøkelse utført av Eirik Hafver Rønjum viser at det er et stort sprik mellom hva “kommunikatører” (webredaktører, konsulenter/rådgivere, ledere og webmastere) forventer av kunnskap om grensesnittsutvikling hos utviklere, og hva utviklerne faktisk kan.
Rønjum slår også fast at kommunikatørene selv har lav kompetanse om grensesnittsteknologier. Han tar dermed opp problemstillingen; “Det er uklart hvem som har og hvem som bør ha kompetansen”. Selv ser jeg også problemet med at de som kjøper tjenestene ikke har kunnskap om dem, og dermed ikke har mulighet til å kvalitetssikre leveranser.
Jeg skal ikke forsøke å svare på hvem som skal stille med kompetansen (kunden selv eller leverandøren av enten teknisk løsning eller design), men jeg vil påstå at det er et skrikende behov for en eller flere personer i ethvert seriøst webprosjekt som har ansvar for grensesnittsutviklingen, og bare den. En slik person bør ha sterk kompetanse på (X)HTML, CSS, Javascript (dersom nødvendig, dette er situasjonsavhengig), og ideelt sett ha noe teknisk kompetanse, og en viss forståelse av designprosessen eller kompetanse også på design/interaksjonsdesign.
Med en slik person i prosjektet har du ikke bare en ressurs som gjør sitt for at grensesnittet skal bli så bra, tilgjengelig og søkemotorvennlig som mulig, men også en glimrende mulighet til å hjelpe samarbeidet mellom designere og utviklere.
Ved å ta grensesnittsutviklere inn i prosjektet på et tidlig stadium er det mulig å gi utviklerne en sjanse til å ligge litt foran. Med semantisk HTML som grunnleggende dokumentstruktur kan man tidlig begynne å utvikle skjermbilder, selvom designet ikke er klart. Så fort wireframes, eller andre konseptuelle skisser foreligger kan
grensesnittsutvikleren lage skjermbilder av disse som utviklerne i sin tur kan begynne å jobbe med (slik jeg tidligere har gjort blant annet på Storebrand).
En slik måte å jobbe på er spesielt nyttig for tjenester som skal berikes med mye Javascript-funksjonalitet ettersom den type funksjonalitet ofte lett kan utvikles uavhengig av det endelige designet. AJAX-funksjonalitet kan også bygges opp i samarbeid mellom grensesnittsprogrammereren og utviklerne.
Designere (inkludert interaksjonsdesignere) vil også dra nytte av en slik ressurs ettersom de kan konsentrere seg helt og holdent om designet, og ikke vil trenge like tett samarbeid med utviklerne. Det er ikke nødvendigvis et poeng at designere ikke skal ha kontakt med utviklere (jeg tror tvert imot at en sånn situasjon ville skade prosjektet), men designerne kan kanskje lettere komme i kontakt med utviklerne gjennom en grensesnittsprogrammerer som kanskje har mer til felles med dem, samtidig som grensesnittsprogrammereren også sannsynligvis har lettere for å
kommunisere effektivt med utviklere.
Grensesnittsprogrammerere kan altså hjelpe ditt prosjekt ved å gi alle involverte klarere definerte oppgaver ved å ta en diffus oppgave som ofte er vanskelig å ansvarsbestemme. I tillegg kan er det muligheter for gevinster på kommunikasjonsfronten og samarbeid mellom ledere, designere og utviklere.
Tips: Dataforeningen har i oktober et kurs i utvikling for kommunikatører, dette anbefales på det varmeste!
3 kommentarer til "Grensesnittsprogrammererens rolle"
Meget gode poenger. Det er ikke tvil at dersom en blander for mange roller får en et dårligere produkt, enn dersom en har tilgang til spesialister innenfor hvert av feltene. Som i samfunnet for øvrig…de færreste ringer til en snekker dersom de har behov for en elektriker, selv om både snekkeren og elektrikeren utfører arbeid i bygninger.
Egen erfaring tilsier også at en bør benytte back-end utviklere for å jobbe med back-end systemer, og ha egne utviklere – de du kaller grensesnittprogrammerere – som tar seg av visningslaget. Det er et must at grensesnittprogrammere har en god forståelse av hva som gjør visningslaget bra, noe en ikke nødvendigvis kan forvente seg av back-end utviklere — som skal være gode på sitt felt og gjerne har en begrenset interesse for webstandarder.
Absolutt. Men jeg har også jobbet i prosjekter der systemutviklerne ikke har god kjennskap til webstandarder men alikevel har ansvaret for visningslaget.
Dette har vært mulig å gjennomføre med suksess fordi jeg eller andre som “grensesnittsprogrammerer” har kunnet gå inn å ta seg av det som har med HTML osv å gjøre uten at man har fullstendig ansvar for hele visningslaget. Med å “gå inn” mener jeg da å i tillegg til å produsere HTML-malverk, implementere/rette på dette i JSP, ASP osv.
[...] teknisk feil, så kan det også føre til at nettstedet ditt laster tregt. Hvis du har slurvet med grensesnittsprogrammeringen, så kan det påvirke hvordan nettsidene dine laster ned. En slurvete oppbygd nettside går også [...]