Not sure how much does support for javascript disabled browsers complicate things, but do we really care to support this when everybody is rushing to HTML5?
I haven't that kind of requirement for a web application in the last 7 years or so. Peter On 23 November 2012 19: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=****<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<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 >>>>>>>> >>>>>>>> >>>>>>>> >
