Hallo!
Wie wahrscheinlich viele andere Benutzer von Oo auch, habe ich das Problem, dass ich häufig Daten mit Microsoft Office Benutzer austauschen will.
Sei es, dass man mir Formulare zum Ausfüllen schickt, sei es, dass ich mit Partnern an einem gemeinsamen Dokument arbeiten möchte.
Wie sind hier die Erfahrungswerte bezüglich Herstellen eines möglichst reibungslosen Ablaufs? Die implizite Forderung ist, dass die Dokumente auf beiden Seiten fehlerfrei lesbar und editierbar sind. "Schönheit" ist nicht gefordert (was z.B. bei Präsentation natürlich ein zentraler Punkte ist).
Welche Formate sollten man verwenden, welche Funktionen sollte man meiden?
Eine Anpassung meiner Installation (3.0.1 unter Linux) ist möglich, auf der "Gegenseite" ist das jedoch (fast immer) keine Option.
Ciao,
Oliver
Interoperabilität
Moderator: Moderatoren
Re: Interoperabilität
Moin!
...ich glaube das Thema reicht locker für diverse Diplom und Dr. Arbeiten, daher hier 'mein' kurzer Ansatz:
bzw. der von mir beobachtete Status:
Mitarbeiter in Firmen stellen schon ohne einen Admin fest, dass sie Probleme haben,
Dokumente zwischen den verschiedenen M$-Office-Versionen austauschen zu können.
(möchte da nur auf das xdoc hinweisen, tolle Schriften und andere Features mal beiseite gelassen)
d.h. für einen 'nicht'-reibungslosen Ablauf hat M$ selbst gesorgt.
- das wiederum senkt die 'OpenOffice-Toleranz'-Hürde erheblich - ein Dank an M$!
Die Frage scheint mir daher eher zu sein:
Kann man dem User zumuten lernen zu müssen, oder erwartet er von OO mehr als die M$-Produkte leisten?
(...das habe ich mit Erstaunen festgestellt...)
an '...fehlerfrei lesbar und editierbar...' hat halt (leider) auch der User einen relativ großen Anteil...
Daher ist z.Zt. mein Ansatz:
Wenn ein Kunde also nicht bereit ist zu lernen führt kein weg an M$ vorbei
- nicht weil es dann besser geht - definitiv nicht! - sondern weil
man als 'Systemintegrator/Admin/Wasauchimmer' keine 'Schuld' trägt:
Geht mit M$-Tools was schief - kein Problem - das kennen/akzeptieren alle
Hat ein WerAuchImmer ein nicht-M$-Produkten empfohlen ist ER ab sofort für alles verantwortlich (Thema: "...mit M$ wäere das nicht passiert.. aber bei mir zuhause...")
Ist ein Kunde/Chef bereit für Konzept, Schulung etc 'was zu investieren - kein Problem!
Dokumente vorbereiten, kleine Anleitung für die User, ToDo-Liste, Font- und Vorlagen-Tabelle, Tests
die Interoperabilität sollte gegeben sein.
- eine fertige Liste was geht und was nicht dürfte schweiriger sein, das das von dem Anwendungsfall abhängt
Beispiele dazu:
- Tabellen können manchmal schwierig sein (je kmplexer die Formatierung je lustiger die 'Fehler')
- Feldfunktionen ( seq(name) zählt mal von 0 und mal von 1 )
- Makros...
- Fonts
- wie oben schon erwähnt hat das weniger mit OO<=>M$ zu tun - eigentlich gilt das gleiche für zwei Firmen mit M$...
nur die Toleranz/Beweislast scheint da anders zu sein
...ich glaube das Thema reicht locker für diverse Diplom und Dr. Arbeiten, daher hier 'mein' kurzer Ansatz:
bzw. der von mir beobachtete Status:
Mitarbeiter in Firmen stellen schon ohne einen Admin fest, dass sie Probleme haben,
Dokumente zwischen den verschiedenen M$-Office-Versionen austauschen zu können.
(möchte da nur auf das xdoc hinweisen, tolle Schriften und andere Features mal beiseite gelassen)
d.h. für einen 'nicht'-reibungslosen Ablauf hat M$ selbst gesorgt.
- das wiederum senkt die 'OpenOffice-Toleranz'-Hürde erheblich - ein Dank an M$!
Die Frage scheint mir daher eher zu sein:
Kann man dem User zumuten lernen zu müssen, oder erwartet er von OO mehr als die M$-Produkte leisten?
(...das habe ich mit Erstaunen festgestellt...)
an '...fehlerfrei lesbar und editierbar...' hat halt (leider) auch der User einen relativ großen Anteil...
Daher ist z.Zt. mein Ansatz:
Wenn ein Kunde also nicht bereit ist zu lernen führt kein weg an M$ vorbei
- nicht weil es dann besser geht - definitiv nicht! - sondern weil
man als 'Systemintegrator/Admin/Wasauchimmer' keine 'Schuld' trägt:
Geht mit M$-Tools was schief - kein Problem - das kennen/akzeptieren alle
Hat ein WerAuchImmer ein nicht-M$-Produkten empfohlen ist ER ab sofort für alles verantwortlich (Thema: "...mit M$ wäere das nicht passiert.. aber bei mir zuhause...")
Ist ein Kunde/Chef bereit für Konzept, Schulung etc 'was zu investieren - kein Problem!
Dokumente vorbereiten, kleine Anleitung für die User, ToDo-Liste, Font- und Vorlagen-Tabelle, Tests
die Interoperabilität sollte gegeben sein.
- eine fertige Liste was geht und was nicht dürfte schweiriger sein, das das von dem Anwendungsfall abhängt
Beispiele dazu:
- Tabellen können manchmal schwierig sein (je kmplexer die Formatierung je lustiger die 'Fehler')
- Feldfunktionen ( seq(name) zählt mal von 0 und mal von 1 )
- Makros...
- Fonts
- wie oben schon erwähnt hat das weniger mit OO<=>M$ zu tun - eigentlich gilt das gleiche für zwei Firmen mit M$...
nur die Toleranz/Beweislast scheint da anders zu sein

thx!
OO3.1/MySql-Connector/Linux 2.6.30/SuSE/(nur bis)XP John.M
OO3.1/MySql-Connector/Linux 2.6.30/SuSE/(nur bis)XP John.M