Contao zukünftig ohne das Artikelmodul?

[MacKP]

Das finde ich auch überflüssig, da sollte einfach der Typ stehen 'Text', 'Galerie' usw.

Genau da fängt mein Problem ja schon an. Bei 30 oder mehr Content Elementen finde ich (und auch meine Kunden) nie das richtige...
Und dann hab ich das bisher auch schon mit Hilfe von Artikeln logisch unterteilt!

Ich weiß nicht was ihr so macht mit Contao. Bei einfachen Seiten mit vll 5 Elementen in einem Artikel geht das vllt noch. Aber sobald da mal was größeres kommt haut das einfach nicht hin. Ich will einfach nicht, das Kunden dann anfangen alles in ein TinyMCE Content Element reinzukloppen, weil die nur dann noch alles wieder finden...

Viele Grüße

[Andreas]

...Bei 30 oder mehr Content Elementen finde ich (und auch meine Kunden) nie das richtige...

Ist von mir ja nicht so gemeint, dass du die gewohnte Ansicht der Elemente innerhalb eines Artikels dann nicht mehr hättest, die würdest du weiterhin sehen, wenn du auf Artikel bearbeiten klickst.

[andreasisaak]

Und ihr meint wirklich der Pagetree würde schneller laden als jetzt? Mit Seiten, Artikel und Inhaltselementen?

[backbone]

Es ist schade dass hier soviel aneinander vorbeigeredet wird.
Grade die "alteingesessenen" (zu denen ich mich jetzt mal dazu zähle) haben hier eine etwas "verbohrte" Ansicht, was ich eigentlich schade finde, da hier viele neue Ideen unterwegs sind, die mMn. durchaus beachtenswert sind.

Ich finde das Mockup toll vom Style her, auch von der Übersichtlichkeit, aber nichts ist perfekt und alleine das DropDown zur Seitenauswahl reicht nicht. In der ML hatte ich dazu folgendes geschrieben:

Instead of the jumpTo-Menu at the top, we could combine a breadcrumb and JumpTo

Root page > Page A > Subpage x

If click on Page A you see a Dropdown with all siblings of Page A (children of "Root page"). If you click an Subpage x you see a Dropdown with all children of "Page A". The children of Subpage x are expanded at the of the listing (like folders in a file system browser) and you have an "up navigation item" like ".." in file systems.
The Dropdowns could have submenus, where you can reach the whole tree below the clicked "head".

Contao wird nicht nur von Kunden redaktioniert. Es muss auch für erfahrene Webworker effizient sein. Je schneller ich eine Website gepflegt habe umso mehr Zeit bleibt für JS Spielereien und sonstiges (abgesehen davon ist es geschäftlich gesehen sehr interessant). Ich habe nach der 10. Seite oder so aufgehört Contao zu pflegen. Ich tue dies inzwischen nur noch, wenn es meine Entwicklungen erfordert, ansonsten machen das andere Leute, die an den Projekten, in denen ich involviert bin, mitarbeiten. Der Grund dafür ist, dass es einfach kein Spaß mehr macht:
- Zu viele Klicks für zu wenig Informationen über die Artikelstruktur (was befindet sich in einem Artikel?)
- Viele Pagereloads sind extrem nervig (Hallo, AJAX!)
- Die Inhalte auf EINER Seite lassen sich nicht ausreichend struktieren (Stichwort Container-Elemente) oder nur mit erhöhtem Aufwand (Artikel/CE-Referenzen mit Dummy-Pages)

Ich würde folgende Dinge für gut befinden (Begründung lass ich jetzt mal aus, da vieles von vielen Seiten schon diskutiert wurde, man kann sich gerne auf dem Camp darüber unterhalten):
- Artikel/CE und Seiten sollten getrennt bleiben
- CEs sollten nicht betitelt werden müssen
- Artikel sollten keine Deeplinks erzeugen (die Artikelteaser-Funktion entfernen)
- Artikel sollten generalisiert werden und ein CE werden, welches andere CE enthalten darf (im Folgenden CEC genannt für CE Container)
- Alle CEs (auch CECs) welche direkt unterhalb einer Seite zugewiesen wurden, müssen in ein Layoutbereich eingeteilt werden

Das wären so die Dinge, wo ich denke, dass es von allen Seite das beste enthält. Ob man solch eine Presentation wie in dem Mockup umsetzt, sei mal dahingestellt.a

[christian]

Es muss auch für erfahrene Webworker effizient sein.

... und genau für den ist das Konstrukt des "Artikels" DER Königsweg für viele Projekte.

Was die Contentpflege angeht: Es kann ja sein, dass viele hier Kunden haben, die selbst pflegen. Meine Kunden tun dies zu 80% nicht (ausser ggf. in Katalogen). Den selben 80% ist es auch egal, ob ihre Website auf Contao, einem Server oder einer Waschmaschine läuft. Hauptsache, sie läuft - und zwar so, wie es gewünscht ist und mit so geringen Kosten wie nötig (nicht zu verwechseln mit "möglich").

Btw: Wenn wir über Effizenz reden, müsste als erstes der ganze Theme-Quatsch dran glauben.

[hofff]

Und wo ist der Vorteil dabei? Dass ich bei jedem Element auch was dabei schreiben muss, um es identifizieren zu können, kann es nicht sein ... dass ich es ausklappen muss(!) auch nicht ... dann muss der Vorteil wohl ein hakeliges Dropdownfeld für die Seitenstruktur sein.

Super. Wenn ich mal genau nachdenke, fallen mir eine Menge Projekte ein, bei denen ich sowas komplexes wie die Seitenstruktur NICHT und keinesfalls in einem Dropdown-Quatsch sehen möchte. Und wie lucina schon sagte - es gibt sehr viele Projekte, bei denen die Artikelstruktur nur noch rudimentär etwas mit der Seitenstruktur zu tun hat. Und wo ein Artikel eben nicht nur etwas für eine einzige Seite ist.

Man kann das Ding sicherlich anders nennen. Container, Section, Artikel, Rumpelkiste - eigentlich völlig egal. Aber verzichtbar für Contao halte ich das strukturelle Element des "Artikel" in keiner Weise. Damit würde sich Contao selbst kastrieren und verschlimmbessern. Das Einzige, was ich persönlich für diskussionswürdig halte, ist die optische Zusammenführung von Seiten- und Artikelstruktur in eine Art Website-Struktur. Was aber wiederum mit gewissen Vorschauen und Icon-Wüsten nicht ganz einfach wird.

Nur - mal ehrlich: Haben wir keine anderen Probleme oder Ideen mehr?

100% Zustimmung ... zu jedem einzelnen Punkt!!!

fg
nicky

[MacKP]

Ist von mir ja nicht so gemeint, dass du die gewohnte Ansicht der Elemente innerhalb eines Artikels dann nicht mehr hättest, die würdest du weiterhin sehen, wenn du auf Artikel bearbeiten klickst.

Ich glaube, das ich dann das Bild einfach nicht verstehe.. da das ja genau das beinhaltet. Content Elemente nur noch mit deren Bezeichnung und nicht mit Angabe von Inhalt.

Viele Grüße

[backbone]

... und genau für den ist das Konstrukt des "Artikels" DER Königsweg für viele Projekte.

Wo schreibe ich, dass Artikel wegfallen sollen? Ich will das Artikel mächtiger werden (nämlich das diese zu generellen Containern werden, deren Funktion man programmatisch ansteuern kann über eigene "Artikeltypen").
Wo behaupten das überhaupt Leute in diesem Thread? Am Anfang irgendwo. Und der Threadtitel der inzwischen gar nix mehr mit der aktuellen Diskussion zu tun hat. Viele sagen nur, das Artikel nicht zwangsweise sein sollten und man sie nur dann einsetzen kann, wenn man es denn will oder die innere Struktur einer Seite dies erfordert.

Ich glaube, das ich dann das Bild einfach nicht verstehe.. da das ja genau das beinhaltet. Content Elemente nur noch mit deren Bezeichnung und nicht mit Angabe von Inhalt.

Seid doch nicht so unflexibel? Ich sehe nicht, wo in dem Mockup explizit eigene Betitelung für die CEs vergegeben werden muss. Bei dem Text CE und dem Galerie CE könnte es die Überschrift sein, beim News-CE der Titel des Newsarchiv. Wo ist das Problem eine (in der Nutzerdaten gespeicherten) Einstellungen anzubieten: Verkürzte CE Darstellung/Vollständige CE Darstellung anzubieten?



Randnotiz: Ich finde das lustig... mein Bruderherz regt sich häufig mal drüber auf, wenn ich jedes Wort auf die Goldwaage lege. Dann sage ich ihm als Informatiker hat man nun mal den Splien. Komischerweise bin ich hier der einzige, der versucht beide Seiten zu verstehen und aus beiden Lagern das beste herauszulesen, zu interpretieren und festzuhalten.

MacKP: Du kannst doch mit Photoshop? Warum nicht das Mockup hernehmen und 2-3 Verdeutlichungen machen, von dem was du Konkretisieren willst, wie es sein sollte.

edit2:
Überigens geht es hier primär um 2 Themen:
1. Wie kann die Contentpflege flexibler gemacht werden, sodass das "einfache" Seiten (wenig Content) nicht zur Klickshow werden und dass "große" Seiten (viel Content) übersichtlich bleiben.
2. Wie kann die Contentpflege angenehmer gemacht werden, durch ein besseres Redakteurs-Interface (aka Backend)
Beides sind 2 völlig legitime Forderungen, von denen ich behaupten muss, das Contao bei 1. noch nicht optimal ist und bei 2. noch weit der Zeit hinterher hinkt

[iainmacnab]

Wir finden es sehr hilfreich Seitenstruktur und Artikel getrennt zu halten. Insbesondere bei Kundenschulung. Die Seitenstruktur ist klar, kompakt und nicht überlaufen. Dann geht mann auf den Inhalt und basta! Die Kunden finden sich damit sehr gut zu recht. Wir haben eine Menge (positive) Erfahrung damit, mit über 40 Contao Implementierungen.

[andreasisaak]

Wir finden es sehr hilfreich Seitenstruktur und Artikel getrennt zu halten. Insbesondere bei Kundenschulung. Die Seitenstruktur ist klar, kompakt und nicht überlaufen. Dann geht mann auf den Inhalt und basta! Die Kunden finden sich damit sehr gut zu recht. Wir haben eine Menge (positive) Erfahrung damit, mit über 40 Contao Implementierungen.

Hier das selbe mit über 100 Contao-Installationen und vielen Contao-Schulungen.

[MacKP]

MacKP: Du kannst doch mit Photoshop? Warum nicht das Mockup hernehmen und 2-3 Verdeutlichungen machen, von dem was du Konkretisieren willst, wie es sein sollte.

Ich kenne PS und ich bin froh, das ich das noch nicht mal auf meinem Linux System installiert habe.
Ich glaube auch nicht, das ich das jetzige Backend noch mal aufmalen muss, damit du dir das anschauen kannst. Dafür reicht ein Blick in ein Contao Backend deiner Wahl.

Um es noch mal zu sagen:
Ich kann verstehen, wenn Leute nur kleine Seiten bauen, das die dann mit sowas daher kommen. Joomla macht das glaube ich auch genau so mit einem Dropdown. Aber: Mit den kleinen Seiten kann ich meine Brötchen nicht verdienen. Ich mache Seiten, die schon etwas mehr beinhalten als 5 Content Elemente.. selbst kleine Seiten versuche ich mit mehr Content Elementen abzubilden, da es dann einfacher in der Pflege wird.
Wenn jetzt meine Kunden keine Seitenstruktur mehr zu sehen bekommen (nur in einem Dropdown), dann fehlt denen etwas ganz elementares. Die haben dann das Gefühl in der Luft zu schweben und wissen nicht wo die sind. Das gefühl hatten die auch schon bei anderen Systemen! Und genau das haben die bei Contao nicht.

Wenn dann Artikel als Ebene wegfallen, dann hat man auch schon wieder ein Strukturproblem. Von mir aus können die anders heißen und was auch immer. Aber die Ebene weglassen (genau davon ist hier die rede!!!) halte ich für eine der schlechtesten Ideen (aus den schon genannten Gründen).

Wenn ich mir das Mokup weiter anschaue, dann fehlen da auch die Dinge, die ich weiter oben beschrieben haben. Ich weiß nicht, warum ich das nicht benennen darf... dafür ist ein Mockup doch da? Um darüber zu diskutieren? Wenns nun mal schlecht ist, das da nur noch 'Galerie' 'Text' etc. steht, dann muss ich das auch so sagen. Tut mir leid.

Viele Grüße

[christian]

Wo schreibe ich, dass Artikel wegfallen sollen?

Du nicht, und auch viele andere hier glücklicherweise auch nicht. Der Thread geht aber genau darum.

...durch ein besseres Redakteurs-Interface (aka Backend)
... und bei 2. noch weit der Zeit hinterher hinkt

Verbesserungen sind immer gut - sagt ja schon der Name . Was das BE angeht, halte ich die aber nicht für essentiell wichtig im Moment. Die Reaktionen von Nicht-Contaoanern sind eigentlich durch die Bank "Och, das ist aber einfach ... das verstehe ich ... endlich mal ein aufgeräumtes System ...". Von daher ist das BE eigentlich eines der Argumente für Contao. Aber um das BE als User-Interface geht es hier ja nur am Rande.

Was sagt denn der, der den Thread losgetreten hat aktuell dazu?

[backbone]

Ich kenne PS und ich bin froh, das ich das noch nicht mal auf meinem Linux System installiert habe.

Dann benutze bitte ein Bildbearbeitungsprogramm deiner Wahl um deine Ideen zu verdeutlichen.

Um es noch mal zu sagen:
Ich kann verstehen, wenn Leute nur kleine Seiten bauen, das die dann mit sowas daher kommen. Joomla macht das glaube ich auch genau so mit einem Dropdown. Aber: Mit den kleinen Seiten kann ich meine Brötchen nicht verdienen. Ich mache Seiten, die schon etwas mehr beinhalten als 5 Content Elemente.. selbst kleine Seiten versuche ich mit mehr Content Elementen abzubilden, da es dann einfacher in der Pflege wird.

Und ich sage es jetzt nochmal: Das DropDown ist sicher nicht optimal (habe ich vorher schon gesagt), aber das kann man durch ein anderes Navigations-Element ersetzen, welches besser geeignet ist. Ich hatte mich übrigens mal mit Tristan unterhalten, ob eine Baumansicht oder Ebenenansicht für Nutzer besser zur Navigation in Bäumen ist. Übersichtlicher und aufgeräumter, waren wir beide der Meinung, das es die Ebenenansicht (wie in den klassischen FS-Browsern) ist und einfacher zu handhaben.

Wenn jetzt meine Kunden keine Seitenstruktur mehr zu sehen bekommen (nur in einem Dropdown), dann fehlt denen etwas ganz elementares. Die haben dann das Gefühl in der Luft zu schweben und wissen nicht wo die sind. Das gefühl hatten die auch schon bei anderen Systemen! Und genau das haben die bei Contao nicht.

Das Problem ist, dass viele hier nicht

Wenn dann Artikel als Ebene wegfallen, dann hat man auch schon wieder ein Strukturproblem. Von mir aus können die anders heißen und was auch immer. Aber die Ebene weglassen (genau davon ist hier die rede!!!) halte ich für eine der schlechtesten Ideen (aus den schon genannten Gründen).

Ich schreibe es auch gern nochmal: In dem Thread geht es inzwischen nicht mehr darum "Artikel ja/nein". Die meisten die etwas geändert haben möchte, wollen dass Artikel/Container optional sind, wie CEs. Das würde die jetzige Arbeitsweise in keiner Weise tangieren, wenn man es nicht möchte, aber viele neue Möglichkeiten öffnen.

Wenns nun mal schlecht ist, das da nur noch 'Galerie' 'Text' etc. steht, dann muss ich das auch so sagen. Tut mir leid.

Der Typ steht da als erstes... danach etwas vom Inhalt (oder etwas, das den Inhalt beschreibt). Das ist beim jetzigen System GENAU so. Also musst du das jetzige auch scheiße finden?
Das dieser "CE-BE-Teaser" nicht manuell betitelt werden muss (was er nicht sollte), fordert das Mockup mMn. nicht.

Du nicht, und auch viele andere hier glücklicherweise auch nicht. Der Thread geht aber genau darum.

Inzwischen eben nicht mehr. Siehe oben.

Die Reaktionen von Nicht-Contaoanern sind eigentlich durch die Bank "Och, das ist aber einfach ... das verstehe ich ... endlich mal ein aufgeräumtes System ...". Von daher ist das BE eigentlich eines der Argumente für Contao. Aber um das BE als User-Interface geht es hier ja nur am Rande.

Da hier viele mit "großen" Seiten argumentieren: Also in einer Installation mit 10 Seitenbäumen, 50+ Seiten pro Baum und 5+ Artikeln pro Seite sieht die Aritkelansicht, alles andere als Übersichtlich aus, wenn man 2-3 Sachen aufgeklappt hat...

Was sagt denn der, der den Thread losgetreten hat aktuell dazu?

Das würde wirklich interessieren

[Hendriks]

Seit jeher verstehe ich nicht, wieso man diese (in der Praxis tatsächlich oft sehr sinnvolle und daher letzten Endes wohl auch unerlässliche) zusätzliche Container-Ebene eigentlich "Artikel" nennt.

Es möge mir doch bitte mal jemand eine Webseite zeigen, auf der mehr als ein einzelner Artikel (sinngemäß als solcher, in voller Länge) gleichzeitig zu sehen ist..!? So was habe ich zumindest in 10 Jahren des Dauer-Web-Surfens noch nie gesehen!

Egal ob die Dinger nun "Artikel", "Nachricht", "Event", "Blog-Beitrag", "Katalog-Eintrag", usw. heissen, es ist doch eigentlich immer das selbe Prinzip hinter einer modernen Website:

• Aufteilung nach Seiten / Menü-Navigation
  
  • statische (eher kleine) Inhaltseinheiten, Module, Werbebanner, etc.
  • eventuell auch ein (großer) statisch eingebundener "Artikel"
  • Teaser-Listen (mit oder ohne Seitenumbruch..)
  • verschiedenartigste Filter-Möglichkeiten
  • Leser-Module (wo dann –auch– das gesamte Ding angezeigt wird..)

Gut, vielleicht gibt es manchmal Seiten auf denen mehrere "Katalog-Einträge" in vollem Umfang angezeigt werden (wobei diese dann meist auch nicht ganze DIN-A4-Seiten an Text umfassen, wie es bei einem längeren "Artikel" ja schon mal der Fall sein kann/darf)..


Mein Lösungsansatz –der mir jetzt auch gerade kommt, wo ich die "Dinger" aufgelistet habe– wäre folgender:


1. Artikel als zusätzliche, system-strukturelle Container-Eben auf jeden Fall behalten, dann aber nicht mehr "Artikel" nennen, sondern vielleicht einfach "Inhaltsbereiche"...


2. Dafür aber vielleicht standardmäßig ein weiteres Core-Modul "Artikel" welches vom Prinzip her z.B. dem des Nachrichten-Moduls gleicht. Also ein Ort (Menüpunkt) an dem man (der Redakteur) tatsächliche Artikel zunächst einmal (ggf. auch nach Archiven getrennt) erfassen, verfassen und verwalten kann...


3. Oder aber, was ich fast noch besser fände, dass man die "Contalog"-Idee weiter verfolgt, wonach sich Contao im Ganzen in so etwas wie die Catalog-Erweiterung verwandelt:

Das könnte dann so aussehen, dass man in den allgemeinen Einstellungen zunächst einmal global festlegen kann, wie viele verschiedene "Inhaltsarten" ("Dinger") man im System haben möchte, und wie diese genau heissen sollen (z.B. "Artikel", "Nachrichten" und "Häufige Fragen", etc.). Jede dieser Inhaltsarten erzeugt dann einen eigenen, individuellen Menüpunkt (ein eigenes Backend-Modul) unter "Inhalte", z.B.:

• SEITENINHALTE* (spezielles, fixes Modul, wie bisher "Artikel"; auch meiner Meinung nach idealer Weise fusioniert zusammen mit der "Seitenstruktur", sowie zusätzlich unterteilt nach den "Layout-Bereichen" aus dem der jeweiligen Seite zugewiesenen Layout; und der dann im Gesamtkonzept vielleicht passenderen Bezeichnung "Seiteninhalte")

• Artikel (oder "Essays", oder what ever..)
• Nachrichten (oder "News", oder what ever..)
• Häufige Fragen (oder "FAQs", oder what ever..)
• ... ...

• Events (spezielles, fixes Modul, wie bisher)

• Newsletter (spezielles, fixes Modul, wie bisher)
• Formulare (spezielles, fixes Modul, wie bisher)
• Kommentare (spezielles, fixes Modul, wie bisher)

4. Die letzte Container-Ebene der "Inhaltselemente" zwar nach wie vor auf "Inhaltsbereich"-Ebene verfügbar lassen, aber auch genauso für jeden einzelnen Datensatz ("Nachricht", "Artikel", oder wie auch immer die Inhaltsarten bezeichnet werden) zur detaillierteren Strukturierung des Datensatz-Inhalts anbieten.

Die allgemeine Container-Struktur (und entsprechend auch die Baumstruktur der *SEITENINHALTE-Ansicht) würde dann folgendermaßen aufgebaut sein:

• Seite XYZ
  
  • Layout-Bereich
    
    • Inhaltsbereich (ursprünglich "Artikel")
      
      • Frontend-Modul (im Speziellen hier z.B. ein Datensatz-Leser-Modul)
        
        • Datensatz-Inhaltselement
        • Datensatz-Inhaltselement
        • ... ...
      • direktes Inhaltselement
      • ... ...
    • Inhaltsbereich (ursprünglich "Artikel")
      
      • ... ...
  • Layout-Bereich
    
    • Inhaltsbereich
      
      • ... ...

Wobei in der SEITENINHALTE-Ansicht dann natürlich nicht die Datensatz-Inhaltselemente einzeln aufgeführt werden.

Die Layout-Bereiche wären in diesem Modell also von den Inhaltsbereichen (vorher: "Artikeln") los-gekoppelt und würden in der SEITENINHALTE-Ansicht als weitere Strukturebene zusätzlich angezeigt werden. Sie wären hier jedoch nicht direkt editierbar, sondern werden automatisch –entsprechend der Einstellungen im der Seite zugewiesenen Layout– generiert/angezeigt. Bis auf diese Layout-Bereiche wären dann die Seiten, die Inhaltsbereiche, die Frontend-Module und die direkten Inhaltselemente bequem per Drag'n'Drop beliebig innerhalb der SEITENINHALTE verschiebbar...


5. Um die quasi-Auslagerung der "Artikel" in ein extra Backend-Modul zu kompensieren müsste es dann natürlich einen zusätzlichen Datensatz-Leser-Modul-Typ geben, welcher es ermöglicht, einen konkreten Datensatz auszugeben/anzuzeigen (anstelle der Ansteuerung/Auswahl über ein Datensatz-Lister-Modul).

...

[s.fakir]

Hallo zusammen,
erstmal toll wie viel Ideen und Erfahrungen hier eingebracht.
-----------------------------------------------------------------------

Kernmessage:
Um die Verbesserungssuche etwas zu optimieren schlage ich vor, dass jeder zunächst das Problem beschreibt, dass er mit seinen Vorschlägen lösen möchte .
So können wir am Problem diskutieren und nicht nur Vorschläge niederwelzen. =) Das wäre toll!

-----------------------------------------------------------------------

Ich fange direkt mal an:


Problem: 'Artikel Alternativen oder Verbesserungvorschläge'

• Vorschlag Inhaltskatalog mit Inhaltstypen (von Hendriks)
• Neuer Name für Artikel (z.B. Inhaltsbereich)
• Weitere Ideen?

Problem: 'Wo bin ich'
In der Bearbeitungsansicht sieht man nicht wo man sich befindet. Grundsätzlich wurde in Contao 3 schon durch eine Breadcrumb versucht da zu verbessern, das reicht aber meiner Meinung nach noch nicht aus.
? Lösung ?

Problem: 'Große Seiten zu unübersichtlich'
Auch durch mehrere Artikel wird die Navigation innerhalb von großen Seiten unübersichtlich. Ich würde es begrüßen, wenn man direkt über ein Frontend Plugin zum entsprechenden Backend-Artikel kommt (vielen bekannt aus dem alten Plugin fast-edit)

• Artikelbearbeiten aus dem Frontend aka Plugin "fastEdit"
• Weitere Ideen?

Problem: 'Grafische Übearbeitung Backend'

• Hier schlage ich persönlich vor auf Twitter Bootstrap zu setzen, tatsächlich halte ich das jetzige Backend aber für sehr gelungen und sehe den Zeitaufwand für eine reine Designüberarbeitung in keinem Verhältnis.

To be continued

[pmmueller]

Also ich weiß nicht. Ich finde das Backend so wie es ist ganz gelungen.

Anfangs fand ich einen umfangreichen Artikelbaum auch manchmal verwirrend, mit der Dopplung von Seiten- und Artikelnamen, aber seit ich mir angewöhnt habe, den Baum durch einen Klick auf den fett hervorgehobenen Seitennamen zu verkürzen ist das überhaupt kein Problem mehr.

Und wenn es darum geht, den Redakteuren das Leben einfacher zu machen, weil sie den Artikel- oder den Seitenbaum zu verwirrend finden, dann hilft doch eigentlich nur richtiges Frontend-Editing

[Hendriks]

Also ich weiß nicht. Ich finde das Backend so wie es ist ganz gelungen.

Anfangs fand ich einen umfangreichen Artikelbaum auch manchmal verwirrend, mit der Dopplung von Seiten- und Artikelnamen, aber seit ich mir angewöhnt habe, den Baum durch einen Klick auf den fett hervorgehobenen Seitennamen zu verkürzen ist das überhaupt kein Problem mehr.

Und wenn es darum geht, den Redakteuren das Leben einfacher zu machen, weil sie den Artikel- oder den Seitenbaum zu verwirrend finden, dann hilft doch eigentlich nur richtiges Frontend-Editing

Da hast Du eigentlich auch wieder Recht. Diese Konsistenz und Einfachheit macht Contao ja gerade auch aus. Ich sehe auch keinen wirklichen Grund, das Rad hier im Bezug auf das User Interface Design ganz neu zu erfinden. Contao ist und bleibt genial - so wie es ist, und auch so wie es sich stets in wohl überlegten (kleinen) Schritten weiterentwickelt hat!

Das Ding mit den "Artikeln" ist (so wie an manch anderer Stelle in Contao nach wie vor auch) meiner Meinung nach vor allem ein semantisches Problem, welches sich bereits über längere Zeit eingeschliffen hat... Ebenso die teils mangelhafte Orientierung für ungeübte Nutzer - ist bestimmt mit einigen wenigen, kosmetischen Handgriffen zu lösen...

[Andreas]

...Btw: Wenn wir über Effizenz reden, müsste als erstes der ganze Theme-Quatsch dran glauben...

Ich dachte immer, ich wäre der einzige der so denkt. +1

Sorry, aber bei dem Thread-Titel ist es halt nicht so einfach beim Thema zu bleiben.

Meine Vorstellungen hatte ich ja bereits skizziert:
Schneller an die Infos gelangen
Schneller an die CEs gelangen

[mike_mcfly]

Vermutlich folgen noch nicht alle der Google Group...

Äh, welche Google-Group? Poste mal den Link dazu...

[sandburg]

Äh, welche Google-Group? Poste mal den Link dazu...

https://groups.google.com/forum/#!to...Kw4/discussion


VG - sandburg

[Flex]

Äh, welche Google-Group? Poste mal den Link dazu...

Die, die ich unter dem Bild als "Quelle" verlinkt habe

[andreas.schempp]

Hört sich an als sollte man dazu eine Session am Contao Camp machen. Wer sich also noch nicht angemeldet hat: HOPP

[mike_mcfly]

Ich bin eifersüchtig: http://neos.typo3.org

[andreasisaak]

Wieso? Es zwingt dich doch niemand mit Contao zu arbeiten

[blackbee]

Hallo zusammen,

ich bin durch Zufall heute auf diesen Thread gestoßen, als ich nach etwas ganz anderem gesucht habe.

Beim Lesen dieser Threads und auch der Google Group dazu bekomme ich etwas Bauchschmerzen wenn die Artikel komplett wegfallen würden. Zumal das teilweise weitreichende Konsequenzen für Dutzende Webseiten hätte, die auf mehrere Artikel pro Seite basieren.

Dazu vielleicht nachfolgend mal ein Anwendungsbeispiel aus der Praxis, wo es mich schon nerven würde, wenn die Artikel an sich wegfallen würde:

1. Includen von Artikeln
Es tritt öfters der Fall ein, dass man bestimmte Elemente eine Seite gern auch auf den unter Seiten 1zu1 verwenden möchte. Daher bietet sich ein Include an. Dies kann nicht nur die Hauptspalte (main) betreffen sondern auch die Linken und Rechten Spalten. Würde es jetzt keine Artikel mehr geben, müsste man jedes Element, welches man auch auf den Unterseiten haben möchte erneut als Element anlegen oder aber als Single-Element includen. Bei einem Element mag das ja noch händlebar sein, aber was ist, wenn ich einen Artikel referenziere der 5 Elemente enthält und das auf 5 Seiten include und ich auf einmal ein Element hinzufügen möchte oder wegnehmen möchte? Das sind schon 5 x 5 = 25 Änderungen notwendig!

Gerade bei größeren Webseiten kann da schon mal eine ganz schöne Summe zusammen kommen und das Risiko etwas zu vergessen ist sehr groß.

(Hinweis: Ich bezog mich jetzt wirklich nur auf Content-Elemente eines Artikels wie eine Überschrift, Bild, Text - Module bindet man sowieso in 85% der Fälle via Layout ein)

Ein (kleines Beispiel) aus der Praxis:
Kontakt-Bereich mit einem Kontaktformular in der Hauptspalte mit einer Übeschrift und vielleicht einem kurzen Text und einem allgemeinen Kontakt-Block auf in der Link/Rechten Spalte. Man benötigt in der Regel die Überschrift "Kontaktformular" sowie die Kontakt-Daten ebenfalls auf der "Nachricht gesendet"-Seite. Ich realisiere das oft so, dass ich einfach die Artikel include. Würden die Artikel jetzt wegfallen, dann müsste ich jedes einzelne Element der Seite includen lassen.
Bei diesem kleinen Beispiel wäre das noch händelbar, jedoch nicht, wenn man wie oben beschrieben das auf x Seiten einsetzt.


2. CSS-Klassen und ID's für Artikel
Es ist möglich Artikeln CSS-Klassen und ID's zuzuordnen. Dies kann manchmal sehr hilfreich sein, wenn man darin befindliche Elemente bzw. deren Eigenschaften verändern möchte, wie zum Beispiel Angaben zu Margins, Paddings, Font-Sizes, etc. Wenn man einer Seite mehrere Artikel hinzufügt, kann man einem Artikel so eine Klasse zuweisen, wenn dies erforderlich ist.

Ein Beispiel aus der Praxis:
Ich habe ein oder mehrere spezielle Seiten mit folgendem Aufbau: Ich habe oben einen Slider, der Randlos gesetzt wird und sichtachsentechnisch bündig links und rechts mit der Seite abschließt. Die darunter folgenden Elemente (Überschrift, Text, etc). sollen aber einen Innen-Abstand wieder haben, damit sie nicht an den Rand geklatscht aussehen. Also weiße ich dem Artikel in dem Fall zum Beispiel eine Klasse zu, dass ein innenabstand gesetzt wird. Möchte ich zum Beispiel jetzt aber als Redakteur darunter noch einen Bild haben, welches bündig wieder abschließt, dann bräuchte ich nichts zu machen, als einen neuen Artikel anlegen mit diesem Bild und ihm keine Klasse zu weisen.


3. Zeitsteuerung für Artikel
Es kommt durchaus vor, dass man Artikel zeitsteuern möchte und alle darin sich befinden Element. Würde man keine Artikel mehr haben, müsste man jedem Element eine Zeitsteuerung hinzufügen oder den Besucher auf eine andere Seite umleiten.


4. Veröffentlichung und Entwurf
Ich habe Kunden, die teilweise bei größeren Änderungen von Seiten, den Artikel dublizieren und die Änderungen durchführen. Gerade wenn in einem Aritkel mehrere Text- und Bildelemente im Wechsel sind. So können die Änderungen durchgefürt werden, korrigiert werden und erst mit dem Online schalten auch auf der Webseite sichtbar werden.

Würde man die Artikel wegfallen lassen, müssten alle Element erst einmal händisch dubliziert und angepasst werden. Auch müsste für jedes Element wieder das sichtbar und unsichtbar eingeschaltet werden.

5. Übersichtlichkeit bei komplexen Webseiten
Bei komplexen Webseiten, kann es manchmal sehr hilfreich sein, wenn man einzelne CE-Elemente in eine Gruppe - sprich Artikel - zusammen fasst. Voraussetzung ist natürlich eine sinnvolle Bezeichnung des Artikels. Gerade wenn man eine Seite mit sehr vielen Elementen hat, wo aber sich nur immer ein kleiner Teil ändert, kann das Readakteuren helfen.


Meine Meinung
Grundsätzlich bin ich für einen Erhalt der Artikel in Contao - Verbesserungwürdig wäre in der Tat eine Bezeichnung für "Artikel". Das verwirrt am Anfang immer Kunden, sodass ich teilweise "Artikel" in Inhaltsbereich übersetzte, da es für Kunden einfacher ist.
Ich habe die Erfahrung gemacht, dass Kunden damit sehr gut zu recht kommen, vor allem in Hinblick auf Typo3 - dort ist es teilweise sehr umständlich.

Es ist oben angeregt worden, die Artikel als CE-Element zu machen. Insoweit die oben skizzierten Problem-Beispiele damit gelöst sind, wäre ich mit einverstanden. Für kleinere Seiten die nur 1 Artikel-Element haben, macht es Sinn dieses eventuell wegfallen zu lassen. Für größere Seiten (30 Seiten + x ) - würde ich ziemliche Bauchschmerzen teilweise bekommen, wenn ich auf einmal hergehen müsste und das Konzept und die Aufteilung anpassen müsste.

Was ich an Contao teilweise sehr schätze ist die Freiheit die man bei der Anlege von Elementen hat. Man kann bzw. der Redakteur kann sich entscheiden ob er erst einen Text, dann ein Bild, dann ein Download oder doch eine andere Reihenfolge haben will. Ich empfinde die Artikel als ein Stück dieser Freiheit, weil Sie quasi als Sammelblock für diese einzelnen Elemente dienen.

Zuätzlich helfen Sie gerade bei komplexeren Webseiten - vorrausgesetzt man hat sich intelligent benannt - einem leichter in der Übersicht zu verstehen, wo befindet sich welches Element.


Ich hoffe mein Beitrag hat ein Paar Anregungen in dieser Diskussion geschaffen.

[okapi]

Für mich ist dieser Container namens "Artikel" etwas, was mit vielen anderen Vorzügen die besonderen Qualitäten von Contao ausmacht: ein zusätzliches Strukturierungselement innerhalb der Seite zur Verfügung zu haben, als zusätzliche Gruppierungsmöglichkeit für Datensätze. In anderen CMS wie TYPO3 und Concrete5 muß mit Hilfe verschiedener Mittel recht mühsam konstruiert werden, was Contao out of the box zur Verfügung stellt.

Warum auf diesen grundsätzlichen Vorteil plötzlich verzichten?

Mehr als radikale Änderungen würde ich mir eher kleine Verbesserungen wünschen, wie z.B., dass es genauso leicht sei, vom Artikelbaum zum Seitenbaum zu switchen wie vom Seitenbaum zum Artikelbaum. Und dass die beiden Bereiche in der Backend-Navigation der gleichen Gruppe zugeteilt sein sollten, z.B. unter dem Titel "Website-Struktur". Denn weder hat für mich die Seitenstruktur etwas mit "Layout" zu tun, noch haben die Artikel etwas mit "Inhalten" zu tun, denn Artikel sind ja wie Seiten bloße Container, Strukturelemente.

[Messa]

Ich bin nicht dafür, dass die Artikel weg kommen

Da ich meinem Kunde zwar den Admin Login gebe, aber nur wenn sie es möchten.
Richte meinen Kunden immer einen eigenen Account ein dort werden nur die Artikel angezeigt und
die Sachen die von meinem Kunden gepflegt werden, Mehr nicht.

Darum wenn dann alles auf einer Seite ist geht, das ja nicht mehr oder nur bedingt.
Finde die Trennung schon sinnvoll.

Vielleicht sind die meisten neuen User einfach nur wegen der Bezeichnung bisschen ratlos und kennen sich nicht aus.
Was sind Artikel? Vielleicht wäre ein anderes Wort besser. (Nur ein Gedanke von mir)

Generell find ich einen Drag & Drop Ansatz wichtiger, damit ein paar Icons weg sind und es übersichtlich bleibt.
Wichtiger find ich, dass sich alles dahin entwickelt "Wie erleichtere ich meinem Kunden / Redakteur die Arbeit."
Was ich persönlich wichtig finde ist die FE-Bearbeitung, dass diese noch umfangreicher wird und einfacher in der Nutzung.

-> Text direkt anklicken bearbeiten
-> Bilder austauschen einfügen (Drag & Drop) (direkt vom Bildschirm?)
-> Menüpunkte deaktiviern / aktiviern
-> Menüpunkte hinzufügen / löschen (Seite wird direkt angelegt + leeren Artikel)
-> Module auf Seiten einbinden (Auswahl + reinziehen)
-> Umstellen von Themen (Weihnachten, Ostern, etc....) mit einem klick + Voransachit

Das nur so am Rande
Aber wie oben erwähnt würde ich die Artikel drinne lassen.
Vorallem was ist wenn man dann Updatet. Muss mann alles umstellen?

Twitter Bootstrap finde ich eine super Idee!

lg Matthias

[qba]

Ich finde es vor allem interessant, dass in Contao 3 für die News und Events ja gerade erst ein "Artikel" hinzugefügt wurde. Er ist der Platzhalter, damit ich meine News mit Inhaltselementen aufbauen kann. Also vom Bauchgefühl her Leo willst Du den Artikel nämlich auch

[psren]

Also vom Bauchgefühl her Leo willst Du den Artikel nämlich auch

Wie viele! Aber für eine kleine Webseite wäre es praktisch wenn der Artikel nicht Pflicht wäre. Ich kann aber muss nicht.
Ein Artikel könnte ein normales CE sein mit der möglichkeit Mehrere Kind-CE's zu haben (Das wäre auch für Accordion, Spaltenset, Slider etc echt praktisch).
Ich will die Artikel. Aber nicht als Pflicht.

[andi-bar]

schnell mal meinen Senf dazugeben:

die Idee, Artikel wegzulassen, finde ich eine gute Idee. Wie das technisch umgesetzt wird, davon hab ich zu wenig Plan.

Man muss in Contao erst ein Layout einrichten, dann Artikel im Layout einschalten, dann Module erzeugen, dann die Module in die Artikel legen. Contentelemente mal außen vor gelassen.
Artikel braucht kein Mensch.
Viel einfacher wäre es, eine Seite in der Struktur zu erzeugen und dort Module oder CE reinzuladen. Man könnte generell Module und CE vereinheitlichen. Also nur noch Module.

Alles viel einfacher... denk ich.



Und dann bitte auch schnellzugriffe auf CSS, Layout, ect.
Das nur mal so am Rande.
Es nervt, sich durchklicken zu müssen.


/senf end

:-)

[okapi]

schnell mal meinen Senf dazugeben:

die Idee, Artikel wegzulassen, finde ich eine gute Idee. Wie das technisch umgesetzt wird, davon hab ich zu wenig Plan.

Man muss in Contao erst ein Layout einrichten, dann Artikel im Layout einschalten, dann Module erzeugen, dann die Module in die Artikel legen. Contentelemente mal außen vor gelassen.
Artikel braucht kein Mensch.
Viel einfacher wäre es, eine Seite in der Struktur zu erzeugen und dort Module oder CE reinzuladen. Man könnte generell Module und CE vereinheitlichen. Also nur noch Module.

Alles viel einfacher... denk ich.



Und dann bitte auch schnellzugriffe auf CSS, Layout, ect.
Das nur mal so am Rande.
Es nervt, sich durchklicken zu müssen.


/senf end

:-)

Zwei Fragen drängen sich für mich auf, wenn ich deinen Beitrag lese:

1) Hast du diesen Thread überhaupt durchgelesen?
2) Warum arbeitest du mit Contao, wenn dir die Grundstruktur dieses CMS schon nicht zusagt?

Ich kann dir Concrete5 empfehlen, da ist alles so einfach, wie du dir es wünscht.

Michael

[MacKP]

Hallo andi-bar,
ich verstehe da auch 2 Punkte noch nicht so ganz:

Module und CE vereinheitlichen:
Das versteh ich nicht ganz... Module setzt man ja durchaus auch direkt ins Seitenlayout und CEs nicht. Warum sollte das dann wegfallen? Oder soll man CE irgendwo anlegen und dann erst in der Seite definieren welche CEs angezeigt werden sollen? Das würde das ja wieder verkomplizieren. Ich glaub ich verstehe den Ansatz einfach nicht ^^

Schnellzugriff:
Dann schau dir doch mal easy_themes an oder die ein oder andere Erweiterung, wo man dann selber direkt-Links definieren kann. Das gibts also schon ;-)

[andi-bar]

@Michael: Ich habe (schon vor langer Zeit) andere CMS durchprobiert. Contao (früher Typolight) ist ganz klar der Favorit. Öffne Dich doch einfach für eine neue Herangehensweise.
Den ganzen Thread hab ich narütlich nicht durchgelesen. Bin drübergeflogen. Wollte nur meine Stimme abgeben. Den technischen kram können andere ausdiskutieren. Ich hab mich aber angespornt gefühlt, meine Meinung dazu zu äußern, falls Zweifel bestehen, das umzusetzen und Userfragen behilflich für die Entscheidung sind. Wenn Du Dir sicher bist, dass man es nicht braucht. Diskutiere es nicht in der Öffentlichkeit

@MacKP: ich hatte immer directentries installiert. Läuft aber nicht mehr auf 3.0.0 und war gezwungen, eine neue Erweiterung zu suchen. Easy_themes kam mir gerade recht. Ich frage mich nur, warum das nicht von Haus aus implementiert ist. Benutzt Leo das CMS nicht selbst? Hat er soviel Zeit, sich durch Untermenüs zu klicken, um eine Seite fertig zu stellen? ;-) Wer solche Hindernisse einbaut, muss mit solchen Fragen rechnen.

Ja die Module sind fürs Layout, CEs für die Artikel. Stell Dir mal vor, man hätte keine Artikel und keine CEs und du könntest alles direkt in die Seite einbauen ohne einen Artikel anlegen zu müssen. Im Moment ist es also doppelt gemoppelt.

Wie das technisch umgesetzt wird, ist ja dann nicht wirklich meine Sache

Es geht auch nicht darum, ein quick and dirty system zu stricken, damit alle schön einfach schnell ne webseite basteln können.
Ich weiß nicht, wie oft ihr eine große Webseite neu aufsetzen musstet. Dann ist diese doppelte Arbeit einfach hinderlich und kostet zu viel Zeit.

Mein Grundgedanke wäre: Seite in der Struktur erzeugen. Seite editieren und dort Module platzieren. Wozu braucht man dann noch artikel? braucht man doch im Layout auch nicht Im Layout wird der Artikel zur Verfügung gestellt und erst dann kann man im Artikelmenü die Artikel bearbeiten. Kann man sich doch alles sparen?!

Denkt mal drüber nach

[MacKP]

Ja die Module sind fürs Layout, CEs für die Artikel. Stell Dir mal vor, man hätte keine Artikel und keine CEs und du könntest alles direkt in die Seite einbauen ohne einen Artikel anlegen zu müssen. Im Moment ist es also doppelt gemoppelt.


Denkt mal drüber nach

Hallo andi-bar,
dann schau dir mal an was ich dazu schon alles geschrieben habe. Ich habe darüber sehr gründlich nachgedacht und einige meiner Installationen durchgesehen und geschaut wann es der Fall ist, das ich mal nicht mehrere Artikel nutze.
Selbst bei kleinen Seiten nutze ich das! Davon mal ab, das man auch irgendwie sortieren möchte, was rechts, links, oben und unten ist ;-)

Viele Grüße

[okapi]

@ andi-bar
Artikel sind für mich Strukturelemente, Container, die mehrere Inhalselemente (auch Module) zusammenfassen können. Diese sind kopierbar, verschiebbar. So kann man also ganz einfach Elementgruppen zusammenstellen, die z.B. auch per inserttag auf einfachste Weise an beliebigen Stellen eingefügt werden können. Dieses Gruppieren von Inhaltselementen eröffnet doch äußerst vielfältige Möglichkeiten. Warum soll man darauf verzichten?

Die Nachfrage nach solchen Containern für Inhaltselemente hat bei anderen CMS, jeweils zur Entwicklung von Erweiterungen geführt: in TYPO3 sind das die sog. "Flexible Content Elements" (TemplaVoila), in Concrete5 wird dies mit sog. "Stacks" realisiert. Im Gegensatz zu Contao bringen beide Systeme diese Funktionalität nicht out of the box mit.

Was ich mir allerdings vorstellen könnte, wäre, das Element "Artikel" umzubenennen in "Box" oder "Container" oder ähnlich, und es optional zu machen. Dann könnten Seiten je nach Bedarf, entweder direkt mit Inhaltselementen befüllt werden, oder auch mit Gruppen von Inhaltselmenten ("Boxen").

Michael

[Andreas]

Erweiterungen die ich kenne um im BE Bookmarks auf bestimmte Seiten zu erstellen in meiner momentanen persönlichen Reihenfolge

1. ztheme_favorite
2. custom_be_modules
3. easy_themes
4. directentries

[psren]

und es optional zu machen.

Daumen hoch dafür. Was spricht denn eigentlich dagegen?
Für mich kann das nur ein Vorteil sein. Alle sind zufrieden.

(backbone hatte das ja schon vorgeschlagen (viel weiter oben, ich finde die Stelle gerade nicht.))

[Spelmann]

Contao ist das erste CMS mit dem ich mich nun ernsthaft und länger auseinander setze. Die Struktur "Seitenbaum -> Artikel (Container) -> Inhaltselemente" war dabei für mich ausschlaggebend. "Artikel" ist halt nur eine unglücklich gewählte Bezeichnung. Ich würde mich freuen wenn's so bleibt.

[andreasisaak]

Ich auch. Und falls doch wieder jemand auf die Idee kommt dieses hirnrissige Feature auszugraben, der soll sich mal dieses Bild anschauen:

https://www.dropbox.com/s/501vnorr8vr5qn3/artikel.jpg

Dort sind Seiten, Artikel und Inhaltselemente auf einer Ebene. Und dabei sind es nur 2 Sprachen, pro Sprache 7 Seiten und pro Seiten 4-5 Artikel.

Ich möchte mir nicht ausmalen wie das mit 26 Sprachen und über 50 Seiten aussieht.

[jan.theofel]

Hi,

ich unterschreibe das sofort! Viele meiner Projekte wären ohne die Anwesenheit von Artikeln absolut undenkbar. Vor allem mittelgroße bis große Projekte benötigen das oft für eine übersichtliche Darstellung.

Jan