On 11/09/13 17:25, Olemis Lang wrote:
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 %)
For me that does not provide enough evidence to suggest which approach
will be best. 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.
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
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.
Options 1, 2 and 5 are all fairly predictable with a bit of experience
and, in the medium term, that is probably good enough for me.
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?
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.
Cheers,
Gary
