Clicking the title of an Activity (Human Task) means I have unnecessary clicks to get to the answers; and the checkbox option is so TINY!

[Berto2002]

There is a bizarre little quirk of the user interface that if Agents click the header of an activity, when the box opens, you then also need to click the show more in order to enter required text (two clicks):

Here's the Activity:

If I click the words "Is this a valid Request" I get this box:

When I click Complete, I then get the real answers below. But that's an annoying extra click for every Agent every time. Why does it not just present the Valid and Invalid options directly when clicking the Title?

Is this something in our workflows that could be configured differently to avoid or is this a function of the UI?

To get the correct options up directly, I need to click this TINY little checkbox which only appears when I hover over it - and then it shows the Valid and Invalid options straight away.

I don't understand a use case for this behaviour. Surely:

1. The "Complete" checkbox can be permanently shown?
2. There is no case for the header and checkbox having different behaviour? Even if there is, the DEFAULT behaviour should be 'Complete' and be on the Header because 99% of the times these Activities are opened, they are opened by an Agent who wants to Complete them
3. The clickable area for the checkbox is TINY and causes exasperation regularly when we miss it; so even if we must persist with these two approaches, please can we make that a bigger target for the mouse?

This is a UI frustration that I wanted to bring to HB attention but also to ask if this is something I can avoid by re-configuration.

Thank you

 

[Adrian Simpkins]

+1 from me regarding having to click Complete to Complete the task if you do not select the tick box - totally in agreement as to just jump to the activity (unsure of the benefit of the Complete screen highlighted above). Also can the tick box be viewable at least without having to hover mouse over it if it cannot be increased in size?

Thanks

[Frank Reay]

+1

[Gerry]

I think this comes down to not understanding the full scope of capability here.  A task has many configurable options for completion.  For a start, a task can include one or more custom fields that can be included in a task, so when you open that task there are extra fields shown.  Populating/seeing those fields is not the same as completing a task.  This is why there is a task "view" state and a different task "complete" state.  When it comes to task completion, a task can present/require addtional fields of input form the user, these fields are global, and presented regardless of any chosen outcome.  One or more of these fields can be mandatory, meaning until those fields are completed, none of the outcome buttons are activated.   Then, after all that, each individual outcome can themselves define even more custom fields, that are either optional and required for that particular outcome, this means that when you press the outcome button, you many or may not be presented for even more input. 

Ok so I know that most people will not use these features all together because that would be complex (and annoying) to the extreme for task users who need to complete a task... but, we have to support these scenarios which is why when a task is opened there are two states, view and complete.  

For exactly these reasons, the checkbox icon cannot be a quick complete action, because that would introduce variable behaviour, meaning, for some tasks it might just complete, but for other tasks you are presented with a choice of outcome, and yet for other tasks, you might be presented with addtional information you have to provide for the task, and yet for other tasks you may also be required to provide outcome-specific extra fields, that may or may not be presented, and all dependant on what outcome you have selected.  

The tasks in Hornbill are really powerful, but they have to deal with all of these scenarios. and that makes for a less than ideal interface.  We could dumb down the task behaviour and remove the task custom fields, and the outcome specific custom fields, but my feeling is that would take quite a lot away - and anyway we have quite a few customers that do depend on this extended behaviour. 

"This is a UI frustration that I wanted to bring to HB attention but also to ask if this is something I can avoid by re-configuration." 

Now I do take your point about not having the view state, if there are no custom fields defined, that would be possible, and possibly we could look at improving this, we could add more smarts so, if for example, there are no addtional mandatory fields we could present a list of outcomes without having to open the view, but we are back to doing pre-task behaviours which will only lead to more frustrations as users who did not configure the tasks don't understand why, sometimes it just completes, other times it opens a details view and presents more fields etc.... 

It may well be if we revisited this we change the strategy and simply have different types of tasks that have distinctly different behaviours, less flexible, but possibly easier to use. 

Gerry



 

[Adrian Simpkins]

Thanks for the update and explanation Gerry, at least it defines why we see the Complete field prior to actually completing a task. I would not want to lower the available functionality in the system of course, but now I can explain to my Users why they see this functionality sometimes in the system which may cause them some frustration. 

Many thanks as always