Improving joomla's backend user experience
•Descargar como PPTX, PDF•
0 recomendaciones•1,149 vistas
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Similar a Improving joomla's backend user experience
Similar a Improving joomla's backend user experience (20)
Más de Luke Summerfield
Más de Luke Summerfield (9)
Último
Último (20)
Improving joomla's backend user experience
- 1. Improving Joomla’s Backend User Experience Randy Carey web architect, Careytech Studios St. Paul, Minnesota Careytech.com
- 2. Over the next few 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 CMS Usability 2.Principles (for CMS Usability) 3.Areas to Improve (in Joomla’s backend) 4.Looking Forward Overview
- 12. Principles
- 13. Don’t show a user options that are irrelevant
- 15. Don’t show a user options that are irrelevant
- 16. Don’t use technical or uncommon terms
- 17. Don’t use technical or uncommon terms
- 18. Use a task-based interface
- 19. Recognize difference in users: infrequent-and-casual –vs– frequent-and-engaged
- 20. Recognize difference in users: infrequent-and-casual –vs– frequent-and-engaged
- 21. Recognize different roles of users: authors site admins content managers
- 22. authors content managers site admin duties developer
- 23. One user with two roles… …two separate accounts content site management administration
- 24. Assign users to the front-end …whenever possible
- 25. Areas to improve
- 26. admin template – improve navigation
- 28. segment users tailored and simplified user experience
- 29. !?! JCE profiles tailored and simplified options
- 30. Task-specific extensions intuitive edit screens for users
- 31. We can do better Areas We Can Improve
- 35. Admin Praise 3
- 36. Admin Praise 3
- 41. Admin Praise 3
- 42. configurable “app shelf” Admin Praise 3
- 44. Mission Control
- 49. Mission Control - tailoring menu bar
- 51. Mission Control controlling visibility per menu items
- 53. MVC Model - View - Controller
- 55. components / modules template (overriding the view)
- 57. RedShop - out-of-box product edit screen
- 61. K2 - irrelevant tabs
- 64. Step 1: Add parameters 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. Article Edit
- 75. Segment users into Groups
- 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. ACL – 1.7
- 81. content site management administration gary gary-admin
- 82. Author Admin
- 83. Overriding view file for Article
- 84. JCE - Profiles and Edit Options
- 98. testimonials Restaurant menus events specialized inventory listing Task-specific extensions
- 104. • Fast to build • 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
- 108. improve edit screens
- 109. Segment users
- 110. JCE Edit Options
- 112. Looking forward…
- 113. category branches
- 114. drag-and-drop
- 115. Help
- 116. Generate extensions
- 117. more refined front-end editing
- 119. 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
- 120. Improving Joomla’s Backend User Experience Randy Carey web architect, Careytech Studios St. Paul, Minnesota Careytech.com
Notas del editor
- 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.Consider this: We often give our clients a CMS cluttered with unneeded options and terms that they don’t find intuitive.
- We often limit our thoughts of CMS users to just two types: web developers and site visitors.
- We can’t forget our client and the client’s staff who must maintain content. Their needs are quite different from the developer who also accesses the CMS from the backend.
- 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.
- We should provide our clients with an interface tailored to how they will be using the CMS.
- Developers think of websites in terms of many technical things: components, plugins, layout positions, etc.
- But the content managers see a reduced set of these: content, media, and perhaps registered users.
- 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.
- Let’s touch on some CMS usability principles to guide us as we seek to improve the Joomla user experience for our clients.
- Principle: don’t show options that are irrelevant to a user or even dangerous in their hands.
- This is a much simpler interface – hence very usable. Something to strive for.
- 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.
- We as developers may know these terms well, but should we expect our clients to learn them?
- 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.
- Label menu or starting-point items with terms that reflect the task of the user.
- We must recognize that… the client’s users of the CMS will be unequally skilled and motivated.
- Develop different levels of controls for the different levels of users. Example: lite, standard, and advanced.
- 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.
- 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.
- 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.
- Remember. Clients and their users perceive a website as web pages. It is more intuitive for them to edit from the front than from the backend.
- Now… Let’s look at some areas where we can improve the backend user experience for our clients.
- 1. Use a customizable administrator template (and customize it)
- 2. Look for ways to improve the out-of-the-box edit screens of the apps we give to our clients
- 3. Segment the users and give each a tailored user experience
- 4. Leverage JCE profiles to provide the appropriate editing experience
- 5. An extension that is tailored to a task is more usable than a generic solution (such as CCK)
- We _can_ do better than what we get out-of-the-box.
- Configuration screen for the default admin template (Bluestork).
- In contrast, this is the configuration screen for Rockettheme’s admin template Mission Control.
- Another worthy and highly configurable admin template is AdminPraise 3.
- Admin Praise even offers editing from tablets, iPhones, and Droids as well as from the desktop.
- I’m currently using Mission Control, so my examples will be using this admin template.
- The admin template contains modules in the way we are used to using modules with the site templates.
- By accessing the admin modules, we can edit a module’s settings, declare its position, and display to a segment of backend users (if we create access levels that segment those who can access the backend).
- 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. Navigation can be made simple and task-based.
- Admin Praise 3 uses this screen to control the labels and links to be displayed as items on the admin navigation bar.
- Admin Praise 3 also provides a configurable shelf for the apps that are available.
- Mission Control also provides a way to add task-based navigation items to the menu bar and to a dashboard listing.
- The configuration panel for setting up the dashboard: label, link, and icon
- I’m becoming resistant to using both the menu bar and the dashboard – this is needless redundancy.
- An easy way is to leave the menu bar for just the essentials and the dashboard for the available apps.
- 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 one back to the set of available apps.
- 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.
- Mission Control allows one to configure the menu bar by overriding the view of the menu.
- Here is the relatively simple code for adding the custom menu items shown above.
- Here is code for controlling who gets to see any particular menu item or set of menu items.
- For the admin template Mission Control, if PHP code is too much for you, then focus on adding items to the dashboard.
- 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.
- 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).
- 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.
- Our goal is to improve the out-of the-box edit screens to one that is tailored for the business rules of our client.
- A powerful component understandably possesses many options. But most clients use just a subset of the fields, and each client is different.
- In this case I am tailoring the edit screen for RedShop’sproduct_detail. I don’t hack the component’s files. Rather I override them, leveraging Joomla’s MVC.
- 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.
- See the difference between tailored and out-of-the-box.
- K2 includes several tabs that are seldom needed.
- I overrode the K2 edit item screen to display only the tabs that are relevant on a per-category basis.
- I added this pane of tab options to the category edit screen.
- I needed to touch the xml file and override three views. These four files can be copied as-is from project to project.
- I have felt that the article’sedit screen displays fields that can be distracting to most authors. Authors are typically concerned just with the areas outlined here in red.
- Mission Control out-of-its-box helps by tucking many of the details behind tabs.
- I simplified the edit screen further (by overriding the view for editing an article).
- I moved the “alias” field to a tab, and I hide the fields that are not used by authors.(The set of fields that are not used by an author can vary per client.)
- I changed the names of the tabs to something more meaning (e.g., “metadata” to SEO”).
- 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).
- I replaced “Advanced” with “Article Display.” The set of options are reduced (per user group) to only those fields that are applicable.
- Here are all the items that display out-of-the-box. Do we really want to make the author consider each of these options? Do we really want to allow an author to bypass the website’s standards by changing these options from the default settings?
- 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 edit screen for articles.
- But what if some users need to use some of the options that we are suppressing from the others? Next…
- We segment users by the abilities (e.g., lite, standard, advanced) and by the types of roles they have (content management, user management, etc.).
- We segment by how much we let a user do.
- Users often can be segmented by what applications and features they should be able to access.
- The “holy grail” of this exercise is to give each user a different user experience – each tailored accordingly.
- Most of us are familiar with the relatively simple 1.5 hierarchy of groups.
- 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.
- 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.
- Returning to my editarticle screen, each role sees the same article with a differing set of fields.
- 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.
- Fourth area: leverage JCE with its profiles and various options
- Get JCE. Walk through and carefully see all the options it provides.
- Buy the premium extensions offered through the JCE site. They are worth it.
- Here is the starting point I set up for JCE profiles. I segment by author-vs-manager and by lite-vs-standard-advanced.
- 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.
- For eachprofile, one can drag and drop edit buttons (JCE plugins) to declare which will be displayed, and how they will be arranged.
- Segmentation by lite-standard-advanced allows each profile to vary its set of edit options.
- 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.
- Here is an example of how authors (green) can be assigned to a more restricted set of media and documents. Meanwhile the manager type profiles (red) have access to more directories.
- 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 site’s assets.
- 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.
- 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.
- I have never liked the white-box dropdowns. Perhaps the least usable of them is the “format” option. It hides the all-important Heading tags. Infrequent users often forget to use these – or where to find them.
- I created a “heading” pluginthat I place next 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 site’s authors. For any given client, I can easily tailor the labels used for the dropdown options.
- 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.
- 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 eleswhere on the site.
- For a restaurant menu, we want entrée items that we can automatically format and reuse elsewhere.
- 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 this edit application is used for multiple types of data. It is obvious that we provide this type of solution only because it is easier for us to build – and not for the usability of our clients.
- The user has to remember (without on-screen instructions) to select the category first, then select “extra fields” and “image” among the other tabs which are irrelevant. Doable, but not the most intuitive. We can do better…
- 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.
- The generic solution is fast to build, but it also requires the user to learn details about the data entry screen - details that are needed only because we delivered a quick-to-build generic solution. The task-based solution is more intuitive for our clients. The cost, of course, is that we have more work that could include building a custom component. It is a trade-off. You decide. But you know which your client wants.
- 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 take one directly to a generic solution (e.g., editing just a particular category within K2).
- Let’s review these five areas for improving the user experience of our clients…
- …to improve the navigation of tasks for which a client uses the CMS
- …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
- … which provides the foundation for tailoring user experiences
- …so we can serve up the appropriate set of tools as well as access to just the appropriate set of assets
- …so we can provide direct links and workflows that are efficient and highly-intuitive
- 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…
- 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?
- We know this is coming. This is needed particularly in ordering articles/items within lists.Do we wait for it? Do we find a way to graft it in?
- 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?
- 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?
- I want to graft in more options for front-end editing: modules, header lines, footer content,…
- …and how about links to edit any given content item within a list!