On 19 October 2013 14:07, Branko Čibej <[email protected]> wrote: > On 18.10.2013 11:45, Joachim Dreimann wrote: > > On 18 October 2013 03:06, Branko Čibej <[email protected]> wrote: > > > >> On 17.10.2013 23:42, Joe Dreimann wrote: > >>>> On 17 Oct 2013, at 23:14, Olemis Lang <[email protected]> wrote: > >>>> > >>>> I'm forwarding this message on behalf of a user (after translating the > >>>> original text in Spanish, adding a bit of slang-ish terms and > >>>> inserting my own comments ;) . I mostly agree in some points that's > >>>> why I'm forwarding it to the ML, especially to request for keeping QCT > >>>> ticket notification visible long after creation, figure out how/where > >>>> to include it and file a new ticket @ i.a.o/bh . > >>>> > >>>> <msg> > >>>> > >>>> When QCT form is submitted there's no confirmation indicating that > >>>> ticket was actually created except for the small window that pops up > >>>> after a while (<= due to limited bandwith it takes a while to be > >>>> shown) and that , at least in my case , captures whole attention > >>>> because > >>>> > >>>> 1. it remains open for about 2 or 3 seconds > >>>> 2. if using a laptop mouse pad then it ends up to be extremely > >>>> complicated to follow ticket link (<= obviously not a Mac user) > >>>> 3. if the popup is missed for any reason then finding the ticket > >>>> is a time consuming task, at least more time-consuming than > >>>> it should be due to the fact that: > >>>> * ticket URL has to be guessed > >>>> * ticket does not show up in dashboard (<= owner and component > >>>> not in QCT) > >>>> * therefore a custom query is required > >>>> 4. the default configuration is sub-optimal since it's always > >> necessary to > >>>> surf to ticket page in order to fill remaining fields > >>>> (<= component , priority , custom fields , ... which otoh are > >>>> configurable). > >>>> > >>>> Summarizing , the confirmation of the most recent ticket must remain > >>>> in the page just in case it's not possible to capture QCT notification > >>>> and browsing to ticket page is still needed. > >>>> > >>>> </msg> > >>>> > >>> These tickets should be easy to find by the Reporter field using Custom > >> Query and sorting by descending ticket ID. The first ticket is the one > last > >> raised by that user. That's the best way to keep track of tickets raised > >> throughout the day too. > >> > >> Isn't an activity stream the normal way of handling this? If you have an > >> activity stream on the dashboard, and an easy (one-click) way to have it > >> show only your own changes, it should be trivial to find such tickets. > >> Certainly easier than running a custom query. > >> > >> -- Brane > >> > > Sure, but you may not be on the dashboard. If you raise a ticket while > > viewing a ticket, milestone, version etc the activity stream in that > > context most likely won't show this. Navigating away you would lose > context. > > I'm confused. Doesn't running a custom query also result in navigating > away from whatever you're currently viewing? It certainly does when I > try that. >
Yes, I was pointing this out in contrast to the approach of appending the 'last created' information to the Quick Ticket dialogue. Sorry for not making that clearer. > > > I do think that we should have the ability to query the activity stream, > > but I see that in the context of the Custom Query interface: output is > > either a list of tickets (current), or an activity stream (optionally in > > future). The activity stream everywhere could contain a link to that > > preformed query (only 'my actions'). That's a pattern we already have for > > the queries shown on the dashboard for example. > > If you can create tickets from any context, and ticket creation does not > automatcially redirect you to the ticket page; then it follows that > there must be a standard UI element that tells you at least which > tickets you recently created, and possibly also which ones you recently > modified (for some definition of "recently"). You should not have to run > a custom query; that just feels totally wrong to me. > Again, that's why my initial suggestion was to append 'last created' information to the Quick Ticket dialogue. > > If the idea is to be able to see what you just created without > navigating away from whatever you're looking at (which a custom query > doesn't give you), then perhaps the solution would be a kind of "recent" > dropdown that displays a heavily filtered and shortened activity stream. > I know we all love to hate dropdowns, but in this case, IMO, it's better > than the alternatives currently available. > > -- Brane > I'm sceptical about that approach because it's basically a new messaging channel which comes with all the issues of .. messaging channels in general. I don't think this is an essential feature. I do believe we should do the lowest effort thing now (therefore my suggestion). Here's my mockup again just for reference: http://redpen.io/tfox7u The user asked for a link to the last created ticket. Why over-engineer it? - Joe > > -- > Branko Čibej | Director of Subversion > WANdisco // Non-Stop Data > e. [email protected] > -- Joachim Dreimann | *User Experience Manager* WANdisco // *Non-Stop Data* e. [email protected] twitter @jdreimann <https://twitter.com/jdreimann>
