HTML and CSS Reference
In-Depth Information
2.1 Designprinzipien
Orion war nicht der erste Vorstoß hin zu webbasiertem Tooling für das Eclipse-Plattform-Team. Wie
sich manch einer erinnern mag, gab es vor einigen Jahren Experimente, die Eclipse IDE als eine Mi-
schung aus HTML und Flash in den Browser zu bringen. Das stellte sich aber als speicherintensiv
und komplex heraus. Ein Jahr später haben wir gemeinsam mit dem Mozilla-Team die Machbar-
keit eines Java-Editors untersucht, der Kern-JDT auf dem Server als Sprachunterstützung und den
auf Canvas basierenden Bespin-HTML5-Editor verwendete. Obwohl diese Experimente letztendlich
nicht von Erfolg gekrönt waren, haben die Lektionen, die sie uns erteilten, das Design von Orion
geprägt. Schon zu Beginn legten wir vier Leitlinien fest, die wir seitdem im Großen und Ganzen be-
folgen und die uns noch immer bei vielen Entscheidungen helfen:
▪
Die Fähigkeiten des nativen Browsers nutzen:
Im Prinzip war das eine Lektion, die wir von
SWT gelernt haben. Es ist einfach unnötig, Tabs zu implementieren, wenn der Browser selbst
schon Tab-basiert ist. Soweit möglich, sollte man es außerdem vermeiden, das Standardverhalten
von Hyperlinks und eingebauten HTML-Input-Widgets zu überschreiben. Wichtig ist, dass der
Zurück-Button des Browsers funktioniert, und Dinge wie URLs sollten sowohl als Lesezeichen
verwendet als auch öffentlich zugänglich gemacht werden können.
▪
Task- und ressourcenorientiert vorgehen:
Benutzer, für die der Eclipse-Desktop neu ist (und
Entwicklern, die wir in der Webcommunity befragt haben), sind von den überladenen IDE-Fens-
tern unter Umständen geradezu erschlagen. Wir versuchen, jede Seite auf einen Task zu redu-
zieren und gegebenenfalls überflüssigen Schnickschnack zu entfernen. Das brachte uns auf die
Formel: Seite = Task + Ressource. Beispielsweise editieren wir (Task) jede einzelne Quelldatei
(Ressource) auf einer separaten Seite. Das funktioniert gut über Browser-Tabs und entspricht der
Art, wie Entwickler normalerweise Änderungen in mehreren Dateien handhaben. Ein positiver
Nebeneffekt dieser Strategie ist, dass Orion-Seiten verlinkt und auf vielen Ebenen verstanden
werden können.
▪
Performanz und Leichtgewichtigkeit anstreben:
Für alle Orion-Seiten ist eine Ladezeit von
weniger als einer Sekunde das Ziel. Wir legen Wert auf Techniken wie JavaScript-Build-Minifi-
zierung und verwenden Image Sprites, damit die Seite schnell lädt und effektiver den Cache des
Browsers nutzen kann. Einmal geladen, darf die Seite keine schlechtere interaktive Performance
aufweisen als das Desktopäquivalent, sonst tut das dem Immersion-Effekt Abbruch. Daher ha-
ben wir uns, wenn es abzuwägen galt, für schnelle Parser und einfacheren Modularitätssupport
anstelle der leistungsstärkeren, aber langsameren Alternative entschieden. Im Web ist Geschwin-
digkeit schlicht das Killerfeature.
▪
Niedrige Einstiegsbarrieren für Anwender:
Die Integration von neuen Tools sollte so trivial
sein wie ein Link in das Tool zu setzen und zu Orion zurück zu verlinken. Tiefere Integration und
