I notice that there were no replies to my last message (see below) and the ticket has therefore been put on hold. We've made no progress in a whole month on an issue all seemed to agree was important.
The question remains: > Should we enable the 'edit' state for all fields using one button and submit > using one button, or should we take Jira's approach of asking for individual > confirmation on every field? - Joe On 5 Oct 2012, at 20:10, Joe Dreimann <[email protected]> wrote: > Ok, that sounds like we have a decision: All are in favour of non-immediate > saves for edits. > > Now, should we enable the 'edit' state for all fields using one button and > submit using one button, or should we take Jira's approach of asking for > individual confirmation on every field? > > http://www.youtube.com/watch?feature=player_detailpage&v=EsQ__dR6Nrw#t=59s > > I'm bringing up Jira because it's used in a very similar context as > Bloodhound. > > Cheers, > Joe > > ________________________ > @jdreimann - Twitter > Sent from my phone > > On 5 Oct 2012, at 09:29, Peter Koželj <[email protected]> wrote: > >> I too am strongly against inline editing causing auto-save. Ticket >> changes must be intended and atomical! >> 1. Tickets are versioned and this messes up the ticket history >> 2. Multiple ticket notifications get sent out >> 3. Any ticket statistics get incorrect >> 4. In bigger enterprise environments tracking systems are integrated with >> other infrastructure, which means unintended inconsistencies are propagated >> to other systems as well >> 5. Companies will offen grant their customers access to tracking system and >> last person that I want to burdon with this, is my client. >> 6. If this works only for half of the tickt's fields, it is inconsistent! >> And the problem will just be worse when we try to get rid of that "Modify" >> section. >> >> I do find the proposed concept appealing for things like user preferences >> but even for that we would need to weight pros and cons. >> >> Peter >> >> >> >> >> On Fri, Oct 5, 2012 at 9:52 AM, Gary Martin <[email protected]>wrote: >> >>> >>> >>> Olemis Lang <[email protected]> wrote: >>> >>>> On 10/4/12, Branko Čibej <[email protected]> wrote: >>>>> On 05.10.2012 05:17, Olemis Lang wrote: >>>>>> On 10/4/12, Branko Čibej <[email protected]> wrote: >>>>>>> On 04.10.2012 18:33, Olemis Lang wrote: >>>>>>>> On 10/4/12, Gary Martin <[email protected]> wrote: >>>>>>>>> On 04/10/12 16:54, Joachim Dreimann wrote: >>>>>>>>>> On 4 Oct 2012, at 12:01, Gary Martin <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>>>> On 03/10/12 20:50, Olemis Lang wrote: >>>>>> [...] >>>>>>> As a user using a web application with the server 50 hops away with >>>> a >>>>>>> 1.5 second ping time, I'd be very, very pissed off if every click I >>>> make >>>>>>> generates a POST request to somewhere; even if it's an async XHR >>>> (even >>>>>>> worse! then I don't know in what order the server actually receives >>>> the >>>>>>> requests). >>>>>> ... if you take a look at #146 attachments you'll notice that my >>>> first >>>>>> proposal included submit button for select fields . I was told to >>>>>> revert that . >>>>> >>>>> Hmm. "Told to" implies hierarchy. >>>> >>>> ... or respect to the opinions of the experts , and Joachim is the UI >>>> expert . When I have radical objections to other people's thoughts and >>>> ideas (e.g. on the subject of WikiMacros ) or even when I agree but >>>> there are underlying technical decisions that make it impossible to >>>> realize some ideas then I express my opinion . This time I don't think >>>> it was the case . /me studying and learning about UI design , etc ... >>>> but that's just work in progress . Hence most of the time I won't >>>> criticize UI decisions beyond «evident» issues I might notice. >>>> >>>> So to clarify my position , in this particular case i.e. #146 , I >>>> declare myself a completely happy neophyte and *so far* I have no >>>> strong arguments in favor or against any of both approaches . Please >>>> get to an agreement . In the meantime , if I have something to say >>>> I'll say it . Just let me know what needs to be done to continue work >>>> needed to finish patches for #146 , please . >>>> >>>> ;) >>> >>> This is why we need more decisions to be made here. No one person is going >>> to be right on every decision. >>> >>> For some reason I didn't get the impression from the discussion in the >>> ticket that it would result in immediate edits. If more people were >>> watching the discussion, this might have been caught earlier as something >>> that people would frown upon. Maybe. >>> >>> Anyway, personally I want to see in-place edits implemented such that the >>> changes are not sent immediately but should be submitted with a single >>> button. >>> >>> I would probably be attempting to effectively use the existing form to >>> send the data - I suspect that at some point we will want the old form >>> hidden but it should probably be available for js disabled situations. >>> >>> For me, that would be enough work on the ticket. After that we can build >>> on that work with things like indicating which fields are edited and >>> perhaps making it easier to comment on the changes (the comment field is >>> way down the page on long tickets). I would also be interested in whether >>> people would want to see a confirmation that the user should move away from >>> a page when there are edits that are not submitted. >>> >>> Cheers, >>> Gary >>>
