incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Dreimann <joachim.dreim...@wandisco.com>
Subject Re: [Apache Bloodhound] #146: Inline editing of objects
Date Mon, 26 Nov 2012 12:51:47 GMT
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 <peter@digiverse.si> 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 <gary.martin@wandisco.com> 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 <jure@digiverse.si> 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 <
> >>>> joachim.dreimann@wandisco.com
> >>>> **>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 <joachim.dreimann@wandisco.com
> **
> >>>>> **>
> >>>>>
> >>>>> 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 <peter@digiverse.si>
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 <
> >>>>>>> gary.martin@wandisco.com
> >>>>>>>
> >>>>>>>  wrote:
> >>>>>>
> >>>>>>  Olemis Lang <olemis@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>   On 10/4/12, Branko Čibej <brane@wandisco.com>
wrote:
> >>>>>>>>
> >>>>>>>>> On 05.10.2012 05:17, Olemis Lang wrote:
> >>>>>>>>>>
> >>>>>>>>>>  On 10/4/12, Branko Čibej <brane@wandisco.com>
wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>  On 04.10.2012 18:33, Olemis Lang wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>  On 10/4/12, Gary Martin <gary.martin@wandisco.com>
wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>  On 04/10/12 16:54, Joachim Dreimann
wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>  On 4 Oct 2012, at 12:01, Gary
Martin <
> >>>>>>>>>>>>>>> gary.martin@wandisco.com
> >>>>>>>>>>>>>>> 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> *

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message