Und was IT und Rentner betrifft, so scheint es, dass die ITler in Rente nichts mehr mit IT zu tun haben wollen.
Das möchte ich so nicht stehen lassen (bin selbst so einer), denn die sind meist eh' schon engagiert.
Beiträge von hrybak
-
-
Es ist wirklich ärgerlich, wenn Entwickler ihre Produkte nicht weiterpflegen. Leider gibt es da keine Garantien nabhängig von der Unternehmensgröße,
So ist es. Deshalb kann ich aus eigener Erfahrung mit der Migration nach J4 nur empfehlen, soweit wie nur möglich die gegebenen Standards zu nutzen (Cassiopeiy, TinyMCE, Media Manager). Da mag es den einen oder anderen Nachteil geben (habe ich allerdings noch nicht gefunden). aber es erleichtert (hoffentlich) zukünftige Migrationen.
Denn gerade als nicht-kommerzieller Nutzer wird mir keiner den Aufwand bezahlen, den Upgrades und Migrationen mit sich bringen.
Was kann nun das CMS Joomla dafür, dass du dir augenscheinlich die falschen Partner für Erweiterungen ausgesucht hast?
Zu dieser Anmerkung habe ich eine Frage: woher weiß ich, dass ich den richtigen Partner für eine Erweiterung gewählt habe? Wenn ich z.B. seit J1.5 eine bestimmtes Template genutzt habe, immer gut und schnell unterstützt wurde und dann von Einzelkämpfer die Nachricht erhalte, dass eine Version für J4 nicht geplant ist?
Ich würde eher zu Buden tendieren, die sich auch abseits ihrer Erweiterungen an der Community beteiligen.
Und wie das Template-Beispiel zeigt ist auch das keine Garantie. Ich habe sowohl mit Einzelkämpfern als auch mit Entwicklerteams sowohl postive als auch negative Erfahrungen gemacht, wobei bei den negativen Erfahrungen hinsichtlich zukünftiger Weiterentwicklungen die Einzelkämpfer überwiegen. Aber das ist letztlich individuelles Schicksal.
-
Freut mich, dass wir helfen konnten.
Übrigens: die "Anfänger"-Webseite gefällt mir insgesamt sehr gut.
-
Wichtig ist zunächst, dass die beiden Kategorien über Komponenten > JEvents > Kategorien verwalten > NEU definiert wurden. Da genügt der Eintrag des Titels.
Die Zuordnung der jcs-Dateien zu diesen Kategorien erfolgt dann über Komponenten > JEvents > JEvents Dashboard > Kalender verwalten > NEU. Es erscheint folgende Eingabemaske
Hier ganz oben einen beliebigen Namen eintragen (kann auch identisch sein mit den zuvor definierten Kategorien). Danach weiter unten bei Kategorie wählen eine der beiden Kategorien auswählen und darunter auf JA setzen. Andernfalls werden eventuell Kategorien übernommen, die in der jcs-Datei mit anderem Namen vordefiniert sind. Anschließend weiter mit URL etc.
In der Kalenderübersicht sollte dann unter Kategoriename nicht nur DEFAULT stehen.
Das war jetzt im wesentlichen wahrscheinlich schon bekannt, aber vielleicht doch an der einen oder andern Stelle etwas anders ausgeführt.
Danach sollte bei der jetzigen Terminübersicht ganz unten eine Leiste erscheinen, wo die Kategorien ausgewählt werden können. Um dieses Kategorie-Menü nach oben zu bringen wäre leider ein Silver-Addon erforderlich. Es geht aber auch so über CSS:
Code#jev_maincal { margin-top: 3em; } div.event_legend_container {position: absolute; top; xem }x ( =20 oder größer) muss so angepasst werden, das die Leiste in die Lücke rutscht.
Alternativ und eventuell sogar besseer wäre folgende Lösung (das ist wohl das, was Elwood meinte): Für jede Kategorie wird ein eigener Punkt im Main-Menü angelegt. (Main-Menü > Neu > Menüeintragstyp = JEvents > Anzeige nach Kategorie. Darunter Kategorie auswählen.)
Ich hoffe das hilft etwas.
-
Also wir haben auf unserer Seite (https://www.tsg-dacapo.de/inde…k.listevents/2023/07/04/-) recht viele Kategorien. Eine davon ist Feiertage und Ferien und die entsprechenden Terminen werden über eine ics-Datei eingelesen.
Es sollte also gehen. (Leider ist das einer der wenigen Punkte, wo ich im Moment selbst nicht weiss wie.) Ich frage mal bei uns nach und melde mich dann, sofern nicht schon jemand anders geholfen hat.
-
zum 1. Punkt zunächst eine Frage (wir selbst sind schon seit Jahren Gold Member - daher weiss ich nicht, ob das bei der Gratis-Version möglich ist): können Kategorien definiert und die Termine einer Kategorie zugeordnet werden?
-
Aber, wie in meinem Post etwas höher geschrieben, kann man in einem Open Source Projekt ja selber tätig werden, und Teil des Ganzen sein. Und dann vielleicht auch mitbestimmen. Und dann vielleicht etwas unabhängiger werden.
Und wie ich dazu geschrieben habe, muss dazu Zeit und Fähigkeit vorhanden sein. Das trifft auch auf folgendes zu
Vorteile ist z.B. das es Kostenlos und der Quellcode einsehbar ist,
Hilft mir nur, wenn ich den Quellcode verstehe oder zumindest eine Erklärung dazu vorfinde, welche Motivation und welche Ziele hinter dem Code stehen also die Beschreibung der Anforderung. (Dass ich das bisher bei den Pull-Requests immer noch nicht gefunden habe, mag natürlich auch an mir liegen.)
Mir selbst liegt vor allem am Herzen, dass auch die sich beteiligen können, die kein Programmierkenntnisse besitzen oder einfach keine Lust mehr dazu haben (ich habe schon vor mehr 20 Jahren damit aufgehört - wollte einfach nicht mehr - aber Joomla hat mich dann doch dazu gebracht das eine oder andere Script zu schreiben
), und vor allem transparente Prozesse und nachvollziehbare Entscheidungen vorzufinden.Das hatte ich bislang vermisst, duch den Hinweis auf RFC sehe ich da jetzt aber Möglichkeiten und werde mich da etwas mehr mit beschäftigen. Soweit ich sehe ist es das, was ich eigentlich wollte. Wegen vieler anderer Aktivitäten wird ein entsprechendes Feedback aber in paar Tage warten müssen.
Aber noch mal zu dem Vergleich mit den Bits und dem Akkuschrauber. Ich denke der hinkt etwas. Denn es geht ja nicht um Änderungen der Oberfläche (Schraubenköpfe). Da gibt es eine Übergangsphase (Tausch der Werkzeug und Anpassung der Arbeitsmethoden) und gut ist. Bei Systemmigrationen geht es ja sehr oft um Änderung von Datenmodellen (Gewindeyp und -größe wäre hier vielleicht der angemessene Vergleich mit nachfolgender Überarbeitung von Gehäusen und Austausch von Komponenten) und dann entsteht richtig Aufwand. Und gerade das ist die Erfahrung der Nutzer mit dem Übergang von Joomla 3 nach 4 (Beispiel ist mein Lieblingsthema: Objektmodell und Verarbeitung von Bildern).
-
Zunächsteinmal zu den kleineren Dingen
Stellt ein Kunde eine Anforderung, die der Dienstleister nicht erfüllen kann gibt er einen Auftrag an einen Kollegen, der das umsetzen kann (und bezahlt ihn natürlich).
Und was machst Du mit der sehr großen Zahl von Privatleuten, Vereinen und anderen Enthusiasten, die gerade nicht das Geld haben jemanden zu beauftragen, auf der anderen Seite aber durchaus meinungsbildend gegenüber anderen potentiellen Nutzern sind? Deren Wünsche und Anforderungen fallen dann hinten runter?
Du übersiehst auch, dass Joomla keine Firma oder Konzern ist. I
Gerade das übersehe ich nicht. Wie ich schon an anderer Stelle sagte, fehlt Jommla der größere Sponsor, der Joomla selber nutzt und daher wichtige Ressourcen (z.B. auch Marketingkapazitäten) zur Verfügung stellt. Nur mit der Friwilligkeit der Engagierten geht es aus meiner Sicht langfristig nicht.
Hilfreich war jetzt aber der Link auf
Ich habe mir das angesehne und danach verstehe ich einige der Deiner Anmerkungen nicht. Denn dort steht eigentlich mehr oder weniger dass, was ich eingefordert habe. Ich zitiere mal aus Proposal Process Meta Document - 1. Summary (https://github.com/joomla/rfc/…epted/RFC-0-rfc-meta.md):
For a sustainable success of the Joomla project, Processes, Features and Specifications need to be well-thought and generally accepted. At the time of this writing (Jan 2020), the organisation does not have a defined process to ensure this.
This proposal aims to define a way to enable everybody in the community to suggest processes, features or specifications, and to define, how the community / project decides on the proposal.
Im weiteren steht dann open for non-developers usw. usf.
Ich schaue mir die Tage noch etwas inteniver an und melde mich dann ggf. nochmal.
Übrigens halte folgende Aussage für absolut kontraproduktiv
Ob ich als Core Entwickler Lust habe, dein Anliegen oder das irgend eines andere Anwenders zu bearbeiten, oder lieber eins, das für mich wichtig ist? Wer weiß.
Für mich heißt das, dass ich als Joomla-Nutzer den Launen der Entwickler ausgeliefert bin.
-
Die vorherige Fassung sollte eigentlich noch korrigiert werden hat aber nicht funktioniert. Daher hier nochmal der Beitrag in korrekter Form.
Hatte erst jetzt Zeit für eine Antwort, wobei mir der Hintergrund der Frage immer noch nicht richtig klar ist, da aus meiner Sicht Extention-Entwickler halt Extentions entwickeln und Core-Entwickler den Core.
Gefragt habe ich mich dann aber, warum für möglich gehalten wird, dass auch ich einen Pull-Request absetze. Das würde ja voraussetzen, dass ich ein Stück Code liefere. Für mich völlig undenkbar, da ich einfach nicht über die notwendigen Pogrammierkenntnisse verfüge.
Und dann fiel mir ein, dass auf meine Frage, wo die Anforderungen sind, auf diesen Link verwiesen wurde:
Hier sind die Anforderungen (jeder kann welche hinzufügen) https://github.com/joomla/joomla-cms/labels/Feature
Eine meiner Antworten war - auf Grund meines bis dahin unzureichenden Verständnisses - zuächst folgende (letztlich unsinnige)
da finde ich am Ende nur Quellcode, mit dem ich überhaupt nichts anfangen kann
Denn erst im Nachinein wurde mir klar, dass bei Joomla eine Anforderung gleich gesetzt wird mit einem Pull-Request.
Dagegen ist mein und nicht nur mein Veständnis von Anforderungen anders und weiter gefasst (einfach mal im Internet schauen, was mit Requirements Engineering gemeint ist (z.B. unter https://t2informatik.de/wissen…requirements-engineering/) - aber bitte bis zu Ende lesen bevor dazu Kommentare abgegeben werden). Danach wird zunächst formuliert, was das Problem ist, und auf dieser Basis die Nutzer-Anforderung(en) beschrieben, abgestimmt, ggf. detailiert, Testkriterien für die Abnahme definiert und an die Entwicklung weitergegeben (sehr verkürzt und generalisiert dargestellt). Die Entwicklung leitet daraus technische Anforderungen ab, die dann - im Fall von Joomla in Form von Code bw. als Pull-Requests - umgesetzt werden. Zum besseren Verständnis das Beispiel einer entsprechenden Nutzer-Anforderung:
Es gibt vier verschiedene Objektmodelle für Bilder (Einleitungsbilder, komplette Beitragsbilder, über den Media Manger eingefügte Bilder mit oder ohne Kommentar). Dies erfordert bei einer CSS-Anpassung der Bilddarstellung auf der Webseite ggf. vierfachen Aufwand. Die Anforderung ist daher, dass es nur ein einziges Objektmodell gibt unabhängig davon, ob die Bilder über den Media-Manager oder über Funktionen des Cassiopeia-Templates eingefügt werden.
Dies ist meine Anforderung (die an dieser Stelle aber nicht weiter diskutiert werden sollte), wobei mir selbst gleichgültig ist, wie diese Anforderung umgesetzt wird. Das ist Aufgabe der Entwicklung bzw. abgeleiteter Pull-Requests. Ich selbst kann am Ende lediglich beurteilen, ob das Ergebnis die Anforderung erfüllt oder nicht.
Dieser vorgelagte Prozess wird bei der Entwicklung von Joomla offenbar überhaupt nicht berückichtigt, d.h. eine Requirements Engeering bzw. Anforderungsmanagement (siehe auch meine Anmerkungen unter #51) existiert nicht.
Das ist aus meiner Sicht für die Zukunft von Joomla kein gutes Zeichen - denn so können die vielen Nutzer nicht abgeholt werden, die gerade keine Programmierkenntnisse haben, aber Probleme und Wünsche. Letztlich entscheiden also nur Programmierer oder Programmierfähige wie und was entwickelt wird - sehr oft abgekoppelt von der großen Welt der Nutzer. Denn viel zu viele Programmierer kennen die Welt der Nutzer nicht ausreichend gut. Ich weiß, dass jetzt viele protestieren werden, aber meine Erfahrungen aus unterschiedlichsten IT- und Softwareprojekten haben das immer wieder bestätigt. Es hilft leider nicht Programmierer ständig mit Samthandschuhen anzufassen, denn daran sind schon Millionenprojekte gescheitert. Weiter möchte ich das an dieser Stelle nicht vertiefen, nur betonen, dass dies nicht heißt die Arbeit der vielen freiwilligen Joomla-Programmierer nicht ausreichend zu würdigen - im Gegenteil.
Ausnehmen möchte ich beispielhaft Dienstleister, die ihre eigenen Anforderungen und die ihrer Kunden in der Regel recht gut kennen und beschreiben können. Aber was ist, wenn auch der Dienstleister kein oder nur sehr begrenzte Programmierkenntnisse hat und seine und die Anforderungen seiner Kunden nicht in ein Pull-Request gießen kann? Wo wird er seine Anforderungen und die der Kunden los?
Und damit kein falscher Eindruck entsteht: wir halten Joomla nach wie vor für ein hervorragendes Tool. Nicht umsonst steht auf unserer Webseite "Sponsored by Joomla". Aber ohne kritische Fragen und Anmerkungen geht's nicht vorwärts.
-
Nun habe ich erfahren, dass sich gerade dijenigen, die mit Ihren Erweiterungen und Plugins Geld verdienen sich die sogut wie gar nicht an der Core-Entwicklung beteiligen.
Die Erwartung, dass sich die Extention-Entwickler auf Grund ihrer Eigeninteressen von sich aus einbringen, halte ich leider für unrealistisch. Denn auch die Extention-Entwickler sind sehr sehr oft Einzelkämpfer oder kleine Teams und haben genug mit der Eigenentwicklung zu tun und es fehlt einfach die Zeit auch noch am Core mitzuentwickeln. (Berechtigt ist diese Erwartung allenfalls für die großen Extention-Anbieter.)
Jetzt wundert es mich auch nicht mehr, dass so viele Erweiterungen hinterherhinken und notwendige Updates erst später verfügbar sind.
Das hat auch damit zu tun, dass die Extention-Entwickler nicht vorab einbezogen sind, sondern mit Ergebnissen konfrontiert werden (sagte mir ein Extention-Entwickler). Wenn ich also denn Nachlauf der Extentionentwicklung deutlich verkürzen will, muss die Core-Entwicklung von sich auf die Extention-Entwickler zugehen, d.h. vorab über Planungen informieren, vorab Feedback einholen, vorab Entscheidungen bestätigen lassen und erst dann umsetzen.
Am Ende wird das für alle Vorteile bringen: die Core-Entwickler entwickeln auf besser abgesicherter Basis, die Extention-Entwickler können frühzeitiger entwicklen und die Nutzer können schneller neue/verbesserte Funktionen nutzen und sind zufriedener. Am Ende nützt das auch dem Image von Joomla.
Warten auf andere hat einen selbst noch nie weiter gebracht.
-
Noch ein paar Anmerkungen zu . . .
Es besteht der Wunsch, dass Joomla sich nicht ständig ändert und sich automatisch updatet.
Dem kann ich uneingeschränkt zustimmen.
Und jetzt das Tolle: Möchte ich diesen Prozess beeinflussen, hebe ich die Hand, und trete einem Team bei und kann durch mein aktives zutun Joomla, die Entwicklung und Migration sowie deren Auswirkung direkt oder indirekt beeinflussen....
Da ist es ja wieder das Totschlagargument. Wie ich schon in #51 sagte: nicht jeder, der Joomla nutzt, hat aus verschiedenen Gründen die Zeit oder das Wissen sich intensiver bei Joomla einzubringen. Überspitzt kann diese Aussage auch so interpretiert werden: wer sich nicht beeiligt hat selbst Schuld und kein Recht Forderungen zu stellen. Das führt dann leider dazu, dass sich eine Entwickler-Blase bildet, die von den Anforderungen der Anwender über kurz oder lang gar keine Ahnung mehr hat. Dahinter steckt offenbar auch die Ansicht, dass die Formulierung von Anforderugen eine Bringschuld ist, was aber zur weiteren Selbstisolierung der Entwickler führt mit dem möglichen Effekt, dass Softwareprojekte mit Volldampf gegen die Wand fahren (so meine Erfahrungen).
Dem kann u.a. durch aktives Zugehen auf die Endanwender (dazu sie unten) begegnet werden und durch das Akzeptieren, dass die Sammlung von Anforderungen eine Holschuld ist. So wäre es z.B. durchaus möglich die Anforderungen und Planungen für zukünftige Versionen mit jeder stable-Version aktiver und verständlicher (s.u.) zu kommunizieren und Feedback einzufordern und nicht nur auf Links (github ) zu verweisen, wo jeder seine Anforderungen plazieren kann, was dann doch die wenigsten tun bzw. vor allem nur diejenigen, die als Entwickler arbeiten. Ein stetig wiederholt angebotener Link wird sicherlich öfter genutz werden. Das wird sicher nicht die große Masse anziehen aber dennoch deutlich mehr Beteiligung erzeugen und vor Allem mehr Feedback der Endanwender bringen.
Wenn einer nicht entwickeln kann - er kann Entwickler entlasten und z.B. Tests machen oder Anforderungen (issues) verwalten. Zum Beispiel prüfen, ob ein gemeldeter Fehler wirklich ein Fehler ist - genau das was wir hier im Forum machen.
Wichtig wäre dabei allerdings auch, dass die Anforderungen besser erklärt werden. Mir selbst ist z.B. der dahinterliegende Problemstellung, die Ziele und die Folgen letztlich unklar (Beispiel: Template style assigned text plurals #40732 - da finde ich am Ende nur Quellcode, mit dem ich überhaupt nichts anfangen kann - was jemanden, der willens ist Feedback zu geben sofort wieder abschreckt.).
Da kann ich dann auch nur schwer testen, wenn ich die Anforderung gar nicht erst verstehe (weiteres Beispiel: ComponentDispatcher comments #41005). Da ist dann doch ein gewisser Erklärungsaufwand erforderlich. Andernfalls bekommt die Blase eine immer dickere Hülle, da wegen fehlendem Verständnis erst gar kein Feedback von außerhalb kommt.
Gibt es dafür Belege, Aussagen, Videos, Webinars oder was auch immer, das Beweist, dass es "denen ("da oben")" nicht bewusst ist, was ihre Entwicklungen für Konsequenzen hat?
Also hier im Forum habe ich dazu schon des öfteren Beiträge gefunden. Und die Ankündigung einer weiteren Major Version zu einer Zeit, wo die meisten Endanwender noch nicht einmal die Migration der aktuellen Major Version abgeschlossen haben, zeigt aus meiner Sicht schon, dass die Konsquenzen zumindest nicht in vollem Umfang klar sind.
Übrigens: wer mit einer Software und seinen Entwicklern nicht zufrieden ist kündigt das in der Regel nicht an sondern geht einfach weg (auch eine meiner Erfahrungen). Daher ist die Frage nach "Beweisen" an dieser Stelle nicht wirklich zielführend.
Unzufriedenheit wird übrigens auch und gerade durch Migrationen verursacht. Da wird lieber stillschweigend auf eine andere Software umgestiegen, selbst wenn es dadurch funktionale Einschränkungen gibt und der Wechsel Zusatzaufwand bedeutet (nach der Devise "Lieber ein Ende mit Schrecken als ein Schrecken ohne Ende" - da können selbst Kosten von zig-Millionen einen Wechsel nicht verhindern, wie Beispiele aus der Industrie zeigen). Denn eines muss auch klar sein: funktionale Defizite können durch Eigenentwicklung nachhaltig ausgeglichen werden - vorausgesetzt diese werden nicht bei einer kommenden Migrationen zunichte gemacht. Von daher können die Defizite von WP nicht unbedingt als Gegenargument genutzt werden.
Diese Entscheidungen werden dann nach dem Prinzip der Mehrstimmigkeit umgesetzt. Ob diese Entscheidungen uns allen gefallen, steht auf einem völlig anderen Blatt.
Das ist ja genau das Problem, dass Entscheidungen getroffen werden, die nur innerhalb der Entwickler-Community und deren unmittelbarem Umfeld abgestimmt sind (so zumindest meine Wahrnehmung). Ich sehe nicht wo Endanwender in die Entscheidungen aktiv mit einbezogen werden. Oder anders gesagt: diese Entscheidungsprozesse sind nicht gerade transparent.
Übrigens: Endanwender sind für mich vor Allem diejenigen, die sich bei der Gestaltung einer Webseite im Wesentlichen auf die Konfigurationsmöglichkeiten von Joomla und der Extentions beschränken und allenfalls CSS-Anpassungen realisieren - aber nur selten eigene Programmerweiterungen - z.B. über JavaScript - vornehmen (weil sie nicht wollen oder nur eingeschränkt können) und auch viele der angebotenen Features (wie z.B. Child-Templates) nur eingeschränkt oder gar nicht nutzen. Daraus ergeben sich natürlich spezielle Anforderungen - aber dazu schreibe ich (vielleicht) später mal was.
-
Komme leider erst jetzt dazu ein paar Anmerkungen beizutragen.
Daher meine Fragen:
Wie funktioniert denn bei Joomla das Projekt- und Changemanagement in der Weiterentwicklung?
Dazu noch eine weitere - aus meiner Sicht noch viel wichtigere - Frage: gibt es überhaupt ein Anforderungsmanagement? Und wird dabei unterschieden zwischen Anwenderanforderungen (von denen, die Joomla nutzen aber nicht entwickeln - wie z.B. Dienstleister oder Betreiber von Vereins-Webseiten) und den daraus abgeleiteten technischen Anforderungen, die im Wesentlichen für die Entwickler interessant sind. Den ohne dem besteht halt die große Gefahr, dass ausschließlich Entwickler entscheiden und nach meiner Erfahrung dann gehäuft an den Anwenderanforderungen vorbei.
Dann hilft dann auch keine Verkürzung der Versionszyklen. Und Testen allein kann Anforderungsmanagement nicht ersetzen: vernünftige Tests basieren immer auf den zuvor definierten Anforderungen und den daraus abgeleiteten Testkriterien. (Leider habe ich bislang noch keine Aufforderung gefunden, sich an der Defintion von Anforderungen zu beteiligen oder insbesondere definierte Anforderungen zu beurteilen. Aber vielleicht habe ich ja was übersehen.)
Von daher kann ich auch nichts mit der Aufforderung anfangen Version 5 herunterzuladen und zu testen. Was soll ich den testen, wenn ich die Spezifikation und die Testkriterien zu neuen oder veränderten Funktionen und deren beabsichtigte Auswirkungen nicht kenne (abgesehen vom Zeitaufwand (s.u.)).
Macht jeder was er will und am Ende wird es zusammengewürfelt oder ist es koordiniert?
Das kann ich so nicht generell beurteilen, halte die Frage aber für berechtigt. Denn wie kann es z.B. sein, dass die Objektstruktur von Bildern im Standard-Media-Manager anders aussieht als im Standard-Template Cassiopeia. Ohne dieses Problem und seine Folgen weiter zu vertiefen: die Tatsache, dass es bei den Standardkomponenten mindestens vier verschiedene Objektstrukturen für Bilder gibt, läßt leider ein unkoordiniertes "Zusammenwürfeln" vermuten.
Das ist so ein typisches Todschlagargument. Es suggeriert, wer nicht aktiv mitmacht, der muss sich halt fügen und sollte nicht kritisieren.
Ja stimme zu, das ist ein Totschlagargument: nicht jeder, der Joomla nutzt, hat aus verschiedenen Gründen (Management einer Dienstleistungsfirma, Aquise von Aufträgen, Kundenbetreuung, Familie wie z.B. Enkelkinder, Ehrenämter wie z.B. Vereinsvorsitz, Engagement in der Kommunalpolitik und anderes mehr) die Zeit sich intensiver um Joomla zu kümmern - kann allenfalls noch bei Definition und Review von Anwenderanforderungen (s.o) einen Beitrag leisten.
Aber jetzt im Ernst - wechseln Leute zu Wordpress weil sie sich vor einer Migration fürchten?
Ja, das tun sie - wenn auch auf Grund falscher Erwartungen oder Versprechungen. Aber gerade die Erwartung einer vereinfachten Wartung und einfacheer Updates bewirkt in besonderem Maße Wechselbereitschaft - auch wenn funktional dann einiges weniger gut ist.
Und leider helfen hier Aussagen wie "es wird jetzt alles einfacher und nicht so schlimm" nicht wirklich weiter. Die Betroffenen glauben es nicht mehr (Ich auch nicht, bleibe aber trotzdem bei Joomla. Den Wordpress ist - wie mir auch von anderen bestätigt wurde, die Erfahrungen mit Wordpress haben - im Vergleich eine einzige Katastrophe. Ich kann allerdings gut reden, da der Aufwand bei nur 2 betreuten Vereins-Webseiten am Ende überschaubar bleibt.)
bis Joomla den Erhalt seiner Nutzer in den Fokus stellt und "weiche" Migrationen einführt
Das ist übrigens in diesem Zusammenhang der einzige sinnvolle Ausweg mit folgender Einschränkung:
Gegen das Werbebudget von Wordpress kommt Joomla nicht an, das ist eine Tatsache
Dem stimme ich zu und das führt zum sehr kritischen Hauptproblem von Joomla: Joomla fehlen aus meiner Sicht und Erfahrung potente Sponsoren, die vor allem ein kommerzielles Eigeninteresse an der Entwicklung haben, da sie Joomla selbst nutzen, und von daher notwendige Ressourcen für Anforderungs-, Projekt- und Changemanagement, aber auch Entwicklungskapazitäten und Werbebudgets stellen (was wäre Eclipse ohne IBM?)
-
Genau, Handbücher o.ä. werden ja nicht mehr wie vor 15-20 Jahren gelesen, alles steht irgendwo im Internet. Da sind diese "Touren" doch logisch.
Handbücher wurden schon vor 30 Jahren nicht gelesen - lag teilweise auch daran, dass niemend Dokumentationen und erst gar nicht Handbücher geschrieben hat.
In vielen Industriefirmen wird entgegen Deiner Aussage aber schon seit Längerem sehr darauf geachtet, dass geeignete Dokumentationen vorhanden sind - nennt sich teilweise Betriebshandgbuch. Hat auch was zu tun mit Betriebssicherheit etc..
Ist allerdings auch ein Thema, das Softwareentwickler und IT-Verantwortliche wegen des damit verbundenen Aufwandes nach wie vor nicht so gerne mögen. Ob hier allerdings "Touren" eine Aufwandsreduzierung mit sich bringen möchte ich bezweifelt. Auch die müssen gepflegt werden und können ebenso am nächsten Tag schon veraltet sein. Und dann kommt bei Touren die didaktische Aufarbeitung hinzu. Und da möchte ich erst recht bezeifeln, ob ein "wissender" Softwarentwickler eine Tour immer so aufbereiten kann, dass ein "Nichtwissender" das versteht.
-
Habe zu dem Thema einen (aus meiner Sicht) guten Beitrag gefunden
KI im Programmierertest: Kann GPT-4 wirklich Code schreiben? - Golem.deGPT-4 kann gut einfachen Code schreiben. Meine Tests mit schwierigeren Pfadfindungs- und Kollisionsalgorithmen hat es nicht bestanden. Statt das einzugestehen,…www.golem.deWichtige Aussage dort: Komplexe Algotthmen lassen sich eben nicht entwickeln. Allenfalls kann vorhandenes in Grenzen modifiziert werden. Ursache für die Überschätzung ist nämlich, dass viele Algorithmen bereits existieren, was die Aufgabensteller nicht wissen (woher auch). Das würde dann darauf hinauslaufen, das ChatGPT eine - wenn auch sehr, sehr intelligente - Suchmaschine ist.
Schaden kann damit trotzdem noch genug angerichtet werden, da viele natürlich auf Grund des aktuellen Hypes dem Glauben verfallen, dass KI das Allheilmittel für schwierige Problem ist.
Das führt mich zurück auf eine frühe Aussage zu KI bei einem Kongress an der Uni St.Gallen: KI ist nicht anderes als Entscheidungstabellentechnik: was da nicht drin ist kann auch nicht abgeleitetet werden (ist sicherlich etwas provokativ - aber ist mir halt auf Grund des erwähnten Beitrags wieder eingefallen).
Und das wird ja indirekt auch bestätigt dadurch, dass ChatGPT in Italien wegen der Datensammelei verboten ist - d.h. Ausagen über Italien dürften damit erst einmal nicht so zuverlässig sein
. -
. . . damit es frisch, modern und vor allem konkurrenzfähig daherkommt. I
Was heißt frisch und modern?
-
wie sehen Deine Moduleinstellungen aus?
Wie schon in #27 gesagt sind die Moduleinstellungen nicht die Ursache dafür, dass die Termine nicht in der Jahresansicht angezeigt werden. Das ist ja das ursächliche Problem.
Ich halte daher die Fokussierung auf Latest Events Module bei der Fehlersuche für einen Irrweg. Die Ursache muss woanders liegen. Habe aber selbst auch noch nichst gefunden.
Habe übrigens mit den Moduleinstellungen herumgespeilt: keinerlei Einfluss auf die Jahresansicht.
-
Was mit noch eingefallenen ist: ist die Eventkategorie veröffentlicht? Das habe ich als einziges gefunden, was die Anzeige von Events verhindern kann (vorausgesetzt alles andere ist ok).
Übrigens: wenn in der Jahresansicht nichts zu sehen ist ist es nur folgerichtig, dass ein Latest Events Module ebenfalls nichts anzeigt. Die Ursache liegt also nicht bei einem Latest Events Module.
-
zu Punkt 2: versuche es mal mit
Codebody { max-width: 1200px; margin-left: auto; margin-right: auto; }Allerdings ist dann der Hintergrund einfarbig. Willst Du aber ein Hintergrundbild über die ganze Breite, also auch bei Screens mit mehr als 1200px, dann mussen die Anweisungen auf alle Items direkt unter body angewendet werden.
Wobei grundsätzlich die Frage bleibt, weshalb eine Einschränkung auf 1200px erforderlich ist ?
-
Ich will Dir hier zunächst nur zu Punkt 1 einen Tip geben (ansonsten wäre es wirklich gut zu jedem Puntk einen eigenen Thread aufzumachen - so wie firstlady schon in #6 angemerkt hat).
Hier nun meine Lösung - realisiert über die user.css (siehe auch https://www.ig-lilienthal.de/ )
CSS@media only screen and (min-width: 992px) { .mod-menu_dropdown-metismenu > li.deeper.parent:hover > ul { display:block !important; } }Daduch klappt sich das Untermenü bei :hover auf, aber die alte Funktionalität, die für Menschen mit Einschränkungen wichtig ist (siehe #8), bleibt dabei uneingeschränkt erhalten.
Die @media-Anweisung wurde gesetzt, da :hover auf Smartphones eher unnütz ist.
Bei dieser Gelegenheit noch eine Anmerkung zu den Menschen mit Einschränkungen: es ist wichtig, dass auch diese eine Webseite so gut wie nur möglich nutzen können. Aber muss deswegen ehemals vorhandene Funktionlität abgeschaltet werden, die für andere erleichternd ist?? - zumal es in diesem konkreten Fall sehr einfach zu realisieren ist.
-
Es ist in der Tat so, dass Microsoft in LINUX investiert. Es gibt dazu eine entsprechenden Artikel in der SZ https://www.sueddeutsche.de/di…t-betriebsystem-1.4965794 von 2020.
Das wüde ich allerdings nicht unbedingt negativ sehen. Microsoft hat bereits vor einiger Zeit angefangen das Geschäftsmodell zu ändern und es würde mich nicht wundern, wenn selbst Windows irgendwann auf LINUX aufsetzt. Bei sowas ist es ist letztlich nur die Frage, ob die Gewinne den Aufwand einer eigenen Betriebssystementwicklung rechtfertigen.
Eines von vielen anderen, vergleichbaren Beispielen ist die Programmentwicklungsumgebung Eclipse, wo IBM schon seit etlichen Jahren der Hauptsponsor ist. IBM beteiligt sich an der Entwicklung und verdient am Ende mit den Dienstleistungen, die auf dieser Open Source aufsetzen. Usprünglich ist das eine Entwicklung von IBM, die dann 2001 freigegeben wurde.
