Tanger
Member
Brian Coords hat einen sehr interessanten Artikel auf WPTavern veröffentlicht - es geht um das FSE-Program und den Site-Editor ::
Gutenberg’s Project Leadership Sits Down with New Outreach Team to Discuss Problems with the Site Editor
Was bekommen Ihr, wenn ihr eine Handvoll ausgesprochener WordPress-Entwickler, Agenturen, Produktbesitzer und Community-Befürworter zu einem Videoanruf mit dem Hauptarchitekten und dem Produktbesitzer des gesamten Gutenberg-Projekts zusammenbringen? Hoffentlich Fortschritte.
Matt Mullenweg hat vielleicht einige Leute überrascht, als er kürzlich erklärte, dass das Gutenberg-Projekt noch Jahre in der Entwicklung sei, aber ich bezweifle, dass irgendjemand, der es nutzt, dem widersprechen würde. Die Tentpole-Funktion von Gutenbergs Phase Zwei, der „Site Editor“, ist seit zwei Jahren im Kern enthalten (und standardmäßig für Neuinstallationen aktiviert), aber die Einführung blockbasierter Themes hat sich bestenfalls enttäuschend angefühlt, insbesondere im Vergleich dazu der Marktanteil von Seitenerstellungstools wie Elementor.
Das Outreach-Experiment1
Das FSE Outreach Experiment wurde vor drei Jahren ins Leben gerufen, um die Lücke zwischen Benutzern, die den Site Editor kennen, und den wichtigsten Mitwirkenden, die ihn erstellen, zu schließen. Letzte Woche gab das Team einen vereinfachten Namen und Umfang bekannt: Outreach. Im Rahmen dieses neuen, vereinfachten Umfangs kann nun jeder Hauptmitwirkende das Outreach-Team direkt in GitHub taggen, während es neue Funktionen entwickelt, wenn er frühzeitiges Feedback von der breiteren Community einholen möchte. Das Ziel besteht darin, mehr wechselseitige Kommunikation zu erreichen und das Feedback dort zu halten, wo es am effektivsten sein kann: im Make WordPress Slack und im Gutenberg-Code-Repository auf GitHub.
Soziale Medien scheinen der einfachste Ort zu sein, eine Meinung zu äußern (etwas, woran ich sicherlich schuld bin), aber sie führen nicht immer zu bedeutsamen Veränderungen. „Bei den meisten unserer Probleme geht es nur um die Auffindbarkeit“, betonte Justin Tadlock, Developer Advocate und Outreach-Teammitglied, kürzlich. „Ich bringe einfach die Leute dazu, zu kommen und all ihre Reaktionen und Gedanken aus den sozialen Medien aufzugreifen, sie einzubringen und einige konstruktive Gespräche in einem offiziellen Kanal zu führen.“
Automattic Product Wrangler Anne McCarthy startete das ursprüngliche FSE Outreach-Experiment, ist aber seitdem weitergezogen. Das hinderte sie nicht daran, Feedback zum Site Editor in Form eines weit verbreiteten Blog-Beitrags mit dem Titel „Überlappende Probleme“ zu geben. Es handelt sich um eine Aufschlüsselung einiger der häufigsten Beschwerden über die Benutzererfahrung, aber fast jedes Feedback bezieht sich auf ein bestimmtes Problem oder einen Pull-Request, bei dem daran gearbeitet wird, es zu verbessern. Wenn Sie es noch nicht getan haben, empfehle ich Ihnen, jetzt innezuhalten und es zu lesen.
Da sich die Probleme „überschneiden“, meinen einige, dass sie auf ein zugrunde liegendes Problem des Site-Editors selbst und des Gutenberg-Entwicklungsprozesses im weiteren Sinne hinweisen. Beim Hallway Hangout letzte Woche, der vom Outreach-Team veranstaltet wurde und an dem eine breite Palette von Leuten teilnahm, darunter Gutenbergs leitender Architekt Matias Ventura und Rich Tabor, wurden viele Ansätze und Theorien verworfen, darunter auch einige von Ihnen.
Hört das Kernteam zu?
Feedbackschleifen in einer so großen und vielfältigen Community sind (wenig) überraschend schwer richtig zu gestalten. Ein klares Feedback scheint jedoch das allgemeine Gefühl zu sein, dass die Leistung und der Funktionsumfang des Site-Editors zwar weiter zunehmen, das tatsächliche Benutzererlebnis jedoch verbessert werden muss. Wenn jedoch Bedenken hinsichtlich dieser Benutzererfahrung geäußert werden, ist die allgemeine Reaktion, dass es die Benutzer sind, die einfach mehr Bildung und Schulung benötigen.
„Ich habe immer wieder das Gefühl beobachtet“, erklärte Mike McAlister von Ollie bei dem Anruf, „dass ‚sie uns nicht zuhören‘.“ Und ob das nun eine Wahrnehmung oder ihre Erfahrung oder was auch immer ist, ich denke, es ist für uns sehr wichtig, das zu tragen und es irgendwie anzuerkennen.“
Ein Teil der Diskrepanz zwischen den verschiedenen Seiten unserer großen Gemeinschaft hängt mit dem Ungleichgewicht der Anreize unter den Mitwirkenden zusammen. Sofern Sie nicht bei einem Hosting-Unternehmen oder einem Produktteam wie WooCommerce oder Yoast angestellt sind, kann es entmutigend sein, eine Funktion voranzutreiben, oder das Gefühl haben, dass sich niemand für Ihren Anwendungsfall einsetzt.
WordPress soll die Möglichkeit demokratisieren, Inhalte ins Internet zu stellen. Daher besteht die Erwartung, dass sich die Benutzeroberfläche einfacher oder zumindest intuitiver anfühlt. Nick Diego, Developer Advocate von Automattic, erzählte von einem Erlebnis, als er seinen technisch nicht versierten Eltern beim Navigieren im Site Editor zusah.
„Eines der größten Probleme, die ich beim Site-Editor sehe“, erklärte er, „besteht darin, wie die von Ihnen vorgenommenen Änderungen beibehalten werden, um zu verhindern, dass Benutzer Fehler machen.“ Und das scheint eine so kleine Kleinigkeit zu sein, aber ich habe gesehen, wie [mein Vater] eine Vorlage gelöscht hat, die angepasst worden war, und es gab keine Möglichkeit, sie einfach wiederherzustellen. Ich sah zu, wie er auf „Anpassungen löschen“ klickte und alles war weg. Und er meinte: „Warte, was, was ist los?“
Nick präsentierte ein großartiges praktisches Beispiel für die Art von Lücken in der Benutzererfahrung, die schließlich ihr Vertrauen in die Fähigkeit der Plattform, Inhalte sicher zu verwalten, untergraben. Er wies auch darauf hin, dass es für viele dieser Interaktionen bewährte Konventionen gebe. „Wenn Sie in altem WordPress die Seite in den Papierkorb verschieben, landet sie im Papierkorb und Sie können sie dann dauerhaft löschen, oder? Es wandert in Ihren Papierkorb. Oh, ich habe einen Fehler gemacht? Das kann ich zurückbringen. Es ist ein sehr logischer Ablauf. Es ist anderen Anwendungen sehr ähnlich.“ Bei der Benutzeroberfläche betritt der Site Editor jedoch häufig Neuland.
Neue Tools und neue Paradigmen sind nicht nur für technisch nicht versierte Benutzer eine Herausforderung. Sie können Entwickler, die neue WordPress-Sites starten möchten, vor neue Herausforderungen stellen. Die Zeit, die Entwickler zuvor mit der Erstellung von Websites verbracht haben, wird heute häufig mit der Erkundung neuer potenzieller Arbeitsabläufe verbracht, und wir können uns bei der Festlegung des Umfangs neuer Projekte nicht auf unsere bewährten Best Practices aus den vergangenen zwei Jahrzehnten verlassen. „Ich denke, ein Teil davon“, sagte Anne McCarthy, „besteht auch darin, wie man diese Tools und den Änderungsprozess nutzt, denn alles, was ich gehört habe, ist, dass es sich nicht nur um eine technische Änderung und die Anpassung an neue Technologien handelt, sondern um einen Änderungsprozess.“
Diese Idee, die grundlegende Benutzererfahrung zu verlangsamen und zu verfeinern, wurde von Brian Gardner, Developer Advocate bei WP Engine, bekräftigt, der sich für „einen Aufruf dafür einsetzte, das, was wir bereits haben, besser und konsistenter zu machen und es einfacher zu identifizieren, zu bearbeiten, zu dokumentieren und weiterzubilden.“ ” Insbesondere WP Engine hat sich mit einem Team aus Pädagogen und Inhaltserstellern sowie Produkten wie Advanced Custom Fields und LocalWP auf die Entwickler-/Freiberuflerseite der Community konzentriert, die sich alle auf ein Marktsegment konzentrieren, das sie „Builder“ nennen und was das ist Das Kernteam wird oft als „Extender“ bezeichnet.
Die Extender2
Extender, Entwickler, Freiberufler, Agenturen. Es gibt viele Namen für diese Seite der Community, aber eines haben sie gemeinsam: Sie erstellen viele Websites, oft für andere, weniger technisch versierte Leute. In dieser Gruppe ist die Meinung weit verbreitet, dass das Gutenberg-Projekt ihre Bedürfnisse nicht priorisiert und sie zum klassischen Editor oder zu Seitenerstellern wie Elementor, Divi und Bricks drängt.
Fabian Kägy ist Mitglied des Outreach-Teams und Sponsored Contributor der Agentur 10up. Er konzentriert sich darauf, mehr Gespräche zwischen der Extender-Community und der Kernentwicklung zu fördern, deshalb habe ich mit ihm über diese Diskrepanz bei den Prioritäten gesprochen.
„Es gibt so viele verschiedene Benutzer, die alle unterschiedliche Anrufe haben“, sagte er mir. „Und der Grund, warum ich versuche, teilzunehmen, besteht darin, diese eine Seite der Geschichte zu teilen und ein Fürsprecher für diese bestimmte Arbeit zu sein. Und ich hoffe sehr, dass ich tatsächlich mehr ähnliche Leute von anderen Agenturen dazu bringen kann, sich ebenfalls einzuschalten und Teil eines Gesprächs zu sein.“
Wie Fabian komme ich aus der Agenturwelt, wo wir ständig versuchen, den Wunsch, die neuesten Technologien für unsere Kunden zu übernehmen, mit dem Bedürfnis nach der Gewissheit in Einklang zu bringen, dass diese neuen Funktionen tatsächlich für den Einsatz in der Produktion bereit sind. Das stellt ein schwer zu lösendes Problem dar. Das Kernteam braucht mehr Leute, die diese Funktionen nutzen und testen, um sie weiterzuentwickeln. Von außen betrachtet zögern wir jedoch, etwas zu verwenden, das möglicherweise noch nicht serienreif ist.
Link zum Artikel:
Gutenberg’s Project Leadership Sits Down with New Outreach Team to Discuss Problems with the Site Editor
You do not have permission to view link please Anmelden or Registrieren
Was bekommen Ihr, wenn ihr eine Handvoll ausgesprochener WordPress-Entwickler, Agenturen, Produktbesitzer und Community-Befürworter zu einem Videoanruf mit dem Hauptarchitekten und dem Produktbesitzer des gesamten Gutenberg-Projekts zusammenbringen? Hoffentlich Fortschritte.
Matt Mullenweg hat vielleicht einige Leute überrascht, als er kürzlich erklärte, dass das Gutenberg-Projekt noch Jahre in der Entwicklung sei, aber ich bezweifle, dass irgendjemand, der es nutzt, dem widersprechen würde. Die Tentpole-Funktion von Gutenbergs Phase Zwei, der „Site Editor“, ist seit zwei Jahren im Kern enthalten (und standardmäßig für Neuinstallationen aktiviert), aber die Einführung blockbasierter Themes hat sich bestenfalls enttäuschend angefühlt, insbesondere im Vergleich dazu der Marktanteil von Seitenerstellungstools wie Elementor.
Das Outreach-Experiment1
Das FSE Outreach Experiment wurde vor drei Jahren ins Leben gerufen, um die Lücke zwischen Benutzern, die den Site Editor kennen, und den wichtigsten Mitwirkenden, die ihn erstellen, zu schließen. Letzte Woche gab das Team einen vereinfachten Namen und Umfang bekannt: Outreach. Im Rahmen dieses neuen, vereinfachten Umfangs kann nun jeder Hauptmitwirkende das Outreach-Team direkt in GitHub taggen, während es neue Funktionen entwickelt, wenn er frühzeitiges Feedback von der breiteren Community einholen möchte. Das Ziel besteht darin, mehr wechselseitige Kommunikation zu erreichen und das Feedback dort zu halten, wo es am effektivsten sein kann: im Make WordPress Slack und im Gutenberg-Code-Repository auf GitHub.
Soziale Medien scheinen der einfachste Ort zu sein, eine Meinung zu äußern (etwas, woran ich sicherlich schuld bin), aber sie führen nicht immer zu bedeutsamen Veränderungen. „Bei den meisten unserer Probleme geht es nur um die Auffindbarkeit“, betonte Justin Tadlock, Developer Advocate und Outreach-Teammitglied, kürzlich. „Ich bringe einfach die Leute dazu, zu kommen und all ihre Reaktionen und Gedanken aus den sozialen Medien aufzugreifen, sie einzubringen und einige konstruktive Gespräche in einem offiziellen Kanal zu führen.“
Automattic Product Wrangler Anne McCarthy startete das ursprüngliche FSE Outreach-Experiment, ist aber seitdem weitergezogen. Das hinderte sie nicht daran, Feedback zum Site Editor in Form eines weit verbreiteten Blog-Beitrags mit dem Titel „Überlappende Probleme“ zu geben. Es handelt sich um eine Aufschlüsselung einiger der häufigsten Beschwerden über die Benutzererfahrung, aber fast jedes Feedback bezieht sich auf ein bestimmtes Problem oder einen Pull-Request, bei dem daran gearbeitet wird, es zu verbessern. Wenn Sie es noch nicht getan haben, empfehle ich Ihnen, jetzt innezuhalten und es zu lesen.
Da sich die Probleme „überschneiden“, meinen einige, dass sie auf ein zugrunde liegendes Problem des Site-Editors selbst und des Gutenberg-Entwicklungsprozesses im weiteren Sinne hinweisen. Beim Hallway Hangout letzte Woche, der vom Outreach-Team veranstaltet wurde und an dem eine breite Palette von Leuten teilnahm, darunter Gutenbergs leitender Architekt Matias Ventura und Rich Tabor, wurden viele Ansätze und Theorien verworfen, darunter auch einige von Ihnen.
Hört das Kernteam zu?
Feedbackschleifen in einer so großen und vielfältigen Community sind (wenig) überraschend schwer richtig zu gestalten. Ein klares Feedback scheint jedoch das allgemeine Gefühl zu sein, dass die Leistung und der Funktionsumfang des Site-Editors zwar weiter zunehmen, das tatsächliche Benutzererlebnis jedoch verbessert werden muss. Wenn jedoch Bedenken hinsichtlich dieser Benutzererfahrung geäußert werden, ist die allgemeine Reaktion, dass es die Benutzer sind, die einfach mehr Bildung und Schulung benötigen.
„Ich habe immer wieder das Gefühl beobachtet“, erklärte Mike McAlister von Ollie bei dem Anruf, „dass ‚sie uns nicht zuhören‘.“ Und ob das nun eine Wahrnehmung oder ihre Erfahrung oder was auch immer ist, ich denke, es ist für uns sehr wichtig, das zu tragen und es irgendwie anzuerkennen.“
Ein Teil der Diskrepanz zwischen den verschiedenen Seiten unserer großen Gemeinschaft hängt mit dem Ungleichgewicht der Anreize unter den Mitwirkenden zusammen. Sofern Sie nicht bei einem Hosting-Unternehmen oder einem Produktteam wie WooCommerce oder Yoast angestellt sind, kann es entmutigend sein, eine Funktion voranzutreiben, oder das Gefühl haben, dass sich niemand für Ihren Anwendungsfall einsetzt.
WordPress soll die Möglichkeit demokratisieren, Inhalte ins Internet zu stellen. Daher besteht die Erwartung, dass sich die Benutzeroberfläche einfacher oder zumindest intuitiver anfühlt. Nick Diego, Developer Advocate von Automattic, erzählte von einem Erlebnis, als er seinen technisch nicht versierten Eltern beim Navigieren im Site Editor zusah.
„Eines der größten Probleme, die ich beim Site-Editor sehe“, erklärte er, „besteht darin, wie die von Ihnen vorgenommenen Änderungen beibehalten werden, um zu verhindern, dass Benutzer Fehler machen.“ Und das scheint eine so kleine Kleinigkeit zu sein, aber ich habe gesehen, wie [mein Vater] eine Vorlage gelöscht hat, die angepasst worden war, und es gab keine Möglichkeit, sie einfach wiederherzustellen. Ich sah zu, wie er auf „Anpassungen löschen“ klickte und alles war weg. Und er meinte: „Warte, was, was ist los?“
Nick präsentierte ein großartiges praktisches Beispiel für die Art von Lücken in der Benutzererfahrung, die schließlich ihr Vertrauen in die Fähigkeit der Plattform, Inhalte sicher zu verwalten, untergraben. Er wies auch darauf hin, dass es für viele dieser Interaktionen bewährte Konventionen gebe. „Wenn Sie in altem WordPress die Seite in den Papierkorb verschieben, landet sie im Papierkorb und Sie können sie dann dauerhaft löschen, oder? Es wandert in Ihren Papierkorb. Oh, ich habe einen Fehler gemacht? Das kann ich zurückbringen. Es ist ein sehr logischer Ablauf. Es ist anderen Anwendungen sehr ähnlich.“ Bei der Benutzeroberfläche betritt der Site Editor jedoch häufig Neuland.
Neue Tools und neue Paradigmen sind nicht nur für technisch nicht versierte Benutzer eine Herausforderung. Sie können Entwickler, die neue WordPress-Sites starten möchten, vor neue Herausforderungen stellen. Die Zeit, die Entwickler zuvor mit der Erstellung von Websites verbracht haben, wird heute häufig mit der Erkundung neuer potenzieller Arbeitsabläufe verbracht, und wir können uns bei der Festlegung des Umfangs neuer Projekte nicht auf unsere bewährten Best Practices aus den vergangenen zwei Jahrzehnten verlassen. „Ich denke, ein Teil davon“, sagte Anne McCarthy, „besteht auch darin, wie man diese Tools und den Änderungsprozess nutzt, denn alles, was ich gehört habe, ist, dass es sich nicht nur um eine technische Änderung und die Anpassung an neue Technologien handelt, sondern um einen Änderungsprozess.“
Diese Idee, die grundlegende Benutzererfahrung zu verlangsamen und zu verfeinern, wurde von Brian Gardner, Developer Advocate bei WP Engine, bekräftigt, der sich für „einen Aufruf dafür einsetzte, das, was wir bereits haben, besser und konsistenter zu machen und es einfacher zu identifizieren, zu bearbeiten, zu dokumentieren und weiterzubilden.“ ” Insbesondere WP Engine hat sich mit einem Team aus Pädagogen und Inhaltserstellern sowie Produkten wie Advanced Custom Fields und LocalWP auf die Entwickler-/Freiberuflerseite der Community konzentriert, die sich alle auf ein Marktsegment konzentrieren, das sie „Builder“ nennen und was das ist Das Kernteam wird oft als „Extender“ bezeichnet.
Die Extender2
Extender, Entwickler, Freiberufler, Agenturen. Es gibt viele Namen für diese Seite der Community, aber eines haben sie gemeinsam: Sie erstellen viele Websites, oft für andere, weniger technisch versierte Leute. In dieser Gruppe ist die Meinung weit verbreitet, dass das Gutenberg-Projekt ihre Bedürfnisse nicht priorisiert und sie zum klassischen Editor oder zu Seitenerstellern wie Elementor, Divi und Bricks drängt.
Fabian Kägy ist Mitglied des Outreach-Teams und Sponsored Contributor der Agentur 10up. Er konzentriert sich darauf, mehr Gespräche zwischen der Extender-Community und der Kernentwicklung zu fördern, deshalb habe ich mit ihm über diese Diskrepanz bei den Prioritäten gesprochen.
„Es gibt so viele verschiedene Benutzer, die alle unterschiedliche Anrufe haben“, sagte er mir. „Und der Grund, warum ich versuche, teilzunehmen, besteht darin, diese eine Seite der Geschichte zu teilen und ein Fürsprecher für diese bestimmte Arbeit zu sein. Und ich hoffe sehr, dass ich tatsächlich mehr ähnliche Leute von anderen Agenturen dazu bringen kann, sich ebenfalls einzuschalten und Teil eines Gesprächs zu sein.“
Wie Fabian komme ich aus der Agenturwelt, wo wir ständig versuchen, den Wunsch, die neuesten Technologien für unsere Kunden zu übernehmen, mit dem Bedürfnis nach der Gewissheit in Einklang zu bringen, dass diese neuen Funktionen tatsächlich für den Einsatz in der Produktion bereit sind. Das stellt ein schwer zu lösendes Problem dar. Das Kernteam braucht mehr Leute, die diese Funktionen nutzen und testen, um sie weiterzuentwickeln. Von außen betrachtet zögern wir jedoch, etwas zu verwenden, das möglicherweise noch nicht serienreif ist.
Link zum Artikel:
You do not have permission to view link please Anmelden or Registrieren
