Kommuner drukner i Word-skabeloner

Okay, nu er du for alvor ved at have mig overbevist. Det lyder som et rigtig godt system, hvis det stadig er muligt, at hive rå data ud at OOXML-dokumentet efter redigering.

Såfremt separationen bevares under denne redigering, så lyder det også som en okay løsning. Indgår data fra de redigerede dokumenter efterfølgende i jeres datagrundlag?

Nej, du opponerede mod kritikken af brugen af Word, ikke OOXML. Der er en meget stor forskel.

Men en umiddelbar redigering af dokumentet ændrer ikke på adskillelsen af data of layout

Dokumenterne vi danner (både DOCX-dokumenter og PPTX-præsentationer) indgår "med det samme" i en redigeringsproces i forretningen

Såfremt separationen bevares under denne redigering, så lyder det også som en okay løsning. Indgår data fra de redigerede dokumenter efterfølgende i jeres datagrundlag?

PDF er ikke voldsomt velvalgt til dette.

jeg opponerede udelukkende på, at brug af OOXML skulle betyde, at adskillelsen imellem data og layout forsvandt.

Men bruger du i det hele taget Word i den beskrevne løsning? Som jeg læser det, så bruger du netop ikke Word, når du genererer OOXML-dokumenterne.

Slutbrugeren kan bruge Word til at læse dokumenterne, men der er vel ikke noget til hinder for at transformere dokumentet til pdf, og så bruge Adobe Reader til at læse dokumentet i?

Med mindre en efterfølgende redigering af dokumentet i Word garanterer, at separationen mellem data og layout bevares.

Men en umiddelbar redigering af dokumentet ændrer ikke på adskillelsen af data of layout (med det forbehold, at alt naturligvis kan smadres af de rigtige personer)

Derimod lyder dit system til at være meget lig det Torben og Henrik foreslår - bortset fra, at outputtet er OOXML i stedet for LaTeX.

Henrik snakker om en custom brugerflade til indtastning af tekster, men det vil jeg ikke umiddelbart vurdere er muligt for os at lave. Det er ret komplekse skabeloner med tekst, billeder, tabeller, illustrationer dannet på baggrund af LOB-data etc flettet med data fra LOB-systemerne, så arbejdet med at danne denne UI synes ikke på nogen måde at være simpel - og jeg kan ikke se den umiddelbare værdiskabning ifht vores eksisterende løsning.

Jeg siger ikke på nogen måde, at man ikke kan lave vores system på en anden måde - jeg opponerede udelukkende på, at brug af OOXML skulle betyde, at adskillelsen imellem data og layout forsvandt.

Min pointe er stadig, at det er noget vrøvl at sige, at hvis man bruger Word, så kan man ikke adskille data fra layout.

Din beskrivelse har endnu ikke overbevist mig om, at Word sørger for adskillelsen af data og layout. Derimod lyder dit system til at være meget lig det Torben og Henrik foreslår - bortset fra, at outputtet er OOXML i stedet for LaTeX.

Jeg synes ikke rigtig, at dit eksempel modsiger den citerede påstand. Det lyder som om, du har lavet et system, der genererer Word filer ud fra data, der stammer fra en ekstern kilde. Hvis det er korrekt forstået, så bruges Word blot som præsentationsapplikation, og ikke som dokumentgenereringsværktøj.

Systemet anvender en række DOCX-templates, hvori der ligger en klump xml. I selve Word-dokumentet er defineret en række "placeholders" (content controls), der hver især er mappet til data i xml klumpen.

Når dokumentet indlæses, så vil Word løbe disse "placeholders" igennem, identificere data i xml-strukturen og vise disse data på de angivne steder.

Så Word er ikke "kun" en præsentationsmekanisme. Man sige, at hvis man skulle tegne arkitekturen bag det, så ville det ligne MVC eller MVVM ret meget, hvor Word så ville være "View"-komponenten, der arbejder på et "View" eller en "ViewModel", der er genereret af en controller (den del af systemet, der henter LOB-data og skriver xml-filen inde i dokumentet.

Hvis jeg tager linien inden det jeg citerede med, så står der:

Pointen er netop at afkoble layout fra data, så data (rå tekst) kan tilgås fra andre kilder.</p>
<p>Brugen "dokumenter" som enhed for data er rigtig dårligt, da det gør det rigtigt svært senere at strukturere data.

(og så kan der jo være tusinde grunde til, at Word er et dårligt program at bruge i det hele taget - men adskillelsen imellem data og layout er ikke én af dem).

det er noget vrøvl at sige, at "hvis man bruger Word, så kan man ikke adskille data fra layout".

Brugen "dokumenter" som enhed for data er rigtig dårligt, da det gør det rigtigt svært senere at strukturere data.

Der er masser af situationer, hvor brugen af Word kunne erstattes af PDF eller lignende, men det er noget vrøvl at sige, at "hvis man bruger Word, så kan man ikke adskille data fra layout".

Hvilke(n) Windows eller cross platform editor vil du/folk anbefale?

Der er f.eks LyX og BaKoMa.

Men egentligt vil jeg ikke anbefale en specifik løsning, for fidusen er også, at du kan i meget større omfang tilbyde en custom brugerflade eller editor til udfyldning af tekster, der så kan generere et LaTeX dokument vha. noget scripting. Så kan man også bygge det visuelle op, så det giver mere mening i forbindelse med indtastningen fremfor at binde sig til layoutet i det færdige dokument, som man gør i de håbløse Adobe PDF formularer, som kommunerne en overgang brugte (eller gør de stadig?).

Nu kender jeg ikke typen af alle disse dokumenter der skrives i kommunen. Men generelt set må der været tale om et fælles layout og en række templates med standard tekst i en form hvor modtager adresse og lidt andre data skal sættes ind efter behov.

Man kunne forestille sig en web baseret løsning, hvor brugeren kan vælge mellem en række formularer, indtaste de variable værdier, trykke på en knap, og bagved er der så noget LaTeX eller PDF kode der danner et nydeligt PDF dokument som output. Dermed skjules generering for bruger, og layout kan styres centralt.

Hvad angår LaTeX findes der web baserede cross platform løsninger, f.eks. https://www.sharelatex.com/

Desuden er der jo meget visuelle LaTeX editorer idag, så brugeren ikke føler sig helt hensat til en gammeldags tekstkonsol.

Hvilke(n) Windows eller cross platform editor vil du/folk anbefale?

Det tror jeg ikke er noget større problem, hvis man har én LaTeX ekspert pr. kommune til at debugge style sheets, og så burde det jo være enkelt nok at kværne dokumenter ud med tiden uden at brugeren skal tænke alt for meget over det. Det tager måske et års tid at få det på plads.

Desuden er der jo meget visuelle LaTeX editorer idag, så brugeren ikke føler sig helt hensat til en gammeldags tekstkonsol.

Men måske er det "styrken" i Word, at man får et sandt WYSIWYG miljø, hvor man nærmest impromptu kan skrive et pænt formateret dokument til en klient, og umiddelbart se resultatet. Det er meget sjovt, men det skalerer ad helvede til, når du skal skrive breve til 100 klienter om dagen, og det er meget kostbart at gøre til et søgbart arkiv, for Word formatet er fuldstændig udueligt til den slags.

Det er i så fald et af de IT abstraktioner der går helt hen over hovedet på almindelige brugere, politikere og whatnot: At den tekst du indskriver ikke nødvendigvis behøver at ligne det du får ud, og at der er administrativ værdi i at optimere dit tekstredigeringsprogram til meget effektiv indskrivning og efterfølgende kompilering og arkivering i stedet for at se pænt ud.

Kunne folk forstå det, slap vi nok for at død og pine hænge fast i Word, og kunne spare nogle gode millioner indenfor offentlig IT.

De fleste sagsbehandlere i en kommune burde slet ikke bruge Word og kommuner kunne spare mange penge på licenser ved at tænke automatisk dokumentgenerering ind i deres fagsystemer.

Flere og flere systemer bliver webbaseret og da sagsbehandleren ofte blot retter til i en skabelon, kunne det med fordel erstattes af form felter eller web-editors som ckeditor. Fagsystemer kan derefter generere en PDF som smides til Digital Post og ESDH.

Efter henvendelse fra Dania Software er tallet i artiklen ændret til omkring 50.000, idet Aabenraa ifølge Dania Software ikke skulle have talt alle ydelserne med. Dania Software påpeger ligeledes, at selvom der er tale om en fordobling, er det et yderst beskedent beløb for en virksomhed på størrelse med en kommune.

Jaja, Kom tilbage efter at du har lärt en sekretär - eller din gamle mor - at bruge LaTeX!

Da jeg studerede på DTH for mange år siden anvendte sekretærerne LaTeX. Rent teknisk er der ikke noget i vejen for at de anvender de samme skabeloner idag.

Forresten så finder jeg den implicitte sammenligning af en sekretær med en gammel mor (hvad det så end præcis måtte være) upassende.

Men. Det er egentligt det samme problem: Nogen skal programmere hvordan dokumentet skal se ud og nogen skal löbende opdatere formaterne og koden.

Men sådan et alternativ passer sikkert ikke ind i det offentlige hvor Windows sikkert er standard, og penge ikke er noget problem.

De fleste Office-anvendere kan knapt finde ud af at bruge Word "Style-sheets" og nu skal de läre at debugge, compile, lede efter manglende tegnsätning mange, mange, linier (eller filer) väk fra den obskure fejlmeddelelse ....

Jeg har engang fået det til at fungere at brugerne placerer ting i en database, hvorefter et program genererer en fint formateret rapport via LaTeX.

Men. Det er egentligt det samme problem: Nogen skal programmere hvordan dokumentet skal se ud og nogen skal löbende opdatere formaterne og koden.

Man kan faktisk også autogenere ooxml ud fra data...

Pointen er netop at afkoble layout fra data, så data (rå tekst) kan tilgås fra andre kilder.

Brugen "dokumenter" som enhed for data er rigtig dårligt, da det gør det rigtigt svært senere at strukturere data.

Et godt eksempel er brugen af Doors til kravsstyring frem for word-dokumenter: Ved at tage tekstfelterne over i en DB, kan man pludselig automatisere en masse ting - og autogenere dokumenter til sidst.

Ja, Word er nemt at bruge for den almindelige bruger, det er WYSIWYG, hvad du ser på skærm kommer ud på papir. Ulempen med Word er dog at det er svært at sikre ensartet layout i en lang række dokumenter da alt gemmes i Word dokumentet, og det er en stor opgave at opdatere når der sker ændring af logo eller navn.

Et nemt og ganske gratis alternativ kan være brug af typesetting,. HTML formularer eller LaTeX. Du indskriver noget tekst, og mediet der præsenterer tekst har til opgave at sikre layout, layout kan så styres ved links til fælles elementer der styrer format. Men sådan et alternativ passer sikkert ikke ind i det offentlige hvor Windows sikkert er standard, og penge ikke er noget problem.