HTML5 and JavaScript are two different issues, most obviously because one is a fix for the other: http://en.wikipedia.org/wiki/HTML5_Shiv HTML5 will also take some of the weight off JavaScript going forward, for example with contentEditable in this context: http://html5demos.com/contenteditable
Public sector organisations usually require all software to meet certain accessibility standards, and I would suggest that we build to their most basic standards at least. Screen readers often struggle with javascript, so Gary's suggestion was to at least have JS-less fallback (the current edit form). It's acceptable that this won't be pretty; most users will never see it. - Joe On 26 November 2012 06:49, Peter Koželj <[email protected]> wrote: > 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 > >>>>>>>> > >>>>>>>> > >>>>>>>> > > > -- Joe Dreimann UX Designer | WANdisco <http://www.wandisco.com/> * * *Transform your software development department. Register for a free SVN HealthCheck <http://go.wandisco.com/HealthCheck-Sig.html> *
