Downloaded 16 times
Uploaded byRandy Carey
Improving the Client's User Experience - JAB 2012
The document outlines a strategy for enhancing a client's user experience by improving various areas of their content management system (CMS). It focuses on usability enhancements in front-end editing, backend roles, client edit screens, user segmentation, and task-based workflows. Key recommendations include recognizing user differences and refining the dashboard and access control features.
More Related Content
Similar to Improving the Client's User Experience - JAB 2012
Improving the Client's User Experience - JAB 2012
- 1. Improving the Client’sUser Experience Randy Carey iCueProject.com
- 6. Strategy: their own CMS user experience
- 7. Strategy: embrace complexity… so we can deliver usability HTML MVC PHP
- 10.
- 11. front-end editing Areas to improve
- 12. ‘client’ backend Areas to improve
- 13. role-based ACL Areas to improve
- 14. client’s edit screens Areas to improve
- 15. segment users Areas to improve
- 16. task-based workflows Areas to improve
- 17. We can dobetter Areas to improve
- 18. front-end editing Areas to improve
- 30. ‘client’ backend Areas to improve
- 32. admin template ‘client’ template
- 33. • Administrator admin • Super template ACL ‘client’ template • Staff
- 34. • Bluestork admin template Template assignment ‘client’ template • Mission Control
- 36.
- 37.
- 38. Mission Control: rokQuickLinks
- 39. Mission Control: rokQuickLinks
- 40. role-based ACL Areas to improve
- 44. grant access tobackend
- 45. Single role forclient
- 46. Multiple roles forclient
- 47. Multiple roles forclient
- 49. explained in RocketThemeMagazine
- 51. client’s edit screens Areas to improve
- 52. RedShop - out-of-box product edit screen
- 59. We can dobetter
- 65. segment users Areas to improve
- 69. Recognize difference inusers: infrequent-and-casual –vs– frequent-and-engaged
- 70. Recognize difference inusers: infrequent-and-casual –vs– frequent-and-engaged
- 75.
- 76.
- 81. task-based workflows Areas to improve
- 82. testimonials Restaurant menus events specialized inventory listing Task-specific extensions
- 84.
- 85.
- 86.
- 88.
- 89.
- 90. iCueProject.com plugin
- 91. index.php?option=com_k2&view=items&catid=2 index.php?option=com_k2&view=items&catid=3 iCueProject.com plugin
- 95. implementing the client’s userexperience
- 96.
- 101. Improving the Client’sUser Experience Randy Carey iCueProject.com
Editor's Notes
- #2 iCue Projectan intelligent approach to improving the CMS user experienceTo receive information on new extensions and plugins produced by the iCue Project, please subscribe through the website: iCueProject.com
- #3 We who build websites tend to see only two types of users using the CMS: those developing the site and those visiting the site. Hence, we divide our view and discussion of the CMS as “backend” and “front-end.”
- #4 But we are forgetting the client – the one commissioning the project for business reasons and the one paying for its development and maintenance. The client is a different type of user. The client is concerned about managing content and the business objectives. Further, the client is almost always less interested and less capable in the technical aspects of the website and its CMS.
- #5 The client sees a website as a series of interconnected web pages, each page containing various pieces of content in some visual format. They do not naturally see all the technical details behind a website as we (developers) see.
- #6 Yet, the standard has been to give the user the same admin interface that we use to develop the site. Such an interface contains a navigation that not intuitive to a non-technical user, terms that are cryptic to the client, multiple steps to reach particular content or web app, clutter of options that the client does not need, and options that are accessible but potentially destructive in the hands of non-technical staff.Why do we give the client the same “backend” experience that developers need and use?
- #7 Our main strategy: Since the client is a different type of user with different motivations, needs, and capabilities, we should be giving the client a user experience that is different from that used by the web developers. Further, we should invest the effort to tailor this user experience to the client as we invest in tailoring an appropriate user experience for site visitors (the front-end).
- #8 Our second strategy: We developers ought to take on the added responsibility of developing a usable interface for our client. Site integrators should be capable of more than just installing and configuring extensions – they should have some understanding of the system and the capability of basic PHP/HTML editing. Such understanding and set of capabilities will go a long way toward tailoring a usable CMS for our clients.
- #9 Within any system there isa natural tension between feature-rich and ease-of-use. Pull in one direction and the other naturally suffers. But this occurs because we unify the all the CMS capabilities with the interface we give the client. These do not have to be linked…In the chart here, assume Joomla is the green bar. Traditionally we have placed it as a good balance of feature-vs-usability when comparing Joomla! against other CMSs and blogging platforms.
- #10 But if we split the bar – giving the client their own version for using the CMS and taking on more technical responsibilities as site integrators – then we can deliver to the client a very usable CMS without the integrator forfeiting any CMS functionality. I argue that such a split enables us to deliver ease-of-use that cannot be equaled by any CMS that does not provide such a split. And given the OO and MVC architecture of Joomla!, this CMS holds an advantaged position to leverage such a split.
- #11 This presentation fill focus on six areas where we can improve the client’s user experience with Joomla!
- #18 My mantra is “We can do better.” Think of what can be. Think of what should be for the client’s use. Then figure out a way to build what we should be delivering.
- #19 The first area of improvement is to leverage front-end editing wherever it is intuitive to do so.
- #20 Remember, the client sees the website as a series of interconnected pages, each containing content. This is the client’s mental model. We should tie-in to that mental model.
- #21 It is very intuitive for a client to find content through navigating the site and clicking an edit button to edit inline.
- #22 Currently, the main content of a page allows front-end editing (articles, K2), but few modules do. It is advantageous to use content-based modules that allow front-end editing. And if we are up to the challenge, it is possible to modify the code of existing modules to graft in front-end editing.The iCue Project is planning development of font-end editing for modules that are commonly needed.
- #23 In an ideal world, components (like this restaurant menu) should offer the user the ability to find and edit small pieces of information, such as any one menu item.
- #24 The JUX team has suggested adding extensive front-end editing in version 3.x.
- #25 I have not found any real discussion about this issue, but I think it needs to be thought out… If we can edit anything from the front-end, should we provide front-end editing to everything? I don’t think everything benefits from front-end editing. Here is my initial perspective as to how I would split front-end editing from backend…
- #26 Content (text, images, links) that appears in some given place on some given page fits the user’s mental model, and so it is advantageous to provide front-end editing. But be careful. If the same content exists in multiple places or is interconnected with other parts of the site, does the user understand the consequence an edit would have elsewhere within the site?
- #27 If the content manager needs to review or manage a list of items (categorizing, ordering, batch processing items, etc), these tasks are best done through a list view – probably in the backend.
- #28 Web apps involve various abstractions around the content. For example, an ecommerce app involves promo codes, shipping criteria and rates, related products, orders, users, gateways, and more. A web app runs deeper than what is displayed on the front-end, and managing it requires a deeper understanding of parts that just don’t map to the mental model of the front-end.
- #29 Structural and complex site details also require more than a simple front-end mental model. For instance, Joomla’s menu structure is more than just a hierarchy of titles - each menu item can be tied to access levels and dictate module positions.Site features that are structural and contain ramifications throughout the site are best managed by from the “inside” by those who understand how things are interconnected.
- #30 Finally, administrative details are rather detached from the font-end mental model. Examples: user management, permissions, extension installations, and even the path declaration of the temp directory.
- #31 We improve a CMS greatly by giving the client their own view of the backend. This includes the set of available options, the terminology used, and navigation.
- #32 Two very different backend views. The top is an example of what is needed for developing a site. The lower is an example of a template tailored for client use.
- #33 This begs the question… These two being so different in looks and function, are we justified is recognizing the lower version as a “client” template in contrast to what we’ve come to term the “admin template”?Obviously, in Joomla! there is no second type of backend template. But we can configure a backend template to be “virtually” different from the traditional admin template. Perhaps there is value is using the term “client template” to represent a backend version tailored just for the client and in contrast to the version used by site developers.
- #34 How do we assign each version to its respective user type?The first way is to leverage ACL. Users are assigned to groups, and we can establish business rules that determine if a user is an admin/developer or a staff/content manager based upon which groups we assign to any given user. Then, in the code, we apply the logic as to what menu items, dashboard items, and modules will be shown to the user. (Through this approach, all users are assigned to the same backend template.)
- #35 A simpler technique is to use template assignment. Pick one of the backend templates to be the client version and configure it accordingly. Make that template the default so that any new user automatically is assigned the “client template.”Likewise, pick a different backend template to be the “admin” or “developer” version. For those who need full and technical backend access to the site, assign them to this “developer” template (overriding the default assignment).
- #36 I wrote an article on how to create a totally different menu bar for the backend. The value is that we can provide a menu tailored for staff (common terms, only the features needed) while the original version remains available for the admin. So we tailor a client menu for the “client template.”Details on implementing this technique can be found in the April 2012 issue of the Joomla! Community Magazine.
- #37 Another approach is to create new admin modules in the dashboard, each module containing icons linked to the components and web applications needed by staff.In this example, I created four sibling modules and used them in place of the “quick icons” that I unpublished.
- #38 The new admin modules are simple CustomHTML modules. I merely pasted in the HTML code that I saw used by the “Quick Icons” module. For each item I changed three details : title, link, and icon to use.
- #39 The admin template Mission Control (by RocketTheme) provides a easy-to-configure dashboard module called rokQuickLinks…
- #40 It provides a configuration screen for setting the title, link, and icon. One can add additional icons to the icon directory and these will be available in the configuration screen.I must mention that I apply a little extra CSS to style my rokQuickLinks so they display as shown in this presentation. That CSS code is listed in my article in RocketTheme Magazine, March 2012.
- #41 We can deliver a very configurable client template if we configure and leverage role-basedACL.
- #42 The goal is for us to present a list of roles that can be assigned to any of the client’s staff. Merely select what roles a user should have and the needed modules will appear for that user. This role-based assignment is intuitive, easy-to-use, and does not require a technical person to manage users.In the examples above, two users are assigned to different sets of roles. What each will see in the client template is noticeably different and appropriately tailored. Each user has access only to what he/she needs.
- #43 The ACL of Joomla! 1.5 (left) was a linear hierarchy imposing incremental levels of rights. Each group represented a “level.” There was not the ability to establish independent and non-overlapping roles.This changed in 1.6 through 2.5 (right). Now one can create a configuration of groups that include parents and siblings and with meaningful titles. Permissions can be assigned independently and without overlap to sibling groups.We achieve role-based ACL by creating sibling groups with each group object being assigned the needed permissions from the component(s) corresponding to its respective role.
- #44 Here is my technique. I create a new group titled “1. backend access.” I prefix the name with a number because the user manager displays the groups alphabetically and this is my way to force this group and its children to the top of the display.Then I go to Global Configuration…
- #45 Under the Global Configuration I go to the group “backend access” and set a single permission – the “Admin Login” is set to “Allowed.”This one setting allows any member of this group or of any of its children groups the permission to login to the backend of the site.
- #46 If the client has a small staff and no need to assign different roles to different users, then one can set all needed permissions on this one group. Just go to each component, category, or item that offers permissions and set them for this one group. However…
- #47 …If the client does want the ability to assign roles differently per user, then you should create a group for each role that can be assigned to a user. For each of these new groups, assign its parent to be the “backend access” group we previously created. Just by creating these groups, they automatically appear as options in the user configuration screen (show in top-left).
- #48 In Joomla, each module must be assigned to a single “Access Level” to determine who can see the module. So we need to create new access levels, and each should have a one-to-one relationship with its corresponding role-based group.As the chart shows above, a user with membership in one of the role-based groups will also have membership in its corresponding role-based access level So membership in this group grants that person the right to view the modules assigned to that access level.BTW, the default access levels (public, special, admin) provide no valuable differentiation within the backend. If one can login to the backend, then he has access for any of these three access levels. To differentiate users in the backend, we need to create our own access levels.
- #49 This is an example of the site developer embracing complexity to deliver usability. By understanding and managing ACL, we deliver to our client this intuitive system for assigning roles to staff.
- #50 I recorded the details as to how this works in a two-part article for RocketTheme Magazine (issues Jan and March of 2012). Please refer to those articles for further discussion and implementation details.
- #51 One final tip… [LEFT side] By default the user screen will display all of the user groups. [RIGHT side] One can hide groups that don’t need to be shown using CSS and “display:none;”. In this example, the parent group “backend access” is an option that does not need to be displayed.
- #52 We improve the client’s user experience by tailoring the edit screens to the business rules and needs of the client.
- #53 A full and powerful system like RedShop has to include all of its options in the edit screens. This is the only way that we as site developers can configure the component. However, if we give the client this same edit screen, its staff will be confused and belabored by all the fields that are not applicable to this site.
- #54 The solution once again is to override the “view” of the edit screen.
- #55 There are multiple ways to tailor the edit screen. Here is how I did it…[top code] In the PHP view file I add a class to each field. In this example I established the classes “f-required,” “f-important,” f-optional,” and f-notUsed.” Each field is assigned to one of these classes.[bottom code] In the CSS file I define the styling rules for each of these classes. The “notUsed” class is set to “display:none” and this effectively removes unused fields from the edit screen.
- #56 As you can see in this example from one of my clients, only a few fields are needed and displayed. The required fields are set off with a black background for emphasis.Also note that I added the image to the first tab – I felt that seeing the item here was helpful for my client.
- #57 Compare my tailored edit screen (top) to the default that comes out-of-the-box (bottom).Note that I didn’t just remove fields – I removed several tabs that this client was not using.
- #58 One of the tabs had a rather complex set of editing features. I need these for setting up the fields for my client, but I know this was too complex for his ability to maintain the simple data he needed to maintain. So…
- #59 I overrode that edit screen and gave the client a much simpler interface (top) – an interface that allowed him to see and easily change just the options that he needed access to.
- #60 For each edit screen that we give our clients, we need to ask if we can do better. Usually we can.Remember… We can offer our clients a better user experience only if we put the extra effort into identifying what more we can do …and then tailoring the improvements into the overriden edit screen.
- #61 I feel the edit screen for articles contains too many options and can be improved. Typically a user just wants to edit content and have access to the editing toolbar (shown in red). All the areas shown in yellow clutter the screen with options that are seldom used by the client. I want to do better.
- #62 The admin template Mission Control has the right idea. It hides all these configuration fields under tabs. The initial screen is much cleaner.Still… I know I can do better yet.
- #63 By overriding the edit screen for articles, I removed a few fields that (in this case) authors do not need. All I show is the minimal set: title, category, and status.
- #64 I moved “alias” to the SEO tab because I saw it as a field to set when tuning a site’s SEO. Typically, the fields for access level, language, featured, and id are not needed by authors – so why show them to authors!?!
- #65 Articles contain this long list of options (right). Do we really want to put all these in front of an author to make her think through each? Do we even want to allow an author to change any of these? Typically not, so my default configuration (left) is to hide most or all of these fields.Yes, in some cases certain of these fields need to be accessible. There are various techniques (PHP code or CSS rules) to conditionally show these fields based upon a user’s credentials. The key is that we segment users using ACL.
- #66 We provide a better user experience for our clients if we segment users. Three suggested areas by which to segmenting users: roles, rights within each role, and capabilities .
- #67 We already talked about segmenting users by roles.
- #68 Within each role we might need to establish more than one level of rights. In this example, the yellow permissions comprise the base rights, the blue denotes a second level, and the red completes that highest level of rights for that component (and its corresponding role).
- #69 We establish levels of rights as we did with roles – a group for each. So far, my experience leads me to establish levels of rights within each role that needs multiple levels. (see above)
- #70 A third way to segment users is by capability (or in some cases by motivation).Some users will be casual and nontechnical, others will be power users. The former will prefer simple editing options while the later expects a large set of tools.
- #71 Here I illustrate three types of groups based upon capabilities and familiarity with the CMS system. The middle group represents the default or standard. The thin-bordered icon (left) represents a group needing the simplest and bare minimum of editing options. In contrast, the boldest icon (right) represents the group of power users.
- #72 The JCE editor allows us to configure the edit tool bar.We give the minimal amount of options to the “lite” user group.We give the “standard “ group the default set of editing icons.The “advanced” group receives all the tools we feel they can manage and use safely.These screenshots are just examples. For each project you will want to assess which set of editing icons are the right ones to include for each profile.
- #73 We set up these profiles in the JCE.
- #74 The simplest way for the client to assign someone to a profile is for us to create an ACL group for each level and assign each JCE profile with its corresponding user groups.
- #75 The area in yellow contains these new groups. These denote a different type of segmentation, so I isolate this set of groups from the role-base groups. In this example, the user has the roles of events and newsletter and will receive the power user’s set of editing tools.
- #76 JCE allows us to assign different root directories for images, videos, and documents. This can be another useful reason for segmenting users. In particular, we might want most users and authors to access a directory reserved for them (upper) while admins and publishers might need access to more directories (bottom example).
- #77 We accomplish this in a way similar to what is illustrated above. The staff type of groups have a root directory that is farther down the root. Whereas the admin type of users are assigned root directories that include more directories. This allows admins and publishers to access directoriesthat are not accessible to regular staff.
- #78 The example above shows a new admin profile within JCE. It is this profile that provides expanded access to asset directories (images, video, documents).
- #79 The JCE editor includes a subscription option for special and improved editing buttons. I recommend subscribing and using these. Our clients are worth it. Provide them these button upgrades.
- #80 Sometimes significant usability can be added by creating a custom JCE button. One of my 1.5 clients wanted a way for its volunteers to copy a block of cells from a spreadsheet and paste them into an article with the cells being auto-formatted into an HTML table. I could not find a button to do this, so I built my own custom button.
- #81 Likewise, I built a “Header” button. The top screen includes the default dropdowns. The user has to remember to use a header, remember where it is hidden in the these options, and then know how to apply it.The bottom screen shows my button. It is placed next the bold button because a user’s inclination is to make a heading bold, but hopefully the ‘H’ button along side of the ‘B’ button will remind the user. Selecting the button prompts the user to choose the right header level. The text is more meaningful to the non-technical user than is the cryptic ‘h1’, ‘h12’, etc.
- #82 We improve our Joomla configuration by streamlining the workflow for each of the commonly performed tasks.
- #83 By “task” I am referring to management of content and web apps that are understood in common or business terms. Examples shown here are testimonials, restaurant menus, events, and lists of specialized inventory.
- #84 Let me demonstrate the streamlined workflow for a component I built for a client. The client runs a pet store and wanted to be able to quickly list his inventory of puppies and kittens. Show here is the page of puppies that he had on stock during on a particular day.
- #85 Once logged in to the site, the store staff sees the list of tasks that can be managed. The desired option is easy to find and is selected in one step (a single click).
- #86 The second screen is a simple listing of all puppies, each item illustrated with a photo. To add or edit an item requires a second click.
- #87 The third and final step involves the walkthrough of fields all on one page. These fields are grouped logically.
- #88 CCK tools offer a quick alternative to building a web app. But the time savings comes in development. The user does not benefit from this time savings. Perhaps this CCK approach actually adds more complexity for our client – requiring the user to navigate through additional steps and terms that are generic (or even non-intuitive).This example leads to a K2 category that implements the same pet store example. Not only are there three steps here, but the user has to make decisions when faced with a clutter of non-specific options. (BTW, the client might wonder why the second option reads “K2” instead of “K9” for his puppy application;-)
- #89 [4] The user must select the category to narrow down the options (or to create a new record of the “puppy” category).[5] the user selects the item to edit.
- #90 [6] The user must remember to click the “extra fields” tab to access the puppy details.[7] the user much remember to click the “image” tab or the puppy’s photo will not be included.Meanwhile, unused tabs and sidebar fields compete for the user’s attention as to what options are used.We can do better!
- #91 We return to the dashboard configuration I’ve been showing.
- #92 But we need more than just a link to K2. We want a link that takes one straight to the “web app.” With this plugin from the iCue Project we can do this. Install/publish the plugin, then add the catid to the link. This link will take one to K2 with the category filter preset to the specified category. As a result, we have dashboard options that lead straight to the specified K2 category, which represents a “web app.”
- #93 We can improve the edit screen for a K2 item by overriding it. Our added code wraps the entire body in a div with its id set to the cat id. Then in the CSS we add rules that suppress the unneeded tabs and fields for the puppy category.With this pattern, we can use the CSS file to declare which tabs will be hiddenfor any given category.
- #94 As a result of overriding the edit screen and CSS that affects only the targeted category, we produce a clean and rather streamlined screen (lower screen).
- #95 And if we compare this to the edit screen I created in the custom application, we see that the generic CCK solution is almost as streamlined as the that for the custom app.We don’t get a streamlined workflow with out-of-the-box CCK. But we can deliver a much improved workflow by applying some extra effort.
- #96 The work of delivering a separate and tailored user experience requires we invest additional effort. Not all of this work needs to be repeated for each client.
- #97 [1] Build a base installation and configure it with all the components, settings, and overrides that are commonly needed across projects. [2] Back up the base installation using Akeeba Backup.[3] For each new client site, install the base installation. All the common work is already in place and does not need to be repeated.
- #98 The base installation can include[1] installed modules that allow front-end editing[2] installed and configured “client template.” Include the overridden menu. Include the initial installation of dashboard modules.[3] set up the ACL with the common role-based groups and access levels[4] within the client template, store the collection of all your commonly used edit screen overrides. [5] Install JCE with profiles, each configured according to the standard settings you choose to baseline.[6] If you will be using K2 (or some other CCK) for task-based apps, override the edit screen and have the CSS code ready to apply as needed.
- #99 The strategy I have argued for is that we give the client their own user experience – one that is different from the developer’s user experience, and one that is tailored for the client’s usability (similar to the added effort we put into front-end usability).
- #100 Remember, Joomla _can_ be very easy to use. But we must follow the two strategies: [1] give client their own user experience, and [2] accept responsibility for investing some additional effort and dealing with a bit more complexity.Do this, and do it well, and we will deliver a CMS that is more usable than any other CMS which does not follow our strategy.
- #101 Joomla is a sophisticated instrument capable of great and beautiful things. When it comes to delivering a tailored and usable CMS to our clients, the biggest gains will come not from further enhancements or features to the instrument – rather our biggest gains are to be had with learning how to play the instrument and how to play it well.It is technique. It is learning how to leverage the ACL. It is learning how to leverage overrides. It is learning how to use PHP and add CSS to accomplish what we want. That is where the biggest gains are waiting. To deliver an improved CMS experience, place your focus on how to “play.”
- #102 iCue Projectan intelligent approach to improving the CMS user experienceTo receive information on new extensions and plugins produced by the iCue Project, please subscribe through the website: iCueProject.com