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 Mon, 26 Nov 2012 06:49:25 GMT
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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>

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