unique observer-identifier for bbcode and for Comanche Page Description Language (german thread)

neue medienordnung plus
  last edited: Wed, 17 May 2017 05:26:16 +0200  
This has never really been confusing to.me as I saw both as completely different things. $observer connects to the php context of pdl. But your concern is valid and I will take it on. Good catch, good to point out in the doco.

@Tobias Ich würde mich freuen, wenn du im Originalposting unique observer-identifier for bbcode and for Comanche Page Description Language abstimmst, sich positionierst. Dafür haben wir doch die tolle Hubzilla-Tools, damit diese helfen - wie hier - zeitsparend ein Meinungsbild zu einem bestimmten Anliegen zu abzufragen und dieses Bild auch aussagekräftig darzustellen.

Ich habe dieses Thread zusätzlich zu "unique observer-identifier for bbcode and for Comanche Page Description Language" gesatrtet, damit im Original-Posting die Nicht-Deutsch-sprachige User sich nicht benachteiligt fühlen. @Tobias
This has never really been confusing to.me as I saw both as completely different things. $observer connects to the php context of pdl.

Wir sind uns doch einig, dass wir als Hubzilla-Anwender nicht nur eingefleischte Programmierer, für die PHP, MySQL, MariaDB usw. selbserklärende Begriffe sind, erreichen möchten. Wenn man auch weniger technik-affine Hubzilla-Anwender im Blick hat, ist es m.E. sehr erstrebenswert die Hubzilla-Doku und die Hubzilla-Dingsbums, hier $observer und observer so in das Hubzilla-Ökosystem einzubetten, dass diese Objekte für einen Durchschnittsanwender vertraut und selbsterklärend sind. Und selbsterklärend in diesem konkreten Fall bedeutet m.E. diesem Durchschnittsanwender unmissverständlich mitteilen:
Es gibt das Ding observerBbc mit den Eigenschaften 1, 2, 3 und es gibt das Ding observerCpdl mit den Eigenschaften A, B, C.

Ich bin der Meinung, es ist vorteilhaft, wenn man diese observerBbc und observerCpdl -Definitionen so formuliert, dass man ohne Erwähnung von PHP oder sonstigen zu technischen Dingen auskommt.

@Deutschsprachige Nutzer+ #observerBbc #observerCpdl #comanche #identifier
hEARt PhoniX
  
Ich denke, daß hier 2 verschiedene Sachen vermengt werden. Wer PDLs schreibt und Webseiten baut und das generelle Verhalten/UI von HZ beeinflusst, sollte ein Mindestmaß an techn. Verständnis mitbringen und auch verstehen können, daß das zwei verschiedene Dinge sind. BBcode observer ist direkt lowlevel in Posts etc nutzbar, von Anwendern. Langfristig sollte da auch zumindest für die wichtigsten Dinge eine GUI geschaffen werden, ich hab nur noch 0 Idee, wie das umsetzbar ist. Wir haben inzwischen eine ziemlich komplexe Funktions- und Einstellungsvielfalt, das ist eine große Herausforderung. Für non-techies ist auch bbcode eine Zumutung.
Trennung Templating – doing.
Ich überlege gerade, wie die Doku verbessert werden kann, ob ich evt eine neue, andere Struktur vorschlage. Mehr Aktionsorientiert. Ich mach das gerne, das soll mein Ding werden. Mein Webbastelkurs den ich  noch baue ist nur ein Anfang.
Der wird umfangreicher als gedacht, aber ich setz Ideen um die ich schon vor Jahren hatte. Endlich. Nur leider ist mein Zeitbudget begrenzt, da ja auch Brötchen auf den Tisch wollen und auch Real Life essentiell ist. Das hab ich mal schmerzhaft gelernt.
neue medienordnung plus
  
Ich denke, daß hier 2 verschiedene Sachen vermengt werden. Wer PDLs schreibt und Webseiten baut und das generelle Verhalten/UI von HZ beeinflusst, sollte ein Mindestmaß an techn. Verständnis mitbringen und auch verstehen können, daß das zwei verschiedene Dinge sind. BBcode observer ist direkt lowlevel in Posts etc nutzbar, von Anwendern.
Sehe ich genauso. Das Problem ist, dass in der Doku das alles vermengt ist und man hat eine Chance, was in der Doku gemeint ist, zu verstehen, wenn man - wie auch immer - in die Hubzilla-Konzepte eingetaucht ist. Wer keine Zeit dafür aufbringen kann, möchte, um sich einzuarbeiten, ist als Anwender, Teilnehmer für das Hubzilla-Projekt verloren.

Ich überlege gerade, wie die Doku verbessert werden kann, ob ich evt eine neue, andere Struktur vorschlage.

  • Im Idealfall - ich nenne das Apple-Ansatz - braucht der Anwender keine Doku - weil die Anwendung, die Oberfläche selbsterklärend ist ;-)
  • Ich habe ein Paar mal hier im Forum wahrgenommen - ich hoffe, ich habe es korrekt verstanden, dass die Hubzilla-Macher es so planen, bzw. bereits umgesetzt haben, dass entsprechendes know-how, hilfreiche Hinweise passend zum jeweiligen Kontext eingeblendet werden, wenn man auf das "?" klickt. Ich bin skeptisch, dass es ein zielführender Lösungsansatz ist bei der aktuellen Ressourcenknappheit im Hubzilla-Projekt. Weil es funktioniert nicht einmal, dass bereits übersetzte größere Menge deutsche Hilfeseiten - bspw. https://hub.libranet.de/help/about oder  https://hub.libranet.de/help/features - für die User, die Deutsch als Standardsprache in Hubzilla eingeblendet haben, eingeblendet werden
  • ich persönlich halte es für zielführender zweigleisig zu fahren:
    • gezielt eine hilfsbereite Hubzilla-Community aufzubauen, die freundlich die größtenteils immer die gleiche Fragen der Hubzilla-Anfänger beantwortet
    • gezielt daraufhin arbeiten, dass mittelfristig eine Institution wie Linux Professional Institute ~ Hubzilla Professional Institute ~ aufgebaut wird. Damit Hubzilla-erfahrene Anwedner in die Hand ein Zertifikat bekommen können, womit ihre Fertigkeiten und Kenntnisse dokumentiert sind.
Nur leider ist mein Zeitbudget begrenzt, da ja auch Brötchen auf den Tisch wollen und auch Real Life essentiell ist. Das hab ich mal schmerzhaft gelernt.

Das mit den Brötchen ist ein ewiger Teufelskreis - bei so gut wie allen Mitwirkenden. Deswegen müssen m.E. parallel zu den technischen Problemen, Fragestellungen auch unbedingt derart buchstäblich existenzielle Probleme betrachtet und Konzepte, Pläne, Lösungsansätze entwickelt werden. Ein denkbarer Lösungsansatz ist die Etablierung einer Institution wie Verein, der Hubzilla-Aktivitäten koordiniert und unterstützt.