Hallo Herr Obermayr,
ich erlaube mir, über unsere Mailingliste zu antworten und nehme dies
auch direkt zum Anlass, weitere Aktivitäten einzuleiten / anzuregen.
Eine Liste mit den zu Zeit noch AK-Mitwirkenden sende ich in
separater Mail auf den Verteiler.
Die zuletzt verfolgte Strategie haben wir in kleinerem Kreise off-
Liste und auf Meetings entworfen, von daher ist das Mailinglisten-
Archiv nicht auf dem tatsächlich letzten Stand.
Die Zielsetzung hat sich zu folgendem entwickelt: Das angestrebte
Ziel ist eine modular aufgebaute Workflow-Beschreibung / Empfehlung,
die sich an der aktuellen Funktionalität der Applikationen bzw.
Umgebung orientiert. Hierfür werden die einzelnen "Stationen" als
Module definiert, die an der Ein- und Ausgabeseite entsprechende
Schnittstellen haben, die sich an der praktischen Durchführbarkeit
orientieren.
Dies soll in mehreren Ebenen passieren, also ausgehend von einem
Komplett-Schema bis zu detaillierten Beschreibungen von
Schnittstellen und Vorgehensweisen.
Es ist geplant, eine Verfügbarkeit online zu erstellen, wo man sich
also je nach Bedarf / Kenntnisstand auf die verschiedenen Level
begeben kann. Den Bildbearbeiter interessiert vermutlich mehr, in
welchen Formaten er die Bilddaten absichern und weitergeben soll,
welches Profil, welches Rendering, etc - wo hingegen der Reinzeichner
wohl auch Bedarf an Kenntnissen bei der PDF/X-Erstellung hat. Auf
jeden Fall soll gewährleistet werden, dass für die Übergabe bzw. das
Ineinandergreifen an den Schnittstellen eine zueinander einheitliche
Definition besteht.
Hierfür wollen wir eine web-basierte Applikation erstellen, welche
eine entsprechende Navigation zu den verschiedenen Level ermöglichen
soll. Vermutlich geht Ihr Gedanke "Tool zum Workflow-Design" in
genau die gleiche Richtung.
Das möglichst einfache und übersichtliche Schema soll eine möglichst
breit gefächerte Zielgruppe ansprechen, also vom Fotografen über den
Produktioner, Retuscheur, Reinzeichner bis hin zur Druckerei als
Datenempfänger. Eine Vertiefung in die jeweilige Materie (Module /
Schnittstellen / Beschreibung) kann nach Wunsch auf mehreren Ebenen
erfolgen.
Bei dem sehr gelungenen BVDM-Projekt lag der Schwerpunkt zunächst auf
der Untersuchung von Farbe allgemein, also Überprüfung von formal
richtiger Umwandlung von Bilddaten und Anwendung von Profilen bzw.
Transformationen. Die beschriebenen Workflow-Strategien mit der
umfassenden Erläuterung der Einstellungen und Vorgehensweisen ergeben
sich aus dieser reinen Funktionalität, nicht untersucht wird
beispielsweise die Qualität von Farbtransformationen oder inwieweit
welche Datenformate Alpha-Kanäle als Maske an das Layoutprogramm
weitergeben.
Diese Dinge könnten auch unser Fokus sein, müssen aber nicht, wir
würden uns allerdings an bestimmten Stellen auf entsprechende Quellen
explizit beziehen.
Mit Job-Jackets habe ich mich noch nicht sehr genau befassen können,
es sieht jedoch so aus als ob eine Betrachtung sinnvoll ist.
Bis auf weiteres
mit freundlichen Grüßen
Andre Schützenhofer
Am 19. Nov 2006 um 16:23 schrieb Georg Obermayr:
Hallo Herr Schützenhofer,
Entschuldigen Sie die längere Funkstille - ich war die letzte Zeit
ziemlich beschäftigt mit der
Vorbereitung eines Vortrags für die SMI. Jetzt habe ich jedoch
Gelegenheit gefunden, mich ein
wenig in das Listen-Archiv des AK-Workflow einzulesen.
Für mich bleiben hier einige Fragen offen, was am Ende zum Ergebnis
bzw. "Nutzwert" des AK
werden soll:
- Eine Art White Paper, in dem aus der Sicht des AK offene Stellen
in den heutigen Systemen
diskutiert werden, und dass dann quasi als ECI-Empfehlung
weitergerecht wird (etwa an das
ICC...)?
- Oder aber (zeitlich erscheint mir das "näher"): Publikation einer
Reihe von konkreten und
abstrakten Workflow-Modulen?
Die Frage die sich mir jetzt hier aufdrängt, ist, wie kann ein
solches eher theoretisches
Denkmodell (das ohne es zu wissen ja heute schon vielerorts so
"läuft") einen echten Nutzwert
für die Anwender darstellen?
-- Macht es Sinn, "Best practices" für verschiedene Ansätze (early
binding, late binding...) und
Einsatzbereiche (Anzeigen, Zeitungen, Offset...) herauszugeben?
--- Und wo liegt dann der Unterschied zur neuen bvdm-Publikation
über das CMS in DTP-
Applikationen?
-- Wenn ein Anwender jetzt mithilfe dieser Vorgaben im Detail durch
betriebs-spezifsche
Komponenten angereichert hat, welchen tiefergehenden Nutzen, ausser
einer strukturierten
Darstellung, kann er daraus ziehen?
Verstehen Sie mich bitte nicht falsch, ich finde die technische
Herangehensweise hier ( http://
lists.callassoftware.com/pipermail/ak-workflow/attachments/
20051110/7083a9a0/
attachment-0001.pdf ) schon sehr intelligent. Nur evtl. doch zu
abstrakt für viele Praktiker?
Es entstehen also für mich zwei mögliche Ergebnisse:
- Eine Art "ECI White Paper Version 2" mit aktualisierten und
erweiterten Workflow-
Empfehlungen. Ist dann der Unterbau in Form von abstrakten u.
konkreten Modulen notwendig?
Wäre es dann nicht besser, einfach zu sagen, die spezifische
Implementierung muss sich an 1,
2, 3... Grundgedanken orientieren?
- Oder man geht einen konsequenten Schritt weiter und stellt ein
Tool zum Workflow-Design
zur Verfügung. Dort wären dann als Vorgabe die ECI Best practices
drin, mit jeweiliger
Verfeinerung. Als "Ausgabe" sollte dann aber nicht nur ein Prozess-
Plott stehen, sondern auch
ein XML/JDF-File welches diesen erstellten Workflow kontrolliert
und steuert. Ich hoffe es wird
klar, worauf ich hinaus will.
Quark hat mit den Job Jackets eine erste Referenz-Implementierung
für ein solches Format
geschaffen. In Anlage hänge ich Ihnen eine erweitere Version meiner
SMI-Präsentation. Der
erste Teil ist eine allgemeine Einführung in die Technologie, der
zweite Teil ist der Versuch
einer Workflow-Definition.
Bitte verstehen Sie meine ersten Anmerkungen nicht als Kritik der
bisherigen Arbeit. Vielmehr
möchte ich Ihnen ein paar Anregungen aus meiner Sicht geben. Ich
bin auch durchaus bereit
hier bei der weiteren Ausgestaltung aktiv mitzuwirken.
Ich bin gespannt auf Ihr Feedback!
Viele Grüße,
Georg Obermayr
<vortrag_jj_v2.pdf>