Recent searches


No recent searches

Justin Moore's Avatar

Justin Moore

Joined Jan 24, 2024

·

Last activity Aug 07, 2024

Following

0

Followers

0

Total activity

11

Votes

2

Subscriptions

4

ACTIVITY OVERVIEW

Latest activity by Justin Moore

Justin Moore commented,

CommentWorking with articles in the knowledge base

Is revision control supported in any way for Content Blocks? I can't seem to find any way to view revisions for a Content Block, but it feels like the way that revisions are accessed for articles has changed several times recently, and it's currently somewhere very silly (the right-most level of the right-side vertical navigation frame). I do not see anything comparable in the interface view for Content Blocks.

 

If revisions aren't supported for Content Blocks then that seems like a major oversight and problem. Revision control is a critical part of information management for any type of documentation content!

View comment · Posted Aug 07, 2024 · Justin Moore

0

Followers

1

Vote

0

Comments


Justin Moore created a post,

Post Feedback - Admin Center

I've seen a Macros Admin page redesign pushed to my Zendesk instance recently, and I've noticed a problem with the design of its Filter capability. The interface communicates information about the filtering state of the search to the user in a way that is both misleading and self-inconsistent, creating a frustrating and negative user experience, and impacting usability and efficiency for Agents. Overall, the interface: 1) Hides important information about the current search filter settings from the user; and 2) Misleads the user about the actual state of the search filters.

 

Description

When I load the Macros Admin page (in Admin Center > Workspaces > Agent Tools > Macros ), I see a consistent default state: the search bar is blank and a single filter tag is displayed, showing Status Active.

Admin Center > Macros Admin: Default State

 

This appearance communicates the clear implication—based on universal common expectations of how search and filter tools interact—that only the Status (Active) filter is being applied, and search results will be shown from the set [all macros with Status (Active)]. However, that is not what will occur. Entering a search term will instead show search results from the set [all macros with Status (Active) and Available for (All shared macros)].

 

Similarly, clicking the “Clear filters” button produces an interface that displays no filter tags, appearing to communicate the clear implication that the search results are no longer being filtered. However, this is false. Entering a search term will show search results from the set [all macros with Status (All statuses) and Available for (All shared macros)]. While the "Status" value “All statuses” indeed represents an unfiltered category, the “Available for” value “All shared macros” does not represent an unfiltered category.

 

The list of filter tags displayed does not accurately reflect the filtering state of the search results! The true filtering state includes another, hidden filter, not displayed with other filter tags.

 

Examples

Clicking the “Filter” button under the search bar brings in a side-panel overlay, showing two filtering categories currently available: “Status” (with states "All statuses", "Inactive", and “Inactive”) and “Available for” (with states “All shared macros”, “All agents”, “You”, and “Group”). 

 

When the “Status” category filter is set to either “Active” or “Inactive”, a corresponding filter tag is displayed adjacent to the “Filter” button. However, when set to “All statuses”, no filter tag is displayed.

 

"Status" Filter Category Screenshots: (State of “Available for” category filter not changed from default value)

  1. Status (Active) 

    Filter State: Status (Active)
  2. Status (Inactive) 

    Filter State: Status (Inactive)
  3. Status (All statuses) 

    Filters State: Status (All statuses)

Similarly, when the “Available for” category filter is set to “All agents”, “You”, or “Group”, a corresponding filter tag is displayed. But when set to  "All shared macros”, no filter tag is displayed.

 

"Available for" Filter Category Screenshots: (State of “Status” category set to “All statuses” for visibility)

  1. Available for (All agents) 

  2. Available for (You) 

  3. Available for (Group) 

     

  4. Available for (All shared macros) 

    Filters State: Status (All statuses); Available for (All shared macros)

 

When the “Status” filter is set to “All statuses” and the “Available for” filter is set to “All shared macros”, either by manually setting these filter states or by clicking the “clear filters” buttonthe interface displays no filter tags, even though two filtering states are actually set. This information is not communicated to the learner in any way by the interface. 

 

It isn't a problem for the filter state Status (All statuses) to show no filter tag, because that's the state in which the category “Status” actually is unfiltered). On the other hand, it is problematic for the filter state Available for (All shared macros) to display no filter tag, because that is not an unfiltered state—the category is being filtered and only some of its total contents are being searched! In fact, there doesn't appear to be any unfiltered state for the “Available for” category.

 

I imagine that this behavior may have been inherited or carried over from historical display settings for Macro Admin, but because of the change in display to the search/filtering interface, the behavior now is problematic.

 

Why is this Problematic

The new interface clearly establishes a standard context (search feature with filters) that leads users to expect information about its functional state will be communicated in certain predictable ways (results can be filtered by the state of one or more filter categories; the filtering state of the search will be indicated by the interface somehow). However, as implemented, the interface:

  1. Silently subverts the standard expectations: The absence of a filter tag indicates the absence of filtering; and also
  2. Inconsistently communicates the standard expectations: The absence of a "Status" filter tag does indicate the absence of filtering in that category, but the absence of an “Available for” filter tag does not indicate the absence of filtering in that category

 

Additionally, the Macros Admin page's implementation of a “search with filter” system behaves quite differently from implementations of the same system elsewhere. For example, in the Help Center Admin's Manage Articles section, the “Filter” button itself acts as a selection tool, multiple state values are selectable from individual categories, and (to the best of my knowledge) the “Clear filters” button acts as expected—it removes all active filters, returning the search to an unfiltered state.

 

 

How Can This Be Fixed?

In short, either:

  • Include an unfiltered state for the  “Available for” category filter—"All macros"
    • So that the default, unmarked state for this category filter communicated true information; or
  • Ensure that the interface always displays a filter tag for the “Available for” category filter
    • So that it is always signaled that the results are always being filtered by this category in some way

 

Given that the search-with-filtering capability appears to function as expected for the “Status” filter category, my preference would be to make changes to allow a true “all macros” state value for the “Available for” filter category. This way, whatever an individual Zendesk instance's defaults are,  not only should the tags displayed by the filter function always display true information, but the functionality of the search capability would be enhanced. Users would be able to much more easily search across both Shared and Personal macros, for instance.

Edited Aug 05, 2024 · Justin Moore

0

Followers

0

Votes

0

Comments


Justin Moore commented,

CommentWorking with articles in the knowledge base

Nora

I also can no longer see a "Preview" option (either a button or a link) anywhere in the editor for FAQ articles.

This article mentions and shows a "Preview" button, but not in context, so I'm not sure where's supposed to appear.

 

Edit:was eventually able to locate the "View" button, and it appears that the UI may have changed since this article was last updated. I'm seeing a "View" button that, when clicked, produces a popup menu that appears to serve the functions of both "View (live)" and  "Preview (draft)". However, the button only displays the popup menu if a draft has been saved, and does not appear to signal what its behavior will be in any way before it is clicked on. This makes it unpredictable—not great UI/UX design.

 

Additionally, when I did eventually locate the "View" button, I was flabbergasted at its location:

Why is this UI element so far away from everything else? It's in the absolute bottom left of the window, along with no other UI elements whatsoever. No wonder I couldn't locate it.

 

What was the reasoning for placing this UI element in this location?... And could you please move it back to the right side where everything else is?

View comment · Edited Feb 05, 2024 · Justin Moore

0

Followers

1

Vote

0

Comments


Justin Moore commented,

Community comment Feedback - Ticketing system (Support)

When the new Agent Workspace, with the new Composer, was enabled for my workplace, I noticed that the Composer window size would automatically grow as I entered text.

However, I touched the Composer resizing bar one time, and now my Composer window remains persistently locked to whatever size I last set it to. I can't find any way to change back to the auto-resizing behavior.

I also use many large macros or otherwise produce long responses to tickets, and it is very frustrating to have to manually mouse target the Composer resize bar (an approximately 7px target—easy to miss and waste time on) and resize it whenever I need to reference the existing ticket (because with a large Composer view the ticket window is tiny) or move back to the Composer (because with a large ticket view the Composer window is tiny).

There appears to be a (small) auto-hiding UI element to "Hide Composer", but again, this is both a very small UI element and not persistently visible, making it a frustrating target to hit. Additionally, I don't know of any way to trigger the hiding behavior via keyboard shortcut, which might be a workable alternative—though certainly not preferable.

  1. Is there a way to return to the Composer window's (apparently) default auto-resizing behavior after an agent manually resizes the Composer?
  2. Is there a way to trigger the "Hide/Show" Composer function without having to hunt for a tiny, hiding UI element?
  3. For both, if not, why not?

View comment · Posted Jan 24, 2024 · Justin Moore

0

Followers

1

Vote

0

Comments


Justin Moore commented,

Community comment Feedback - Ticketing system (Support)

I've just switched over to the Agent Workspace and, like many others before me, have been adapting to the new composer paradigm.

One specific pain point regarding Draft Mode is that, as far as I can tell, making use of the "persistent Draft Mode" feature requires a mouse click. This is an unwanted and inefficient imposition on efficient, consistent, and predictable workflow.

It seems like I can either:

  1. Manually re-enable Draft Mode at the start of working on every ticket, and then manually disable it before submitting the ticket—all three possible via keyboard shortcut; or
  2. Manually enable Draft Mode once, save/submit the ticket—both via keyboard shortcut—and then confirm the send through Draft Mode—and be forced to move to the mouse to click the "Save" button

In the old workspace, my ticket workflow was this:

  1. Load into a ticket, defaulted to Internal Note mode
  2. Compose response
  3. When ready to submit, use ctrl+alt+C to switch to Public Reply mode, then use ctrl+alt+S to submit and solve the ticket (or the shortcut for a different status)

The basic shape of this efficient and predictable process flow is broken by the design of the new Workspace. Not only am I forced to switch to Public Reply mode immediately—adding another step to be memorized for the process—but if I want to make use of Draft Mode to replace the Internal Note mode's previous "drafting/safety" function, then I'm forced to swap interaction modality from keyboard to mouse and aim for a small button target to submit every ticket.

I'm confused as to why the "This message is in Draft Mode, do you want to send it publicly?" modal does not either:

  1. By default place focus on the "Send" button; and/or
  2. Accept a simple keystroke to activate the "Send button"

In fact, based on extremely standard UI design principles, I would already expect 'enter/return' to activate the "Send" button, because it is clearly colored as the default UI element. However, regardless of whether I trigger the "Are you sure?" modal by clicking the "Submit" button in the Ticket UI or by using one of the keyboard shortcuts that submit a ticket, focus does not appear to land on the "Save" button—neither the 'enter/return' nor the 'space' keys trigger that button.

The button can be navigated to by pressing 'tab' twice and then 'space' to activate the button, but not only does this force the agent to take even more actions, it is easy to over- or under-shoot the number of inputs necessary, especially when an agent's time is spent handling dozens of tickets or more every day.

Either there should be an ability to default to Draft Mode when loading the Public Reply composer for a ticket—regardless of whether Draft Mode was manually turned off in the previous ticket—or if you're dead-set on forcing a modal dialog to confirm sending through Draft Mode, it needs to be navigable by simple keyboard interaction.

If you can get to the "Are you sure?" modal via keyboard shortcuts, you need to be able to also get through the modal with keyboard shortcuts.

 

View comment · Edited Mar 06, 2024 · Justin Moore

0

Followers

2

Votes

0

Comments