Contao zukünftig ohne das Artikelmodul?

[leo]

Hier können wir über https://github.com/contao/core/tree/...-more-articles sprechen.

In dem Feature-Branch sind die Inhaltselemente direkt in der Seitenstruktur gespeichert und es gibt kein Artikelmodul mehr. Es ist nur ein Proof of Concept, um herauszufinden, ob es sich lohnt, in diese Richtung weiter zu entwickeln. Natürlich müsste dann die Ansicht entsprechend angepasst werden, damit man die Spaltenzuweisung leichter erkennt usw.

[andreasisaak]

Wie genau verläuft dann die Konfiguration? Hast du davon eventuell einen Screenshot damit man sich das mal vorstellen kann? Er muss ja nicht perfekt sein.

[the_scrat]

Ah, hier gibts ja sogar einen Thread dazu, sehr gut.

Generell finde ich die die Idee klasse. Allerdings denke ich, dass es ein Chaos gibt, wenn der "Artikel" als Container wegfällt. Sofern ich das richtig verstanden habe.
Besser fände ich, wenn der Artikel weiterhin als Container der einzelnen Elemente vorhanden bliebe, jedoch direkt in der Seitenstruktur. Optional wäre es super, wenn man wie bisher üblich die Elemente aufklappen könnte. So wäre es - möglich - Contentelemente in der Masse (über mehrere Bearbeiten) im ganzen System/Seitenstruktur zu bearbeiten, was ja bisher nur innerhalb eines Artikels geht.

Die Contentelemente allerdings direkt unterhalb einer Seite zu hängen ist meiner Meinung nach nicht nur unübersichtlich (vorallem bei großen Seiten), sondern man müsste ja demnach auch jedem Element seine Position (header, main, left, right, footer) mitteilen, richtig? Also eine Einstellung, welche bisher der Container (=Artikel) übernommen hat.
Ebenso spricht dagegen, dass man mit der geplanten Methode keine "Artikel" per include Elemente weiterverwenden kann, sondern mühsam einzelne Elemente verlinken müsste.

Cool wäre also so ein Aufbau innerhalb der Seitenstruktur

+ Seite
    + Artikel1 (enhält Konfigurationen wie bisher, Position, Syndikation und ID/Klassen etc.)
     |_Contentelement-1
     |_Contentelement-2
     |_Contentelement-2
  + Artikel2
     |_Contentelement-1
     |_Contentelement-2
     |_Contentelement-2

Denn so kann alles auf-/zugeklappt werden, wie man es braucht und man sieht im Idealfall nur Seiten+Artikel.

[andreas.schempp]

Wie genau verläuft dann die Konfiguration? Hast du davon eventuell einen Screenshot damit man sich das mal vorstellen kann? Er muss ja nicht perfekt sein.

Ich denke Leo meinte damit auch, dass man sich das mal installieren kann
Wenn ich den Code lese, sehe ich dass jedes Inhaltselement einer Spalte zugewiesen werden kann.

Wir hatten das schon kurz diskutiert und angemerkt dass es dann eine andere Gruppierungsmöglichkeit für Grid etc. (ala Subcolumns?) geben müsste.

[andreasisaak]

Die Seiten und Artikel in einer Ansicht zu verbinden klingt toll. Auf Artikel komplett zu verzichten sehe ich kritisch und kann es mir ehrlich gesagt noch garnicht vorstellen wie man sich dann konfigurieren soll.

[NetMediaWork]

Übersichtlicher finde ich die bisherige Variante und als erstes stellt sich mir die Frage, was man damit erreichen will ?

[planepix]

Hallo Leo,

auch eben mal installiert.

Kommt in der Seitenstrukturansicht dann das Icon für Artikel weg?
Im Moment führt ein Klick darauf auf eine leere Artikelseite.

Wenn man den Editiermodus der Seite anklickt kann man Artikel anlegen. OK.

Ist zum einen sicher eine Gewöhnung - mir fehlt da aber das visuelle Nachvollziehen einer Struktur.
Warum nicht die Artikelansicht wie bisher anzeigen, aber eben unter der Seitenstruktur?

Root
-- Seite 1
--- Artikel 1
-- Seite 2
--- Artikel 1
--- Artikel 2
-- Seite 3

Eventuell kann man dann auch wieder je Seite auf- und zuklappen?

[sandburg]

Ich würde es begrüßen, wenn das Artikelmodul wegfällt! Für (Neu-)Redakteure (und Kunden) ist es manchmal ziemlich verwirrend, wo die Inhalte geändert werden sollen - intuitiv auf der „Seite“...!?

Und ein weiterer Grund für Redakteure (und Kunden) auf die neue 3er umzusteigen

VG - sandburg

[Babelfisch]

Ich würde die bisherige Trennung Seite/Artikel auch lieber aufheben. Um bestehende artikellastige Installationen mirgieren zu können, würde ich aber vorschlagen, als Ersatz eine Art Container-Element zu schaffen, welches bisherige Artikel „simulieren“ kann. Zusätzlich könnte man das Element dann auch dazu nutzen, Inhalte semantisch zu strukturieren. Ich stelle mir das in etwa so vor:

Seiten können direkt Inhaltselemente bekommen. Zusätzlich gibt es ein Container-Element, welches wiederum Inhaltselemente aufnehmen kann. Das Container-Element kann konfiguriert werden und bspw. ein Contao-2-Artikel simulieren. Es kann aber auch von Typ HTML-Article, -Header, -Footer, etc. pp. sein und somit zur sematischen Strukturierung genutzt werden.

Durch eine Extension oder einen Migrationsassitenten kann dann bei oder nach der Installation über ein vorhandenes Contao 2 entschieden werden, ob Seiten mit nur einem Artikel (was ja sicherlich die Mehrzahl sein wird) aufgelöst werden sollen oder ob die Artikel zu dem Container-Element vom Typ „Artikel“ oder „HTML-Article“ konvertiert werden soll.

Für Neulinge oder bei kleinen Webseiten kann man dann die Inhalte direkt in den Seiten anlegen und bei größeren Installationen kann man alles wie bisher und noch genauer strukturieren.

Gruß

[the_scrat]

Also, ich habs mir jetzt auch grad mal installiert. Ich persönlich würde auf jeden Fall ein Containerelement behalten, welches die Inhalte struktuiert. Artikel ist vielleicht die falsche Bezeichnung, Container trifft es eigentlich perfekt. Er regelt, den Anzeigebereich und auch IDs, Klassen usw. Fällt das weg, hat man es auch um einiges Schwieriger die Elemente auf der Seite "zusammenzuhalten". Ich nutze einen Artikel auch oft wegen seiner "Wrapper"-funktion, weil man damit alle enthaltenen Elemente sauber per CSS ansprechen und stylen kann.

Natürlich ist klar, dass die Version die da im Moment besteht nur ein erster Entwurf ist, aber sammelt man wirklich alle Elemente unterhalb einer Seite, gibt das ein Chaos. Vielleicht funktioniert das bei kleinen Seiten, aber sobald man pro Seite 20 oder mehr Elemente hat und braucht, weil sie beispielsweise in jedem Bereich (header, main, left, right,footer) gebraucht werden, gibt das eine Latte an Elemente und dann ist nix mehr mit "schön für Redakteure".

Hab mal kurz was im Photoshop zusammengebastelt. So würde es mir sehr gefallen. Vorallem auch aus dem bereits obigen Post genannten Grund, dass ich damit auch über eine komplette Seite, z.B. alle Elemente bearbeiten kann. Mehrfach hatte ich nun schon den Fall, dass ich 20 Artikel hatte in denen sich die Überschriften einzelner Elemente geändert haben. Also bleibt einem nichts anderes übrig als in jeden Artikel zu gehen und das Element zu bearbeiten. Das würde mit direkten Zugriff auf die Elemente umgangen bzw. eine Massenbearbeitung zulassen.

Zu-/Aufklappen müsste man jedoch die Elemente können. So hat man auf einen Blick direkten Zugriff auf die nötigen Elemente, ohne in einem "Wulst" an Contentelementen suchen zu müssen.


contao3-artikel-zusammengeklappt.png

contao3-artikel-aufgeklappt.png

edit: Noch eine Anmerkung. Um das ganze noch produktiver zu gestalten, bräuchte es nur wenige Filter in der Kopfzeile. Ich stelle mir hier etwas vor wie ein zeige alle Container aus [left] / [main] / [right] usw. und alles andere wird einfach mal ausgeblendet. So hantiere ich mühelos, auch bei großen Strukturen.

[MacKP]

Ich bin auch eder Meinung, das wir auf keinen Fall auf Artikel verzichten können. Wie viele schon anmerkten käme es sonst zu einem riesen Haufen Chaos im Backend. Die Idee von the_scrat ist an sich ganz nett. Bringt aber für Redakteure auch nicht viel Licht ins Dunkel (was z.B. war noch mal Überschrift oder Text?). Die Ansicht wie man sie jetzt in Artikeln hat ist schon super so um die Einzelnen Content Elemente gut voneinander unterscheiden zu können (vor allem bei komplexeren Seiten, mit 30 oder mehr Content Elementen).

Ich würde auch eher für eine Ansicht stimmen, die der jetzigen Artikel Ansicht stark ähnelt. Um die Seiten von Artikeln zu trennen wäre es vllt ganz praktisch, die Seiten eher nach links zu verschieben, damit man da eine deutlichere Trennung hat. Eventuell das ganze dann noch mit einem Filter oben, der einem dann auch nur die Seiten anzeigt.

Viele Grüße

[joe]

Guter Ansatz aber warum trennt man sich nicht von der Seitenstruktur, zieht diese in das Artikel Modul und nennt das ganze Seiten / Inhalte.

Das würde weniger Probleme machen, müsste Kompatibel zu älteren Version sein (klar muss man dafür was umbauen) und benötigt kein neues Konzept und die Nutzer müssen sich nicht komplett umstellen.

Was auch nicht vergessen darf ist das der derzeitige Worklfow nicht unnötig komplizierter werden darf, da sehe ich das größte Problem.

vg Joe

[planepix]

Lässt sich Seitenstrukturansicht und Artikelstrukturansicht nicht verbinden (siehe Screenshot)?
Alles auf einer Ebene, auf einen Blick.
Klickt man auf Seitenebene, werden die Seiteneigenschaften bearbeitet, klickt man auf Artikel, werden die Artikeleigenschaften und Inhaltselemente bearbeitet.

[joe]

planepix genau so meinte ich das. Man müsste allerdings etwas an dem User Interface arbeiten, da das nun doch sehr viele Buttons sind.

[andreas.schempp]

Findest du das nicht ein riesiges Icon-Chaos?

Die Spalten-Übersicht müsste natürlich gewahrt werden, aber das liesse sich bestimmt realisieren (z.B. mit einer Mehrspaltigkeit in der Inhaltselement-Ansicht). Allerdings sind imho die Artikel-als-Container sehr wichtig, und Subcolumns wird nicht wirklich übersichtlich.

[planepix]

Ja ist eben ein quick an d dirty, aber dann weiss man wovon man spricht

Man kann ja die Icons für Seiten in der Farbigkeit reduzieren, nur graue Icons verwenden, bei Hover farbig etc.
Aber das, wie gezeigt, denk ich jedesmal wenn ich zwischen Seitenansicht und Artikelansicht wechsle:
Eigentlich hab ich in der Artikelübersicht alles was ich benötige.

[BugBuster]

Und Ihr glaubt allen ernstes das wird übersichtlich?
Nee,bitte, lasst es so wie es ist.

[joe]

Ich hatte mal die Icons in ein more dropdown minimiert. Das ganze ist ein quick and dirty poc welches auf js basiert (findet ihr im Anhang). Dadurch würden die Icons minimiert werden.

Zu dem arbeite ich an einer Lösung für Drag and Drop. Auch hier gibt es einen beta Test unter: https://github.com/downloads/may17/c...g_beta_0.1.zip

Denke das beides dem Tree gut tun würde, vor allem könnte durch das Drag and drop der verschhieben Button entfallen (zumindest bei aktiven Javascript). Für Duplicate und New hätte ich auch schon eine Idee wie man das einfach lösen könnte.

Das nur mal so am Rande, um die Usability vielleicht etwas zu erhöhen.

Ich muss noch erwähnen das ich beide Lösungen rein in Google Chrome getestet habe und das dies nur tests sind.

[the_scrat]

Lässt sich Seitenstrukturansicht und Artikelstrukturansicht nicht verbinden (siehe Screenshot)?

Aber welchen Mehrwert würde so eine Ansicht bieten, bis auf dass man nun direkt die Seiteneigenschaften aufrufen/editieren kann? Man muss weiterhin in die einzelnen "Artikel" um die Elemente zu bearbeiten.

Natürlich gebe ich zu, dass es unübersichtlich wird, wenn man Artikel mit jeweils 20 Elementen hat. Aber dafür würde es ein einfacher Filter am oberen Rand tun, der solche "Elemente" ausblendet und nur richtige Elemente anzeigt, wie Text, Überschrift etc. Elemente wie Spaltensets (start, mittelstück, ende) oder Sliderelemente (start/stop) könnte man per Filter ganz einfach temporär ausblenden. Wenn man vielleicht sogar eine Art aufklappbare Selectliste mit Checkboxen hat (ähnlich wie im Excel beim Filter) in denen man die Haken setzt, von Elementen die man sehen möchte. Denke ich, dass von 20 Elementen nur noch wenige übrig bleiben, die für einen Redakteur von Bedeutung sind.
Und kann man die Elemente auf und zuklappen (unterhalb eines Artikels/Container) so bleibt die Ansicht immer sauber, da man selbst entscheidet, was man grad braucht.

Die "Augen" in meinem q&d Mockup waren auch nur ein Beispiel und sind sicherlich nicht schön anzusehen. Bei einer optischen sauberen Gestaltung kann man da sicherlich mehr rausholen. Entweder in Graustufen oder ohne Symbol.

Ich würde vielleicht sogar 2-Gleisig fahren. Klickt man auf editieren im "Artikel/Container"-Element, hat man die Ansicht wie bisher, kann die einzelnen Elemente per Drag&Drop verschieben und einzeln editieren. Doch in der Gesamtübersicht, für einen recht schnellen Zugriff, sehe ich wirklich einen sehr hohen Mehrwert. Ist halt nur eine Frage der Umsetzung. Vielleicht gibt es hier ja potente Grafiker, die eine zündende Idee haben :-)

[planepix]

Und Ihr glaubt allen ernstes das wird übersichtlich?
Nee,bitte, lasst es so wie es ist.

Im so gezeigten Stand: bedingt.
Das ist zu bunt.

Aber ist ja Work in progress

Ich finde es strukturell übersichtlicher - hin und wieder gibt es u.a. bei Schulungen Fragen wie:
Wenn das doch seitenbasiert ist warum sind die Artikel nicht entsprechend angeordnet?
Warum der Wechsel zwischen Seitenstruktur und Artikelansicht?
In der Artikelansicht ist doch alles zu sehen, warum kann ich da nicht auch gleich die Seiten bearbeiten.

Das fände ich gut in diesem Zuge zu verbesern; über die Optik etc. muss man sicher noch hirnen.

[BugBuster]

Dann lasst aber wenigstens die Artikel bestehen. Sonst sehe ich viel Aufwand bei Grid Systemen alles wieder so hinzubiegen.
Man stelle sich mal vor: Ich habe eine Seite, die hat 3 Artikel, je Artikel 10 Elemente. Die 3 Artikel werden per grid nebeneinander gelegt.
Nun fallen die Artikel wech. Ich soll nun 30 Elementen Gridklassen verpassen? Dazu müsste ich die auch noch umsortieren. Das soll ein Redakteur verstehen? Nee, ohne mich. Dann bin ich wech.

[planepix]

Aber welchen Mehrwert würde so eine Ansicht bieten, bis auf dass man nun direkt die Seiteneigenschaften aufrufen/editieren kann? Man muss weiterhin in die einzelnen "Artikel" um die Elemente zu bearbeiten.

Es spart enorm Zeit beim Bearbeiten. Die Wechsel zwischen Seitenansicht und Artikelansicht entfallen.

Das das noch nicht die Problematik mit Übersichtlichkeit der einzelnen Inhaltselemente löst, ist klar.
Wenn gleich dieser Schritt mit den sichtbaren Inhaltselementen prima wäre: Dann könnte man auch mal eben in x Artikeln Elemente über Mehrfach bearbeiten einfügen und ändern.

[planepix]

Dann lasst aber wenigstens die Artikel bestehen.

Ja versteh ich
Artikel würde ich belassen, nur die extra Anzeige dafür innerhalb der Seitenstrukturansicht ergänzen.

[joe]

@BugBuster Ohne Artikel wird das nicht funktionieren und so wie ich das sehe ist die Mehrzahl hier für Artikel. Ich kann mir auch nicht vorstellen das die Artikel ganz entfernt werden.

Das Thema Usability ist eh ein ganz großer Faktor in Contao. Ich denke das ein Ansatz wie ihn the scart gescribbled hat sinnvoll ist bzw. wie er schon sagte ausbaufähig. Ob das Teil nun Artikel oder Seitenstruktur oder Seiten / Inhalte heisst ist nebensache. Wichtig ist dass das Artikel und Seitenstruktur System sinnvoll vereint wird. Ich denke in dem Punkt sind wir uns alle einig.

[BugBuster]

Na Hauptsache da wird dann keine Scroll Orgie draus.
Ich arbeite fast nur in der Artikel Ansicht, habe also nicht ganz das Problem wie manch anderer hier. OK, ein Link vom Artikel zurück direkt auf die Seite wäre manchmal hilfreich, geht aber auch so.

Ich zweifle aber immer noch das die Redakteure, die wie hier angedeutet wurde den Unterschied/Sinn von Seite und Artikel nicht verstehen, es besser verstehen wenn nun alles auf einer Seite ist.
Praktischer wäre es sicherlich, aber wenn das nicht Usability mäßig gut erkennbar ist, höre ich schon das Fluchen : Mist, wieder der falsche Button...

[christian.kolb]

Ich finde die Idee super:

+ Kein zwingend vorgeschriebenes (und in meinen Augen meistens überflüssiges) Artikel Element mehr
+ Mehrere Inhaltselemente über Seiten hinweg bearbeiten (ohne Seitenwechsel, Möglichkeit für richtiges DnD)
+ Übersicht über mehrere Inhaltselemente über Seiten hinweg

- Wird bei vielen Inhaltselementen über mehrere Seiten unübersichtlich(, aber dafür gibt es ja Filter)

Das Artikel Element sollte trotzdem behalten werden. Viele benötigen die Artikel zur Gruppierung oder haben Redakteure die daran schon gewöhnt sind.

Ob das ganze jetzt Artikel oder Container oder sonst wie heißt ist ja egal (kann ja auch über die Langauge Files angepasst werden)

Ganz großes Thumbs Up für die Idee, die in meinen Augen ein echtes Usability Plus wäre.

Wäre das dann bereits in Contao 3 vorhanden?

Gruß
Christian

[the_scrat]

Na Hauptsache da wird dann keine Scroll Orgie draus.

Versteh ich nicht, warum soll es eine Scroll Orgie werden? Es würde sich nichts an der Ansicht ändern (sofern man zu und aufklappen kann). Im zusammengeklappten Zustand würde die Ansicht genauso groß oder klein sein wie die Struktur im jetzigen Artikel.

Ich arbeite fast nur in der Artikel Ansicht, habe also nicht ganz das Problem wie manch anderer hier.

Aktuell gibts ja auch keine andere Option wo anders zu arbeiten oder? ;-) Schätze mal der Großteil wird sich in den Artikeln aufhalten, zumindest wenn es um den Content geht

[xchs]

Wie sieht es denn mit der Performance aus, wenn im (Page)Tree nun auch Artikel/Inhaltselemente angezeigt werden sollen? Eine Funktion wie beispielsweise "Alle umschalten" könnte da - bei vielen Startpunkten/Seiten/Artikeln/Inhaltselementen - schon mal ordentlich auf die Ressourcen schlagen (insbesondere, wenn die Serverpower entsprechend limitiert ist). Vermutlich müsste man sich darüber auch den einen oder anderen Gedanken machen.

[the_scrat]

Wie sieht es denn mit der Performance aus, wenn im (Page)Tree nun auch Artikel/Inhaltselemente angezeigt werden sollen? Eine Funktion wie beispielsweise "Alle umschalten" könnte da - bei vielen Startpunkten/Seiten/Artikeln/Inhaltselementen - schon mal ordentlich auf die Ressourcen schlagen (insbesondere, wenn die Serverpower entsprechend limitiert ist). Vermutlich müsste man sich darüber auch den einen oder anderen Gedanken machen.

Das wäre allerdings ein Performanceproblem, wenn bei jeder Ansicht im Hintergrund alle Elemente geprüft werden müssten.
Könnte man das nicht damit lösen, dass man diese Struktur wie eine art Index (pro Seitenbaum) speichert bzw. wie ein Caching behandelt? Man speichert nur die nötigsten Informationen (welche man eben für diese Ansicht braucht) dann sollte dies recht schnell und performant sein, oder?

[f1shman]

Ich finde dies auch einen supper Ansatz.
Meine Kunden hatten oft mühe, den Unterschied zwischen Seitenstruktur und Artikel zu verstehen, oder wo sie genau was ändern mussten.

Evt. wäre es dann auch möglich, eine bessere Möglichkeit für mehrsprachige Inhalte zu implementieren.

[leo]

Ich verstehe das Argument "Artikel sind Container für Inhaltselemente" nicht. Seiten sind doch genauso Container für Inhaltselemente, oder?

[the_scrat]

hi leo,

technisch gesehen natürlich, aber wenn die Inhaltselemente direkt unterhalb der Seite liegen hat man es wesentlich schwerer bestimmte Bereiche per CSS anzusteuern. Wie oben schon geschrieben nutze ich Artikel oft um eine Gruppe Inhaltselemente wegen einer speziellen Stileigenschaft zusammenzufassen. Das wäre - ohne - Artikel dann nicht mehr so einfach möglich.

[MacKP]

Hallo leo,
ich versteh nicht warum du dein eigenes Konzept nicht verstehst ;-)

Seiten sind natürlich Container. Artikel genau so. Artikel gliedern ja noch einmal zusätzlich die Seitenbereiche oder Teilen das ganze ja sogar noch weiter auf in einzelne Seiten (Artikelteaser als Stichwort). Ohne die Unterteilung wird es zu einem eher unübersichtlichen Haufen an Content Elementen kommen. Bei größeren Seiten geht es mir öfter so, das ich 4 Artikel auf einer Seite habe, die dann nur die verschiedenen Bereiche beinhalten (rechts / links / mitte oben / mitte unten / etc.). Dadruch ist man wesendlich flexiebler und vor allem aufgeräumter, weil man dann nur an einer Stelle gucken muss wo das Content element der rechten Seite ist und nicht bei 80 Content Elementen den Überblick verliehrt.
Bei kleineren Seiten nicht so das Problem. Bei großen schon. Denn eigentlich baue ich (und ich empfehle es auch immer wieder) den Content immer mit dem passenden Content-Element auf und nicht alles in einem TinyMCE (wie bei News bisher üblich).
Zusätzlich bietet die Ansicht der Content-Elemtne in einem Artikel schon eine gute Orientierungsmöglichkeit an, weil da eben nicht nur steht, das da ne Überschrift ist. Ich habe sonst Seiten mit 10 Überschriften und dazwischen Listen, Tabellen, was auch immer. Was ist dann da genau was?

Viele Grüße

[Flex]

hi leo,

technisch gesehen natürlich, aber wenn die Inhaltselemente direkt unterhalb der Seite liegen hat man es wesentlich schwerer bestimmte Bereiche per CSS anzusteuern. Wie oben schon geschrieben nutze ich Artikel oft um eine Gruppe Inhaltselemente wegen einer speziellen Stileigenschaft zusammenzufassen. Das wäre - ohne - Artikel dann nicht mehr so einfach möglich.

Eventuell könnte man das so ähnlich lösen wie die Beschriftungsgruppen im Backend.

[sandburg]

Wenn ich diese Diskussion hier lese habe ich manchmal den Eindruck, dass einige Programmierer ihre persönlichen Vorlieben verwirklicht sehen wollen. Ich bitte den „normalen“ Nutzer / Redakteure nicht zu vergessen. Dieser sitzt nicht jeden Tag vor seiner Homepage und pflegt selbige. Und dafür ist doch ein CMS gemacht – damit technisch nicht so versierte Anwender ihre Seiten einfach und schnell pflegen können.

Vielleicht sollte man daher zunächst die Eingangsfrage beantworten: „Contao zukünftig ohne das Artikelmodul?“ Ich erwarte dadurch mehr „Benutzungsfreundlichkeit“ und bin dafür! Wie das Ganze technisch realisiert wird, ist dann Aufgabe vorgenannter Programmierer. Ich denke aber 90% der Contao-Nutzer wird die Umsetzung nicht interessieren – die sind froh (dank der Programmierer) ein noch einfacheres System bedienen zu können.

BTW: Die Darstellung auf einer Seite könnte doch analog wie die „Eingebundene Module“ im Seitenlayout bei den Themes aussehen = Inhaltselement | Spalte | Icons zum bearbeiten. Inhaltselemente sind auch heute schon per „CSS-ID/Klasse“ ansprechbar…

VG - sandburg

[andreasisaak]

Wenn ich diese Diskussion hier lese habe ich manchmal den Eindruck, dass einige Programmierer ihre persönlichen Vorlieben verwirklicht sehen wollen. Ich bitte den „normalen“ Nutzer / Redakteure nicht zu vergessen. Dieser sitzt nicht jeden Tag vor seiner Homepage und pflegt selbige. Und dafür ist doch ein CMS gemacht – damit technisch nicht so versierte Anwender ihre Seiten einfach und schnell pflegen können.

Vielleicht sollte man daher zunächst die Eingangsfrage beantworten: „Contao zukünftig ohne das Artikelmodul?“ Ich erwarte dadurch mehr „Benutzungsfreundlichkeit“ und bin dafür! Wie das Ganze technisch realisiert wird, ist dann Aufgabe vorgenannter Programmierer. Ich denke aber 90% der Contao-Nutzer wird die Umsetzung nicht interessieren – die sind froh (dank der Programmierer) ein noch einfacheres System bedienen zu können.

BTW: Die Darstellung auf einer Seite könnte doch analog wie die „Eingebundene Module“ im Seitenlayout bei den Themes aussehen = Inhaltselement | Spalte | Icons zum bearbeiten. Inhaltselemente sind auch heute schon per „CSS-ID/Klasse“ ansprechbar…

VG - sandburg

Ich betreue über 100 Installationen und lasse den Redakteur eben nicht aus den Augen. Ich nutze die Artikel seit dem ersten Tag und auch wenn es Kunden zuerst ungewöhnlich finden, habe ich in 5 Jahren noch keinen Kunden gehabt der sie einfach nicht verstanden oder nutzen wollte. Artikel sind perfekt um mal eben was neues auszuprobieren - Artikel kopieren, auf inaktiv setzen, neue Inhaltselemente erstellen und spielen bis es einem gefällt. Wenn dann alles passt, einfach den alten Artikel löschen und den neuen veröffentlichen.

Daher bitte ich dich als neuer User nicht gleich alle Programmierer/Entwickler über einen Kamm zu scheren. Nicht alle haben nur eine Installation, die Demo-Installation. Es ist schon schwierig genug von 2.11.5 auf Contao 3 zu aktualisieren. Wenn dann noch sowas wichtiges wie die Artikel wegfällt, dann werde ich das Update nicht machen können - dieser Aufwand gleicht einer neuen Website, inklusive einer neuen Schulung für das Backend. Und es geht hier primär auch garnicht um die Umsetzung, es geht hier um die "Benutzerfreundlichkeit". Und die sehe ich nach 5 Jahren deutlich gehn Sonne fliegen.

Langsam bin ich es leid das sich alle Neulinge mit ihren 3 Installationen hier melden und dann meinen alle anderen die die Idee nicht so toll finden wären ja nur verbohrt und würden das neue Konzept ja garnicht verstehen!

[lucina]

Bei größeren Seiten geht es mir öfter so, das ich 4 Artikel auf einer Seite habe, die dann nur die verschiedenen Bereiche beinhalten (rechts / links / mitte oben / mitte unten / etc.). Dadruch ist man wesendlich flexiebler und vor allem aufgeräumter, weil man dann nur an einer Stelle gucken muss wo das Content element der rechten Seite ist und nicht bei 80 Content Elementen den Überblick verliehrt.
Bei kleineren Seiten nicht so das Problem. Bei großen schon. Denn eigentlich baue ich (und ich empfehle es auch immer wieder) den Content immer mit dem passenden Content-Element auf und nicht alles in einem TinyMCE (wie bei News bisher üblich).

Ich hab lange überlegt, ob ich Artikel in bisheriger Form möchte oder nicht - und ich möchte Sie weiterhin.

Meine Gründe:

• alle meine Redakteure haben Zugriff auf Artikel und in der Regel nicht auf Seiten
• in größeren Installationen ist eine sinnvolle Gliederung über Artikel möglich
• auf einer Seite finden sich (ähnlich wie bei Marc) bei mir meist mehrere bis viele Artikel
• in Artikeln habe ich in der Regel so viele Content-Elemente, dass sie die Listing-Voreinstellungen von Contao (30) gerne mal sprengen
• insbesondere der Einsatz von semantischem HTML5 erfordert schon jetzt extrem viele zusätzliche Elemente
• der Einsatz von Gridsystemen mit möglicherweise diversen Layoutbereichen funktioniert artikelbasiert - wie das seitenbasiert mit Übersicht gehen soll ist mir schleierhaft
• eine Seite mit 100 Inhaltselementen ist weder transparent, noch für Redakteure inhaltlich fassbar - ein 'Artikel oben' mit den darauf platzierten Elementen hingegen schon
• es geht also ggf. eine Strukturierungsmöglichkeit verloren.

Je länger ich darüber nachdenke desto schlechter finde ich die Idee.

Die freie Zuweisung von Contentelementen zu Seiten / Artikeln hingegen ist ja für C3 auf der Roadmap.

Carolina.

[lucina]

Langsam bin ich es leid das sich alle Neulinge mit ihren 3 Installationen hier melden und dann meinen alle anderen die die Idee nicht so toll finden wären ja nur verbohrt und würden das neue Konzept ja garnicht verstehen!

Präventivhinweis: Auch wenn ich Deinen Groll verstehe - eine Trennung Neulinge / Profis ist nicht hilfreich. Es gibt unterschiedliche Bedürfnisse und unterschiedliche Qualifikationen. Bitte darauf achten, dass wir respektvoll miteinander umgehen und kein Bashing von Usergruppen betreiben.

Die Moderatorin

[pmmueller]

Ich verstehe das Argument "Artikel sind Container für Inhaltselemente" nicht. Seiten sind doch genauso Container für Inhaltselemente, oder?

Ja natürlich, aber dann fehlt eine Hierarchie-Ebene, die ich im Alltag äußerst nützlich finde. Ich würde diese Dreiteilung Seite - Artikel - Inhaltselemente nicht missen wollen. Siehe auch den Beitrag von lucina.

Ob man dafür im Backend einen oder zwei Seitenbäume benötigt, steht auf einem anderen Blatt, aber die Entscheidung sollte gut überlegt und gründlich vorbereitet werden, auch mit User-Interface-Studien vorab. Das Backend funktioniert meines Erachtens so wie es ist ganz hervorragend, und das sollte man nicht einfach so mal eben vorschnell ändern.

Eine Frage noch:
Geht es hier eigentlich über eine Änderung für die bevorstehende Version 3.0?
Oder eher über "demnächst"?

[CeeKay]

Da auf GitHub gerade der Release Candidate anklopft, dürfte das eher ein Thema für "demnächst" sein.