On 21.10.2013 19:12, Joachim Dreimann wrote: > 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?
Ah, this in fact looks pretty good. There could even be several links to recent issues, instead of just the one (I guess making the notification area two lines high instead of one isn't that bad). I would suggest adding a kind of visual hint that the links are there in the create-ticket dialogue; it seems a bit counter-intuitive to me to click "Create Ticket" in order to see which tickets I've recently created. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. [email protected]
