I think that sounds like a reasonable process given our requirements. Regarding point 5. though maybe there shouldn't be a submit button in the view state - to avoid confusion users should only be able to leave the edit state by submitting or reversing their changes.
That way a submit button in the view state is only needed for the 'new comment' section. - Joe ________________________ @jdreimann - Twitter Sent from my phone On 23 Nov 2012, at 18:50, Gary Martin <[email protected]> wrote: > OK, > > Given the lack of further discussion, I will attempt to propose a solution > that begins to fit the requirements: > > 1. Initial access to a page shows the potentially editable fields in > the view state which should more or less match the current view > subject to differences specified below > 2. If the user has the appropriate permissions to modify the ticket, a > button is added to toggle between editable and view states (keyboard > shortcuts for these actions would also be nice enhancements for later.) > 3. In the editable state, all fields will be changed to the appropriate > kind of control for the field > * Any fields that the user does not have permission to change > should be locked in a way that is obvious - I would probably say > that it is better to be changed to a locked control to make it > feel that it is locked on purpose > 4. A field that is changed relative to the original state should > provide an indication of this status in both edit and view states. > 5. A submit button should be available from either edit or view states > - active when there are changes that can be submitted. > 6. For javascript turned off on the browser, behaviour should revert > back to the current separate form with an appropriate links to skip > down to it. With javascript on, the form is hidden and the > associated navigation item is then not required. > > Or something like that. So, apart from a clear idea of how we clearly mark > fields as edited, are there any other holes in this? It is also worth > considering if this fits with the current mechanisms for guarding against > conflicts dues to concurrent edits. > > Cheers, > Gary > > On 06/11/12 06:08, Peter Koželj wrote: >> On 5 November 2012 16:17, Jure Zitnik <[email protected]> wrote: >> >>> On 11/5/12 12:44 PM, Gary Martin wrote: >>> >>>> Individual confirmation on every field? That sounds like the same thing as >>>> an immediate save. I think that so far the consensus is that we don't want >>>> that. >>> +1 >> +1 >> >>> >>> I've been using a few developers at apachecon as sounding boards as I am >>>> worried that things might be more complicated than necessary. The solution >>>> that would seem most efficient would be that all the fields that are >>>> editable are considered to be in an editable state already. The problem >>>> with this is then how it is made abundantly clear that a field is editable >>>> - and it would be nice to see when a field has been edited too. >>>> >>>> I am not yet convinced that a button to make all fields editable is the >>>> right approach at the moment - it seems like a step you shouldn't need. >>> I think that the ticket could be shown as read only initially, with the >>> scroll spy component being visible from start (I think that was discussed >>> in another thread already). As the scroll spy already includes the 'Modify >>> ticket' button, clicking that button would enable 'edit mode' which would >>> replace ticket fields inline (read only for editable) - that is, w/o >>> scrolling to the 'Modify ticket' section. So, I would go for one button to >>> enable the 'edit' state and one button for submission. >> >> +100 :) >> >> >>> >>> Other than that, a submit all changes button would probably work well. >>> +1 >> +1 >> >>> Cheers, >>> Jure >>> >>> >>> Cheers, >>>> Gary >>>> >>>> On 5 November 2012 10:21, Joachim Dreimann <[email protected] >>>> **>wrote: >>>> >>>> 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<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 >
