User Interface Programming

August 2000

God ettermiddag.

Årsmøtekomiteen har bestemt at alle må møte friske og uthvilte på Geilo. Derfor har man altså plassert foredragsholdere i bussene, sånn at det skal bli god anledning til å sove underveis. Bare len dere godt tilbake i stolen, så skal jeg gjøre det jeg kan for at dere kan slumre fredelig inn.

Som noen kanskje vet, så har jeg utgitt en bok som heter «Programming Industrial Strength Windows,» og jeg er blitt bedt om å si noen ord om prosessen rundt det å få publisert artikler i blader, om hvordan det er å skrive en bok, om hva det egent­lig innebærer å skrive en bok.

I tillegg til å skrive denne boka har jeg gjennom en del år skre­vet artikler for et prog­rammerings-blad som heter Win­dows De­vel­oper Maga­zine, eller WDM. Det siste året har jeg gledet spesielt interesserte med en fast, månedlig spalte i bladet. Den heter «User Interface Programming»; det er kanskje ingen stor bombe at den hand­ler om brukergrensesnittprogrammering, eller gruperbremsesnitt, som noen liker å kalle det.

Men egentlig så har jeg mest lyst til å snakke om selve skrivingen—det å set­te de riktige ordene ned på et papir i riktig rekkefølge. For å være helt sikker på at alle sov­ner, skal jeg snakke om begge deler—først litt om publisering, og et­terpå noen praktiske tips for å skrive bedre, og forhåpentligvis litt inspirasjon til å synes at det faktisk er bryet verdt å skrive bedre. For at vi skal få tid til det hele vil denne bussen kjøre om Åndalsnes.

Det arket dere har fått utdelt er en liten souvenir som dere kan ta med hjem og kose dere med—fin å ha hvis det er vanskelig å få sove om kvelden. Jeg skal kom­me inn på litt av det som står der et­ter­hvert, så ikke pakk det bort riktig enda.

Tittelen på foredraget—Language Made Plain—har jeg stjålet fra en bok av Ant­ho­ny Bur­gess. Han er kanskje mest kjent for romanen A Clockwork Orange, som ble filmatisert av Stanley Kubrick. Han var en meget språkmektig mann. Og ikke bare kunne han en lang rekke språk, han kunne også en hel masse om språk. Boken Lan­guage Made Plain beskriver sammenhenger og slektskap mellom forskjellige språk på en meget lettlest og underholdende måte.

Del 1: Om publisering

Publisering av artikler

Det første spørsmålet er: Hva skal du skrive om? Finn noe du er interessert i, noe du kan, noe du bryr deg om. Jeg er for eksempel opptatt av programmering, og da er det naturlig å skrive for et programmeringsblad.

Det beste er å skrive for et blad du pleier å lese selv—da er du kjent med stilen, du er kjent med inn­hol­det, du er sannsynligvis interessert i inn­hol­det og du har en ide om hvem som er interessert i å lese det du skriver.

Det er best å begynne i det små—skrive et leserbrev, for eksempel. I Win­dows De­vel­oper Maga­zine finnes en egen spalte som heter Tech Tips, der lesernes egne små tips kommer på trykk. Det første jeg skrev for Win­dows De­vel­oper Maga­zine var et sånt Tech Tip. Selv om det ikke var så langt, hadde jeg stor glede av å se teks­ten og navnet mitt på trykk. Dessuten fikk jeg femti dollar for det, nok til flere øl.

Hva om du vil skrive en større ar­tik­kel?

• En mulighet er å skrive ar­tik­kel­en og sende den inn.
• Men de fleste redaktører vil helst ha et utkast—et forslag. Et sånt forslag be­står av et eller to avsnitt om hva du har tenkt å skrive om, og hvorfor det er interessant for leserne. Forslaget bør være så konkret som mulig.
• Men hvorfor vil redaktøren helst ha et forslag? For det første er det fort gjort for redaktøren å vurdere et forslag. Det å vurdere et helt manuskript tar mye lenger tid, så sjansen er stor for at det blir lagt til side til redaktøren får en lengre bolk med tid ledig.
• Og det kan bli lenge til.
• For det andre kan det være at redaktøren ikke liker forslaget. Siden det ligger ganske mye arbeid bak en ar­tik­kel, er det dumt å skrive en til ingen nytte. For­delen for redaktøren er at han slipper å vurdere en ar­tik­kel han allikevel ikke kommer til å kjøpe.
• Hva er et godt forslag? Et forslag er ikke godt bare fordi det blir akseptert på forslagsstadiet. Et forslag er godt der­som det til syvende og sist fører til en solgt ar­tik­kel. Forslaget må være så konkret og klart at redaktøren skjønner hva du har i tankene. Hvis han ikke skjønner det, ber han deg kanskje skrive ar­tik­kel­en—for å finne ut hva du har tenkt. Det betyr ikke at han kjøper den.

Et godt forslag lar redaktøren avgjøre der og da hvorvidt han kommer til å kjøpe den ferdige ar­tik­kel­en.

Noen vil kanskje tro det er en god ide å sende et forslag eller en ferdig ar­tik­kel til flere blad samtidig. Det virker kanskje lurt, men i det øyeblikk et blad bestemmer seg for å kjøpe blir du nødt til å fortelle alle de andre at ar­tik­kel­en ikke lenger er til salgs. Og du kan være bra sikker på at ingen av disse gidder å kikke på den neste ar­tik­kel­en du sender dem.

Redaktørens jobb er å redigere. Enten du liker det eller ikke, betyr det at han eller hun kommer til å endre teksten din, legge til noe, fjerne noe, kanskje endre den til det ugjenkjennelige. Der­som det ikke er akseptabelt for deg, er sjansene for pub­li­sering meget, meget små.

Men du skal være glad for at ar­tik­kel­en redigeres. Retting av det som er direkte feil er kanskje den mest opplagte.

Men det største problemet er at når du har skre­vet en ar­tik­kel er du ikke lenger i stand til å lese den på samme måte som andre lesere. Din vurderingsevne blir da lite verdt. En redaktør ser på ar­tik­kel­en med nye øyne. Du kan til en viss grad opp­nå samme effekt ved å legge ar­tik­kel­en til side; effekten blir bedre jo lenger den blir liggende.

Redaktøren vil ofte endre tittelen og skrive om innledningen for å være sikker på at den dra le­se­ren inn i ar­tik­kel­en—alt for mange skriver artikler som om de var de­tek­tiv­his­to­ri­er, og avslører ikke poenget før i det siste avsnittet. Dit er det desverre ingen lesere som kommer.

En dårlig skre­vet ar­tik­kel kan bli akseptert allikevel der­som det tekniske inn­hol­det er bra. Redaktøren kan skrive, og fikser gjerne ar­tik­kel­en slik at den blir leselig—der­som inn­hol­det gjør det bryet verdt.

Hvis du nå har fått solgt en ar­tik­kel, så vil du før bladet går i trykken få en siste sjanse til å se gjennom det ferdige produktet og ret­te opp eventuelle feil—sta­ve­feil, gale kryss­referanser og den­slags. Hvis du forlanger store endringer på det­te stadiet blir redaktøren meget lite blid.

Når bladet omsider er trykt får du betaling. Den er ikke så mye å skryte av. Noen hundre dollar for en ar­tik­kel er normalt, og da blir ikke timeprisen rare greiene—det ligger som regel mange timers arbeid bak en ar­tik­kel.

Men du får en belønning utover pengene når du står med bladet i hånden, økt selvfølelse og noe nytt og sexy å føre på CV-en din.

Fast spalte

Jeg skriver en fast spalte for WDJ. Det er i og for seg ikke så veldig forskjellig fra å skrive mange artikler på rad, bortsett fra at jeg må forholde meg til en deadline hver måned.

Det morsomste resultatet av den spalten opplevde jeg i San Jose i våres, da jeg var jeg på en konferanse som het «Software Development.» Normal adgangspris var to tusen dollar, men i egenskap av spaltist ble jeg tildelt pressekort, med gratis ad­gang og dessuten tilgang til presserommet, der de hadde Internett-PC-er og gratis kaffe døgnet rundt.

Å utgi en bok

Under arbeidet med boka mi formulerte jeg det som jeg i all beskjedenhet har tenkt å kalle Hesselbergs lov: «Å skrive en bok er en mye større jobb enn du tror.» Et­ter­hvert som jeg jobbet med boka, kom jeg frem til at Hesselbergs lov er gyldig selv om du tar Hesselbergs lov med i betraktningen.

Heldigvis hadde ikke kona mi kjennskap til Hesselbergs lov da jeg begynte, ellers had­de det vel aldri blitt noen bok.

Lag et forslag: Kort beskrivelse av hva og hvorfor, hvem er målgruppen, hva skiller boken fra konkurrentene. Lag et utkast til innholdsfortegnelse, og ta gjerne med et eksempel-kapittel.

Der­som forlaget liker boken, begynner kontrakts­diskusjonen. Hvor stort forskudd kan du få. Hvordan skal forskuddet utbetales? Du kan få en del av det ved kont­rakts­sig­ne­ring, en ny bit ved le­ve­ring av halvferdig manuskript, en bit til ved le­ve­ring av ferdig manuskript, resten når boka er trykkeklar. For eksempel.

Hvilket format skal manuskriptet ha, når er deadline. Deadline er ikke like absolutt som for et blad. Om en bok blir forsinket er det ikke nødvendigvis noen katastrofe, men et blad må komme ut til fastsatt dato hver måned.

Forskuddet trekkes fra ved utbetaling av royalties. Det betyr at du ikke får utbetalt royalties før forskuddet er nedbetalt.

Skaff deg så stort forskudd som mulig—det er bedre å få pengene nå enn siden, og der­som forlaget har investert i et stort forskudd får de et større insentiv til å selge boken.

Få forlaget til å sende deg en bok mest mulig lik den du skal skrive. Jeg gjorde ikke det, og visste for eksempel ikke at hvert kapittel kom til å begynne midt på siden, ikke på toppen. Mange av ka­pit­lene mine begynner med et kort avsnitt et­ter­fulgt av en figur, med det resultat at det korte avsnittet ble stående alene midt på ka­pit­lets forside, og figuren ble skjøvet over på neste side.

Du kan ikke regne med å få gjøre layouten selv, men en del innflytelse vil du kunne få.

Teksten skal gjennom tre forskjellige redigeringsprosesser.

Først er det teknisk redaktør, en fagperson som sjekker det tekniske inn­hol­det. Den tekniske redaktøren finner (forhåpentligvis) det som måtte være av faktiske feil. Der­som han misforstår noe—det hendte med meg—skyldes det antageligvis at frem­stillingen er for dårlig, og du kan skrive om. Litt mail med forskjellige versjoner må du regne med.

Etter at du har levert det «endelige» manuskriptet vil en redaktør se på språk og struktur, ret­ter feil, stiller spørsmål ved det vedkommende ikke forstår, og så vi­de­re.

På galley-stadiet er sidene lagt ut slik som de skal bli. Nå vil både du og en fra forlaget gjøre en siste sjekk for trykkfeil, manglende ord og linjer, riktige kryss­referanser, at stikk­ord­regis­ter og inn­holds­for­teg­nel­se er rik­tig, et cetera.

Til syvende og sist går boken til trykking, og ikke lenge et­ter står du med boken i hånden, økt selvfølelse og noe nytt og sexy å føre på CV-en din.

Er du heldig blir det inntekter av det også, men jeg vil ikke anbefale noen å ta store økonomiske sjanser på det grunnlaget.

Markedsføring

Markedsføring: Forlaget selger til bokhandlere. Markedssjefen i forlaget ba meg om gode ar­gu­men­ter for at folk skulle kjøpe boken; blant annet ville han gjerne ha ar­gu­men­ter som kunne brukes overfor en mor som skulle kjøpe gave til sin pro­g­ram­merende sønn. Jeg trodde det var en spøk, men det var det fak­tisk ikke. De fleste bok­hand­lere er ikke pro­g­ram­merere, og tar gjerne inn bøker basert på denslags ar­gu­men­ter.

Markedsføring: Computerworld skrev en ar­tik­kel. Der stod det at jeg had­de skre­vet en bok som het «Pro­gram­ming Industrial Strength» som hand­let om fil­be­hand­ling (ikke feil­be­hand­ling). Det sto også at jeg har verdensrekorden i hekke­løp og at boken var en best­selger. Alt ble i grun­nen galt, men tross alt i en venn­lig­sin­net tone.

Det er ganske pus­sig, men hver gang jeg leser i pres­sen om en sak som jeg fak­tisk kjen­ner til, er det meste som står der bare vås. Det har ført til at jeg ikke tror på alt som står i avisene.

Markedsføring: Akademika bokhandel har noe de kaller «Akademisk friminutt» an­nen­hver torsdag. Som regel kommer det en forfatter som forteller om boken sin en halvtimes tid.

Da jeg møtte opp hadde de stilt opp stoler og lagt frem bøker; de hadde satt frem kaffe og de hadde laget plakater der det sto, «møt en som kan alt.»

Det eneste problemet var at det ikke fantes en eneste tilhører, selv om jeg faktisk hadde fått Computerworld til å nevne det, og de til og med hadde klart å stave datoen riktig.

Etter et kvarter, da vi så smått begynte å tenke på å pakke sammen, kom det faktisk en informatikk-student. Han var bare interessert i å snakke om Java og kjøpte ingen bok, men jeg fikk i alle fall med meg navnet hans og ga det til Bjørn Schulstock, så noe godt kom det jo utav det. Kanskje han ender opp som Acc­en­t­ure-konsulent når han er ferdig.

Robert Heinlein’s Rules of Writing

Øverst til venstre på det arket jeg har delt ut finner dere Robert Heinleins skrive­reg­ler. De opp­sum­merer en del vesentlige punkter rundt det å skrive for publisering. Selv har jeg et personlig forhold til regel num­mer en [du må skrive]—jeg gikk med boken i magen ganske lenge før jeg nevnte det for noen.

Det blir hverken bøker eller artikler av å tenke, ei heller av å snakke. For å skrive må man set­te ord i rekkefølge på et papir. Eller en data­skjerm.

Del 2: Om skriving

Det første spørsmålet vi må stille er:

«Hvorfor skriver vi?»

Vi skriver for å kommunisere. Vi skriver for at noen skal lære noe de ikke visste fra før, vi skriver fordi vi vil at noen skal gjøre et eller annet, eller vi skriver fordi vi vil at noen skal føle et eller annet. Som for eksempel entusiasme for eUnits.

I vår jobb bruker vi mye av arbeidsdagen enten på å skrive eller på å lese det som noen andre har skre­vet. Enten vi skriver en ar­tik­kel, et brev, et møtereferat, en brukerhåndbok eller en pro­sjekt­rap­port, så er det mye å hente på å skrive—det vil si kommunisere—best mulig.

Det er to ting jeg har lyst til å snakke litt om—det ene er strukturering av det vi skriver, på et litt overordnet plan; det andre er bruk av ord, det vi kaller språkføring, på et mer detaljert plan.

OK, strukturering først. Det er to ting du må ha klart for deg før du begynner å skrive. Hvem det er som skal lese det, og hva budskapet ditt er.

Husk at din jobb som skribent er å hjelpe le­se­ren til å forstå, ikke å imponere le­se­ren med alt du vet og hvor flink du er. Det er le­se­rens behov som skal dekkes, ikke dine.

Vi som er konsulenter synder mye mot det; vi snakker og skriver et språk som klienten ikke forstår, og bruker begreper som klienten egentlig gir blanke i.

I tillegg til å plass­ere deg selv i le­se­ren sine sko må du vite hva budskapet er. Det skrives utrolig mye ull fordi budskapet er uklart selv for den som skriver. Det skrives også mye ull fordi den som skriver er opptatt av formulering og struktur—på be­kost­ning av bud­skapet. Der­som du klarer å fokusere på budskapet mens du skriver vil resten ofte gå av seg selv.

Når jeg skriver den månedlige spalten min har jeg tre mål for øyet:

1. Le­se­ren skal lære noe nytt og interes­sant—for eksempel en ny pro­g­ram­merings­teknikk, eller noe nytt om hvordan Win­dows fungerer.
2. Le­se­ren skal få et stykke nyttig, gjenbrukbar kode til å plugge inn i sine egne programmer.
3. Og sist—hvis jeg får det til—vil jeg gjerne påpeke feil og svakheter ved Win­dows sitt brukergrensesnitt. Skadefryd er en sterk drivkraft hos meg, he, he.

Når vi snakker med hverandre tenker vi ikke så mye på for­muleringen, men på inn­hol­det i sam­talen. Så lenge du tenker klart kommer ordene naturlig—utnytt det­te når du skriver også.

Think straight—talk straight—write straight.

Det kan nå allikevel være greit å ha litt struktur å henge tankegodset på. Regel num­mer en er som følger: Få frem det viktigste først. Den første setningen i en ar­tik­kel er den viktigste. Hvis den ikke lokker le­se­ren vi­de­re til neste setning, er ar­tik­kel­en død. Og hvis den andre setningen ikke lokker le­se­ren til den tredje, er ar­tik­kel­en like død.

I løpet av maksimalt femten sekunder må le­se­ren ha forstått hva det er du prøver å fortelle, ellers har du en leser mindre.

En grovinndeling som ofte er hensiktsmessig er: (1) Budskapet, (2) bakgrunn og forklaring, (3) detaljer og (4) neste skritt:

1. Budskapet: Beskriv hva saken gjelder. Er det et brev, fortell hvorfor le­se­ren har fått det. Er det en ar­tik­kel, fortell hva den handler om og hvorfor det er nyttig for le­se­ren. Bruk et eller to korte avsnitt.
2. Bakgrunn og forklaring: Forsterk eller forklar det viktigste punktet. Bruk så mange avsnitt som nødvendig.
3. Detaljer: Gjør denne delen så kort som mulig. Flytt gjerne informasjon til ved­legg, «sidebar,» kodelistinger, tabeller eller grafer.
4. Neste skritt: Repetér eller sammenfatt de viktigste punktene. I et pro­sjekt­memo, fortell hvem som skal gjøre hva, og når. I en ar­tik­kel, gi et kort sam­men­drag, eller sett hoved­bud­skapet inn i en større sammenheng, eller fortell hva som er neste steg, for eksempel for å lære mere.

Problemer med å komme i gang?

Ikke prøv å skrive perfekt fra begynnelsen. Skriv ned tankene dine så raskt og av­slappet som mulig. Bruk de ordene som er naturlig for deg, uten å vurdere dem. Det­te er omtrent som prinsippet for brain-storming, der ideene som kommer frem bare skal noteres, ikke vurderes. Vurdere kan du gjøre senere.

Det er ikke så mange som kan snyte en velformulert tekst rett ut av nesen. De som kan det har enten et usedvanlig talent eller lang trening—en tekst blir vanligvis ikke helt bra før du har skre­vet den om minst en gang.

Det hender faktisk at jeg bruker lenger tid på en tekst på to setninger enn på en tekst på en side.

Et siste struktureringsråd: Bruk avsnittet som enhet i komposisjonen. Et avsnitt kan være langt eller kort, men skal omhandle en hovedidé.

Siste tema: Ord og språk. Språkføring.

Her har jeg ganske enkelt tenkt å ramse opp en del regler, og illustrere dem med eksempler.

Ikke bruk vanskeligere ord enn nødvendig.

Nå burde jeg selvsagt valgt en litt annen måte å si det på: Velg enkle ord.

Her er et eksempel fra en av våre klienter:

«Behovet for å dekke kompetansegapet er stort.»

(Vi har et stort opplæringsbehov.)

Et annet eksempel fra samme dokument:

«Utvikling av nye produkter og revisjon av eksisterende skjer i en takt som gjør at tradisjonell klasseromsopplæring ikke tilfredsstiller krav til tilgjengelighet av opplæringstilbud.»

(Utviklingen går så fort at tradisjonell klasseromsopplæring ikke greier å henge med i svingene.)

Et tredje eksempel fra en pro­sjekt­plan skre­vet av en annen klient:

«Det­te innebærer en betydelig ekstrainnsats både hva angår økonomi og personalressurser.» (11 ord)

For å si det på en annen måte:

«Det­te blir dyrt og krever mye arbeid.» (7 ord)

Her er noen eksempler på hvordan språket kan forenkles:

I stedet for	skriver du
umiddelbart	straks
enkelte	noen
spesifisere	angi
separert	adskilt
adaptere	tilpasse
benytte	bruke
anvende	bruke
allokere	tildele
selektere	velge
akseptere	godta
konsept	skisse, løsning
majoritet	flertall
mandat	oppdrag
temporær	midlertidig
indikere	tyde på

Ikke bruk flere ord enn nødvendig. For eksempel:

«Det­te vil bidra til økt salg i forhold til dagens salgstall, samt mer fornøyde kunder sammenlignet med dagens tilfredshetsnivå.» (19 ord)

• Ordet «tilfredshetsnivå» er oppstyltet.
• Det er en betydelig grad av overflødig redundans:
  • Økt salg i forhold til dagens salgstall—hva ellers?
  • Mer fornøyde kunder sammenlignet med dagens tilfredshetsnivå—hva skal vi ellers sammenligne med?
• Logisk gal rekkefølge. Det er de fornøyde kundene som bidrar til økt salg, ikke det økte salget som bidrar til mer fornøyde kunder. Derfor bør kundene nevnes først, slik at sammenhengen mellom årsak og virkning blir så klar som mulig.

En bedre formulering kan for eksempel være:

«Det­te vil bidra til mer fornøyde kunder og økt salg.» (10 ord)

Eksempel på baksiden av arket: Standard konsulent-memo.

Skriv klart. PC-banken min har et godt eksempel på uklarhet. Der­som jeg taster inn et KID-num­mer som er galt, får jeg opp en meldingsboks: «Er du sikker på at du vil bruke denne KID-en?»

Det­te her er et misforstått forsøk på å være høflig. Det det egentlig betyr er at KID-num­mer­et er galt, og det er veldig tvilsomt om du faktisk ønsker å bruke det. Der­som du har dårlig nytt å komme med, så er det greit å presentere det på en mest mulig skånsom måte, men ikke pakk det inn så mye at budskapet ikke blir forstått.

Unngå ord som ikke bidrar til fremdriften:

i og for seg, som oftest, for så vidt, sannsynligvis, langt på vei

Varsellampene bør blinke ved:

iverk­set­te, foreta, finne sted

Unngå substantiveringer. Substantivering er å ta et kort og greit verb og gjøre det om til et langt, krøkkete substantiv:

Ikke skriv…	Men skriv…
Vi foretar en vurdering av saken.	Vi vurderer saken.
Oppstart av pro­sjekt­et finner sted på tirsdag.	Pro­sjekt­et starter tirsdag.
MMI foretok en undersøkelse av folks stem­me­giv­ning ved siste valg.	MMI spurte folk hva de stemte ved siste valg.
Vi må iverk­set­te tetningsarbeid i forhold til lekkasjene i tunnellen.	Vi må tet­te tunnellen. (Romeriksporten?)

Avslutning

Og det var i grunnen alt jeg hadde på hjertet: Finn ut hva du vil si—og si det.

Så enkelt er det. Og så vanskelig.

Hilsen Petter, 306. sjef i AMO

---

(Start bottom menu)

Top • Home • Articles • Book • Resources
Win­dows De­vel­oper Maga­zine • R&D Books • CMP Books
Amazon.com • Amazon.co.uk • Contact Petter Hesselberg

(End bottom menu)