it-swarm.com.de

CMS-Schnittstellen: Formulare basierend auf Klicken und Ändern?

In Bezug auf CMS-Schnittstellen würde ich sagen, dass wir sie in zwei Hauptzweige aufteilen könnten [* 1]:

  1. diejenigen mit einem Kontrollfeld, wo Sie normalerweise eine Liste von Seiten (Blog-Artikel/E-Commerce-Produkte) sehen, dann können Sie jede Seite aktualisieren/ändern, indem Sie Formularfelder ausfüllen. Eher wie: WordPress, Joomla ...

  2. Wenn Sie sich die Seite ansehen, klicken Sie auf den Abschnitt, den Sie ändern möchten, und es erscheint ein kleiner Editor, in dem Sie die Änderungen vornehmen.. Eher wie: Jimdo, Google-Sites (ich glaube, ich bin mir nicht sicher), viele andere.

Neben den Vor- und Nachteilen beider Ansätze [* 2]: In gewisser Weise scheinen diejenigen, die auf Kontrollfeldern (auszufüllenden Formularen) basieren, besser zu funktionieren, wenn Sie viele Inhalte verwalten müssen, z. B. große Blogs, große Eccomerce-Websites Der andere Ansatz (Klicken und Ändern) scheint für kleine Websites besser zu sein.

Aber am Ende des Tages, welches ist für den Nicht-Tech-Geek-Endbenutzer leichter zu verstehen/zu verwenden/zu interagieren? (D. H. Meine Mutter)

UPDATE: Gibt es Forschungen/Tests zu diesem Thema?


[* 1] Ich weiß, dass es Plattformen gibt, die versuchen, Ihnen beide Ansätze zu bieten, zum Beispiel in WordPress, nachdem Sie sich angemeldet haben, sehen Sie direkt auf den Seiten kleine Symbole, um die Seite zu ändern, aber ich denke immer noch, WPs Das Control Panel ist eher eine formularbasierte Oberfläche. Wenn ich einen Artikel in meinem Blog ändern muss, verwende ich das Control Panel, das die Formulare ausfüllt.

[* 2] Fühlen Sie sich frei in Ihrer Antwort, um zu erklären, welche anderen Vor- und Nachteile Sie sehen

5
Marco Demaio

Nach meiner Erfahrung sind die meisten WYSIWYG-Editoren selbst für nicht technisch versierte Benutzer zu begrenzt und am Ende des Tages verwirrender als ihre Dashboard-Kollegen.

Wenn ein Anfänger einen WYSIWYG-Editor sieht, erwartet er, dass er genau das anzeigt, was er auf der veröffentlichten Seite sieht. Für alle außer den grundlegendsten Elementen ist dies jedoch normalerweise nicht der Fall, und nicht technisch versierte Benutzer sind verwirrt - entweder weil der Editor ihnen nicht erlaubt, das zu erstellen, was sie wollen, oder weil sie eine Sache im Editor selbst und etwas zeigen ganz anders, nachdem die Seite veröffentlicht wurde.

Dashboard-Oberflächen haben anfangs möglicherweise eine etwas steilere Lernkurve, aber sie werden die Anfänger nicht länger einschränken und keine falschen Erwartungen setzen.

4
Philip Seyfi

Direkte Manipulations-/WYSIWYG-Schnittstellen (Ihre Nummer 2) sind für Anfänger einfacher. Auf diese Weise müssen sie weder die Hierarchie noch die interne Struktur der Website verstehen und nicht erraten, welche Kategorie des Dashboards welche Einstellungen usw. enthält. Sie suchen nur das Element, das sie ändern und bearbeiten möchten es direkt. Sie benötigen möglicherweise den sehr langen und ineffizienten Weg, um dorthin zu gelangen (z. B. Durchsuchen und Blättern statt Suchen), aber letztendlich tun sie dies. Die Lernkurve für diese Art von Schnittstellen ist nicht so steil wie für die vom Typ Dashboard.

3

1 ist viel mehr INHALT-Management. Der Inhalt ist von der Präsentation getrennt und die Aufgaben werden aus einer inhaltsorientierten Perspektive behandelt.

In 2 geht es viel mehr um das PAGE DESIGN-Management. Der Inhalt ist vollständig mit der Präsentation verflochten und Sie ändern ihn als einen.

Im Allgemeinen finde ich, dass der größte Fehler der meisten Content-Management-Systeme darin besteht, dass sie beim Verwalten von Inhalten scheiße sind, weil sie Mühe damit verschwenden, Präsentationen zu verwalten, und in der Regel auch daran scheitern Husten SharePoint Husten.

Die meiste Zeit schlage ich vor, dass # 1 der richtige Weg ist. Dies gilt für große Organisationen mit mehreren Autoren, mehreren Kanälen, mehreren Websites, mehreren Präsentationsebenen usw. In solchen Situationen sollte die Präsentation wirklich von denjenigen gehandhabt werden, die sie verstehen, und der Inhalt sollte von denen gehandhabt werden, die sie verstehen.

Es gibt jedoch Fälle für # 2 ... normalerweise kleinere, marketingorientierte Websites, auf denen eher eine Broschüre als ein Enterprise Content Repository bearbeitet wird.

2
DA01

Dieser Artikel könnte für Sie nützlich sein: In-Context vs. Back-End-Authoring , von Step Two Designs. Es basiert nicht auf Forschung, aber dieses Unternehmen hat viel Erfahrung auf diesem Gebiet.

Dies ist ein Auszug aus dem Artikel:

Aus diesen Gründen wird die Bearbeitung im Kontext häufig als die benutzerfreundlichere Authoring-Option angesehen. Es wird auch allgemein als eine „modernere“ Option zum Aktualisieren der Website angesehen.

Die kontextbezogene Bearbeitung ist nicht ohne Schwächen. Die Einfachheit der Schnittstellen macht einige Aufgaben schwieriger oder zumindest weniger offensichtlich.

1
Pep López

Ich denke, wir müssen den Inhalt differenzieren, den das CMS verwaltet. Wenn wir über "CMS" sprechen, denken alle an WordPress, SharePoint und dergleichen, die normalerweise Folgendes verwalten: Seitenhierarchie, Beiträge, Kategorien und Tags im Bereich meta und Titel, Text und Kommentare im Bereich Inhalt. Es gibt jedoch komplexere CMS wie E-Commerce-Websites.

In den einfachen Fällen halte ich einen gemischten Ansatz für besser . Seitenhierarchie muss in einem Kontrollfeld verwaltet werden (Option 1), aber Titel, Inhaltstext, Bilder und sogar Tags oder Kategorien lassen sich einfacher direkt im Kontext verwalten (Option 2). Sowohl unerfahrene als auch experimentierte Benutzer hätten eine gute Benutzererfahrung, wenn sie Seiten auf true WYSIWYG-Weise bearbeiten könnten (ich hasse es, wenn WordPress mein benutzerdefiniertes CSS nicht anwendet) das WYSIWYG).

Idealerweise sollte der Front-End-Inhalt ​​im Kontext bearbeitet werden können : Texte, Bilder und sogar Blöcke und Widgets. Der Meta-Inhalt ​​sollte aufgrund seines Back-End -Zeichens in einem Control Panel verwaltet werden .

Andere komplexere CMS, wie z. B. E-Commerce-Websites, würden es schwer haben, eine lohnende und effiziente Erfahrung zu bieten, wenn sie komplexe Daten vom Front-End aus verwalten würden. Daher wird sich komplexes CMS normalerweise stark auf Backoffice - oder Control Panel - Management.

StackExchange verwendet eine Art kontextbezogene Bearbeitung. Und ein sehr gutes CMS, das auch kontextbezogene Bearbeitung verwendet, ist Concrete5 :

concrete5 in-context editing

Um Ihre Frage zu beantworten, ist die Bearbeitung im Kontext sowohl für Anfänger als auch für fortgeschrittene Benutzer einfacher zu verstehen und zu interagieren. Dies gilt für einfache CMS, die normalerweise verarbeitet werden Kopieren, Bilder, einige Metadaten und Widgets. Als Einschränkung werden komplexe Inhalte effizienter (daher besser für fortgeschrittene Benutzer) in einem ad hoc Kontrollfeld verwaltet, z. B. E-Commerce-Produkte, hierarchische oder relationale Daten usw.

1
Naoise Golden