Der folgende Text stammt von Ende 2000 und habe ich im Februar 2001 nochmal überarbeitet. Inzwischen ist Golive 6 erschienen. Der Text steht hier allenfalls noch aus historischen Gründen hier...

Adobe Golive 5

Eindrücke

Die Eindrücke sind keineswegs repräsentativ für das Programm. Es werden hier vorallen Schwierigkeiten und Probleme die mir innerhalb meines Workflows aufgefallen sind.

Es gab unlängst einen Artikel auf Ars Technica der Apples Cinema Display getestet hat. Was der Tester besonders hervorhob, war die Wertigkeit die schon die Verpackung ausstrahlt. Ähnlich bei mir: Eine glückliche "Shopping-Experience" des Kunden ist das Fundament für Kundenzufriedenheit.

Beeeep. Adobe, leider sind sie durchgefallen. Wenn eine in Hamburg programmierte Software mich erst zwei Monate nach den US-Kollegen erreicht, und diese zu allem Überfluß auch nicht an die korrekt angegeben Empfänger- sondern Rechnungsadresse gesandt wird, dann gibt das ganz, ganz dicke Minuspunkte. Nicht nur das Adobe europäische Kunden benachteiligt (weil z.B. diverse Bundleangebote des US-Shops nicht nach Europa versandt werden). Es ist auch noch ein Malheure passiert, weil in Mac-Packungen Windows-CDs steckten. Aber anstatt Kunden, über deren Adressen man in zwei bis dreifacher Anfertigung verfügt, schließlich benützt man ja den Adobe-Shop und registriert seine Software, über die Verzögerung aufzuklären, läßt man sie im dunklen.

Es wurde nicht Bescheid gesagt, es wurde sich auch nicht entschuldigt. Wieso liebe Freunde, sollte ich überhaupt noch jemals daran denken Adobe Software zu registrieren?

Für Außenstehende mag es nicht verständlich sein, wieso ich darüber so abgrundtief sauer bin. Aber zu Erinnerung: Golive Cyberstudio wurde einst von Adobe aufgekauft. Ein paar Monate später kam eine eiligst zusammengeschusterte Version raus, Golive 4.0, die kaum was neues enthielt. Das war April 1998. Und dann passierte nix. Adobe sagte nix, man hörte nix. Man sah nur wie Dreamweaver zu Golive aufschloß und sogar überholte.

Im Sommer 2000 war es soweit und Golive 5 wurde angekündigt. Man bekam feuchte Finger: Endlich würde die Welt eine bessere werden, man besseren Code schreiben ecetera.

Und dann als erstes die "Shopping Experience", der Schlag ins Gesicht!

Und es sollte sowas wie ein Menetekel für Golive 5 werden. Ich stand da, hatte das Programm installiert, las von den ganzen duften neuen Features und stellte fest: Irgendwie brauche ich sie nicht, oder sie sind nicht so wie ich sie bräuchte.

Ganz klar standen zwei Features auf den Top-Positionen der Wishlist: Datenbank-Anbindung und Optimieren des generierten JavaScript-Code.

Datenbankanbindung

über die "Dynamic Link" genannte Datenbank-Anbindung kann ich mangels Erfahrung nicht soviel sagen. Es bleibt nur festzustellen daß die von Adobe versprochenen Zusätze zur Anbindung weiterer Datenbankformate wie JSP, bislang ausgeblieben sind.

JavaScript

Der von Golive mit den Actions generierte JavaScript-Code ist zum Gruseln. Er ist abstrakt, diverse Ebenen tief verschachtelt und enorm fett. Zudem nicht-Netscape6-kompatibel. Einer der größten Enttäuschungen daß Adobe diese Schwäche aber auch nicht annähernd angefaßt hat. Aus der Not hat man in der letzten Minute noch eine Funktion eingebaut die in der Lage ist die generierte, externe JavaScript-Datei um redudante Komponenten zu erleichtern. Diese Funktion ist so spät eingebaut worden, daß sie nicht mehr ins Handbuch aufgenommen wurde.

Es lohnen sich keine Ausreden, Adobe, dies ist einer der am meisten gewünschten Korrekturen gewesen. Nix wurde gemacht. Von der seit Mitte 1999 bekannten Netscape 6-Problematik ganz zu schweigen.

Workflow mit Photoshop

Eines der gern beworbenen Features: Die Einbindung von Photoshop/ImageReady in den Workflow. Was steckt da ein Potential drin? Lohnt sich der Umstieg von Fireworks? Antwort: Nein. Es gibt drei Funktionalitäten die diesbezüglich in Golive 5 neu sind:

Grafik ist Photoshop-Dokument

Die als Photoshop-Datei vorliegende Grafik könnte 1:1 übernommen werden. Mit Hilfe der SmartObjects kann man diese Datei einfach auf das HTML-Dokument ziehen. Golive fragt dann in einem "save as web"-fenster nach, in welchen Einstellungen die Grafik wohin abgespeichert werden soll. Die Grafik kann dann nochmal nachträglich in Golive skaliert werden, woraufhin Golive im Hintergrund das GIF oder JPEG nochmal neu aus der Photoshop-Datei erstellt.

Für mich die praktischste Funktion, aber mit der Einschränkung daß es relativ selten vorkommt das ich in einer PSD-Datei nur ein einziges einzubauendes Objekt habe...

Der Bullshit den Golive in dem HTML-Code reinschreibt, beschränkt sich auf ein LIVESRC-Attribut das im IMG-Tag reingeschrieben wird, und den Pfadnamen der PSD-datei verewigt. Das ist nicht unheikel in Zeiten in denen JavaScript-Bugs im Explorer oder Outlook Hackern Zugriff von außen auf Rechnern geben kann. Die bedanken sich für Infos bzgl. der Verzeichnisstruktur.

Mehrere Grafiken liegen auf jeweils unterschiedlichen Ebenen in Photoshop vor

Dann erstellt das SmartObject aus den unterschiedlichen Ebenen "Floating Boxes", die also auf DHTML zugreifen. Das ist meines Erachten noch ein absoluten No-No, macht Schwierigkeiten bei einigen Browsern und wird, pauschal gesagt, nicht dem Medium Internet/HTML gerecht.

Photoshop-Dokument ist "geslicet"

Unter "slicen" versteht man das Unterteilen eines Grafikdokumentes in mehreren Sektionen. Jede diese Sektionen wird getrennt, mit eigenem Namen und eigenen Voreinstellungen, exportiert. Die Umsetzung ist, mit Verlaub, wirklich für den Arsch! In einem solchen Fall schneidet das SmartObject die Datei eigenständig auseinander und bastelt eine entsprechende HTML-Datei zusammen, die alle "Slices" zum gesamten Screendesign wiederzusammensetzt, so wie es auch in Photoshop aussieht. Vor diesem Vorgang wird nach dem Speicherort für ein neues Verzeichnis gefragt, in dem dann die generierte HTML-Datei sowie die ausgeschnittenen Bilder abgelegt werden.

Erstens wird dadurch die Site-Struktur komplett mit neuen Verzeichnissen zugemüllt. Überall werden eigene HTML-Dateien mit eigenen "images"-Verzeichnissen eingesetzt. Da zweitens die einzelnen HTML-Dateien wiederum mit Tonnen von Golive-eigenen Tags und Attributen versehen sind, kann man auch nicht nachträglich irgendwelche Bild-Dateien in den Verzeichnissen rumschieben.

Kurzum: dieser Weg nimmt mir Möglichkeiten der Einflußnahme, ich verliere die Kontrolle über die Site. Angesichts der sonstigen Schwächen im Golive-Code über den ich mich im Cross-Browser-Publishing-Artikel auslasse, ein weiteres "No-No".

Zusammenfassung: Zwei von Drei Möglichkeiten sind von mir nicht erwünscht, die dritte Möglichkeit vermutlich nicht praxisnah.

Wenn Adobe wirklich was für die User machen will, sollten sie auch mal über den eigenen Tellerand blicken und sehen das auch andere Grafikprogramme benützt werden außer Photoshop, Illustrator und LiveMotion.

Layout-Grid

Ich war lange Zeit ein Gegner des Layout-Grids und der Komponenten in Golive. Das Layout-Grid hat zu komplexe Tabellen gebaut, und, genauso wie bei Verwendung von Komponenten, massenweise eigene Tags und Attribute eingebaut.

Ich sehe das inzwschen etwas entspannter. Zum einen sind Tools wie die Golive-eigene FIND-Option mächtiger geworden, und mit selbstgeschriebenen Erweiterungen kann man diese Tags und Attribute rausschmeissen. Zweitens ist der Golive-Code diesbezüglich sauberer geworden. Und drittens wollen die Kunden inzwischen häufig was "roughes" auf die schnelle sehen. Code-Optimierungen sind also zu dem Zeitpunkt noch nicht so wichtig.

Leider wäre es aber von Golive noch cleverer gewesen wenn sie sich bekannter Standards bedient hätten und zum Beispiel die FIND-Scripts, die ja extern auf Festplatte gespeichert werden, in einem XML-Format gepackt hätten. So könnte man sie auch mit Texteditoren bearbeiten.

Extensibility - Bigmouth Adobe

Schon unter dem Punkt Datenbank-Anbindung angesprochen: Einer der propagierten Vorteile von Golive 5 sollte die Offenheit der Architektur sein. DynamicLink sei offen, das JavaScript-SDK für Golive sei offen, die Actions sind offen. Es wäre nur eine Frage der Zeit bis eine Flut an Erweiterungen über die Kunden hereinbrechen würde.

Resümee fast ein halbes Jahr nach Erscheinen von Golive 5: In Sachen Datenbanken hat sich nix getan. Bei den Extensions wurden auf der Adobe-Site solche markerschütternde Dinge wie "WorldClock" abgelegt. Sowie sage und schreibe dreizehn weitere Extensions. Ob ein Modul zur Generierung von HTML-Code für japanische Handys wirklich das ist, worauf die Webgemeinde gewartet hat, bezweifle ich...

Speicherverbrauch

Zwar tut Golive so als würde es nur 48 MB RAM benötigen (ist so sowohl im Informationsfenster als auch in "Minimal Requirement" aufgeführt), doch dabei handelt es sich um Lug und Trug. Golive5 ist auf meinem 128MB-PowerBook nicht voll einsatzfähig! Unterm Strich bleiben nach Starten von Golive 5 auf meinem PowerBook gerademal 10 MB über, zuwenig um auch noch einen der beiden "großen" Browser zu starten. Da nach dem Booten noch 90MB überbleiben, greift sich Adobe nicht 48MB, sondern 80MB.

Das Verhalten von Golive wird dadurch unverschämter daß es selbst via Infomationsfenster sich nicht auf 32MB beschränken läßt (obwohl das "nur" die Mindestanforderung ist).

Zwar zieht Golive selber in der Tat lt. Speicherfeld nur 46-48MB. Zwar wird im Hintergrund auch nur eine weitere Anwendung namens ADM geladen, die sich auch nur 3MB zieht. Dafür schwillt das MacOS auf 66MB an, wird also um 20MB größer. Der reele Speicherverbrauch von Golive liegt damit also eher bei 70MB - 80MB.

SiteDesigns

Das Generieren und Verwalten einer Site via Diagramm und Zeichnungen ist eine praktische Angelegenheit. Rätselhaft bleibt allerdings warum man keine bereits vorhandenen Sites als "Design" einlesen kann. Stattdessen ist endlos viel Handarbeit nötig.

SourceCode

In meinen alltäglichen Arbeiten sind noch nicht allzuviele Neuerungen von Golive 5 eingeflossen. die Neuerung die es als erstes geschafft hat, war die SourceCode-Ansicht die man sich zur normalen Layout-Ansicht dazuschalten kann. Leider etwas langsam, aber es ist okay.

Und als dann im Dezember Dreamweaver 4 herauskam, mit einer besseren und schnelleren Sourcecode-Ansicht, gab es kein Halten mehr. Golive 5 setzt seitdem Staub an.

Resumé

Ich will nicht ungerecht sein. Es hat sich vielleicht bis dato angehört als würde Golive keine Stich gegen Dreamweaver bekommen.

Ganz so schlimm ist es nicht.

Ich sehe in der Tat keinen Sinn drin eine Site in Golive anzulegen. Im Bereich des Codings liegt Dreamweaver meilenweit vorne. Was aber für Golive spricht, sind die komfortablen Site-Management-Funktionen. Das betrifft sowohl das Site-Fenster, als auch die extrem erweiterte FIND-Funktionalität: Von der Volltext-Suche hin bis zur Untersuchung der Site nach bestimmten Gesichtspunkten (Dokumentenlänge, Navigationstiefe).

Es ist aber erschreckend wie grundsätzlich wenig sich an einigen kritischen Punkten beim Versionssprung von 4 auf 5 getan hat. Entweder hat die Golive-Truppe so lange gebraucht um die ganze Engine komplett umzuschreiben. Oder, und das wäre sehr erschreckend, man kennt seine Zielgruppe nicht mehr.

<<= Einleitung