Office-opgradering skaber makro-mareridt
Muligheden for at tilpasse værktøjslinjerne i Microsoft Office har været en højtelsket funktion i Microsofts kontorpakke. Den mulighed forsvandt i Office 2007, og det gør det vanskeligt for mange kunder at skifte til den nye version.
I mange virksomheder har både enkelte medarbejdere og hele afdelinger lavet deres egne makroer og egne værktøjslinjer, som brugerne har vænnet sig til. Men når disse værktøjer bliver overført fra eksempelvis Office 2003 til Office 2007, så ryger fidusen
Office 2007 understøtter ganske vist i mange tilfælde selve makrokoden, men ikke værktøjslinjerne. De bliver i stedet gemt under et særskilt faneblad på den nye værktøjsbjælke, kendt som båndet eller Ribbon.
»Der optræder de i fuldstændig tilfældig orden. De er der, men de er besværlige at få fat på. Office 2007 prøver at regne ud, hvad du har brug for, så den skifter rundt mellem fanebladene, og fanebladet med add-ins ryger altid i baggrunden,« forklarer Lene Fredborg, stifter af it-firmaet DocTools og Microsoft MVP i Word.
Det betyder, at medarbejderne ikke længere har let adgang til genveje med de makroer, de har vænnet sig til gennem måske mange år.
Office 2007 har godt nok en begrænset mulighed for at tilpasse værktøjerne, men kun den særlige bjælke til Hurtig Adgang, som i forvejen har ikoner til at gemme og fortryde. Hurtig Adgang har plads til op til 40 ikoner, men ikke til tekstforklaringer.
Man kan dog også lave et specialtilpasset faneblad. Det kan ikke gøres direkte i det traditionelle makrosprog Visual Basic for Applications, VBA, men skal i stedet laves i XML. Derefter skal man ændre sin originale makrokode for at kæde den sammen med XML-koden.
»Det betyder, at man får lagt et ekstra lag på. Og det er ikke noget, den almindelige bruger kaster sig ud i,« forklarer Lene Fredborg.
Hendes erfaring er, at langt det meste makrokode vil kunne køre i Office 2007, men forskellen i brugerfladerne betyder, at det bliver langsommere at bruge makroerne i Office 2007.
Microsoft lover mere tilpasning i Office 2010 Næste udgave, Office 2010, vil ifølge Microsoft og ud fra betaversionen åbne for større mulighed for at tilpasse fanebladene i brugerfladen på stort set samme måde, som man hidtil har kunnet tilpasse værktøjslinjer i Office 2003 og ældre udgaver.
Alligevel vil mange virksomheder stå med ikke blot at skulle oplære brugerne i den nye brugergrænseflade, men også med at konvertere de gamle makroer. Det er allerede et problem for mange virksomheder, som skifter til Office 2007.
»Nogle af makroerne går i stykker ved skiftet. Vi ser først problemet nu, fordi så mange organisationer har ventet, og mange andre sprang en version over,« siger analysedirektør Rob Helms fra Directions on Microsoft til it-nyhedstjenesten The Register.
Han vurderer, at især små virksomheder vil stå over for udfordringer med at konvertere, fordi en stor organisation vil have flere ressourcer til at planlægge og implementere en opgradering. Rob Helm foreslår derfor, at Microsoft kunne ændre supportaftalen, så de konsulentydelser, man kan få som en del af Software Assurance, kunne bruges til hjælpe kunderne med migreringen.
Kommentarer (27)
Hvis der var blevet skiftet fra Office til OpenOffice ville OO være blevet sablet ned, og udråbt til et elendigt program.
Nu er det MSO som ikke er "kompatibelt" med MSO, og så er løsningen: Vent til den nye udgave udkommer, og BETAL så for den.
Der er ingen ramaskrig fordi det ikke virker, bare irritation.
Det kommer godt nok an på, hvilke steder du bevæger dig.
Læser du med herinde, så er det jo uanset om MS laver noget godt eller skidt, så lyder der et ramaskrig.
Hej Svend,
Hvis der var blevet skiftet fra Office til OpenOffice ville OO være blevet sablet ned, og udråbt til et elendigt program.
Mig bekendt er der aldrig nogen (herinde), der har udtalt, at "da man ved skift fra Microsoft Office til OOo skal omskrive sine makroer, så er OOo et elendigt program".
Jesper,
Mig bekendt er der aldrig nogen (herinde), der har udtalt, at "da man ved skift fra Microsoft Office til OOo skal omskrive sine makroer, så er OOo et elendigt program".
Nej, det har jeg nu heller ikke oplevet. Men konspirationsteorier er jo altid underholdende. Jeg kan stadig tage mig selv i at sidde og ryste på hovedet over Virum-Gate :)
Mig bekendt er der aldrig nogen (herinde), der har udtalt, at "da man ved skift fra Microsoft Office til OOo skal omskrive sine makroer, så er OOo et elendigt program".
Jeg mener ikke det er usædvanligt i forbindelse med diskussioner om hvorvidt et billigere/mere åbent alternativ til et microsoft produkt er blevet foreslået, at argumentet for at bevare status quo tit lyder;
"Jamen man kan ikke spille sine spil på ..."
"Jamen man kan ikke migrerere sine makroer til ..."
"Jamen ens dokumenter er ikke gengivet pixel for pixel i ..."
Dette er vel bare et eksempel på, at debatten fremover bør være meget varsom med den slags argumenter.
Muligvis ikke :-)
Men hvis man var skiftet fra MSO 2003 til OO, og makroerne/genvejene ikke virkede, ville det være OO's skyld, og der ville have været en lang debat.
Laver man et dokument i MSO's lukkede format, og smider det over i OO, og det ikke virker, er det igen OO's skyld.
LAver man et dokument i MSO 2007 og forsøger at bruge det i MSO 2003, virker det ikke, men "så skal du bare gemme det i et andet format".
Laver man makroer/genveje i MSO 2003 og det ikke virker i 2007, skal man bare vente til MSO 2010.
OO er kompatibelt med det meste MSO.
MSO er ikke 100 % kompatibelt med MSO...
i det herrens år 2010 - at Office 2007 har et makroproblem.....
Citat: " Den mulighed forsvandt i Office 2007, og det gør det vanskeligt for mange kunder at skifte til den nye version"
Come on...Selvom jeg er klar da er helt klar over at mange faktisk kører 2003 endnu...
Svend:
Men hvis man var skiftet fra MSO 2003 til OO, og makroerne/genvejene ikke virkede, ville det være OO's skyld, og der ville have været en lang debat.
Nej, det ville det ikke. Det ved folk herinde udmærket. Ikke-nørder ved det måske ikke, men det bliver det jo ikke rigtigt af.
Laver man et dokument i MSO's lukkede format, og smider det over i OO, og det ikke virker, er det igen OO's skyld.
Se ovenfor.
Ang. de sidste 3 pointer, så tror jeg vi er enige. Jeg savner stadig en standard, som alle kan være enige om - og som ikke ændrer sig årligt.
Niels D.:
Jeg vil nu mene at spil er en ret god undskyldning. Kan man lave en makro, kan man nok også ændre den til at fungere i OO. Det kan man ikke gøre med spil :)
@Thomas
Jeg vil nu mene at spil er en ret god undskyldning. Kan man lave en makro, kan man nok også ændre den til at fungere i OO. Det kan man ikke gøre med spil
Pointen er, at hvis manglende mulighed for at medbringe sine spil fra platform X til platform Y er et godt argument, bør det ligeledes være en kritisk faktor hvis man ikke kan (eller kun med stort besvær) medbringe sine spil fra platform X til platform X 2.0.
Erstat spil med makroer, dokumenter ect.
Som sagt, så tilbyder Office 2007 (og 2010) et nyt XML baseret API til at udvide brugerfladen med.
Hvis man benytter .NET til udviklingen af plugins til Office, i stedet for at blive ved gamle VB macros er problemet ikke så stort.
Dette her er bare et typisk legacy-support problem ved skift af platform. OpenOffice skal nok opleve sin kage af problemerne når de begynder at strømline og refactor deres plugin APIs om et par år :-)
Niels:
Pointen er, at hvis manglende mulighed for at medbringe sine spil fra platform X til platform Y er et godt argument, bør det ligeledes være en kritisk faktor hvis man ikke kan (eller kun med stort besvær) medbringe sine spil fra platform X til platform X 2.0. Erstat spil med makroer, dokumenter ect.
Det kan man sige ja. Lige præcis dokumenter vil man dog i de fleste tilfælde kunne overflytte uden de større problemer. Makroer kan vel omskrives.
Det kan spil ikke - ikke medmindre man har mange penge eller vil rode med WINE.
Og når vi nu alligevel snakker om MSO <-> OO.
Microsoft: Visual Basic 6 (VB.NET kan svjv benyttes i 2007+)
OpenOffice.org: BASIC
Så der er ikke så stort konversations problem igen. Det afhænger simpelthen af om der laves produktspecifikke kald, eller om det er rent og skær data in/out replacements og diverse templates.
@Thomas
Lige præcis dokumenter vil man dog i de fleste tilfælde kunne overflytte uden de større problemer.
Ehh.. Er det ikke præcis det modsatte, som Jesper/Jasper har brugt et utal af mandtimer på at forklare os.
Selvom makrokoden kan overføres fra MSO 2003 til MSO 2007, så er problemet med værktøjslinjen en påmindelse om, at vendor-login med MSO også omfatter virksomhedens forretningslogik.
Niels:
Ehh.. Er det ikke præcis det modsatte, som Jesper/Jasper har brugt et utal af mandtimer på at forklare os.
Pas. Den diskussion er blevet ødelagt af talrige flamebaits, løgne og andet pjat fra begge sider.
Det jeg snakkede om var dog simple dokumenter. Dokumenter uden makroer, alt for meget formatering mv.
Du mener ikke det er tilfældet ved OpenOffice.org?
Siden hvornår har macros nogensinde været kompatible mellem flere produkter?
Mine macros i World of Warcraft virker heller ikke i Fable, selvom begge er i LUA. Det er klart, fordi det er to forskellige produkter.
Hvis det om noget, er det jo et plus at Office er en nem platform at skrive plugins til, og netop at det er .NET frem for BASIC gør det er nemt at finde kvalificede udviklere på det danske jobmarked.
@Thomas
Delvist enig i, at det er noget pjat. Diskussionen blev affødt af artiklen med overskrift "Officeopgradering skaber makro-mareridt". Jeg tror, at jeg i lighed med Svend reflekterer over alle de debatter der har været, hvor problem-stillingen kunne have været "Office-migrering skaber makro-mareridt". Hvortil jeg synes at det er karakteristisk, at en MSO <-> MSO problematik ofte bliver foreslået løst med "Buy the new one, and your life will be fabulous", mens en MSO <-> OO problematik bliver set eskaleret til nærmest uoverstigelige problemer. Specielt op gennem tiden indtil nu, hvor normaliteten dog heldigvis er ved at indfinde sig hos de fleste folk.
Niels:
Delvist enig i, at det er noget pjat. Diskussionen blev affødt af artiklen med overskrift "Officeopgradering skaber makro-mareridt".
Jeg tror du misforstod mig. Jeg snakkede om diskussionen med OOXML og ODF. Denne diskussion har været ganske sober indtil videre.
Jeg er enig i, at det ikke altid er nogen god ide at opgradere, bare for at gøre det. Personligt ser jeg ingen ide i at hverken opgradere vores Office 2003 - eller at udskifte den med OpenOffice. If it aint broken, don't fix it.
Hvortil jeg synes at det er karakteristisk, at en MSO <-> MSO problematik ofte bliver foreslået løst med "Buy the new one, and your life will be fabulous", mens en MSO <-> OO problematik bliver set eskaleret til nærmest uoverstigelige problemer.
Somebody, think of the children!!!
http://www.computerworld.dk/art/50156/microsoft-open-source-kan-ramme-de...
http://en.wikipedia.org/wiki/For_the_children_%28politics%29
Siden hvornår har macros nogensinde været kompatible mellem flere produkter? Mine macros i World of Warcraft virker heller ikke i Fable, selvom begge er i LUA.
Din sammenligning er ikke holdbar.
MS Office 2007 og 2003 tilhører den samme produkt-linje, så i realiteten er der tale om to udgaver af det samme produkt.
Din sammenligning er ikke holdbar. MS Office 2007 og 2003 tilhører den samme produkt-linje, så i realiteten er der tale om to udgaver af det samme produkt.
For god ordens skyld skal det måske nævnes, at makroer i World of Warcraft jævnligt går i stykker, når der kommer en ny patch.
Du mener ikke det er tilfældet ved OpenOffice.org?
Korrekt. OpenOffice.org er nemlig open-source og dermed eksisterer vendor lock-in ikke.
PS. Undskyld den ovenstående stavefejl, det hedder naturligvis "lock-in" og ikke "login", som jeg er mere vant til at skrive. :-(
I MSo og OO bruges macroer vel ikke ret meget i virkeligheden. Argumenter om makroer må derfor være henvendt til den 0.01% af brugerne der i det hele taget anvender disse funktioner, eller dem der er ved at tage et "PC-kørekort" hvor man jo bliver undervist i det mærkeligste, som så bagefter aldrig bliver anvendt til noget.
Således f.eks. også med Database delen i begge programmer, leder man via google efter eksempler, vil de fleste MSo eksempler være skoleopgaver og kun ganske få er i det hele taget tilgængelige til OOo (her er noget at lave for tilhængerne).
Vendor lock-in versus at man skal skrive en ny macro engine til OpenOffice.org ?
Kig på kildekoden til OOo og vuder om ikke de fleste business-cases vil anbefale vendor lock-ins.
Jo, makroer i MS Office bliver faktisk brugt rigtig, rigtig meget! OO skal jeg ikke udtale mig om.
Det er muligt, at mange af dem, der lærer lidt om at lave makroer på et kursus, aldrig bruger den viden senere. Men antallet af makroer, der er i brug rundt i virksomhederne, er enormt. Jeg tæller jo selv kun som én person, men jeg har udviklet meget omfattende sæt af makroer – fortrinsvis til Microsoft Word – der bruges af flere tusinde brugere, alt sammen med det formål at automatisere eller forenkle opgaver og forbedre kvaliteten af dokumenterne. På samme måde er der mange andre – måske oftest internt i de enkelte virksomheder – som har udviklet makroer, der bruges af mange i det daglige. Makroer er med til at spare meget store mængder af arbejdstid hver dag.
Hvis man spørger de enkelte brugere, om de bruger makroer, er det imidlertid meget tænkeligt, at mange vil svare nej – de bruger bare værktøjerne via knapper og menuer og er ikke bevidste om, at det er makroer, der ligger bag.
Lene Fredborg
DocTools
http://www.thedoctools.com
Claus, Claus, Claus....
OpenOffice skal nok opleve sin kage af problemerne når de begynder at strømline og refactor deres plugin APIs om et par år :-)
Enten ved du ikke hvad refactoring er eller også må du forklare dig nærmere.
Nu behøves de der har udvikling som levebrød, og ikke kun himler op om det, ikke Wikipedia for at forklare refactoring, men de formulerer det nu så fint at jeg ikke gider prøve selv. Og forklares skal det tilsyneladende. Fra http://en.wikipedia.org/wiki/Code_refactoring:
Code refactoring is the process of changing a computer program's internal structure without modifying its external functional behavior or existing ...
Så nej. At refactor deres plugin API, hvis man da ellers kan refactor et API, vil ikke introducere de problemer der nu opleves i MSO.
Hvad du mener med "strømline" ved jeg ikke, men jeg gætter på at du heller ikke selv ved det. Den slags ordvalg plejer at betyde at argumenterne ikke er gode og der derfor skal flere ord (ninjarøg) til at illudere argumentation.
Hvis du, mod forventning, kan forklare hvordan "strømlining" af et API kan introducere de problemer med at værktøjslinjerne forsvinder og knapperne kastes tilfældigt ind i det bagerste faneblad, er jeg lutter øren.
Bedste hilsner,
Morten
P.S.: Man kan også lave makroer til OOo i python. Det har jeg i hvert fald gjort.
