Search the Community

I find that editors with low web skills have difficulties working with the ProcessWire Admin interface. I am here talking about users who rarely write text and with low web skills. Also, my customers are Danish but see the ProcessWire Admin interface in English -- they are not all comfortable working in an English user interface (I can fix this in part by adding fields in Danish). The main reason for the usability challenges is that users are forced to work in the tree structure in the ProcessWire Admin interface as it is today. The Page tree can be hard to comprehend when getting back to Admin after 2 months or more. Below I offer observations on what I have seen customers do in the user interface, and based on that I suggest how usability may be improved. Note, this post is written in a positive spirit with the intention to improve ProcessWire. Observed user behavior 1. New pages. Users incorrectly place new pages at root level when they correctly should have been placed in - say - the "News" section. Observed behavior: Users log in to Admin, immediately see the "New" link and create a new page. The link is incorrectly being placed at root level. Correct behavior: Users log in to Admin, click "News", click "new" (next to "News"). Training users in doing the right thing is also hard. It is hard to explain users to: "1) log in to Admin, 2) click "News", 3) click "new" (next to the News link)." As a possible workaround, I can lock down the content types that can be created from the root level, but in my view that should not be stricly necessary. 2. Overview. Users find the admin interface hard to understand when getting back to it after 2 months. Some of the questions users (and me too) ask themselves are: "What can I do here?", "Under which section (segment1 nodes) should I add my new Product or Event?" Possible workaround: The web designer can spend time writing a guide, but I guess most would prefer that the admin interface answered the question "What can I do here?" -- possibly with a written instruction. 3. Clutter in the tree structure. As a web designer I have to store categories andother system nodes in a tree structure that is visible to end users. I create a "Value lists" node and put pages that I use in different Select boxes in other pages -- editorial users really don't need to see these "Value lists" in the main view. Better: Move system information to a secondary area as in many other CMSes (see suggestion 3 below). 4. User error risks. Users can mess up the entire site structure if they start moving around with root-level pages. For instance, Navigation will suffer when using the Simple Navigation module. Also entire sections can be deleted / moved by editors. Suggested Solutions 1. Buttons. As a web designer it would be nice to have the option to create "buttons" on the admin start page (/processwire/page/). Example Buttons: "New Article" - clicking the button will create a new page of type "Article" and place it under a specified parent page ("/articles"). "New Event" "New Product" "New Solution" "New Employee" 2. Apps. Pretend that the website contain many "apps". As a web designer I can create such "apps" in Admin. Apps can be as simple as a shortcut in a menu (right menu as seen here). 3. "Site system trees". The Page tree contain two very different types of data. The first is content, the next is "system nodes". I would like to move the "system nodes" to one or more "site system trees". As a web designer I can create a "system tree" for the site that contain non-content nodes. A link to the "site system tree" can be placed in the admin navigation (Pages, Setup, Modules, Access). Access to "system trees" can be restricted. My "system tree(s)" would contain information such as: Blocks Snippets Menus Site settings Search Admin 404 Page Not Found Trash PS: How do I create "Admin apps" in the Admin left menu (as in this example)?