bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: Move away from "default product" concept
Date Thu, 19 Sep 2013 17:47:29 GMT
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

Mime
View raw message