New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Help Topics improved #974

Merged
merged 18 commits into from Jun 5, 2014

Conversation

Projects
None yet
3 participants
@greezybacon
Member

greezybacon commented May 30, 2014

  • System has a default help topic now
  • Help topics are sortable
  • Topics can be arbitrarily nested

protich added a commit that referenced this pull request Jun 5, 2014

Merge pull request #974 from greezybacon/feature/help-topic-default
Help Topics improved

Reviewed-By: Peter Rotich <peter@osticket.com>

@protich protich merged commit 3afc4fb into osTicket:develop-next Jun 5, 2014

@Chefkeks

This comment has been minimized.

Show comment
Hide comment
@Chefkeks

Chefkeks Jun 10, 2014

Contributor

Hi, we just looked at the improved help topics / the whole develop next branch today. Even though this is already merged, here some positive feedback to the improved help topics:

  • Default help topic is great
  • Sorting of help topics is really useful
  • Autosave mode is giving a "Yay" effect when changing back to manual sorting

But in our eyes there's something else that also could be improved (if we did not missed something that is may already implemented)

  • Cascading help topics on the client side to different dropdown lists. So first a dropdown list with the parent topics and when a parent topic is then selected (and contains sub-topics) another dropdown list with the subtopics (+ an option for None to just select the parent topic only without a subtopic)
  • Some background info on that suggestion: We have 4 departments with at least 5 topics each (a lot of custom forms) and our clients are always complaining that the dropdown list with 27 or 28 help topics is really long and we shall move it into to two dropdown lists instead of 1 really large dropdown list.
Contributor

Chefkeks commented Jun 10, 2014

Hi, we just looked at the improved help topics / the whole develop next branch today. Even though this is already merged, here some positive feedback to the improved help topics:

  • Default help topic is great
  • Sorting of help topics is really useful
  • Autosave mode is giving a "Yay" effect when changing back to manual sorting

But in our eyes there's something else that also could be improved (if we did not missed something that is may already implemented)

  • Cascading help topics on the client side to different dropdown lists. So first a dropdown list with the parent topics and when a parent topic is then selected (and contains sub-topics) another dropdown list with the subtopics (+ an option for None to just select the parent topic only without a subtopic)
  • Some background info on that suggestion: We have 4 departments with at least 5 topics each (a lot of custom forms) and our clients are always complaining that the dropdown list with 27 or 28 help topics is really long and we shall move it into to two dropdown lists instead of 1 really large dropdown list.
@greezybacon

This comment has been minimized.

Show comment
Hide comment
@greezybacon

greezybacon Jun 10, 2014

Member

@Chefkeks may main feedback is that the help topic should not be used by the client to select the department. The help topic should be used to capture the nature of the support request and allow the client to fill out additional information. You can use the filtering feature for greater flexibility in sorting and routing tickets.

We now support adding forms after the fact. So you can always (as an agent) staple a form to a ticket and then ask the user to visit the client portal, edit the ticket, and add the new information

Member

greezybacon commented Jun 10, 2014

@Chefkeks may main feedback is that the help topic should not be used by the client to select the department. The help topic should be used to capture the nature of the support request and allow the client to fill out additional information. You can use the filtering feature for greater flexibility in sorting and routing tickets.

We now support adding forms after the fact. So you can always (as an agent) staple a form to a ticket and then ask the user to visit the client portal, edit the ticket, and add the new information

@Chefkeks

This comment has been minimized.

Show comment
Hide comment
@Chefkeks

Chefkeks Jun 16, 2014

Contributor

We see / use them a bit different here based on the history of our old (self-made) ticket system, where we "trained" our users to fill out the form (if there is any). So our users (old & new users) first check if there is a form for a request (e.g. New user account, Order new hardware, etc.) to make sure the request is directly assigned to the right person and all the info that is required by that staff agent is provided by them.

Sure there are also users (mostly new users, but also some "training-resistance" old users :D) who do not use our forms in first place. In such cases we reply them by adding the form and tell them to use it. And exactly here the users and also the agents are complaining about the usability which has a top priority for us and was also one of the main reasons for choosing osTicket!

Let me explain that usability complainment and start with the users. They get a mail / reply from the system with the notice to fill out the form. The click on the ticket link and see the ticket and now they often stop and think "Ok here's my ticket, but where's that form the agent told me to fill out?" ... "Ahh here it is, but how can I enter the information into that form" .... "May I need to click into the form area" ... "Hmmm, no..." ... ... ... "Ahhh, there's an edit button at the upper right corner, ok now I can finally enter the information". Some also are telling us it's hard to find and that the "usability is really not good". Same for some staff agents, only once every few month I guess they need to attach a form and in that case they start searching like "where was that option to add a form" ... "must be next / somewhere around to the ticket reply box at the bottom" ... and so on till they found it or called us to quickly ask.

Don't get me wrong it's not that HUGE problem or so, but it's like "That again...". I think that we have a different approach here since we optimized our old self-made ticket system together with our department for usability (of software, apps, websites, etc.) and so the expectations from users and also staff are quite high. We always get offers / tipps / hints to optimize our systems usability and there also have been some suggestions / hints how osTicket could be optimized (from a UX point of view), so in case you like to hear it, let me know. Overall their feedback was really positive and nothing like "that's totally crap" or so, but some usability improvements could be made ;)

Sorry for that maybe a bit too long comment,
Michael

Contributor

Chefkeks commented Jun 16, 2014

We see / use them a bit different here based on the history of our old (self-made) ticket system, where we "trained" our users to fill out the form (if there is any). So our users (old & new users) first check if there is a form for a request (e.g. New user account, Order new hardware, etc.) to make sure the request is directly assigned to the right person and all the info that is required by that staff agent is provided by them.

Sure there are also users (mostly new users, but also some "training-resistance" old users :D) who do not use our forms in first place. In such cases we reply them by adding the form and tell them to use it. And exactly here the users and also the agents are complaining about the usability which has a top priority for us and was also one of the main reasons for choosing osTicket!

Let me explain that usability complainment and start with the users. They get a mail / reply from the system with the notice to fill out the form. The click on the ticket link and see the ticket and now they often stop and think "Ok here's my ticket, but where's that form the agent told me to fill out?" ... "Ahh here it is, but how can I enter the information into that form" .... "May I need to click into the form area" ... "Hmmm, no..." ... ... ... "Ahhh, there's an edit button at the upper right corner, ok now I can finally enter the information". Some also are telling us it's hard to find and that the "usability is really not good". Same for some staff agents, only once every few month I guess they need to attach a form and in that case they start searching like "where was that option to add a form" ... "must be next / somewhere around to the ticket reply box at the bottom" ... and so on till they found it or called us to quickly ask.

Don't get me wrong it's not that HUGE problem or so, but it's like "That again...". I think that we have a different approach here since we optimized our old self-made ticket system together with our department for usability (of software, apps, websites, etc.) and so the expectations from users and also staff are quite high. We always get offers / tipps / hints to optimize our systems usability and there also have been some suggestions / hints how osTicket could be optimized (from a UX point of view), so in case you like to hear it, let me know. Overall their feedback was really positive and nothing like "that's totally crap" or so, but some usability improvements could be made ;)

Sorry for that maybe a bit too long comment,
Michael

@greezybacon

This comment has been minimized.

Show comment
Hide comment
@greezybacon

greezybacon Jun 16, 2014

Member

I see your point. Should we create a new issue to get the UX fixed?

Perhaps we should scan the ticket meta-data when the client is viewing a ticket, and, if there is a required field (that is visible and editable by the client) that does not have a value, display a banner above the "Post a Reply" box with something like

[!] There are fields on this ticket requiring your attention.
    [Click here] to add required information to this ticket
Member

greezybacon commented Jun 16, 2014

I see your point. Should we create a new issue to get the UX fixed?

Perhaps we should scan the ticket meta-data when the client is viewing a ticket, and, if there is a required field (that is visible and editable by the client) that does not have a value, display a banner above the "Post a Reply" box with something like

[!] There are fields on this ticket requiring your attention.
    [Click here] to add required information to this ticket
@Chefkeks

This comment has been minimized.

Show comment
Hide comment
@Chefkeks

Chefkeks Jun 19, 2014

Contributor

That's a great idea with the banner! In case I should create it, let me know, otherwise please go ahead and create a new issue to get the UX "fixed" :)

Btw. About 3 weeks since 1.9.1 and I noticed there are already the release notes for upcoming osTicket 1.9.2 with lots of fixes and improvements - that's really impressive!

Contributor

Chefkeks commented Jun 19, 2014

That's a great idea with the banner! In case I should create it, let me know, otherwise please go ahead and create a new issue to get the UX "fixed" :)

Btw. About 3 weeks since 1.9.1 and I noticed there are already the release notes for upcoming osTicket 1.9.2 with lots of fixes and improvements - that's really impressive!

@greezybacon greezybacon deleted the greezybacon:feature/help-topic-default branch Jun 19, 2014

@greezybacon

This comment has been minimized.

Show comment
Hide comment
@greezybacon

greezybacon Jun 19, 2014

Member

#1045

Thanks for all the debugging assistance!

Member

greezybacon commented Jun 19, 2014

#1045

Thanks for all the debugging assistance!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment