On 9/11/13, Gary Martin <[email protected]> wrote: > On 11/09/13 17:25, Olemis Lang wrote: >> On 9/11/13, Joachim Dreimann <[email protected]> wrote: [...] >>> >>> 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 %) > > For me that does not provide enough evidence to suggest which approach > will be best.
Ok, I'm not saying that this is the whole truth , indeed those stats are taken in set of 539 tickets created in unexpected product context . JFTR , not the biggest of the numbers for the short lifetime of BEP 3 out there , but also users do not make mistakes every day , so also consider that there's a much bigger number of correctly created tickets not influencing the stats . I'm just offering the metrics I've collected tracking interactions of real users working on real projects and committing mistakes ; and indeed the regular interactions with BH site might be different to the workflow highlighted by Joe in previous messages . 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) >>>> 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 . >> >> [...] >> > > The ultimate protection around this would be the permissions around > report creation. This means that they almost certainly require a health > warning and people will need to make sure that they are providing access > to the reports appropriately. Some users, however, are likely to require > the power provided. Improving upon the query module would be good of > course but I suspect that will take some time and a lot of thought. > AFAICT I see that this subject is more about who sees what , instead of creator . IMO it's much harder to ensure data protection upon ticket queries than free style SQL reports . -- Regards, Olemis - @olemislc
