bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: Move away from "default product" concept
Date Wed, 11 Sep 2013 16:25:45 GMT
On 9/11/13, Joachim Dreimann <joachim.dreimann@wandisco.com> wrote:
> On 10 September 2013 20:35, Olemis Lang <olemis@gmail.com> wrote:
>
>> On 9/10/13, Gary Martin <gary.martin@wandisco.com> wrote:
>> > On 09/09/13 19:47, Olemis Lang wrote:
>> [...]
>> >>
>> >> I've been running BH without default product since a while ago and
>> >> there
>> >> is
>> >> something related to this that I find annoying . Currently QCT product
>> >> initial value is set considering context . That's ok . Nevertheless
>> after
>> >> creating the first ticket and/or clearing QCT form it turns out that
>> >> another product is activated by JS code . Based on my experience this
>> >> results in a frequent kind of *blindness* (resembling akinetopsia or
>> >> achromatopsia or alike , without being a pathology but a consequence
>> >> of
>> >> the
>> >> brain assuming a pre-existent condition) . This leads to a number of
>> >> mistakes related to product selection.
>> >
>> > Yeah, that does not sound good.
>> >
>> > I may have missed something but there seem to be four basic choices
>> > that
>> > have varying levels of sense to them:
>> >
>> >  1. Go back to the initial product based on current product context
>> >  2. Clear the current product on each submission to force the choice
>> >     each time
>> >  3. Let the product selection remain persistent until it is changed for
>> >     future choices
>> >  4. Only allow users to raise tickets in the product that they are in
>> >
>> > Of these, option 2 is least likely to cause user errors. Whether it is
>> > annoying for them is another question.
>> >
>>
>> I'd choose (2) by also disabling submit button if product field is empty
>> .
>>
>
> From my observation the best predictor for which product I will raise a
> ticket for next is the product for which I last raised one.
>
> I've changed my view on this a few times, but I think (1) seems like out
> best option.
> When I raise tickets I:
> - am working with a specific product, rather than switch between them
> frequently
> - frequently first search if a related tickets exists, which puts me in the
> product context
>
> (3) would be my second choice for the same reasons, but introduces many new
> considerations regarding the implementation and just how persistent it
> should be, for example across tabs. (Thanks Gary for challenging me on
> this!)
>
> I feel like option (2) will be annoying, mostly. (4) violates the idea of
> the global header.
>

This is what I thought initially but, in practice the main causes for
moving tickets to another products (which in fact is an 'unsupported'
hack) have been

  - spam (56,2 %)
  - qct submit > 1 (21,7 %)
  - RPC bug already fixed (18.4 %)
  - Others ... (3.7 %)

>
[...]
>>
>> Reporting across multiple products might be problematic. There's
>> already limited support for aggregating events in global timeline ,
>> which is fine .
>>
>
> Reporting across products may be technologically problematic, but I'm
> certain that this is a feature that will be expected by users.
>

I didn't say it before because I considered it implicitly . The fact
is that reports are arbitrary SQL . I'd rather suggest to (improve |
extend | rethink) the query module and include MP features in there
rather than in reports module .

[...]

-- 
Regards,

Olemis - @olemislc

Mime
View raw message