incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: [Apache Bloodhound] #146: Inline editing of objects
Date Sat, 24 Nov 2012 19:54:49 GMT

Interesting point. I am not sure that a separate submit button is a 
particularly good idea so I am not sure why I created point 5. In fact I 
would prefer to encourage users to provide a comment on why they made 
the change but I was hoping to avoid enhancements relating to comments 
in this proposal. I suggest that for now we stick with the current 
submit button.

I was also thinking that per field reverts could be considered an 
enhancement for later too.

Anyway, given that there was a feeling that tickets should not start in 
an editable state, I was assuming that the ability to toggle between 
states would be wanted to avoid accidental changes. Without that I 
suppose users are encouraged to submit their changes earlier so I am 
happy to lose that aspect.


On 23/11/12 19:15, Joe Dreimann wrote:
> I think that sounds like a reasonable process given our requirements.
> Regarding point 5. though maybe there shouldn't be a submit button in the view state
- to avoid confusion users should only be able to leave the edit state by submitting or reversing
their changes.
> That way a submit button in the view state is only needed for the 'new comment' section.
> - Joe
> ________________________
> @jdreimann - Twitter
> Sent from my phone
> On 23 Nov 2012, at 18:50, Gary Martin <> 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 <> wrote:
>>>> On 11/5/12 12:44 PM, Gary Martin wrote:
>>>>> Individual confirmation on every field? That sounds like the same thing
>>>>> an immediate save. I think that so far the consensus is that we don't
>>>>> 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 <
>>>>> **>wrote:
>>>>>   I notice that there were no replies to my last message (see below)
>>>>>> 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
>>>>>> submit using one button, or should we take Jira's approach of asking
>>>>>> individual confirmation on every field?
>>>>>> - Joe
>>>>>> On 5 Oct 2012, at 20:10, Joe Dreimann <**>
>>>>>> 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
>>>>>> and submit using one button, or should we take Jira's approach of
>>>>>> for individual confirmation on every field?
>>>>>> EsQ__dR6Nrw#t=59s<>
>>>>>>> I'm bringing up Jira because it's used in a very similar context
>>>>>> Bloodhound.
>>>>>>> Cheers,
>>>>>>> Joe
>>>>>>> ________________________
>>>>>>> @jdreimann - Twitter
>>>>>>> Sent from my phone
>>>>>>> On 5 Oct 2012, at 09:29, Peter Koželj <>
>>>>>>>   I too am strongly against inline editing causing auto-save.
>>>>>>>> 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
>>>>>>> with
>>>>>>> other infrastructure, which means unintended inconsistencies
>>>>>>> propagated
>>>>>>> to other systems as well
>>>>>>>> 5. Companies will offen grant their customers access to tracking
>>>>>>> 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
>>>>>>> inconsistent!
>>>>>>> And the problem will just be worse when we try to get rid of
>>>>>>> "Modify"
>>>>>>> section.
>>>>>>>> I do find the proposed concept appealing for things like
>>>>>>> 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 <
>>>>>>> wrote:
>>>>>>>>> Olemis Lang <> wrote:
>>>>>>>>>   On 10/4/12, Branko Čibej <>
>>>>>>>>>>> On 05.10.2012 05:17, Olemis Lang wrote:
>>>>>>>>>>>> On 10/4/12, Branko Čibej <>
>>>>>>>>>>>>> On 04.10.2012 18:33, Olemis Lang wrote:
>>>>>>>>>>>>>> On 10/4/12, Gary Martin <>
>>>>>>>>>>>>>>> On 04/10/12 16:54, Joachim Dreimann
>>>>>>>>>>>>>>>> On 4 Oct 2012, at 12:01,
Gary Martin <
>>>>>>>>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>> 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

View raw message