incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <pe...@digiverse.si>
Subject Re: [Apache Bloodhound] #146: Inline editing of objects
Date Tue, 27 Nov 2012 06:50:49 GMT
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
<joachim.dreimann@wandisco.com>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 <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