search

contao / core-bundle

[READ-ONLY] Contao Core Bundle
GNU Lesser General Public License v3.0
123 stars 58 forks source link

Content element "Backend Hinweis" für Entwickler/Redakteure #1683

Closed havutcuoglu closed 5 years ago

havutcuoglu commented 5 years ago

Hallo zusammen,

kann man zu den Elementtypen einen weiteren Content-Element als Backend-Hinweis hinzufügen, damit die Redakteure und andere Entwickler in Zukunft einfacher haben um es zu verstehen, was gemacht wurde und gemacht werden darf oder nicht?

Zur Zeit verwende ich immer HTML-Elemente um die Hinweise zu integrieren und blende es aus. So eine Funktion wäre sicher sehr hilfsreich für die Entwickler und Redakteure selbst.

Sonst schreibt man die Besonderheiten immer irgendwo auf dem Papier und gibt es an Redakteur oder Webseitenbesitzer weiter oder integriert man HTML-Kommentare sowie ich es mache.

standard

Klar es gibt auch eine Erweiterung von do-while https://packagist.org/packages/do-while/contao-ce_be_remarks aber damit ist man immer bei der Aktualisierung von Contao abhängig von anderen Entwicklern und diese führt nur zu Problemen (bitte nicht persönlich nehmen :) ).

Das Content-Element muss auch nicht viel können. Es reichen 3 Markierungen:

Ich hoffe das dafür auch von anderen Entwicklern bedarf besteht.

Examples

info warning alert
leofeyer commented 5 years ago

Klar es gibt auch eine Erweiterung […] aber damit ist man immer bei der Aktualisierung von Contao abhängig von anderen Entwicklern und diese führt nur zu Problemen

Diesem Argument folgend müssten wir ja alle Erweiterungen möglichst in den Core integrieren, damit man nicht "von anderen Entwicklern abhängig" ist. Das widerspräche jedoch völlig dem Prinzip von Contao!

Der Core sollte idealerweise nur die Funktionen bereitstellen, die die Mehrheit der Benutzer regelmäßig für ihre Projekte benötigt. Alles andere sollte in optionalen Paketen gekapselt sein, die man bei Bedarf installieren kann.

do-while ist ein aktiver Contao-Entwickler, der seit über 10 Jahren bei Contao dabei ist. Du kannst seine Erweiterung bedenkenlos einsetzen.

havutcuoglu commented 5 years ago

@leofeyer vielen Dank für dein ausführliche Antwort.

Eigentlich waren die beiden meine Argumente:

kann man zu den Elementtypen einen weiteren Content-Element als Backend-Hinweis hinzufügen, damit die Redakteure und andere Entwickler in Zukunft einfacher haben um es zu verstehen, was gemacht wurde und gemacht werden darf oder nicht?

Sonst schreibt man die Besonderheiten immer irgendwo auf dem Papier und gibt es an Redakteur oder Webseitenbesitzer weiter oder integriert man HTML-Kommentare sowie ich es mache.

Klar, ich entwickle mittlerweile auch seit 6 Jahren Webseiten mit Contao. Ich bin mit viele Probleme konfrontiert und mit manchen sogar immer wieder. Und genau das ist so ein Problem. Die Redakteure rufen immer wieder an und möchten nochmal wissen wie was genau funktioniert. Oder löschen include Elemente weil Sie meinen es wird nicht mehr benötigt etc. Manchmal weiß ich selbst nicht mehr was und warum ich gemacht habe :)

Wenn do-while als aktiver Contao-Entwickler das Bedürfnis hatte um so eine Erweiterung zu entwickeln, dann muss es was bedeuten oder einen Sinn machen.

Letztendlich, diese eine Inhaltselement würde die Contao Core auch nicht aufblähen.

Beste Grüße

Toflar commented 5 years ago

Ich sehe die Anforderung der Doku, aber die Lösung gefällt mir nicht. Es ist ja eben kein Inhalt sondern eine Erklärung zu einem speziellen Element. Ich könnte auch eine Erklärung zum Aliasfeld in der Seite haben wollen, dort gibt's keine Inhaltselemente 😄 Also wenn schon eine Lösung im Core, dann eine etwas flexiblere. Dafür bräuchte es aber erst einen 🦊 mit einer schlauen Idee 😄

fiedsch commented 5 years ago

Eine spontane Idee wäre, jedem Eintrag im Backend (einem Record in der Datenbank) ein weiteres Feld (z.B. help, ein Textfeld) zu geben, in das diese Informationen eingepflegt werden könnten. Zugriff darauf wäre dann einheitlich über das bereits vorhandene blauen (i) Icon, das die Daten des Records zeigt.

Nachteil -- neben der Arbeit, das im Core für alle Tabellen einbauen zu müssen 😱 -- bei Erweiterungen fehlt es, solange der Maintainer es nicht nachpflegt.

leofeyer commented 5 years ago

Ich bin gegen eine Lösung im Core.

Der Core sollte idealerweise nur die Funktionen bereitstellen, die die Mehrheit der Benutzer regelmäßig für ihre Projekte benötigt.

Das sehe ich bei dieser Funktion nicht als gegeben.

havutcuoglu commented 5 years ago

Der Core sollte idealerweise nur die Funktionen bereitstellen, die die Mehrheit der Benutzer regelmäßig für ihre Projekte benötigt.

Definiere bitte die Mehrheit 🤔, besteht diese mehr aus Contao-Entwicklern/Agenturen oder mehr aus den privaten Personen?

Privat Personen verwenden Homepage-Baukasten für Ihre Webseite. Es sind mehr die Agenturen die Contao verwenden um richtige Projekte damit in die Tat umzusetzen und anschließend mehrere Seiten Anleitungen für den Redakteur schreiben, wie man was anpassen kann.

m-vo commented 5 years ago

Ich habe so ein Feature noch nie vermisst.

Erklärungen sollten bei einem guten UI Design sowieso kaum nötig sein (ziele auf intuitive Bedienbarkeit). Regeln und Constraints sind eh besser in Code aufgehoben, wenn sie wirklich effektiv sein sollen.

havutcuoglu commented 5 years ago

Erklärungen sollten bei einem guten UI Design sowieso kaum nötig sein (ziele auf intuitive Bedienbarkeit). Regeln und Constraints sind eh besser in Code aufgehoben, wenn sie wirklich effektiv sein sollen.

@m-vo klar doch. Ich werde von nun an zu den Redakteuren sagen, Sie sollen sich die Codes anschauen und versuchen zu verstehen was so abgeht. Sorry aber, hier ist nicht die Rede von Programmierern, sondern von Backend-Redakteuren, die Inhaltselemente erstellen, bearbeiten und löschen.

Wenn man einen Zentralen Inhaltselement erstellt (z.B. Text-Element mit ID 1254) und diese später irgendwo anders mit Insert-Tag {{insert_content::1254}} integriert, dann braucht man eben solche Hinweis-Blöcke. Dadurch kann der Redakteur nicht aus versehen einen Element löschen.

Aber, da der @leofeyer gegen eine Lösung im Core ist, wird hier weiter zu diskutieren nichts bringen.

Euch allen einen schönen WE 🙋‍♂️

leofeyer commented 5 years ago

Aber, da der @leofeyer gegen eine Lösung im Core ist, wird hier weiter zu diskutieren nichts bringen.

Das würde ich so nicht sagen. Für mich ist halt die Voraussetzung "Mehrheit der Benutzer regelmäßig für ihre Projekte benötigt" nicht gegeben, aber wenn jetzt eine große Anzahl an Nutzern hier im Ticket kommentiert, dass sie die Funktion sehr wohl immer braucht, lasse ich mich gerne vom Gegenteil überzeugen.

frontendschlampe commented 5 years ago

Also grundsätzlich finde ich die Idee nicht schlecht, aber der Lösungsansatz über ein eigenes Contentelement sehe ich als falsch an, wie auch @Toflar schon geschrieben hat. Es bräuchte dann schon eine sinnvolle Lösung, die auch für andere Sachen funktioniert und die sich schön ins Backend einfügt. Und da wird's schon schwierig ...

Toflar commented 5 years ago

Wenn man einen Zentralen Inhaltselement erstellt (z.B. Text-Element mit ID 1254) und diese später irgendwo anders mit Insert-Tag {{insert_content::1254}} integriert, dann braucht man eben solche Hinweis-Blöcke. Dadurch kann der Redakteur nicht aus versehen einen Element löschen.

Da haben wir schon ein Problem. Es gibt Erklärungen für statische Sachen (also z.B. eine Eingabemaske) und Erklärungen für ein bestimmtes Element (dein Fall). Also grundsätzlich irgendwelche Erklärungstexte bei einem Input-Feld anzugeben ist ja nicht so schwierig (den Helpwizard haben wir ja eh schon) aber zu sagen "Hey Element 42 nicht verschieben/löschen weil" ist ja was was nur gerade für dieses Element gilt. Aus UX-Sicht ist für mich ein Hinweis irgendwo auf der Seite in einem anderen Element eh falsch. Richtig wäre die Warnung dann auszugeben, wenn ich auf den "Löschen"- oder "Verschieben"-Button klicke. Das sehe ich schon als eine Herausforderung an und ich sehe nicht, wie wir hier eine allgemeine Lösung für den Core bauen können. Es ist halt schon sehr individuell...

havutcuoglu commented 5 years ago

Richtig wäre die Warnung dann auszugeben, wenn ich auf den "Löschen"- oder "Verschieben"-Button klicke. Das sehe ich schon als eine Herausforderung an und ich sehe nicht, wie wir hier eine allgemeine Lösung für den Core bauen können.

Klar, das wäre noch besser 😃aber wäre zu viel des Guten.

(den Helpwizard haben wir ja eh schon)

Helpwizard finde ich sehr schön, wenn man diese nicht in DCA anlegen müsste, aber eine in Backend editierbare Helpwizard wäre auch eine Möglichkeit. ODER?

Toflar commented 5 years ago

Ja, aber:

Da hängt halt schon so einiges dran :)

ausi commented 5 years ago

Warum müssen die Hilfetexte übers Backend editierbar sein? Geht es nicht darum, dass die Redakteure die Hilfetexte sehen die vom Admin erstellt wurden?

m-vo commented 5 years ago

Wenn man einen Zentralen Inhaltselement erstellt (z.B. Text-Element mit ID 1254) und diese später irgendwo anders mit Insert-Tag {{insert_content::1254}} integriert, dann braucht man eben solche Hinweis-Blöcke. Dadurch kann der Redakteur nicht aus versehen einen Element löschen.

Das Grundproblem ist hier aber, dass Elemente nicht wissen wo sie per InsertTag eingebaut werden und deswegen nicht wissen ob sie ein Löschen verweigern sollten. Und eine manuelle Lösung für dieses Problem, die ein Entwickler implementieren könnte, wäre z.B. eine Element-Eigenschaft, die das Löschen verhindert (das ist der Contraint-in-Code-Part). Die Bitte an den Anwender etwas nicht zu tun halte ich für einen Designfehler. 😃

fiedsch commented 5 years ago

An @m-vo's Argument gibt es nichts auszusetzen, aber vielleicht ist @havutcuoglu's Beispiel mit dem Löschen des mehrfach verwendeten Inhaltselements auch "falsch". Nehmt als Beispiel für den Hilfetext doch etwas wie "Achtung, wenn Du diesen Text änderst, betrifft dies mehrere Stellen der Website". Also nur eine Information für den Redakteur, der über die Details der Verwendung des Inhaltselements aufklärt.

asaage commented 5 years ago

Für das oben angesprochene Beispiel verwende ich z.B. gern https://github.com/terminal42/contao-rootcontent. da komme ich nicht so leicht in die Verlegenheit Contentelemente in Templates zu verankern. In anderen Fällen verwende ich das Include-Contentelement - dadurch wird das OriginalElement bereits vor einer versehentlichen Löschung geschützt. https://github.com/do-while/contao-ce_be_remarks hab ich gelegentlich auch schon eingesetzt ich sehe aber da irgendwie keinen akuten Bedarf, das in den Core zu übernehmen.

Aybee commented 5 years ago

Grundsätzlich habe ich auch immer wieder Projekte, wo ich im BE spezielle Anweisungen hinterlasse. Dies mache ich teilweise mit unveröffentlichten CEs direkt an Ort und Stelle, oder auf einer unveröffentlichten Seite _README auf welcher ich mehrere Inhaltselemente mit Hinweisen hinterlege. Da müssen die Redakteure natürlich den Weg zu Artikeln - _README finden.

Auch ne readme.txt habe ich in files/ schonmal angelegt, oder ein readme.html5 in templates/.

havutcuoglu commented 5 years ago

@Aybee

Grundsätzlich habe ich auch immer wieder Projekte, wo ich im BE spezielle Anweisungen hinterlasse. Dies mache ich teilweise mit unveröffentlichten CEs direkt an Ort und Stelle, oder auf einer unveröffentlichten Seite _README auf welcher ich mehrere Inhaltselemente mit Hinweisen hinterlege. Da müssen die Redakteure natürlich den Weg zu Artikeln - _README finden.

Auch ne readme.txt habe ich in files/ schonmal angelegt, oder ein readme.html5 in templates/.

Das mache ich auch so. Das siehst kannst du hier an der Screenshot erkennen. https://github.com/contao/core-bundle/issues/1683#issue-437620630 Ich versuche an viele stellen die Hinweise in HTML-Elemente als Kommentar zu platzieren und deaktiviere Sie dann zusätzlich. Nur das ist für den Redakteur nicht sofort ersichtlich.

@m-vo

Die Bitte an den Anwender etwas nicht zu tun halte ich für einen Designfehler.

Da stimme ich dir zu. Allerdings ich gestalte die Websites nicht. Ich bin zwar gelernte UX-Designer und Mediengestalter in Digital aber bin in der Agentur als Web-Entwickler tätig. Meine Kenntnisse sind leider nicht gefragt. 🤷🏻‍♂️

@fiedsch

Nehmt als Beispiel für den Hilfetext doch etwas wie "Achtung, wenn Du diesen Text änderst, betrifft dies mehrere Stellen der Website". Also nur eine Information für den Redakteur, der über die Details der Verwendung des Inhaltselements aufklärt.

Genau so was meine ich auch. 👍

@Toflar

Da hängt halt schon so einiges dran :)

Das ist mir bewusst. Deshalb dachte ich an eine Möglichkeit wie Helpwizard. Man muss Helpwizard dafür nicht nehmen, wie der @fiedsch vorgeschlagen hat, kann man eben jedem Artikel-, Page- und CE-Eintrag in der Datenbank eine Zusatzfeld mit dem Namen Infowizard integrieren. Die Mehrsprachigkeit könnte man wie bei den Dateien/Bildern lösen z.B. wie die Titel, Alt und Link Attribute angelegt werden. So wie in Dateiverwaltung der Fall ist.

Ich bin mir sicher, wenn man etwas will, kann es auch in die Tat umsetzen.

Euch allen ein erholsames WE