Gutenberg: Geben Sie einen klaren Umriss von Projektumfang, -richtung und -zielen

Dies verdeutlicht, warum eine klare öffentliche Produkt-Roadmap hilft. https://open.buffer.com/transparent-product-roadmap/

Danke, das würde sehr helfen.

Eine offene Frage vieler Site-Betreiber, die ihre Ausrichtung für die nächsten Jahre planen, sollte ebenfalls behandelt werden: das Verhältnis von Gutenberg zu Pagebuildern.

Zum Beispiel:

• wie werden sie sich in einem ersten schritt integrieren?
• Welche Bereiche der Page Builder-Funktionalität wird Gutenberg in welchem ​​Meilenstein abdecken? B. responsive Layouts in Abschnitte/Spalten strukturieren, detailliertes Styling (Farben, Hintergrundbilder, Auffüllen der Ränder und all das Zeug). Mit anderen Worten: Wird der Gutenberg-Editor als Werkzeug für Autoren oder auch als Werkzeug für Designer gesehen?
• Wird Gutenberg so etwas wie eine Vorlagenbibliothek unterstützen?

Angenommen, sie werden für lange Zeit nebeneinander existieren:

• Wird es möglich sein, einen Block mit einem Page Builder-Layout zu haben?
• Ist es ein Ziel, eine Gutenberg-Instanz oder einzelne Blöcke in ein Page Builder-Layout ziehen zu können?

Ganz zu schweigen von der Frontend-Bearbeitung...

Ja, das Gutenberg-Projekt scheint einen schleichenden Umfang zu haben, der unnötige FUD über die Zukunft von WordPress erzeugt, zumal sich der Erfolg des Projekts mit dem Erfolg von WordPress selbst überschneidet. Es gibt zwar viel effizientes, iteratives Projektmanagement, aber es gibt eine Lücke im Produktmanagement, die damit geschlossen werden könnte.

Dies ist symptomatisch für ein größeres Problem mit der WordPress-Roadmap , bei der es sich lediglich um eine historische Liste von Veröffentlichungen handelt. Das Haupthindernis für Agenturen, die WordPress for Client-Lösungen verwenden, ist die RoadMap gemäß unserem aktuellen WordPress-Nutzungsumfragebericht von WordPress Marketing. Trotz ihrer hohen Zufriedenheit mit WordPress äußern einige Agenturen Bedenken über das mangelnde Bewusstsein für den CMS-Anwendungsfall und die Abwärtskompatibilität.

@Skarjune Basierend auf dem, was ich aus dem Beobachten des Prozesses im Laufe der Jahre, dem Lesen verschiedener veröffentlichter Materialien des Teams und den Gesprächen mit Teammitgliedern zusammengetragen habe, glaube ich nicht, dass es hier (viel) Umfangskriechen gibt. Es gibt eine ziemlich klare Argumentation, die sich durch das gesamte Projekt zieht und in eine bestimmte Richtung weist. Das Problem besteht darin, dass Informationen nicht an einem Ort enthalten sind, auf den die Leute zugreifen können. Wenn eine einzige Ressource erstellt würde, um diese Dinge richtig zu beschreiben, würden viele Leute nachts besser schlafen.

Ein paar andere Dinge, die ich gerne in keiner bestimmten Reihenfolge sehen würde:

• Der Grund dafür, Gutenberg speziell an 5.0 zu binden, vs. ein Feature-Plugin wie die REST-API-Arbeit zu sein, die integriert wird, wenn sie fertig ist.
• Eine Begründung für die Übernahme des gesamten Bearbeitungsbildschirms im Vergleich zum Inhaltseditor (was dies ermöglicht usw.).
• Ein grober Zeitplan für das Zusammenführen und Freigeben. Was denkt das Team, wenn 5.0 als Ziel für die Veröffentlichung vorgesehen werden sollte? Dies könnte nur ein Viertel sein ("Q2 18 vs "Anfang April"), aber im Moment scheinen die Leute unterschiedliche Erwartungen zu haben, wann 5.0 passieren wird und ob es wirklich, sagen wir, ein Jahr warten würde, wenn Gutenberg so lange braucht, um die Markierung.
  
  
  
  • Gleichzeitig damit, Freigabekriterien. Was muss da sein, bevor das Team fusioniert? Metabox-Unterstützung und wie das erreicht wird, ist der aktuelle Hot-Button, aber die Kriterienliste sollte darüber hinausgehen.
  
  
• Was NICHT in der ersten Version enthalten sein wird. Wenn beispielsweise festgestellt wird, dass die Unterstützung für die Fields-API außerhalb des Bereichs liegt, wird sie in dieser Liste aufgeführt. Dies muss nicht alle ausgeschlossenen Elemente auflisten, sondern sollte größere Elemente abdecken, die externe Diskussionen erhalten haben.
• Wichtige offene Fragen. Wiederum am Beispiel der Fields-API: Wenn die Entscheidung, dies zu beenden und Gutenberg zu unterstützen, auf dem Tisch stünde, würde es als offenes Thema aufgeführt, damit die Leute wissen, dass es diskutiert wird. Nochmals, dies sollte nicht jedes offene Problem sein, sondern nur alle großen Probleme, die viel Zeit oder Mühe erfordern oder die einen erheblichen Einfluss auf die Ausrichtung und Fähigkeiten von Gutenberg haben würden.

@mor10 OK, ich stehe korrigiert, dass Gutenberg als Projekt nicht unter "Scope Creep" leidet, aber das ist die Wahrnehmung vieler Beobachter. Ich habe den Fortschritt seit dem frühen Beitrag zur technischen Übersicht des

Ich kann nicht für alle sprechen, die den Begriff verwenden, aber wenn ich "Scope Creep" sage, beziehe ich mich auf einen Scope, den ich aufgrund öffentlicher Aussagen in Make blog posts, der ehemaligen Zielseite des Projekts (die ich nicht mehr kann) vermutet habe überall finden) und die aktuelle Plugin-Seite .

Der Nachwelt zuliebe ist dies die aktuelle Plugin-Beschreibung:

Das Ziel des Blockeditors ist es, das Hinzufügen von Rich Content zu WordPress einfach und angenehm zu machen.

Das ist Beta-Software.

Die neue Erfahrung zum Erstellen von Beiträgen und Seiten macht das Schreiben von umfangreichen Beiträgen mühelos und macht es einfach, das zu tun, was heute Shortcodes, benutzerdefiniertes HTML oder „Mystery Meat“-Einbettungserkennung erfordert.

WordPress unterstützt bereits eine große Anzahl von „Blöcken“, bringt sie jedoch nicht sehr gut zur Geltung und bietet ihnen auch keine großen Layout-Optionen. Indem wir uns der blockigen Natur von Rich-Post-Inhalten zu Nutze machen, werden wir die bereits vorhandenen Blöcke ans Licht bringen und für jeden von ihnen erweiterte Layout-Optionen bereitstellen. Auf diese Weise können Sie ganz einfach schöne Beiträge wie dieses Beispiel verfassen.

Wenn Sie die Plugin-Seite lesen, werden bis heute keine Metaboxen erwähnt. Wir sehen Verweise auf den Editor, das Schreiben von Rich-Posts, Shortcodes, benutzerdefinierten HTML-Code, Einbettungen und das Verfassen schöner Posts (die dann auf ein Beispiel für Post-Inhalt verweisen).

Die in der Beschreibung der Plugin-Seite verwendete Terminologie würde jeden, der mit WordPress vertraut ist, erwarten lassen, dass der Inhaltseditor aktualisiert wird. Wieso den? Da es sich bei all diesen genannten Begriffen um Dinge handelt, für die wir heute den Inhaltseditor verwenden. Es gibt nichts, was einem unbekannten WordPress-Benutzer oder -Entwickler darauf hindeutet, dass der Umfang des Projekts beabsichtigt, über den Inhaltseditor hinauszugehen.

Während einige den Umfang basierend auf einem internen Verständnis interpretieren, betrachte ich ihn basierend auf diesen nach außen gerichteten Materialien. Die Roadmap, die @mor10 vorschlägt, ist eine Möglichkeit, beides zu synchronisieren.

Vernetzung mit #3347.

Meine Hauptsorge ist, inwieweit sich die Datenerhebung ändert, um Gutenberg Rechnung zu tragen? Ändert die zugrunde liegende Datenstruktur unsere zugehörigen API-Endpunkte?

Ich stimme den aufgeworfenen Fragen zu und die Diskussion über Gutenberg war höchst problematisch.

Ich würde jedoch sagen, was an dieser Stelle eine Roadmap braucht, ist nicht nur Gutenberg, sondern _WordPress_ selbst.

Die aktuelle Projektrichtung der "trendigen JS-Webanwendungsplattform, die auf einem Legacy-Kern im veralteten PHP-Dialekt basiert, den die Leute tatsächlich zum Erstellen von Inhaltsseiten verwenden" wird bizarr.

An dieser Stelle kann es scheinbar rechtfertigen, selektiv daraus zu zitieren:

• absolute abwärtskompatibilität
• Abwärtskompatibilität brechen
• große technologische Veränderungen
• Technologie ändert sich nicht
• Lernen von einer größeren PHP- und/oder Webentwicklungsbranche
• alles außerhalb des Projekts komplett ignorieren

Das Gespräch über Gutenberg scheitert nicht _nur_ daran, dass seine Vision unklar ist.

Es scheitert, weil Gutenberg behauptet, für die Ziele des _WordPress-Projekts_ von entscheidender Bedeutung zu sein. Und in den letzten Jahren scheint _diese_ Vision stetig an Klarheit über Zweck, Richtung und Prioritäten verloren zu haben.

Als kleiner WordPress-Redakteur und leitender Betreuer der WordPress-basierten Website unserer Organisation, der die WordPress-Entwicklung hauptsächlich aus der Ferne verfolgt - vom gelegentlichen Durchsuchen von make.wordpress.org und dem Scannen von wptavern.com; Ich bin über wptavern auf dieses Ticket gestoßen und stimme voll und ganz zu.

Ich danke @mor10 für die Bemühungen, die Bedenken in prägnanter und klarer Sprache

Ich stimme @kevinwhoffman zu. Als ich Gutenberg ursprünglich bei unseren monatlichen Treffen als "das neue Bearbeitungserlebnis für WordPress 5.0" erwähnte, erwartete ich auch, dass es ein Ersatz für das TinyMCE-Editorfenster sein würde. Ich hatte nicht erwartet, dass es die gesamte Post-Editor-Seite übernimmt, basierend auf der Gliederung auf der Plugin-Seite.

Von besorgten Benutzern werden mir alle möglichen Fragen gestellt, was das für ihre Website bedeutet, die ich im Moment nicht eindeutig beantworten kann.

Auf der Plugin-Seite wird erwähnt, dass dies Beta-Software ist, aber ich würde bestreiten, dass dies zumindest eine frühe Alpha ist. Es erinnert mich an frühe Dotcom-Sites, die in den folgenden 2 Jahren die kleine "Beta" -Grafik in der Ecke des Browsers posten würden, was es ihnen im Grunde ermöglichte, nicht den Umfang oder die Roadmapping-Funktion zu bestimmen, was sie taten, wodurch die Benutzererfahrung stark variieren konnte.

Aus Wikipedia

Die Beta-Phase beginnt in der Regel, wenn die Funktion der Software vollständig ist, aber wahrscheinlich eine Reihe bekannter oder unbekannter Fehler enthält

Gutenberg ist meiner Meinung nach bei weitem nicht vollständig (schau dir einfach die ganze Iframe-Saga an).

Beim folgenden Meetup kamen Leute zu mir, die in Panik gerieten, weil sie bei der Installation von Gutenberg viele ihrer Postdaten (Metaboxen usw.) "verloren" haben. Das ist keine gute Position, um Leute für Beta-Software einzusetzen.

@rickgregory erwähnte in seinem Beitrag, dass die REST-API seit Ewigkeiten ein Feature-Plugin ist, bis sie in den Kern integriert wird. Es scheint fast so, als ob Gutenberg der entgegengesetzten Methodik folgt und in die nächste Version von WordPress gehämmert wird, ob die Benutzer es mögen/wollen oder nicht.

Als jemand, der Websites für lokale Unternehmen entwickelt, fand ich es sehr schwierig, den Umfang und die Vision des Gutenberg-Projekts zu verstehen. Ich unterstützte voll und ganz die Notwendigkeit eines besseren Editors, fand aber lange Zeit die Blockaden für alle Nachrichten, die aus dem Team kamen, äußerst verwirrend.

Das Gutenberg-Team verstand, was ein Block bedeutet, aber als Benutzer/Entwickler, der von außen hineinschaute, konnte ich es nicht fassen. Ich bin neulich zufällig über den Beitrag "Gutenberg oder das Schiff des Theseus" gestolpert und es war das erste, was ich gelesen habe, das mir klar gemacht hat, wie gut Blöcke sein können. Aber ich bin nur zufällig auf den Beitrag gestoßen.

Ein endgültiges Dokument, das die Vision und den Umfang des Projekts umreißt, würde viel dazu beitragen, die Anliegen der Gemeinschaft insgesamt zu berücksichtigen.

Ich habe mit vielen Entwicklern gesprochen, die im Moment ehrlich gesagt Angst um ihre Zukunft haben. Sie wissen nicht, ob sie zurückgehen und große Änderungen an all den Sites/Themes/Plugins vornehmen müssen, die sie in der Vergangenheit entwickelt haben. Sie haben Angst, große Projekte in Angriff zu nehmen, falls sie nach der Veröffentlichung von 5.0 ihre gesamte Arbeit wiederholen müssen. Sie wissen nicht, wann oder wie sie ihre Kunden in der Verwendung von Gutenberg schulen müssen. Sie wissen nicht, wann und wie sie sich selbst beibringen sollen, sich mit Gutenberg zu entwickeln. Viele von ihnen befürchten, dass ihre Kunden WordPress nicht weiter verwenden möchten, und erwägen, andere CMS zu erlernen oder ihre Kunden zu SquareSpace zu migrieren. Gut möglich, dass all diese Befürchtungen unbegründet sind, aber sie haben keine Möglichkeit, es so oder so zu erkennen. Ein klarer Überblick über den Umfang, die Ziele und den Zeitplan von Gutenberg würde Entwicklern helfen, ihre Zukunft zu planen und ihnen zu versichern, dass sie und ihre Kunden WordPress weiterhin verwenden können.

Jeder hält es für eine gute Idee und wäre sehr von Vorteil. Bleibt nur noch die Frage, wer es wann schreibt? Ich würde anbieten, es zu tun, aber ich bin kein Programmierer und es braucht wirklich einen Entwickler bei Gutenberg Central, um alle Details korrekt beschreiben und gestalten zu können. Obwohl ich jetzt anbieten werde, mich an allem zu beteiligen, was Marketingaspekte betrifft, ist das meine Stärke.

Ich kann berichten, dass vor einigen Monaten eine Anfrage beim WordPress Marketing Team eingegangen ist, um einen Werbeplan für Gutenberg zu erstellen. Es wurde gechartert und diskutiert, aber auf Eis gelegt, da einige von uns es für verfrüht und seltsam hielten, ein Beta-Plugin für Endbenutzer ohne weitere Klarheit zu bewerben. Für mich führt dies zu einem Problem zwischen Produkt und Projektumfang oder Wagen vor Pferd oder einer anderen Analogie. Punkt: Das Produkt benötigt eine Roadmap mit einem begleitenden Projektumfang.

@Skarjune - auf seltsame Weise macht es Sinn, dass sie versucht haben, das falsch

Ich habe Mortens Präsentation über Gutenberg beim WordCamp Seattle am vergangenen Wochenende sehr geschätzt, die zu meiner eigenen Überraschung meine Einstellung zum Projekt als Ganzes verändert hat.

Er ermutigte auch alle, sich an dem Projekt zu beteiligen, weshalb ich mir die Zeit nehme, hier zu kommentieren.

Um Menschen zu beruhigen, ist es nie eine schlechte Idee, Ziele und Umfang zu skizzieren. WordPress wird oft kein Akquisitionsproblem, sondern ein Aufbewahrungsproblem nachgesagt. Erwartungen innerhalb der Entwickler-Community und im Kampf (einschließlich mir) im Open Source Bazaar zu verwalten, ist nie eine schlechte Sache.

Missverständnisse führen zu Verwirrung, die zum Burnout führt.

Vielen Dank für all Ihre harte Arbeit an diesem Projekt und für alle, die großartige Projekte aufbauen, die wir alle so sehr lieben.

Ich wollte hier nur eine Nachricht hinterlassen, um zunächst Danke für die Kommentare und das Engagement aller zu sagen. Im Moment haben wir ein paar Ressourcen verteilt:

Landing-/Marketing-Seite: http://wordpress.org/gutenberg

Readme: https://github.com/WordPress/gutenberg/blob/master/README.md

Docs: https://wordpress.org/gutenberg/handbook/ (jetzt neuerdings mit einer besseren URL).

Wir können es jedoch besser machen und Sie werden gehört. Ich wollte vorbeischauen und sichergehen, dass Sie das wissen.

Ich habe zwei Vorschläge, der erste ist bereits in Arbeit. Derzeit werden zwei dieser Ressourcen iteriert; http://wordpress.org/gutenberg und die Projekt-Readme. Die Iterationen werden sich darauf konzentrieren, was Gutenberg ist und sein wird, Links und Ressourcen hinzufügen und das, was hier und in der Community gesagt wurde, zur Kenntnis nehmen. Wenn möglich, geben Sie uns einfach eine Woche Zeit, um dies einzurichten, da es zumindest Inhalte zum Durcharbeiten bereitstellen sollte. Es wird hoffentlich ein guter Ausgangspunkt dafür sein, wohin wir als nächstes gehen, um dies zu kommunizieren.

Zweitens möchte ich hören, was Sie alle für ideal halten. Was genau will jeder produziert sehen? Welche Formate funktionieren? Würden diese Seiten ausreichen? Was wäre für Sie alle das Format, das Sie idealerweise haben möchten?

Ich weiß, es ist schwer zu sagen, während an diesen Seiten gearbeitet wird, aber ich möchte sicherstellen, dass alles berücksichtigt wird, um zum nächsten Schritt zu gelangen. Sobald diese fertig sind, würde ich gerne mehr Leute dazu bringen, unsere Ressourcen und unsere Dokumentation zu verbessern. Ich werde sie hier verlinken, wenn das passiert, um mit denen zusammenzuarbeiten, die sich bereit erklärt haben, zu helfen. Dank an alle.

Es gibt zwei Formate, die meiner Meinung nach in Verbindung nützlich wären:
1) Eine Roadmap mit einer Liste der Funktionen/Meilensteine, die vor der Veröffentlichung von Gutenberg vorhanden sein werden, mit zumindest vagen Angaben dazu, wann diese Dinge voraussichtlich passieren werden.
2) Ein FAQ-Bereich mit Antworten auf Fragen wie "Wird es Metabox-Unterstützung geben?", "Muss ich meine Plugins und Themes neu schreiben, um mit Gutenberg kompatibel zu sein?" und "Kann ich zurückkehren, wenn Gutenberg meine Site zerstört?" Antworten auf häufig gestellte Fragen würden wirklich helfen, Angstzustände zu lindern.

Was den Standort dieser Dokumente angeht, denke ich, dass es zumindest sinnvoll ist, sie von der Marketingseite aus zu verlinken. Außerdem ist es sinnvoll, die Dokumente dort abzulegen, wo sie am ehesten gepflegt und regelmäßig aktualisiert werden. Wenn die Veröffentlichung dieser Inhalte auf der Marketingseite ein Hindernis für die Aktualisierung darstellt, sollten sie dorthin gelangen, wo sie am wahrscheinlichsten auf dem neuesten Stand bleiben, mit Links auf der Marketingseite.

@wpalchemist Ihr (1) steht im Mittelpunkt dieser Ausgabe, wobei Funktionen und Meilensteine ​​geklärt werden.
Für (2) hat das Projekt das bereits in GitHub:
https://github.com/WordPress/gutenberg/blob/master/docs/faq.md
@karmatosed hat gezeigt, dass es sowohl dort als auch auf WordPress.org einige gute Ressourcen gibt, und ja, es wäre schön, sie vollständig auf der Hauptseite indiziert zu haben:
http://wordpress.org/gutenberg

@Skarjune Danke für den FAQ-Link! Das müssen wir leichter finden. :)

Guter Punkt über die FAQ-Seite, lassen Sie mich sicherstellen, dass dies in die erste Iteration der Änderungen eingeht, über die ich gesprochen habe. Danke für das Feedback. Es zeigt, dass viele dieser Informationen vorhanden sind, es geht darum, sie an die Oberfläche zu bringen, also ein guter Punkt.

Hier meine unmittelbaren Vorschläge:

1. Erstellen Sie ein Projektskizzendokument mit aktuellen und zukünftigen Zielen, Zeitplänen und wichtigen Entscheidungen, einschließlich der Datenstrukturen, die beibehalten werden, welche Datenstrukturen hinzugefügt werden und worauf sich Designer und Entwickler vorbereiten sollten.
2. Erstellen Sie ein umfassendes Wiki ähnlich WP-API.org mit umfassender Dokumentation, die aktuelle Dokumente und leere/von Mitwirkenden benötigte Dokumente bereitstellt, um jedem klar zu machen, was existiert und was gebaut werden muss.
3. Erweitern Sie die FAQ, um Fragen für Administratoren, Designer und Entwickler zu beantworten

Oben sind Kommentare mit Vorschlägen für das, was hier sein sollte. Meine sind unter https://github.com/WordPress/gutenberg/issues/3354#issuecomment -342310592 und im Allgemeinen denke ich, dass Mor10s Kommentar direkt darüber richtig ist.

Ich würde gerne sehen, was in der ersten, zweiten usw. enthalten sein wird. Mit anderen Worten, während das Endziel von Gutenberg viele Dinge sein könnte, wie sieht die Feature-Liste für die erste Veröffentlichung aus?

Außerdem denke ich, dass es wichtig ist, eine Liste mit wichtigen offenen und abgeschlossenen Problemen zu haben. Ich sage dies, weil einige meiner Bedenken funktional sind - wie werden Metaboxen unterstützt usw. -, aber einiges dreht sich auch um die Tatsache, dass so vieles undefiniert und ungewiss ist.

Meiner Meinung nach konzentriert sich Gutenberg auf Blogs und es könnte tatsächlich eine nette Ergänzung für Blogs sein.

Wie im Bild unten gezeigt, das direkt von der Gutenberg-Site aufgenommen wurde :

Titel hinzufügen
Schreib deine Geschichte

Sites, die nicht als Blogs verwendet werden, sondern als Sites für Unternehmen, für E-Commerce, für Listings, für Jobs, für Wissensdatenbanken, für Restaurants, für Schulen und die lange Liste geht weiter und weiter, schreiben keine Geschichten .

Gutenberg ist daher für diese Art von Sites völlig nutzlos und wenn man bedenkt, dass dies auch die typischen Sites sind, die Metadaten verwenden, sollte das Entwicklerteam hinter dieser Monstrosität meiner Meinung nach anfangen, Licht auf diese zu werfen und es als Plugin zu behalten oder Wenn es in Core gefaltet ist, wird es nur beim Standard-Post-Post-Typ aktiviert.

Aufbauend auf dem obigen Kommentar von

Einer der wichtigsten Grundsätze von WordPress war die Sicherstellung der Abwärtskompatibilität. Die Diskussionen über Metaboxen, die vagen Zeitleisten usw. ließen mich an verschiedene Gespräche über die Jahre hinweg denken, um die von WordPress benötigte PHP-Version zu aktualisieren. Um Andrew Nacin in einer dieser Diskussionen über den Wechsel von 5.2 auf 5.3 zu zitieren: „Es ist wirklich nicht in unserem Interesse, auf Kosten unserer Nutzer „mitzuspielen“. Dutzende Millionen Nutzer wären betroffen – und möglicherweise gestrandet, oder Ich frage mich sicherlich, warum WordPress sie mitten in all das steckt – alles aus Gründen. Es ist völlig albern. Es ist auch die Art von Schritt, die WordPress machen könnte, die eine gehostete oder alternative Blogging-Lösung gerne sehen würde." Dies ist nur ein Beispiel für etwas, das die Leute von WordPress als Ökosystem erwarten und schätzen: WordPress wird Fortschritte machen, aber nicht auf Kosten seiner Benutzer.

Es gibt eine Reihe moderner Entwicklungspraktiken, die ich gerne in WordPress sehen würde, aber ich habe diese besondere Philosophie respektiert, die Benutzern die Sicherheit gegeben hat, dass sie oft auf die neuesten und besten aktualisieren können, ohne befürchten zu müssen, ihre Websites zu beschädigen.

Obwohl ich gelesen habe, dass die wichtigsten Gutenberg-Mitwirkenden erwähnen, dass sie hier an den "langjährigen WordPress-Benutzer" denken, sehe ich die Verbindung nicht und würde gerne mehr darüber erfahren, wie Gutenberg dies tun wird. Ich persönlich freue mich sehr über Gutenberg als Editor-Ersatz und bin der Meinung, dass das Entwicklerteam für viele seiner Bemühungen in diesem Bereich gelobt werden sollte.

Während ich jedoch die Gespräche über das Ersetzen des gesamten Beitrags-/Seitenbearbeitungsbildschirms durchlese, werde ich immer nervöser. Zahlreiche gut begründete Bitten um einen methodischeren Ansatz bei der Freilassung von Gutenberg wurden mit Antworten wie:

• Solche Ansätze entsprechen nicht der Vision des Projekts
• Es wird nicht veröffentlicht, bis es fertig ist.

Dies sind ehrlich gesagt keine Antworten, weil sie uns nichts sagen. Erstens: Warum läuft eine schrittweise Herangehensweise, zuerst einen Editor freizugeben und sich dann auf den Rest des Bearbeitungsbildschirms zu konzentrieren, wenn sich Entwickler und Benutzer an das neue Erscheinungsbild gewöhnt haben, der Vision des Projekts zuwider? Es scheint eher die Befürchtung zu sein, dass dies einem willkürlichen Zeitplan zuwiderläuft, der implizit um dieses Projekt herum festgelegt wurde. Und zweitens: Was ist der voraussichtliche Fertigstellungstermin? 'Irgendwann im Jahr 2018', wie es in den aktuellen FAQ heißt, ist überhaupt keine Antwort. Mit welchen Parametern wird 'ready' definiert? Als @ mor10 ‚erste Bemerkungen gesagt haben, wir Besonderheiten hier wirklich benötigen. Das Fehlen eines klar definierten Zeitplans mit Meilensteinen innerhalb dieses Projekts trägt hier ernsthaft zu viel Besorgnis bei. Es wäre großartig, eine Mitteilung zu sehen, die klar beschreibt, wie die Veröffentlichung von Gutenberg auf den Kern-WordPress-Grundsatz der Abwärtskompatibilität achtet, um die Millionen von Benutzern, die es derzeit auf ihren Websites verwenden, nicht zu gefährden – mit dem Verständnis, dass Variationen auf 'vertrau uns' sind nicht wirklich eine Antwort.

Erstens: Warum läuft eine schrittweise Herangehensweise, zuerst einen Editor freizugeben und sich dann auf den Rest des Bearbeitungsbildschirms zu konzentrieren, wenn sich Entwickler und Benutzer an das neue Erscheinungsbild gewöhnt haben, der Vision des Projekts zuwider?

Weil es wahrscheinlich nicht genug Ressourcen gibt, um an einer so isolierten Richtung zusätzlich zu der kombinierten Richtung zu arbeiten. Wenn sich später herausstellt, dass die reine Editor-Direktion für das Gesamtbild einfach nicht funktioniert, was werden Sie tun - die Software neu entwickeln (massiv teuer) und alle neu schulen (massiv teuer)? Wie viele solcher Trial-and-Error-Zyklen glauben Sie, wird die Benutzerbasis ertragen können? Das ist eine gescheiterte Strategie von vornherein.

Die Wirkung ist hier so massiv groß, dass für etwas anderes als eine „Alles-oder-Nichts“-Strategie wenig Raum bleibt.

Weil es wahrscheinlich nicht genug Ressourcen gibt, um an einer so isolierten Richtung zusätzlich zu der kombinierten Richtung zu arbeiten.

Begrenzte Ressourcen sind gerade der Grund, warum ein inkrementelles Vorgehen sinnvoll ist. Unser Ansatz sollte darin bestehen, versunkene Kosten zu reduzieren, indem wir den Fortschritt an vordefinierten Kontrollpunkten auf dem Weg validieren, beginnend beim Editor.

Stattdessen haben wir eine kleine Anzahl fähiger Entwickler, die sich auf verstreute Prioritäten konzentrieren, während die Community gebeten wird, darauf zu vertrauen, dass die Gesamtvision am Ende eines ungewissen Zeitplans zusammenkommt. Infolgedessen fühlt sich jede Veröffentlichung eher wie eine Liste von Funktionen an als wie ein Fortschritt in Richtung eines einzelnen Meilensteins.

@lkraav - Ich glaube, du missverstehst den Punkt. Es wird keine „isolierte Richtung“ vorgeschlagen, sondern eine schrittweise Verfeinerung.

Im Moment ist der Vorschlag, Gutenberg den gesamten Bearbeitungsbildschirm übernehmen zu lassen. Was mehrmals gefragt wurde, ist, warum es in seiner ersten Version nicht einfach den Editorbereich des Bildschirms ersetzen kann und im Laufe der Zeit mehr Bearbeitungsfläche einnimmt. Dies hat einige Vorteile:

1) Es gewöhnt Benutzer auf begrenzte, aber nützliche Weise an eine Blockbearbeitungserfahrung. Gleichzeitig reduziert es den Arbeitsumfang, so dass diese erste Phase relativ schnell geliefert werden kann.
2) Es vermeidet, die Meta-Box (und andere?) Probleme jetzt herausfinden zu müssen und vermeidet, dass Plugins wie ACF auch für Gutenberg modifiziert werden müssen, damit viele bestehende Sites nicht kaputt gehen.
3) Im Anschluss an Nr. 1 erhält das Team Feedback aus der realen Welt zu UX und wie ein Blockeditor von echten Endbenutzern aufgenommen wird. Das kann helfen, zukünftige Designarbeiten zu lenken, bevor so viel getan wurde.

Eine nächste Phase könnte sich beispielsweise mit dem Meta-Box-Problem befassen und den Funktionsumfang erweitern. Dies könnte so lange fortgesetzt werden, bis die gesamte Vision geliefert wird.

Schließlich würde Gutenberg den gesamten Bearbeitungsbildschirm ersetzen, aber wenn er richtig gemacht wird, vermeidet dieser Ansatz das Risiko des Alles-oder-Nichts, macht es perfekt oder bricht die Dinge schlecht .

Schließlich denke ich, dass wir dies in einem breiteren Zeitrahmen betrachten müssen. In fünf Jahren wird jeder Ansatz wahrscheinlich ein fertiges, robustes Gutenberg-Erlebnis geliefert haben. Ist es wirklich wichtig, ob dieser Punkt in 2 Jahren oder in 3 Jahren kommt? Wenn wir über einen dominanten Spieler wie WP sprechen, ist das meiner Meinung nach egal. Tatsächlich ist ein gewisses Maß an Vorsicht besser - WP muss sich nicht anstrengen, um einen Marktführer einzuholen, da es der Marktführer ist. Es wäre katastrophal, eine Lösung zu entwickeln, die Websites zerstört, die Fähigkeit von Frontline-Agenturen beeinträchtigt, robuste Lösungen bereitzustellen und vieles mehr, alles im Dienste einer starren Designvision, die das Team nicht ändern wird.

Zunächst @lkraav , ich schätze die Resonanz und schätze die gigantische Aufgabe, die sich das Gutenberg-Team gestellt hat, voll und ganz. Ich denke, wir sind uns alle einig, dass die Auswirkungen enorm sind.

Wo ich von Ihrer Schlussfolgerung abweiche, ist, dass dies eine "Alles-oder-Nichts"-Binärdatei ist. Wie @rickgregory feststellt , führt die Konzentration auf den Redakteur nicht in eine andere Richtung, sondern ist ein Schritt zur Verwirklichung der Vision, die sich Ihr Team gesetzt hat. Ich denke, dies ist besonders relevant, wenn man bedenkt, dass sich der einzige greifbare Vorteil für WordPress-Benutzer, der in den FAQ und anderen Dokumentationen zu diesem Zeitpunkt identifiziert wurde, ausschließlich auf den Inhaltseditor konzentriert – nicht auf den gesamten Admin-Bildschirm.

Ich sage, wenn ich "alles oder nichts" höre, ist das für mich ein bisschen ein Warnsignal, da sehr selten etwas schneidet und trocken ist. Die Annahme, dass ein Inhaltsblock-Editor nicht als eigenständige Komponente funktionieren kann, wenn nicht alle anderen Aspekte des Admin-Bildschirms auch unter der Kontrolle einer zentralen Reaktionsinstanz stehen, macht dies noch besorgniserregender.

Es scheint diese Annahme zu geben, dass WordPress kaputt ist und wir diese Änderung vornehmen müssen, um zu überleben. Wenn ja, wenn es diese treibende Notwendigkeit gibt, WordPress komplett zu überarbeiten, warum besteht dann kein größeres Interesse daran, das Plugin auszuprobieren? Das Plugin-Ökosystem hat uns gezeigt, dass Benutzer, die der Meinung sind, dass WordPress ein bestimmtes Bedürfnis nicht erfüllt, nicht zögern, ihrer Site Plugins hinzuzufügen. Und doch stehen wir heute bei 3000 Installationen. Sie können sagen: "Nun, es liegt daran, dass die Leute kein Beta-Plugin in ihre Site einbauen möchten" ... und Sie haben wahrscheinlich Recht. Aber hoffentlich können Sie verstehen, warum wir bestrebt sind, von einem Beta-Plugin (mit bestenfalls geringer Produktionsnutzung) sofort in den Kern um etwas zu springen, das WordPress grundlegend verändert.

Die Tatsache, dass keine Zeitlinien angegeben werden können, macht dies umso verwirrender. Ich schätze die Herausforderung, die sich die Gutenberg-Entwickler gestellt haben, und wenn Sie mir sagen, dass "alles" die einzig akzeptable Lösung ist und Sie sich die Zeit nehmen werden, um es richtig zu machen, ist das in Ordnung. 5.0 ist jedoch bereits als nächste Version geplant... also entweder ist es bereit für die Zusammenführung oder Sie fahren auf eine künstlich gesetzte Frist zu, ohne klar zu verstehen, ob Sie überhaupt "alle" für "alle" arbeiten lassen können. WordPress-Benutzer. Ich bin gespannt, wann Gutenberg innerhalb Ihres Projektplans stabil genug sein wird, damit Entwickler beginnen können, zu überprüfen, wie sich dies auf ihre Plugins und Themes auswirkt? Wie viel Zeit wird den besagten Entwicklern zur Verfügung gestellt, um sich auf Gutenberg vorzubereiten? Wenn Sie diese Fragen noch nicht beantworten können, verstehe ich nicht, wie Sie planen können, dies in den nächsten 12 Monaten in den Kern zu integrieren.

Ich werde sagen, wenn ich "alles oder nichts" höre, ist das für mich ein bisschen ein Warnsignal...

Ich habe nichts damit zu tun, die Richtung auf Gutenberg festzulegen, also brauche ich keine Flaggen zu hissen wegen allem, was ich schreibe. Einfach die Welt hier mit dem Rest von euch allen interpretieren, gewürzt mit ein paar Jahrzehnten Erfahrung in der Softwareentwicklung. Ich habe echte Kunden und Privatunternehmen, die auf WordPress brummen, und das kaputte Visual-HTML-Editing-Paradigma hatte bei mir schon vor einiger Zeit seine Grenzen erreicht. Ich sehe genau, welche Verbesserungen Gutenberg (oder das Modell, wie wir es heute kennen) für meine Prozesse tun kann und begrüße es mit offenen Armen, indem ich mein Möglichstes zum Kern und zum Gutenberg-Prozess beisteuere.

Zum Thema: Jeder kann von "iterativ" oder "all-inclusive" reden, soviel er will, auch ich, aber Worte + Wünsche sind billig und es kommt darauf an, genug qualitative Pull Requests zu haben, um die Machbarkeit einer Richtungswahl zu beweisen.

Ich habe nur niemanden gesehen, der schnell genug die erforderlichen Ressourcen einsetzt, um an diesen alternativen Richtungsideen zu arbeiten. Am Ende des Tages werden diejenigen, die Ressourcen bereitstellen, die Anrufe auf die eine oder andere Weise tätigen. Verständlich, denn es ist höllisch teuer, sich in großen Details (auf Codeebene) und auf dem erforderlichen Fachwissen zu beteiligen.

Und dann müssen wir nur noch sehen, wie es ausgeht und versuchen, mit unseren Anforderungen im Rahmen einer gewählten strategischen Ausrichtung Einfluss zu nehmen. Zugegeben, ich verfolge die PR-Liste nicht täglich (zu groß), aber das Gutenberg-Team hat bereits öffentlich behauptet, alle Beiträge willkommen zu heißen. Eine Richtungsänderung wird nur erfolgen, wenn jemand die harte Arbeit leistet, die Technologie schnell genug herauszufinden. "Jahre" ist wahrscheinlich kein vernünftiger Zeitrahmen, um die Teile zusammenzusetzen.

Deshalb prognostiziere ich (nicht vorschlagen oder ausdrücklich wünsche usw.), dass die "Alles" -Richtung weitergehen wird. Meine persönliche Hypothese ist hier, dass ich, was auch immer passiert, in der Lage sein werde, die Dinge für meine Sachen und die Kunden, die ich betreue, herauszufinden, weil sogar das aktuelle Modell vielversprechend genug aussieht. Es könnte sich sicherlich als falsch herausstellen.

Ich habe nur niemanden gesehen, der schnell genug die erforderlichen Ressourcen einsetzt, um an diesen alternativen Richtungsideen zu arbeiten. Am Ende des Tages werden diejenigen, die Ressourcen bereitstellen, die Anrufe auf die eine oder andere Weise tätigen. Verständlich, denn es ist höllisch teuer, sich in großen Details (auf Codeebene) und auf dem erforderlichen Fachwissen zu beteiligen.

Genau daran scheitert ein solches Projekt – und gerade hier. Unfähigkeit zu verstehen, dass die Fähigkeit, zu einer guten Lösung beizutragen, nicht proportional zur Fähigkeit sein kann, Code zu schreiben. Auf der anderen Seite würde ich sagen, dass die Fähigkeit, guten Code zu schreiben, nutzlos (wenn nicht sogar gefährlich) ist, wenn der Programmierer kein umfassendes Gespür für die Verwendungszwecke hat, auf die sein Code reagieren muss.

WordPress ist, was es ist, wegen seiner Flexibilität und Erweiterbarkeit, weil es attraktiv ist für Entwickler, die seine Funktionalität erweitern können, und für Autoren und Schöpfer, die keine hohen Kenntnisse benötigen, um es auf ihre eigene Weise zu gestalten. Das ist auch der Grund, warum WordPress auf viele verschiedene Arten verwendet wird, nicht nur in Blogs oder auf Storys ausgerichteten Websites.

Bei der Entwicklung einer neuen Methode zum Erstellen und Bearbeiten von Inhalten ist es entscheidend, dass jeder, der zu diesem Projekt beiträgt, die Vorstellung hat, dass er diese Flexibilität und Erweiterbarkeit, die Verwendung benutzerdefinierter Felder, die Verwendung benutzerdefinierter Beitragstypen und anderer Formulare nicht übersehen kann der Verwaltung und Interaktion mit Inhalten in WordPress. Es ist nicht sekundär, es ist der Kern seines Erfolgs.

Wenn dieses neue Bearbeitungserlebnis diesen umfassenden Anwendungsbereich nicht einbeziehen kann, ist es nicht zur Veröffentlichung bereit und sollte nicht veröffentlicht werden.

@lkraav --Keine Sorge ... das bedeutet definitiv nicht, dass Sie irgendwie für die Binärdatei "Alles oder nichts" verantwortlich sind. Ich habe gerade diese Schlussfolgerung kommentiert, weil ich ähnliche Aussagen in anderen Threads und Artikeln zu Gutenberg gelesen habe. Und wie Sie begrüße ich Gutenberg als Ersatz für den Visual HTML-Editor - keine Meinungsverschiedenheiten von mir :)

Ich wollte Pull-Requests kommentieren, da dies auf ein Problem hinweist , das angesprochen hat. Ich kann die Frustration, die einige Mitwirkende an diesem Projekt angesichts der begrenzten Anzahl von Entwicklerressourcen empfinden, voll und ganz verstehen. Ich denke jedoch an die Gespräche in den letzten Monaten über die Einführung eines JS-Frameworks für WordPress, die sich oft zwischen Vue und React aufteilen. Einer der Hauptgründe für die Unterstützung von Vue JS war die niedrigere Einstiegshürde. Dieses Projekt begann offensichtlich, bevor diese Diskussion stattfand, aber bitte haben Sie Verständnis dafür, dass die höhere Eintrittsbarriere von React die Anzahl der Personen, die zu diesem Projekt beitragen können, offensichtlich einschränken wird. Das Team hat sich selbst entschieden, zu reagieren, was in Ordnung ist, da sie derzeit die schweren Arbeiten erledigen. aber das Team kann sich dann nicht beschweren, wenn die Zahl der Mitwirkenden am Projekt nicht so hoch ist, wie sie es sich wünschen würde. Ich für meinen Teil arbeite täglich in Vue und Angular in einer Unternehmensumgebung, habe aber React aufgrund seiner BSD-Lizenzierungsprobleme nie berührt. Daher scheint die Hochlaufzeit, um einen Punkt zu erreichen, an dem ich einen qualitativ hochwertigen Pull-Request in React bereitstellen kann, aufgrund einer (meiner Meinung nach) aggressiven Zeitleiste unerschwinglich.

Ich füge hier nur hinzu, dass wordpress.org/gutenberg und die Readme jetzt Updates haben. In Arbeit, aber ein Schritt in die richtige Richtung.

Ich gehe nicht davon aus, weil ich es einfach nicht weiß. Aber hat Automattic oder jemand anderes bei WordPress com/org jemals eine Marktforschung in Auftrag gegeben oder die verfügbaren Metriken studiert, um genau sagen zu können, wie WordPress verwendet wird?

Wie viel Prozent verwenden es, um Geschichten zu erzählen und Artikel in Blogform zu veröffentlichen, und wie viele verwenden es als CMS, um ihr Unternehmen zu präsentieren oder in ihrem E-Commerce-Shop zu verkaufen? Und wie wächst/schrumpft/projiziert das?

Ich hätte gedacht, dass dies ein nützlicher Beitrag zu dieser Diskussion sein könnte und uns helfen würde, die angemessene Natur von Gutenberg für jede Modalität zu erkennen oder nicht.

Weiß jemand, ob das verfügbar ist und kann uns hier einen Link schicken?

Danke Tammy! Die Abschnitte wordpress.org/gutenberg und wordpress.org/gutenberg/handbook/ sind sehr hilfreich. Aber gibt es eine vollständige Roadmap für WordPress Version 5, wie ich diese Woche von Matt Mullenweg im WP Tavern-Podcast bestätigen hörte, dass Gutenberg als Kern darin enthalten sein wird. Wenn ich mir wordpress.org/about/roadmap/ ansehe, wird nur Folgendes angezeigt:

Version: 5.0
Geplant: 2018
Im Monat vor einer Veröffentlichung werden neue Funktionen eingefroren und der Fokus liegt ausschließlich darauf, die Qualität der Veröffentlichung zu gewährleisten, indem Fehler beseitigt und der Code auf Leistungsprobleme untersucht wird.

Der springende Punkt bei diesem Problem ist, dass Entwickler besonders besorgt über Zeitpläne, Support-Einbrüche und veraltete Versionen sind. Als Beispiel bietet Drupal klare LTS-Timelines:
https://www.drupal.org/core/release-cycle-overview

Terrence, ich habe mich dieses Jahr mit der Marktforschung für ein Make WordPress Marketing-Projekt befasst. Es gab einige informelle Umfragen von Designern, Entwicklern und Agenturen zu WordPress, aber nichts formelles oder schlüssiges über die Verwendung. Unser Projekt konzentrierte sich auf eine informelle Umfrage unter Agenturen zur WordPress-Nutzung, ausschließlich zum Zweck der Entwicklung von Supportmaterialien für Agenturen, um WordPress an Kunden zu vermarkten, und um die Einführung in Unternehmen in Betracht zu ziehen.

Wir haben zwar nicht viel Anklang gefunden, aber wir haben nur freiwillige Ressourcen und wurden nicht so bekannt wie die aktuelle "Haben Sie schon an der WordPress 2017-Umfrage teilgenommen?" Link auf WordPress.org – aber wir haben einige wertvolle Erkenntnisse gewonnen. Bitte guck dir das an:
https://make.wordpress.org/marketing/handbook/resources/surveys/wordpress-usage-survey-2017/

@David Skarjune - danke, das bestätigt ziemlich genau, was ich mir vorgestellt hatte.
Die meisten Organisationen verzichten auf diesen Schritt, weil er sie von Angesicht zu Angesicht bringt
mit der Realität, anstatt sie tun zu lassen, was sie wollen, oder was
ist schlimmer, was sie aufgrund von Bauchreaktionen und Vergangenheit beschlossen haben
Erfahrung. Bleibt also die Frage. was würde ich am besten mitbringen
etwas Realität in diese Geschichte des Back-to-Front-Gutenberg-Projekts. Von
Übrigens, ich bin mir nicht sicher, ob ich mich richtig erinnere, ob ich es nur geträumt habe,
aber war Gutenberg nicht eines von Matts Babys? Wenn ja, frage ich mich, was war das?
Motivation und wie "echt" das war?

Am Freitag, den 1. Dezember 2017 um 16:54 Uhr schrieb David Skarjune [email protected] :

Terrence, ich habe dieses Jahr die Marktforschung für ein Make WordPress untersucht
Marketingprojekt. Es gab einige informelle Umfragen unter Designern,
Entwickler und Agenturen auf WordPress, aber nichts formelles oder schlüssiges
über die Nutzung. Unser Projekt konzentrierte sich auf eine informelle Befragung von Agenturen zu
WordPress-Nutzung, ausschließlich zum Zweck der Entwicklung von Supportmaterialien für
Agenturen zur Vermarktung von WordPress an Kunden und zur Berücksichtigung von Enterprise
Annahme.

Wir haben zwar nicht viel Anklang gefunden – wir haben nur freiwillige Ressourcen und
keine Exposition wie die aktuelle "Hast du WordPress 2017 genommen" bekommen?
Umfrage schon?"-Link auf WordPress.org – aber wir haben einige wertvolle Erkenntnisse gewonnen.
Bitte guck dir das an:

https://make.wordpress.org/marketing/handbook/resources/surveys/wordpress-usage-survey-2017/

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/WordPress/gutenberg/issues/3354#issuecomment-348547816 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AD0dztdHtoNFHDbK2mNc_yma5n8O1GFpks5s8C8zgaJpZM4QTl13
.

>

https://qloudpress.com/
Kypeside-Ställe, Nether Kypeside
von Deadwaters, South Lanarkshire ML11 0JL
Telefon: +44 (0)141-416-3322

PGP-Schlüssel-ID: 18D7884E29597525
http://keyserver.pgp.com

@Skarjune - interessante Informationen, danke für den Link. Mein Hauptanliegen bei dieser Umfrage als Leitfaden für die WP-Community ist die Aufschlüsselung, wie Menschen ihre Rollen beschreiben. Entwickler... 30%. Inhaltsersteller... 1%. Auf die Frage, wie viele Websites sie verwalten, gaben 46 % 25 oder mehr an. Dieses Publikum ist typisch für Agenturen, nicht für die Leute, die WP verwenden, um Inhalte zu erstellen und zu verwalten.

Dies ist eine großartige Ressource, um die Perspektive von Agenturen zu verstehen, aber ich habe das Gefühl, dass wir auch die Perspektive der Menschen verstehen müssen, die die von uns entwickelten Lösungen verwenden.

@rickgregory @TerenceMilbourn Die Umfrage war eine kleine selbstgewählte Fokusgruppe, die auf einen offenen Aufruf reagierte, der auf WP-org, WP Tavern und Social Media beworben wurde, um WordPress-Marketing zu leiten. Es war nicht als breites WordPress-Forschungsinstrument gedacht, wie unten erläutert. Hier ist die Aufschlüsselung der Befragten (Unternehmen=Kunde):

Agentur: 58 69%
__Wartung​ ​WordPress​ ​für​ ​Kunden 46 — 55%
__Bereitstellung von​ ​WordPress​ ​für​ Kunden 12 — 14%
Unternehmen: 18 21%
__WordPress nutzen​ ​mit​ ​Host 14 — 17%
__WordPress nutzen​ ​mit​ ​Agentur 4 — 5%
Unternehmen: 8 10 %
__Enterprise​ ​WordPress​ ​(Netzwerk/Cloud) 4 — 5%
__Host​​bietet​​WordPress 4 — 5%

Lassen Sie uns nicht vom Thema abschweifen, aber lassen Sie mich die Notwendigkeit einer WordPress-Roadmap kommentieren, die sich derzeit auf das Gutenberg-Projekt konzentriert.

Die Umfrage war meine Idee als Reaktion auf Ideen, die vom Startup-Marketing-Team beim WCUS 2016 Contributor Day generiert wurden, insbesondere für die Untergruppe zu Kunden und Agenturen, deren Vorsitzender ich jetzt bin. Mein Interesse bestand darin, mich bei Agenturen über die Verwendung von WordPress zu erkundigen, bevor ich versuchte, es bei weiteren Agenturen zu bewerben.

Während die Befragten positivere Bewertungen von Gründen für die Verwendung von WordPress als von Barrieren dagegen hatten, war die Roadmap (dh das Fehlen davon) ein Haupthindernis, weshalb ich in diesem Thementhread poste.

Ja, es wäre schön, eine breite Perspektive auf die Verwendung von WordPress zu haben, aber das würde ernsthafte Ressourcen und Sponsoring erfordern. Leider scheint das Argument hinter Gutenberg zu sein, dass Blogger in Zukunft ein Blockbildungssystem brauchen, obwohl ich dafür keine Beweise gesehen habe oder warum dies angesichts der großen Benutzer- und Anwendungsfallbasis ein Hauptfaktor wäre

Persönlich arbeite ich seit einigen Jahren an Enterprise-CMS-Projekten auf verschiedenen Plattformen, und Workflow-Anliegen können komplex sein. Der Editor ist normalerweise an den Workflow angepasst und variiert je nach Benutzerrolle, und auch die Stapelverarbeitung wird verwendet. Ich habe noch nie eine Entweder/Oder-Frage gesehen, welcher Editor der beste ist. Die beste Referenz zu einigen davon ist "Author Experience" von Rick Yagodich. Ich habe in den letzten Jahren bei einigen WordCamps über das Thema gesprochen, aber ehrlich gesagt hat sich niemand darum gekümmert ... jetzt könnte man meinen, es sei wichtig.

@Skarjune - OK, ich hatte jetzt Zeit, den Bericht zu lesen und darüber nachzudenken, und
es ist wirklich ein ausgezeichnetes Dokument. Ich kann sehen, dass viel harte Arbeit darin steckt
es und es bietet offensichtlich einige wesentliche Rückmeldungen und Bestätigungen.

Meine Reaktion darauf wäre, sagen wir, als Kunde, der den Bericht in Auftrag gegeben hat,
dass es in seinem Umfang für das, was wir jetzt wollen, zu begrenzt ist, da es nur wirklich
zielt darauf ab, Feedback von Agenturen und der Entwickler-Community zu erfassen.

Um zu versuchen und zu verstehen, was Gutenberg genau sein sollte und wie es sein sollte
sollte funktionieren, ich denke, wir brauchen einen viel stärker nach außen gerichteten Ansatz, damit
wir beginnen, die Marktreaktionen, Absichten und Bedürfnisse der Endverbraucher zu verstehen,
wenn es um die Art von Inhalten geht, die sie erstellen und verwalten möchten. Und
wie sie das machen wollen.

Es überrascht mich, dass die Neugier zumindest nicht getrieben hat
WordPress oder Automattic, um eine Marktforschung in Auftrag zu geben, die gleichzeitig
zumindest in der Lage ist, die Branchensegmentierung endgültig aufzuschlüsseln,
Endbenutzer-Organisationstypen, Aufschlüsselung nach Anwendungsfällen usw. für alle seine Millionen
der Endverbraucher.

Ich meine, wie kann jemand entscheiden, was er baut, wenn er nicht weiß, wer er ist?
bauen sie dafür?

Wenn wir diese Grundlagen nicht verstehen, sprechen wir weiter mit
uns im Wesentlichen selbst und verzichten auf jeden wesentlichen Input aus der realen Welt. Und
Das bedeutet, dass wir nicht verstehen, was da draußen wirklich gebraucht wird, und könnten
Mach einfach weiter und baue etwas, was die Entwickler für ordentlich halten
Lösung.

Aber eine Lösung wofür? Das ist die eigentliche Frage.

Mit der Möglichkeit, einen Fragebogen an Millionen von Endbenutzern über die
WordPress-Dashboard zum Beispiel könnten wir, wenn wir wirklich wollten
verstehen, was die Leute brauchen, die dieses Tool täglich verwenden
Basis ~ entsprechend den Bedürfnissen innerhalb des WordPress-Ökosystems ~ take a
wirklich globale Auswahl von Meinungen und Entwicklung einer Marktdefinition,
Segmentgröße und andere Metriken, auf denen zukünftige Ziele aufgebaut werden können und
Planung.

Ein ausgeklügelter Fragebogen und eine ausgeklügelte Methodik können extrem sein
sinnvoll, solange das Projekt nicht zu weit kriechen durfte.

Wie würden wir so etwas machen. Könnten wir sowas machen
das?

Am Freitag, den 1. Dezember 2017 um 20:01 Uhr schrieb rickgregory [email protected] :

@Skarjune https://github.com/skarjune - interessante Infos, danke
für den Link. Mein Hauptanliegen bei dieser Umfrage als Leitfaden für das WP
Gemeinschaft ist die Aufschlüsselung, wie Menschen ihre Rollen beschreiben. Entwickler...
30%. Inhaltsersteller... 1%.

Es fühlt sich für mich so an, als ob wir die Perspektive nicht nur verstehen müssen von
Menschen, die Lösungen entwickeln, sondern von denen, die die von uns entwickelten Lösungen verwenden.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/WordPress/gutenberg/issues/3354#issuecomment-348600347 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AD0dzqdI4q0CIp4ViLLF6duied048AhEks5s8FsugaJpZM4QTl13
.

>

https://qloudpress.com/
Kypeside-Ställe, Nether Kypeside
von Deadwaters, South Lanarkshire ML11 0JL
Telefon: +44 (0)141-416-3322

PGP-Schlüssel-ID: 18D7884E29597525
http://keyserver.pgp.com

@TerenceMilbourn Es gibt Gutenberg-Usability-Tests, das ist also zusammen mit der Forderung nach einer klareren Roadmap hilfreich. Telemetrie wurde für WordPress diskutiert, aber das wird kompliziert, ebenso wie massive Recherchen. Was Gutenberg betrifft, so wird uns der aktuelle Fokus auf Benutzerfreundlichkeit und Roadmap helfen, festzustellen, ob es angemessen ist, Version 5 Anfang 2018 auf den Markt zu bringen.

Wenn Sie weitere Gedanken oder Vorschläge haben, treten Sie bitte dem Make WordPress Marketing Slack-Kanal bei: https://make.wordpress.org/marketing/

Zwei Ziele für 2018 sind

Gutenberg-BearbeitungGutenberg-Anpassung

Gibt es ein Update zum ursprünglichen Problem? Konkret dies:

Eine einzige Ressource, die erklärt
a) warum gibt es Gutenberg (eine vereinfachte Version von @ms Beitrag?),
b) wohin es geht (Endziele + große Vision),
c) warum das Projekt derzeit den Redakteur im Fokus hat und
d) dass der Editorfokus der erste Baustein in einem größeren Plan ist

Ich habe heute nach einem Roadmap-Dokument gesucht und kann keins finden.

@mor10 , dies wurde während der heutigen Gutenberg-Bug- überprüft. Wir würden gerne Ihr Feedback zu wordpress.org/gutenberg und der README.md dieses

@jeffpaul Zunächst einmal gibt es keine Roadmap. Niemand wird eine klare Antwort darauf geben, welche Funktionen Gutenberg bei der ersten Veröffentlichung haben wird und/oder welche Funktionen in späteren Revisionen enthalten sein werden.

Ja, Gutenberg hat eine gute Dokumentation hinzugefügt. Aber, wie einige bemerkt haben, gibt es keine nützliche Entwicklungs-Roadmap, im Vergleich zu Drupal zum Beispiel. Es gibt zwar eine detaillierte Entwicklungsverfolgung, aber wo ist die High-Level-Roadmap?

Ein großes Anliegen ist die langfristige Unterstützung. Es wurde gesagt, dass 4.9.x nach dem Start von 5.x gepatcht wird, und das war in der Vergangenheit der Fall:
https://codex.wordpress.org/WordPress_Versions

Da der Community dringend empfohlen wird, mit 5.0 fortzufahren, werden ältere Versionen weiterhin gepatcht und wie lange?

Es besteht die Befürchtung, dass der Legacy-Pfad verwirrend sein könnte. Als Teillösung wird das Classic Editor Plugin angeboten, das aber auch Gutenberg und einige zusätzliche Konfigurationen erfordert. Das Ziel von LTS ist es, einen sicheren Weg für einige Jahre zu gewährleisten, wenn vollständige Upgrades auf neue Technologien nicht gerechtfertigt oder budgetiert sind.

@maddisondesigns @Skarjune fehlt ein Roadmap-Dokument, das Sie bevorstehenden Meilensteine ​​für Gutenberg.

@Skarjune meiner Erfahrung nach, die weniger als 2 Jahre Freiwilligenarbeit mit WordPress-Kern ist, sind die Patches auf 3.7.x zurückgegangen. Ich denke, es ist realistisch zu erwarten, dass das Patchen so weit zurück wahrscheinlich nicht ewig dauern wird, aber es ist noch realistischer zu erwarten, dass alle Entscheidungen darüber während offener Meetings in Slack mit Updates getroffen werden, die an Make/Core gepostet werden.

@jeffpaul Ehrlich gesagt ist das meistens nutzlos. Alles, was das tut, ist im Grunde die Bereitstellung von Links zu den verschiedenen markierten Gutenberg-Meilensteinen. Es enthält nicht nur einen sehr kleinen Teil der Probleme, die tatsächlich mit einem Meilenstein versehen wurden, es ist auch viel zu einfach für jeden, die Meilensteine ​​einfach zu ändern, sollte er sich entscheiden. Was nützt eine Roadmap, wenn man am Tag vor der Veröffentlichung des Projekts einfach alle Meilensteine ​​ändern kann, sollte man Lust dazu haben?

Es muss eine richtige (einfach englisches) Projekt-Roadmap geben, die alle Funktionen umreißt, die in Gutenberg ab WP5.0 verfügbar sein werden, zusammen mit den Funktionen, die in die folgenden Releases (5.1, 5.2 usw. ..). Im Moment hat niemand außerhalb des Gutenberg-Projekts eine Ahnung, welche Funktionalität sie erwarten können, wenn diese endlich im Kern ist, und niemand wird auf Nachfrage Antworten geben. Alles, was uns gesagt wird, ist, dass "_Gutenberg wird mit WordPress 5.0 ausgeliefert, aber die Veröffentlichung wird herauskommen, wenn Gutenberg fertig ist, nicht umgekehrt_".

Wer entscheidet, wann Gutenberg „fertig“ ist? Wie treffen sie diese Entscheidung? Wer entscheidet, welche Funktionalität in Core freigegeben wird? Wer entscheidet, welche Funktionalität in die erste Version und was in die folgende Version einfließt? Es ist offensichtlich, dass niemand außerhalb der Gutenberg-Kernentwickler an dieser Entscheidung beteiligt sein wird. Es ist lächerlich, dass das Projekt so lange andauert, ohne dass ein Umfang oder eine Roadmap definiert wurde, was auch bedeutet, dass es wenig bis gar keine Diskussion mit der WP-Community darüber gegeben hat, welche Funktionalität die Leute tatsächlich in diesem Ding sehen möchten.

@jeffpaul Danke für die Info! Das ist hilfreich, aber mehr für den internen Entwicklungsprozess und interessierte Parteien, weniger für externe Parteien, die kurz- und langfristig Systemarchitektur und Support planen.

Zum Beispiel sind Drupal-Versionsmeilensteine ​​und LTS sehr spezifisch:
Roadmap für die Drupal-Entwicklung
Drupal-Kern-Release-Zyklus : Haupt-, Neben- und Patch-Releases

Joomla hingegen schwankt ein wenig über sein neues 4.0-Framework, was angesichts seiner früheren Versionsprobleme kein gutes Zeichen für das Projekt ist:
Joomla!

Trotz der Debatten über Gutenberg und im Sinne der Ansprache "Bereitstellen eines klaren Umrisses von Projektumfang, -richtung und -zielen" würden eine detaillierte Roadmap und ein LTS-Zeitplan einen großen Unterschied machen, insbesondere für Agentur- und Unternehmenscamps. Danke für Ihre Hilfe!

Es gibt viele Informationen, sowie das Leitbild von Gutenberg ( Alles ist ein Block ), in der README des Projekts.

Obwohl ich denke, dass in dieser Ausgabe einige gute Ideen enthalten sind, ist die Ausgabe mit vielen verschiedenen Stimmen, verschiedenen Fragen und verschiedenen Zielen ziemlich überwältigend geworden.

Ein Großteil des Feedbacks in dieser Ausgabe wurde/wird weiterhin vom Gutenberg-Team bearbeitet. Einer der gemeinsamen Threads, die ich hier sehe, sind Sorgen um die Roadmap/Kompatibilität; Ich denke, es ist wichtig, sich daran zu erinnern, dass WordPress 5 mit Gutenberg ausgeliefert werden soll, Benutzer jedoch immer noch auf den "Classic Editor" zurückgreifen können, sodass wir die Benutzer nicht im Stich lassen sollten.

Ich werde dies schließen, weil ich denke, dass es kein umsetzbares Problem ist. Das heißt nicht, dass hier alles falsch ist oder dass es keine umsetzbaren Elemente gibt. Im Allgemeinen gibt es zu viele, um dieses Thema einfach als "geschlossen" zu betrachten.

Was hast du mit WP Tavern gemacht !!?? Ich komme, um WP-Nachrichten zu lesen, und das ganze Portal dient der Gutenberg-Propaganda. Gib mir eine Pause.

Ja, ich kenne die Antwort. Sie sind nicht mit ihnen verbunden.