I agree, HTML5 brings improvements beyond DOM/JS API standardization in we can and I think we should adopt it regardless of what our policy with JS is.
I also do not mind maintaining non-JS version if that is something our users need, let's just not design our default UX around that and I am happy with that. Peter On 26 November 2012 13:51, Joachim Dreimann <[email protected]>wrote: > 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> * >
