I've removed the discussion about data to attempt to discourage me from
talking about how the data does not give enough information to come to
any conclusion. Well, apart from that.
On 11/09/13 20:46, Olemis Lang wrote:
I guess the results will vary depending on many factors , but (my)
conclusion is that users in practice are highly biased by product
context and pay more attention to real tasks they are doing. Therefore
(3) is not a feasible choice based on my experience , at least under
the circumstances and workload, ... of the deployments I've tracked.
My opinion on this subject is :
(1) it's ok , but IMO not optimal
(2) would be best , by also disabling submit button
(3) definitely no
(4) would work but provides limited UX
It is quite likely that this will only come through use of
the various options so, unless we are going to trial a number of
options, this all comes down to opinion. I don't think we should go
through all the options that way yet. Let's just select something that
is good enough to be going on with.
... but let's move forward this way ;)
Option 2 is the pretty much foolproof one but of course it is annoying.
The others leave the potential for a user to forget the behaviour (be it
location based or continuing from a previous selection).
I guess I missed:
5. Stay on the product that was last submitted from the QCT on that page
This is similar to (3) , when users switch back and forth the mistake
happens quite often . I'm one of those who would fall in this trap
quite often
I have to say that, at the moment I am hoping for very simple options so
I don't want to expand on ways that option 3 could be made to work.
+
[...]
For the sake of annoyance reduction (and a quick decision), does anyone
object to option 5 being used until we have time to look at this again?
unfortunately I do , If (2) is out of consideration then I'd rather choose (1)
While option 2 is the safe option, I am still worried that it would get
too annoying. Personally I would be willing to go with it as I would
like to consider a second enhancement beyond this.
So, what I think may actually be best is:
* On page load, QCT forces selection of fields (matching option 2)
* After ticket submission, QCT retains the current selection for the
submitted ticket for the next ticket (temporarily matching option 5)
* On a timeout, the QCT reverts to the initial settings it had on page
load (reverting to option 2)
To get towards completeness, a few more rules are required:
* The revert timeout is ignored if the QCT is open or if the QCT has
been changed
* The revert timeout is restarted on closing the QCT
So, hopefully I will get a bit of a sanity check on this plan from
everyone. I think we also need to roll out the behaviour to all fields
although we should probably additionally respect any default selection
values. Anything else I haven't covered?
Cheers,
Gary
