Wer sich einen ersten Eindruck verschaffen will, geht einfach auf die Aloha-Website. Denn den oberen Contentbereich kann man versuchsweise bearbeiten:
Hier sieht man auch sehr schnell einige wesentliche Punkte des Konzepts. Der Editor präsentiert sich zum einen als schwebende Palette über dem zu bearbeiten Inhalt. Eine Vorschau als Zwischenschritt beim Erstellen und Bearbeiten von Content sei nicht mehr notwendig, verspricht Haymo. Alles wird sofort exakt so gezeigt, wie es auch auf der Website aussieht. Zum anderen ist die Zahl der auf den ersten Blick sichtbaren Buttons und Optionen gegenüber anderen Editoren radikal reduziert. Niemals mehr als 15 Icons ist die Richtschnur. Alle Bearbeitungsschritte für Inhalte seien schneller erledigt.
Auch unter der Haube wurde abgespeckt und auf neueste Technologie gesetzt. So nutzt der Aloha Editor beispielsweise keine Iframes, sondern wird pro Seite ein einziges Mal geladen - auch wenn zahlreiche Inhaltsbereiche bearbeitet werden sollen. Am Ende liefert er validen Code. Einen HTML-Quelltext-Editor gibt es konsequenterweise nicht.
Alles in allem macht der Aloha Editor einen sehr guten Eindruck. Zwar fehlen im aktuellen 0.9.1-Release zur Zeit noch wichtige „Real-Life-Funktionen“ wie zum Beispiel das Einfügen und Verwalten von Bildern und hier und da klemmt auch manchmal noch eine Schaltfläche, aber insgesamt hat der Aloha-Editor durch seine radikalen Ansätze ausgezeichnete Chancen, andere Editoren à la TinyMCE und FCKEditor als Standard-Editor in Open-Source-CMS wie TYPO3 oder Drupal abzulösen. Oder welchen Eindruck habt Ihr?
Aloha Editor: Idee und Technik
Die folgende Präsentation erklärt die Idee und was der Aloha Editor kann:
Weiterführende Links zu aktuellen HTML5-News auf t3n.de:
- HTML5: Eingabefeld mit Vorschlägen als Dropdownliste - t3n News
- 3D Web: Standards, Plugins und Frameworks auf einen Blick - t3n News
- HTML5: Überschriften und Einleitungen von Artikeln gruppieren - t3n News
15 Answers
von Pascal Birchler 16.07.2010 (10:58Uhr) 1.
Also für mich sieht das eigentlich nur wie ein auf MS Word gepimpter Editor aus. Da kann man genau so gut bei TinyMCE o.Ä. bleiben.
von Martin Brüggemann 16.07.2010 (11:04Uhr) 2.
Ich find den Ansatz super und im Vergleich zu TinyMCE revolutionär. Sicher nicht auf den ersten Blick von außen. Aber wer mal versucht hat mit TinyMCE validen XML-Code zu generieren oder ein Plugin dafür zu schreiben, weiß wovon ich spreche.
von PHPGangsta 16.07.2010 (11:38Uhr) 3.
Ich sehe nach wie vor das "Problem" HTML5. Da auf nicht absehbare Dauer noch Browser unterwegs sein werden die es nicht unterstützen muss man sich zumindest starke Gedanken machen über eine Fallback-Lösung, denn sonst wird man seine User ganz schnell vergraulen.
HTML5 ist genial in seinen Möglichkeiten, aber leider spielen die alten Browser in den nächsten Jahren noch eine zu große Rolle als dass man nur darauf setzen kann.
von Andreas Kuckartz 16.07.2010 (12:54Uhr) 4.
@PHPGangsta Voraussetzung ist für einen solchen Editor ist nicht eine allgemeine Unterstützung von HTML5 (was auch immer darunter konkret verstanden wird), sondern nur ein kleiner Ausschnitt, insbesondere das Attribut contentEditable. Das wird durch den IE bereits seit Version 5.5 unterstützt.Browser die es nicht unterstützten sind in einer kleinen Minderheit.
Andreas (kein PHP-Anhänger :-)
von Joey 16.07.2010 (13:23Uhr) 5.
Wenn da auch wieder alles reingeschraubt wird, was ein Rich TEXT Editor gerade nicht braucht (Bilder, Tabellen etc.), haben wir zwangsläufig wieder die gleiche Performance Katastrophe wie beim aktuellen htmlAreaRTE. Wobei der Ansatz, den Code nur einmal zu laden und dann einfach zu benutzen, deutlich smarter ist. - Hoffentlich bleibt das Teil dennoch so schlank wie möglich und gleichzeitig so funktional wie nötig.
BTW: Ich sehe das durchaus auch in einem Backend mit ähnlicher Struktur wie im aktuellen TYPO3 und nicht nur als reine FE-Editing Lösung
von Tom 16.07.2010 (13:25Uhr) 6.
HTML5 halte ich nicht wirklich für ein Problem. Bei nicht unterstützten Tags fällt der Browser auf das Verhalten für einen Inline-Tag zurück. Bei den neuen Input-Typen fällt er zurück auf "text". Und bei Audio- oder Videofiles kann man selbst ein herkömmliches "Object" oder "Embed" als Fallback angeben. Okay: Canvas, CSS-Animationen, Geo-Location API und SVG bleiben u.a. vmtl. ein Problem.
Es ist aber unter den alltäglichen Features (fast) nichts dabei, was sich nicht durch ein kleines automatisiertes Skript beheben lässt. Dass es freilich in alten Browsern mit einem Fallback nicht so hübsch aussieht, da muss der Kunde einfach durch. Eben das verklickert Microsoft seinen Kunden aber sowieso gerade indem sie öffentlich den Tod des IE6 fordern und verlangen, Kunden sollten stets die aktuellste Browserversion einsetzen.
von Karsten Dambekalns 16.07.2010 (14:39Uhr) 7.
@ Pascal Birchler: Birnen und Äpfel? Aloha mal ausprobiert? Ich hab TinyMCE & Co noch nie so *in* einer Website gesehen. Fassungslos...
von Joern 16.07.2010 (15:40Uhr) 8.
Ganz netter Ansatz, aber ohne Bildupload/einfügen bis jetzt nicht zu gebrauchen
von Digial Life – Links des Tages vom… 16.07.2010 (21:51Uhr) 9.
[...] Tschüß, TinyMCE, hier kommt Aloha Editor – schnell, simpel, HTML5 Ich glaue ja, auch andere Editoren werden sich weiterentwickeln. Und bisher brauchte ich immer auch [...]
von Aloha Editor » business model inno… 17.07.2010 (14:17Uhr) 10.
[...] editor contenteditable useable View more presentations from Haymo Meran. Via t3n – das Versprechen und die Vision finde ich ja toll: No Markup! No reload! No iframe! No [...]
von Florian Gutmann 18.07.2010 (23:42Uhr) 11.
@Joey Ein Grundlegendes Konzept von Aloha sind Plugins. Funktionen wie Tabellen, Bilder, Formatierungen und dergleichen sind alle als seperate Plugins realsiert. Das ermöglicht es einzelne Funktionen nach Bedarf zu laden und alles andere weg zu lassen.
von Daniel Brün 20.07.2010 (09:39Uhr) 12.
Der Ansatz ist super. Aloha arbeitet offensichtlich direkt auf dem DOM und bildet Markierungen, Copy&Paste etc. selbst in Javascript ab. Wer schonmal einen Editor programmiert hat weiss jedoch, dass die Probleme hier in den Details liegen. Wohin springt der Cursor nach dem Einfügen oder Ausschneiden? Wie nehme ich z.B. eine Überschrift auseinander, die ich nur zur Hälfte markiert und dann ausgeschnitten habe? Das funktioniert bei Aloha schon ganz gut, allerdings gibt es noch einen ganzen Haufen von Bugs und Unschönheiten. Und das sind bekanntlich die Dinge, die am längsten dauern und die einen beim ernsthaften Arbeiten in den Wahnsinn treiben, wenn sie nicht perfekt funktionieren.
Einen dermassen gut integrierten, performanten und erweiterbaren RTE habe ich bisher nicht gesehen. Von daher: Thumbs up, hoffentlich wird daraus was!
von Norbert Pomaroli 22.07.2010 (09:30Uhr) 13.
@Joern Das ist schon klar, dass hier noch grundsätzliche Funktionalität fehlt - nicht nur das Einfügen von Bildern. Ziel des jetzigen Releases war es auch nicht, einen fertigen Editor zu präsentieren, der alle Stückerl spielt, und sofort jeden anderen ersetzen kann!
Die Ziele waren viel mehr: Die Konzepte zu zeigen (Bearbeiten in der Webseite selbst, Plugin Konzept, ...), auf den Editor aufmerksam zu machen, Feedback einzuholen, Interesse zu erzeugen.
von Norbert Pomaroli 22.07.2010 (09:35Uhr) 14.
@Daniel Brün
Danke mal für das Lob! An den Bugs und Unschönheiten arbeiten wir natürlich noch, aber wie schon gesagt, sind das genau die Details, die einen am längsten beschäftigen.
von WebSchaker 05.04.2012 (11:10Uhr) 15.
Ich verstehe nicht wieso man überhaupt einen "Editor" benutzt, eine Textarea :
1. Müsste man den gesammten Administrationsbereich ins Frontend verlegen. Unmöglich wenn Administrationsbereich und Frontent auf verschiedenen Servern laufen und lediglich eine gemeinsame Datenbank haben.
2. Sind Editoren ohnehin das Problem. Sie sind Fehleranfällig und bei copy&past von einer anderen Webseite (z.b. Wikipedia) hat man 2 unterschiedliche Formate. Wer solche Probleme vermeiden möchte benutzt ohnehin eine textarea im zusammenhang mit Wikisyntax, Textile, reStructuredText, Markdown oder vielleicht auch BBCode. Diese haben auch den Vorteil dass sie von den HTML4 und HTML5-unterschieden unabhängig sind.
Übrigens Benutzt Auch Drupal by default ledigliche eine "textarea" um das HTML Raw zu bearbeiten. TinyMCE und co sind nur optional.