Download to read offline
Uploaded byRandy Carey
Improving Joomla’s Backend User Experience
The document outlines strategies to enhance the backend user experience of Joomla, focusing on usability principles and areas for improvement. Key recommendations include customizing the admin template, improving navigation and edit screens, and tailoring user experiences based on user roles. The author promises to provide further discussions and accessibility to usability extensions being developed for Joomla.
More Related Content
Similar to Improving Joomla’s Backend User Experience
Improving Joomla’s Backend User Experience
- 1. Improving Joomla’s Backend UserExperience Randy Carey web architect, Careytech Studios St. Paul, Minnesota Careytech.com
- 2. Over the nextfew months, I will be providing further discussions and access to the usability extensions I’m creating: Careytech.com/icue Randy Carey web architect, Careytech Studios St. Paul, Minnesota Careytech.com
- 3. 1.Case for CMSUsability 2.Principles (for CMS Usability) 3.Areas to Improve (in Joomla’s backend) 4.Looking Forward Overview
- 12.
- 13. Don’t show auser options that are irrelevant
- 15. Don’t show auser options that are irrelevant
- 16. Don’t use technicalor uncommon terms
- 17. Don’t use technicalor uncommon terms
- 18. Use a task-basedinterface
- 19. Recognize difference inusers: infrequent-and-casual –vs– frequent-and-engaged
- 20. Recognize difference inusers: infrequent-and-casual –vs– frequent-and-engaged
- 21. Recognize different rolesof users: authors site admins content managers
- 22. authors content managers site admin duties developer
- 23. One user withtwo roles… …two separate accounts content site management administration
- 24. Assign users tothe front-end …whenever possible
- 25.
- 26. admin template – improve navigation
- 27.
- 28. segment users tailoredand simplified user experience
- 29. !?! JCE profiles tailored and simplified options
- 30. Task-specific extensions intuitive edit screens for users
- 31. We can dobetter Areas We Can Improve
- 32.
- 35.
- 36.
- 37.
- 41.
- 42. configurable “app shelf” AdminPraise 3
- 43.
- 44.
- 49. Mission Control - tailoring menu bar
- 51. Mission Control controlling visibilityper menu items
- 53. MVC Model - View- Controller
- 54.
- 55. components / modules template (overriding the view)
- 56.
- 57. RedShop - out-of-box product edit screen
- 61. K2 - irrelevanttabs
- 64. Step 1: Addparameters to K2 category /administrator/components/com_k2/config.xml Step 2: display new pane of parameters in category view Step 3: overriding the two item edit screens (site and admin) so each checks parameters and displays each tab accordingly
- 65.
- 75. Segment users intoGroups
- 76. • Edit • Edit • Create • Delete • Edit Status • Edit • Create what a user can do
- 77. what assets a user should be able to access
- 79. Authors, Editors, Publishers Managers, Admins Super Admin
- 80.
- 81. content site management administration gary gary-admin
- 82.
- 83. Overriding view filefor Article
- 84. JCE - Profilesand Edit Options
- 92.
- 93.
- 98. testimonials Restaurant menus events specialized inventory listing Task-specific extensions
- 104. • Fast tobuild • Unintuitive steps to access • Not all info on one screen • No help text on fields • No grouping of fields • Exists as a category within edit tool, not as a stand alone app • intuitive to use • one-step app • single screen edit • Custom code to build or modify existing extension
- 106. Improving Joomla’s Backend User Experience
- 107.
- 108.
- 109.
- 110.
- 111.
- 112.
- 113.
- 114.
- 115.
- 116.
- 117. more refined front-endediting
- 119. I will beproviding further discussions and access to usability extensions I’m creating: Careytech.com/icue Randy Carey web architect, Careytech Studios St. Paul, Minnesota Careytech.com
- 120. Improving Joomla’s Backend UserExperience Randy Carey web architect, Careytech Studios St. Paul, Minnesota Careytech.com
Editor's Notes
- #5 For an elderly person who wants a portable phone to use in case of emergencies, this interface is too complex: unneeded buttons lead to confusion and no intuitive way for a computer-illiterate to find the list of people she can call during an emergency.
- #6 We often limit our thoughts of CMS users to just two types: web developers and site visitors.
- #7 We can’t forget our client and the client’s staff who must maintain content. Their needs are quite different from either of the other user types.
- #8 Out-of-the-box Joomla (and other CMSs) are full-featured for the developer. But this is too much and too technical for most content managers.
- #10 Developers think of websites in terms of many technical things: components, plugins, layout positions, etc.
- #11 But the content managers see a reduced set of these: content, media, and perhaps registered users.
- #12 Our clients see a web site as a series of web pages and content – not in the technical detail we developers see. The client will have a better user experience with the CMS if we tailor it to the client’s perspective and workflow.
- #13 Let’s touch on some CMS usability principles to guide us as we seek to improve the CMS user experience for our clients.
- #14 Principle: don’t show options that are irrelevant to a user or even dangerous in their hands.
- #15 This is a much simpler interface – hence very usable. Something to strive for.
- #16 This edit screen includes many fields not used by the client. There is no indication which fields are required, which can be used, and which should be avoided.
- #17 We as developers may know these terms well, but should we expect our clients to learn them?
- #18 Even the term “K2” is alien to our clients. We can do better. Relabel the link to something that has meaning to the person using the CMS.
- #19 Label menu or starting-point items with terms that reflect the task of the user.
- #20 We must recognize that… the client’s users of the CMS will be unequally skilled and motivated.
- #21 Develop different levels of controls for the different levels of users. Example: lite, standard, and advanced.
- #22 The client’s users will differ also by their roles with the CMS. Managing content and managing registered users are two different needs for accessing the CMS.
- #23 Segment the users not only by their level of capability, but also by their roles in using the CMS. We’ll want to give each of these groups a user experience tailored to it.
- #24 Because each role tends to access different parts of the CMS and on a different schedule, consider giving a person with multiple roles a different login account (and user experience) for each.
- #25 Remember. Clients and their users perceive of a website as web pages. It is more intuitive for them to edit from the front than from the backend.
- #26 Now… Let’s look at some areas where we can improve the backend user experience for our clients.
- #27 1. Use a customizable administrator template (and customize it)
- #28 2. Look for ways to improve the out-of-the-box edit screens of the apps we give to our clients
- #29 3. Segment the users and give each a tailored user experience
- #30 4. Leverage JCE profiles to provide the appropriate editing experience
- #31 5. An extension that is tailored to a task is more usable than a generic solution (such as CCK)
- #32 We _can_ do better than what we get out-of-the-box.
- #35 This is the configuration screen for the default admin template. Not a lot of options.
- #36 In contrast, this is the configuration screen for Rockettheme’s admin template Mission Control.
- #37 Another worthy and highly configurable admin template is AdminPraise 3.
- #38 Admin Praise even offers editing from tablets, iPhones, and Droids as well as from the desktop.
- #39 I’m currently using Mission Control, so my examples will be using this admin template.
- #40 The admin template contains modules in the way we are used to using modules with the site templates.
- #41 By accessing the admin modules, we can edit a module’s setting, declare its position, and display to a segment of backend users if we create access levels that segment those accessing the backend.
- #42 The point of this discussion is that we leverage the admin template to create a user experience for the content mangers that differs from the interface we developers use.
- #43 Admin Praise 3 uses this screen to control the labels and links to be displayed as items on the admin navigation bar.
- #44 Admin Praise 3 also provides a configurable shelf for the apps that are available.
- #45 Mission Control also provides a way to add task-based navigation items to the menu bar and to a dashboard listing.
- #46 The configuration panel for setting up the dashboard: label, link, and icon
- #47 I’m becoming resistant to using both the menu bar and the dashboard – this is needless redundancy.
- #48 An easy way is to leave the menu bar for just the essentials and the dashboard for the available apps.
- #49 The advantage to this approach is that when one clicks into an app, the other app options are not distracting. But clicking the “dashboard” tab (which could be renamed “apps”) will bring oine back to the set of available apps.
- #50 But an advantage to listing the apps in the menu bar is that the user can browse drop-down links to frequently-used forms within each app.
- #51 Mission Control allows one to configure the menu bar by overriding the view of the menu.
- #52 Here is the relatively simple code for adding the custom menu items shown above.
- #53 Here is code for controlling who gets to see any particular menu item or set of menu items.
- #54 For the admin template Mission Control, if code is too much for you, then focus on adding items to the dashboard.
- #55 As we transition to the next point, I want to provide an overview of the MVC pattern and how Joomla’s use of it gives us a big advantage in tailoring the user’s experience.
- #56 A big advantage of Joomla over some other CMSs is that it forces extensions to separate the code for Model (data and database), View (display of the data), and Controller (interaction rules with the user).
- #57 Joomla allows us to “override” the view portion of an extension. Keep in mind that for the backend edit screens we must override the view files within the admin template (not the site’s template). Understanding how to do this is huge for improving backend usability.
- #58 Our goal is to improve the out-of the-box edit screens to one that is tailored for the business rules of our client.
- #59 A powerful component understandably possesses many options. But most clients use just a subset of the fields, and each client is different.
- #60 In this case I am tailoring the edit screen for RedShop’s product detail. I don’t hack the component’s files. Rather I override them, leveraging Joomla’s MVC.
- #61 By using a combination of CSS and PHP editing, the front tab of the screen now shows only the usable fields and tabs, distinguishes between required/important/optional, includes help text next where needed, and brings the product’s image to this front tab.
- #62 See the difference between tailored and out-of-the-box.
- #63 K2 includes several tabs that are seldom needed.
- #64 I overrode the K2 edit item screen to display only the tabs that are relevant on a per-category basis.
- #65 I added this pane of tab options to the category edit screen.
- #66 I needed to touch the xml file and override three view files. These files can be copied as-is from project to project.
- #67 I have felt that the edit screen for an article displays fields that can be distracting to most authors. Authors are typically concerned just with the areas outlined here in red.
- #68 Mission Control out-of-its-box helps by tucking many of the details behind tabs.
- #69 I simplified the edit screen further (overriding the view for editing an article).
- #70 I moved the “alias” field to a tab, and I hide the fields that are not used by authors (as applicable per client’).
- #71 I changed the names of the tabs to something more meaning (e.g., “metadata” to SEO”).
- #72 The newly organized “SEO Settings” provides a checklist and set of fields for leveraging SEO (from the author’s perspective). Compare the new version (right) with the default (left).
- #73 I replaced “Advanced” with “Article Display.” The set of options are reduced (per user group) to only those fields that are applicable.
- #74 Here are all the items that display out-of-the-box. Do we really want to show all the options? Do we really want to allow an author to bypass the website’s standards by changing these options from the default settings?
- #75 I showed three examples of improving the edit screens: tailoring an app’s edit screen to the client’s needs, adding parameters to an app to remove unneeded options from its edit screen, and reorganizing the frequently used article edit screen.
- #76 But what if some users need to use some of the options that we are suppressing from the others? Next…
- #77 We segment users by the abilities (e.g., lite, standard, advanced) and by the types of roles they have (content management, user management, etc.).
- #78 We segment by how much we let a user do.
- #79 Users often can be segmented by what applications and features they should be able to access.
- #80 The “holy grail” of this exercise is to give each user a different user experience – each tailored accordingly.
- #81 Most of us are familiar with the relatively simple 1.5 hierarchy of groups.
- #82 Joomla 1.7 has added a lot more options and complexity to how we can segment users. We should accept the challenge of learning how to leverage this new system.
- #83 Consider giving the same user two different accounts when he/she has two distinctly differing roles. Each is assigned to a differing set of groups and access level.
- #84 Returning to my editarticle screen, each role sees the same article with a differing set of fields.
- #85 Code used in overriding the article detail view: in this case I configure the set of visible fields with CSS rules and apply CSS classes based upon user details.
- #86 Fourth area to leverage: leveraging JCE with its profiles and various options
- #87 Get JSCE. Walk through and carefully see all the options it provides.
- #88 Buy the premium extensions offered through the JCE site. They are worth it.
- #89 Here is the starting point I set up for JCE profiles. I segment by author-vs-manager and by lite-vs-standard-advanced.
- #90 The settings tab for each profile allows you to select which profile to be used based upon user group, or individual user, or even by component.
- #91 For each profile you we can drag and drop which edit options (JCE plugins) will be displayed, and how they will be arranged.
- #92 Segmentation by lite-standard-advanced allows each profile access to a varying set of edit options.
- #93 One capability that is easily overlooked is setting the root directory of images, videos, and documents per profile. Here is the simple, initial view of the images directory assigned to authors – no clutter from the site-level images.
- #94 Here is an example of how authors (green) can be assigned to a more restricted set of media and documents.
- #95 So the author profiles see only the media and documents relevant to them. Managers see and can access more. This technique can inject security as well as simplicity regarding the sites assets.
- #96 One of my clients wanted to be able to copy a matrix of cells from Excel and paste them into an article. Of course this meant all the data would need to be transferred into an html table.
- #97 I could not find a JCE plugin to do this, so I created one based upon the plugin that inserts text from Word. If you have a special need – JCE allows you to add custom plugins.
- #98 I have never liked the white-box dropdowns. Worse yet is the “format” option. It hides the all-important Heading tags. Infrequent users often forget to use these – or how to access them.
- #99 I created a plugin that is a sibling to the “bold” button. When text is selected, it turns bright and allows a dropdown of options labeled with terms that are more vernacular to the all authors. I can easily tailor the terms per client.
- #100 Finally, we can improve the user experience by using task-specific extensions rather than generic solutions. Here are examples of specific website items, each benefiting from having a dedicated extension behind it.
- #101 The easiest solution is to give the user a blank screen. But users often are inconsistent with how they format the information. Further, the pieces of information are just text on a page – we want pieces of data we can reuse.
- #102 For a restaurant menu, we want entrée items that we can automatically format and reuse elsewhere.
- #103 This is the generic solution created by a CCK (K2 in Joomla). It is easy to set up, but the edit screen is structured generically and for an article.
- #104 The user has to remember (without on-screen instructions) to select the category first, then select “extra fields” and “image” amoung the set of irrelevant tabs. Doable, but not the most intuitive. We can do better…
- #105 Here is a custom extension tailored to a pet store retailer who wants to post the new arrivals of puppies. On a single screen he can upload photos (auto-sized upon upload) and add a slate of relevant information.
- #106 The generic solution is fast to build, but it also require the user to learn details about the data entry screen that are needed only because we delivered a generic solution. The task-based solution is intuitive. The extra work falls to use to either find one, customize one, or out-right build it. It is a trade-off. You decide. But you know which your client wants.
- #107 A big advantage of a task-based extension is that you can supply a simple link taking one straight to that application. Typically, it is not straight-forward to apply a link to a generic solution (e.g., a category within K2).
- #108 Let’s review these five areas for improving the user experience of our clients…
- #109 …to improve the navigation of tasks for which a client uses the CMS
- #110 …to tailor the editscreens from the full and generic features that come out-of-the-box to the way a particular client will use it
- #111 … which provides the foundation for tailoring user experiences
- #112 …so we can serve up the appropriate set of tools as well as access to just the appropriate set of assets
- #113 …so we can provide direct links to workflows that are efficient and highly-intuitive
- #114 If we keep challenging ourselves with “we can do better” …we still can improve the client’s user experience. Here are some areas I plan to explore…
- #115 For articles and K2, I’d like to be able to lead the user to the component - but only to a branch of categories. Why make the user navigate through other types of categories when his/her task-at-hand focuses on just a subset of categories?
- #116 We know this is coming. This is particularly needed in ordering articles/items within lists.Do we wait for it? Do we find a way to graft it in?
- #117 I assume most developers don’t customize the help system. But the new help system is customizable. How can we improve what is given to us? Can we provide help that is more context sensitive? If we use a different admin template and tailored edit screens, are we compelled to write our own set of help screens?
- #118 Code generation will go a long way to enabling us to create and offer our clients a richer set of task-based extensions. How close can we get with an automated process, and how much code do we have to adjust by hand?
- #119 I want to graft in more options for front-end editing: modules, header lines, footer lines,…
- #120 …and how about links to edit content item-by-item!