On 9/11/13, Joachim Dreimann <[email protected]> wrote: > On 10 September 2013 20:35, Olemis Lang <[email protected]> wrote: > >> On 9/10/13, Gary Martin <[email protected]> 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
