Was erwartet ihr von einem guten Contao-Theme?

[Nina]

Im anderen Thread ging es um die Frage, was die bisher vorhandenen Themes im Theme-Shop von contao.org taugen. Hier soll es explizit NICHT darum gehen.

Stattdessen fände ich es schön, wenn wir hier Ideen/Gedanken dazu sammeln, was ihr von einem guten Contao-Theme erwartet (Framework, Art der Style-Einbindung, Einbindung von Third-Party-Extensions?, Einbindung verschiedenster Farbvarianten trotz dadurch entstehendem CSS-Overhead?, garantierte/nicht garantierte Updates, ...).

Ihr könnt auch dazu schreiben, was aus eurer Sicht schlecht für Contao-Themes ist bzw. was ihr euch von Theme-Herstellern wünscht. Bitte macht das aber als generelle Darstellung und nicht, indem ihr Thema X hier ins Rampenlicht zerrt und dann bashed. Also bitte KEIN Hersteller- oder Theme-Bashing hier. Das Thema soll eine Hilfestellung und positive Anregung (für etwaiges Umdenken bei Theme-Herstellern) sein, kein Ort für Vorwürfe.

[Nina]

Hier mal meine bisherigen Erwartungen an Themes:

// hab das mal umsortiert, damit es besser gelesen werden kann

HTML-Framework/angepasste Templates
Ich erwarte, dass ein kaufbares Contao-Theme auf dem HTML-Framework von Contao basiert. Template-Anpassungen sollten daher auf ein vertretbares Minimum reduziert sein. Natürlich sind Template-Anpassungen aber in Ordnung, denn gewisse Dinge kann man eben nur dadurch erreichen.

Art der Einbindung von Stylesheets
Bei der Einbindung von Stylesheets denke ich, dass es Sinn macht den internen Stylesheet-Generator von Contao zu nutzen. Der Gedanke dahinter ist, dass ich vermute, dass die meisten Käufer von Themes nur beschränkte CSS-Kenntnisse haben. Entsprechend gehe ich davon aus, dass für diese Käufer der Stylesheet-Generator (u.a. mit seinen globalen Variablen die schnellen Austausch von Farben, Schriften, o.ä. ermöglichen) eine wirkliche Hilfe ist.

Ich erwarte nicht, dass das CSS-Framework (Layout Builder) von Contao genutzt wird, da es auch Einschränkungen mit sich bringen kann.

Ich finde es nicht gut, wenn X-Farbvarianten fix in die Stylesheets eingewoben sind, da sich somit ein enormer Overhead an unnötigen Daten darin befindet, die dann bei jedem Seitenaufruf mit ausgeliefert werden. Wenn man Farbvarianten mitliefert, finde ich es gut, wenn das über optional auswählbare Stylesheets geschieht. Unter entsprechender Anleitung kann dann der Käufer statt einem blau-dominierten Layout z.B. das entsprechende Stylesheet abhaken und stattdessen das alternative rot-dominierte Layout-Stylesheet anhaken.
Wenn das Theme CSS über den Stylesheet-Generator einbindet, ginge das sogar noch einfacher über die Nutzung von globalen Variablen. Dann muss die Doku nur erklären, wie man die Farbwerte in den globalen Variablen austauscht - das wäre sogar noch einfacher als unterschiedliche Auswahl von Stylesheets.

Ich erwarte nicht, dass SASS oder vergleichbare Techniken für die Bearbeitung von Stylesheets enthalten sind. Das sind Methoden die imho von Profis genutzt werden - die wiederum meiner Meinung nach nur sehr unwahrscheinlich Themes kaufen. Vielleicht liege ich da aber auch falsch.

Art der Einbindung von Modulen/Elementen
Ich erwarte, dass alle Module des Contao-Core im Theme eingebunden sind.

Ich erwarte, dass Inhalte und Layout-Elemente möglichst basierend auf den optimalen Contao-Möglichkeiten eingebunden sind (mal abgesehen davon, dass die eine oder andere Möglichkeit bei Theme-Imports eingeschränkt ist).
Das bedeutet auch, dass ich z.B. erwarte, dass möglichst NICHT oder nur in Ausnahmesituationen das Inhaltselement HTML genutzt wird. Der durchschnittliche Redakteur kann kein HTML und sollte sich daher im normalen Redakteursbereich (in den Artikeln) auch möglichst nicht damit beschäftigen müssen. Eine Ausnahme sehe ich darin, wenn im Layout-Rahmen z.B. generell die Adresse im Footer des Layouts eingebunden ist und dabei mit HTML gearbeitet wird um z.B. Microdata oder schema.org Angaben eingesetzt werden. Das sind Bereiche die wahrscheinlich nie von Redakteuren angepasst werden.

Ebenso bedeutet das, dass ich erwarte, dass Layout-Elemente üblicherweise möglichst sinnvoll im Seitenlayout eingebunden sind und nicht hard-codiert in die fe_page. Begründete kleine Ausnahmen - wie immer - ausgenommen.

Stylings
Ich erwarte, dass alle Module des Contao-Core gestyled sind.

Ich erwarte, dass alle üblichen typografischen Elemente (Überschriften, Listen, Tabellen, Formular-Elemente) gestyled sind.

Außerdem sollte es gestylte Beispiele für "Boxen" geben (z.B. Infobox, Hinweisbox, Anregung zur Kontaktaufname, Warnbox, o.ä.)

Updates für das Theme
Ich erwarte nicht, dass im Kaufpreis unendliche Updates enthalten sind (wobei die Unendlichkeit bei Kaufzusagen rechtlich sowieso heikel sein kann ). Wenn das Theme möglichst wenig vom Contao-Standard abweicht, werde ich sowieso normalerweise ohne relevanten Aufwand das Update von Contao drüber ziehen können. Dann muss mir der Hersteller nichts zusichern.

Bei Major-Updates (z.B. von Contao 2 auf 3) erwarte ich noch viel weniger, dass das Theme-Update kostenfrei im ursprünglichen Kaufpreis enthalten ist, da ein Major-Update massivste Änderungen enthalten kann. Bei Contao 2 auf 3 war das z.B. ein kompletter Wechsel des grundlegenden HTML-/CSS-Frameworks. Ich fände es aber gut, wenn Hersteller beim Theme für die neue Major-Version einen Infozettel beilegen, der Käufern der Vorgänger-Version erklärt, was sie austauschen müssen, damit ihr altes Theme nun mit dem neu gekauften Major-kompatiblen Theme läuft. Ich geh da aber davon aus, dass man eben bei einer Major-Version das Theme neu kauft - schließlich musste ja auch voraussichtlich der Theme-Hersteller massiv neu Zeit in das Theme investieren und es ggf. vielleicht sogar ganz neu entwickeln.

Ich finde es aber gut, wenn der Hersteller zusichert, dass er z.B. für die nächsten X Monate Informationen bereitstellt, falls es kleine Contao-Fixes (kleine/mittlere Updates) gibt, die sich auf das gekaufte Theme auswirken. Also wenn z.B. ein offizielles Template für Newsliste A den HTML-Code im Core ändert und dadurch im CSS ein paar Anweisungen umgeschrieben werden müssen. Realistischer Weise erwarte ich aber eben nicht, dass der Hersteller mir das für einen sehr langen Zeitraum zusagt - schon rein aus normalen betriebswirtschaftlicher Logik heraus

Integration von Third-Party-Extensions
Schwierig finde ich die Sache mit der Integration von Third-Party-Extensions. Ich finde es schön, wenn Theme-Hersteller für sehr beliebte Extensions z.B. schon optionale Styles beilegen.

Ich frage mich aber, ob es rechlich in Ordnung ist, die Dateien von Third-Party-Extensions schon direkt mit auszuliefern - das können wir aber nicht hier klären, das müssen Theme-Hersteller mit ihrem Rechtsanwalt klären!.

Doku
Ich denke, dass Theme-Käufer eine grundlegende Anleitung zur Installation eines Themes sowie die Erläuterung der unterschiedlichen Einbindungsarten (sql über die install.php oder Theme-Paket über die Theme-Verwaltung) erwarten können.

Darüber hinaus ist jegliche weitere Form von Theme-Doku natürlich schöner Service und begrüßenswert.

Angaben vor dem Kauf
Ich erwarte von Herstellern, dass sie die Käufer vorm Kauf im Produkttext klar auf etwaige Besonderheiten hinweisen. Wenn ein Theme z.B. auf einem anderen HTML-Framework basiert, sollte das imho dabei stehen und auch fairerweise erläutert sein, was das in Bezug auf Updates bedeuten kann.

Ich fände es gut, wenn Hersteller im Produkttext schreiben, welche Templates modifiziert sind und vielleicht eine kurze Erläuterung dazu abgeben. Z.B. "DIV mit Klasse .content-wrapper in ce_text.html5 eingebunden um XYZ zu erreichen".

Ich erwarte, dass auf der Shop-Website im Impressum oder im Shop-Portal direkt im Produkttext die Geschäftsadresse des Herstellers steht, damit ich weiß, von wem ich da kaufe. Leider ist das bisher nicht immer so eindeutig.

Ich erwarte vor dem Kauf Infos zur Lizenz des Themes, damit man als Käufer weiß, ob das Theme z.B. auf eine Contao-Installation begrenzt/eine Firma begrenzt/unbegrenzt nutzbar ist. Eine unbegrenzte Nutzbarkeit erwarte ich persönlich nicht, da dann imho betriebswirtschaftlich die Relation von Kaufpreis zu Einsatzanzahl nicht mehr fair gegenüber dem Anbieter ist. Aber natürlich kann das jeder Anbieter selbst entscheiden.

Genauso sollte klar sein, ob man z.B. als Agentur das Theme kaufen und dann die Lizenz auf einen Kunden übertragen darf (wobei üblicherweise die kaufende Agentur dann selbst keine Lizenz mehr dafür hat).

Es sollte Infos zu den im Theme genutzten Fotos geben, also ob diese Bestandteil des Themes sind oder noch separat lizensiert werden müssen, wenn man sie nutzen möchte. Es wäre z.B. legitim, dass man in der Demo des Themes Fotos nutzt und dann im Produkttext schreibt, dass diese Fotos unter den Nummern X,Y und Z separat bei Fotolia o.ä. Anbietern erworben werden müssen, wenn man sie als Theme-Käufer auch einsetzen will.

[andreasisaak]

Aber ich frage mich, ob es rechlich in Ordnung ist, die Dateien von Third-Party-Extensions schon direkt mit auszuliefern - das können wir aber nicht hier klären, das müssen Theme-Hersteller mit ihrem Rechtsanwalt klären!

Mal davon ab das es rechtlich zu klären ist - wenn ich Themehersteller wäre würde ich es nicht machen da ich sonst jede Version der Extension vorhalten müsste. Ich würde an dieser Stelle eher eine Integration zu Composer oder zum ER2 anbieten wo ich die benötigten Extension nachinstallieren kann. Mit einem Knopdruck. Siehe Contao-Bundles.

Als Anregung an alle Themehersteller die sich in gewisser Weise abhängig von anderen Extensions machen.

[Nina]

Ein interessanter Ansatz, danke.

Ich habe zur Integration von Third-Party-Extensions in Contao-Themes ein neues Thema aufgemacht.

[Nina]

Aus aktuellem Anlass (gerade bei einer fremden Contao Layout-Umsetzung gesehen):

Ich erwarte bei Contao-Themes, dass CSS-Anweisungen möglichst global einsetzbar sind. So finde ich es z.B. nicht gut, wenn in den Styles einzelne Formularfelder explizit mit ihrer ID angesprochen werden. Ich habe soetwas gerade gesehen (und für dieses Beispiel hier sogar noch vereinfacht): #main .ce_form input#ctrl_4 { width: 50% !important; }

Das ist natürlich ein Weg, aber ein sehr begrenzter, denn sobald ein Redakteur im Formular ein Feld löscht und stattdessen ein neues anlegt, greift der Style nicht mehr oder an der falschen Stelle.

Daher finde ich es besser, wenn in Contao-Themes globalere Anweisungen geschrieben werden, die für Redakteure dokumentiert sind und von diesen bei Bedarf eingesetzt werden können. So könnte man z.B. eine Klasse a'la input.field-50 { width: 50% !important; } anlegen, die - wenn der Redakteur sie einem Formularfeld zuweist - dieses Feld dann nur noch mit einer Breite von 50% anzeigt. So könnte der Redakteur die Klasse bedarfsweise auch weiteren Formularfeldern zuweisen.

[jan.theofel]

Hi Nina,

sehr guter Text. Ich würde das fast alles so unterschreiben.

Bis auf diesen Punkt: "Ich erwarte, dass alle Module des Contao-Core im Theme eingebunden sind."

Nicht jeder nutzt alle Möglichkeiten von Contao. Für viele werden zum Beispiel Events oder der Newsletter verzichtbar sein. Ich würde daher erwarten, dass auf der Kaufseite klar ersichtlich ist, welche Module eingebunden und gestylt sind und welche nicht.

Jan

[Schneetiger]

Hallo Nina,

ich bin recht neu mit der Nutzung von Contao und verwende derzeit V 3.1 mit einem Theme. Da ich leider nicht jeden Tag damit arbeiten kann, habe ich mich für ein Theme entschieden, da dies eine schnellere Entwicklung ermöglichen soll. Der CSS-Code umfaßt dort weit mehr als 3000 Zeilen und die Anpassungsmöglichkeiten sind enorm, so daß ein Newbee damit schnell überfordert werden kann. Ich beherrsche zwar relativ gut CSS, aber leider noch kein SASS.

Was mir wichtig wäre, ist wie Du schon erwähnt hast, der globale Einsatz von CSS-Anweisungen, um bei Änderungen/Anpassungen auf der sichereren Seite zu sein. Auch fände ich eine straffere Verwendung des CSS-Codes recht angenehm, soweit dies möglich ist und Sinn macht. Was die Erweiterungen betrifft, denke ich, daß jeder selbst entscheiden können sollte, ob er die eine oder andere Erweiterung benötigt.

Ich hoffe, als Newbee einen qualitativ ausreichenden Beitrag geschrieben zu haben.

Viele Grüße
Scnheetiger

[KlausGrenoble]

@Nina: In Frankreich hast Du eine Menge Erfolg mit Deiner Frage.
http://forum.contao.fr/modeles-css/e...-t2786-15.html
Die Diskussion fängt schon heftig an (restructuration und catastrophique)

Il faudrait une véritable restructuration de Contao au niveau de la gestion des thèmes dans le BE (> Présentation de pages). Car je trouve que c'est tout simplement catastrophique actuellement.

Und gleich ein Vergleich mit Kiubi
https://github.com/contao/core/issues/5812
und mit WP:

WP est un CMS simple d'utilisation (ergonomique, bien pensé... mais pas forcément optimisé dans tous les cas, contrairement à Contao)

WP ist einfach in der Bedienung aber nicht optimiert wie Contao.

- WP dispose d'un système de galerie de thèmes en interne (dans le BE)
- WP dispose d'énormément de thèmes et de tuto sur le net
- WP plaît - d'une façon générale - aux non-initiés
Je pense que Contao devrait s'améliorer sur ces points...

- WP besitzt intern ein System von Galeriethemen
- WP besitzt enorm viele Themen und Tutoriels im Netz
- WP gefällt - allgemein gesehen - den Unbedarften bzw. Uneingeweihten
Contao sollte sich in dieser Richtung verbessern.

[andreasisaak]

Contao sollte sich in dieser Richtung verbessern.

Vielleicht will man das aber nur bis zu einem Grad Es muss nicht immer allen gefallen und allen recht gemacht werden. Viele fangen mit einfachen CMS'en an, landen dann irgendwann bei Contao und sind glücklich oder gehen weiter zu komplizierteren wie TYPO3. Ich persönlich fände es schade wenn Contao nun das nächste WordPress werden soll. Sorry für den Off-Topic aber ich habe das Gefühl das dieses "es muss leichter werden" immer eine Art Rechtfertigung ist wenn man sich nicht weiter mit der Materie auseinandersetzen will. @Klaus Ohne das jetzt auf dich zu beziehen.

[KlausGrenoble]

Hast Du recht. Das Gleiche habe ich gerade gepostet.

Faut peut-être pas avoir non plus un CMS Wpontao...

Wär' vielleicht nicht gut, am Ende mit einem CMS "Wpontao" dazustehen.
Und das sehen in dem Forum da auch einige so.

[ATLAS]

Nicht jeder nutzt alle Möglichkeiten von Contao. Für viele werden zum Beispiel Events oder der Newsletter verzichtbar sein. Ich würde daher erwarten, dass auf der Kaufseite klar ersichtlich ist, welche Module eingebunden und gestylt sind und welche nicht.
Jan

Das wird zu kompliziert für den Suchenden. Es sollte stets alles eingebunden sein was das System hergibt. Letztlich weiß auch der Theme-Ersteller nicht, welche Anwendung sein Angebot mal finden wird. Auch kann man nicht immer vorher wissen, was man später mal in die Webpräsenz mit aufnehmen will. Dann wäre es ärgerlich, wenn ausgerechnet dieser Bereich mit Kraft und Mühe selbst gestaltet werden muss.

Andersherum: wenn die Demo das schon nicht schafft, dann kann es stets nur privater Ehrgeiz sein. Zumindest bei den Freien Angeboten. Beim Kaufprodukt aber darf man den vollen Umfang durchaus erwarten. Meine Meinung.

[jan.theofel]

Hi,

Das wird zu kompliziert für den Suchenden. Es sollte stets alles eingebunden sein was das System hergibt. Letztlich weiß auch der Theme-Ersteller nicht, welche Anwendung sein Angebot mal finden wird. Auch kann man nicht immer vorher wissen, was man später mal in die Webpräsenz mit aufnehmen will. Dann wäre es ärgerlich, wenn ausgerechnet dieser Bereich mit Kraft und Mühe selbst gestaltet werden muss.

Ok, da hast du Recht.

Jan

[Kahmoon]

Aus aktuellem Anlass bei einem Forenbeitrag zu einem kostenlosen Theme:

Hier werden auch Contao Beginnern Templates mit einer HTML Struktur geliefert, die jedem mit ein wenig SEO Wissen die Haare zu Berge stehen lassen. Hier werden auf einer Seite fünf mal H1 Tags verwendet und das nicht nur im Contentbereich sondern auch in der Randspalte. Mir ist klar das es ein kostenloses Theme ist...dennoch sollte man solche Sachen sauber anordnen. Inzwischen sollte jedem bewusst sein das ein H1 nur einmalig pro Seite auftauchen sollte. Viel tiefer wollte ich da dann auch gar nicht bohren...

Nur eine Kleinigkeit..dennoch unnötig . Das geht ohne Mehraufwand sauberer!

just my 2 cents

[Nina]

Inzwischen sollte jedem bewusst sein das ein H1 nur einmalig pro Seite auftauchen sollte.

Immer vorsichtig sein mit solchen absoluten Wahrheiten Das mehrmalige Auftauchen von H1 ist spätestens seit HTML5 durchaus erlaubt und semantisch korrekt. Aber das ist ein Thema für sich - kannst bei Interesse gerne ein separates Thema dafür öffnen.

[Kahmoon]

Tatsache??? OK..dann ziehe ich diese Aussage natürlich zurück.. Alte Schule und so :-)

Edit & thx:
Matt Cutts Multiple H1: http://www.youtube.com/watch?v=GIn5q...ature=youtu.be