You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Joachim Dreimann <jo...@wandisco.com> on 2012/11/05 11:21:29 UTC
Re: [Apache Bloodhound] #146: Inline editing of objects
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 <jo...@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=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 <pe...@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 <ga...@wandisco.com>wrote:
>>
>>>
>>>
>>> Olemis Lang <ol...@gmail.com> wrote:
>>>
>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
>>>>> On 05.10.2012 05:17, Olemis Lang wrote:
>>>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
>>>>>>> On 04.10.2012 18:33, Olemis Lang wrote:
>>>>>>>> On 10/4/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>>>>>> On 04/10/12 16:54, Joachim Dreimann wrote:
>>>>>>>>>> On 4 Oct 2012, at 12:01, Gary Martin <ga...@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
>>>
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Olemis Lang <ol...@gmail.com>.
On 11/5/12, Jure Zitnik <ju...@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
>
>> 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
So far it turns out that we don't need jEditable at all . It seems to
me that we are moving towards an scenario in which existing «Modify
Ticket» is redesigned to look like fields list and then toggle it to
switch back and forth between editable form and initial read only
field / value list .
Did I understand what you mean ?
>>
>> - and it would be nice to see when a field has been edited too.
>>
this introduces some complexities . IMO if edits are canceled
read/only ticket field/value list should be reverted to reflect its
initial state .
>> 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.
>
>> Other than that, a submit all changes button would probably work well.
> +1
>
Well this looks like what I mentioned above , isn't it ?
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Gary Martin <ga...@wandisco.com>.
Joe,
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.
Cheers,
Gary
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 <ga...@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 <ju...@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=**
>>>>>> 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 <pe...@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 <ol...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
>>>>>>>>>>> On 05.10.2012 05:17, Olemis Lang wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 04.10.2012 18:33, Olemis Lang wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 10/4/12, Gary Martin <ga...@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
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Joe Dreimann <jo...@wandisco.com>.
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 <ga...@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 <ju...@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=**
>>>>> 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 <pe...@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 <ol...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
>>>>>>>>>> On 05.10.2012 05:17, Olemis Lang wrote:
>>>>>>>>>>
>>>>>>>>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 04.10.2012 18:33, Olemis Lang wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 10/4/12, Gary Martin <ga...@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
>
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Olemis Lang <ol...@gmail.com>.
On 11/30/12, Joachim Dreimann <jo...@wandisco.com> wrote:
> The look won't change that much, so I'm not sure a wireframe would be that
> helpful. I will restate Gary's last 'reset' email though:
>
[...]
ok . I'll create new patches asap .
Thanks for the feedback .
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Joachim Dreimann <jo...@wandisco.com>.
The look won't change that much, so I'm not sure a wireframe would be that
helpful. I will restate Gary's last 'reset' email though:
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.
*
*
*[ point 5 removed because discussion indicated this won't be necessary ]*
*
*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.
I believe this should be the basis of our work going forward. Specific
details should be decided in the implementation phase.
Cheers,
Joe
On 28 November 2012 10:47, Peter Koželj <pe...@digiverse.si> wrote:
> After 40+ mails on this topic where other things (quick create ticket, app
> links, js fallbacks) in the mix I have lost track of what everybody on
> here visualizes the new "inline" edit ticket should look like.
>
> Maybe we should reset this with a mock or wire diagram for new edit ticket
> and discuss other things like create ticket button in new thread?
>
> Peter
>
> On 28 November 2012 07:59, Olemis Lang <ol...@gmail.com> wrote:
>
> > On 11/27/12, Gary Martin <ga...@wandisco.com> wrote:
> > > On 27/11/12 16:00, Olemis Lang wrote:
> > >> On 11/23/12, Gary Martin <ga...@wandisco.com> wrote:
> > >> [...]
> > >>> 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.
> > >>
> > >> Yes. I notice a gap here (unless I'm missing something ...) , and it
> > >> is related to ticket workflow . Inline edits have to pass through
> > >> workflow . Ideally we could always force `leave` action on in place
> > >> edits but if Modify Ticket section won't be there then what shall we
> > >> do ?
> > >>
> > >
> > > I wouldn't say that changes to the ticket details imply a change of
> > > ticket status within the workflow so I was hoping to leave this as a
> > > separate proposal.
> > >
> >
> > A change of ticket status ? Well , no . You are right . That's what
> > built-in leave action is for . However IMO edits must always pass
> > through workflow . If action=leave nothing remarkable happens though .
> >
> > > However, it does seem worthy of comment as there are a few
> > > inconsistencies.
> >
> > yes
> >
> > > For example, it would be nice to be able to change the
> > > "assigned to" user but the ability to do that is dependent on workflow
> > > too. Meanwhile "reported by" could be considered an in-place edit. A
> > > similar thing happens with the status and ticket type fields that are
> > > close together. The attempts to change the workflow related items would
> > > probably have to either send you to the "Action" control or present you
> > > with the control somehow.
> > >
> >
> > I'd rather prefer to see workflow actions when editing other fields as
> > well .
> >
> > OTOH , editing «owner» leads to the ambiguous situation when there are
> > many choices to assign a ticket to somebody (e.g. info request ,
> > review , assign to , test , ...) . Not to mention and custom workflow
> > actions / controllers and related side-effects happening at once .
> > This makes me wander whether it's better (correct ?) to focus on
> > workflow actions rather than fields when analyzing this particular
> > subject from a user experience perspective .
> >
> > > At this point I really have to see what those with more knowledge of ui
> > > design will come up with though.
> > >
> >
> > beyond UI , or UX ... it may also be about domain / business logic ,
> > and workflow semantics
> > ;)
> >
> > --
> > Regards,
> >
> > Olemis.
> >
> > Blog ES: http://simelo-es.blogspot.com/
> > Blog EN: http://simelo-en.blogspot.com/
> >
> > Featured article:
> >
>
--
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> *
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Peter Koželj <pe...@digiverse.si>.
After 40+ mails on this topic where other things (quick create ticket, app
links, js fallbacks) in the mix I have lost track of what everybody on
here visualizes the new "inline" edit ticket should look like.
Maybe we should reset this with a mock or wire diagram for new edit ticket
and discuss other things like create ticket button in new thread?
Peter
On 28 November 2012 07:59, Olemis Lang <ol...@gmail.com> wrote:
> On 11/27/12, Gary Martin <ga...@wandisco.com> wrote:
> > On 27/11/12 16:00, Olemis Lang wrote:
> >> On 11/23/12, Gary Martin <ga...@wandisco.com> wrote:
> >> [...]
> >>> 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.
> >>
> >> Yes. I notice a gap here (unless I'm missing something ...) , and it
> >> is related to ticket workflow . Inline edits have to pass through
> >> workflow . Ideally we could always force `leave` action on in place
> >> edits but if Modify Ticket section won't be there then what shall we
> >> do ?
> >>
> >
> > I wouldn't say that changes to the ticket details imply a change of
> > ticket status within the workflow so I was hoping to leave this as a
> > separate proposal.
> >
>
> A change of ticket status ? Well , no . You are right . That's what
> built-in leave action is for . However IMO edits must always pass
> through workflow . If action=leave nothing remarkable happens though .
>
> > However, it does seem worthy of comment as there are a few
> > inconsistencies.
>
> yes
>
> > For example, it would be nice to be able to change the
> > "assigned to" user but the ability to do that is dependent on workflow
> > too. Meanwhile "reported by" could be considered an in-place edit. A
> > similar thing happens with the status and ticket type fields that are
> > close together. The attempts to change the workflow related items would
> > probably have to either send you to the "Action" control or present you
> > with the control somehow.
> >
>
> I'd rather prefer to see workflow actions when editing other fields as
> well .
>
> OTOH , editing «owner» leads to the ambiguous situation when there are
> many choices to assign a ticket to somebody (e.g. info request ,
> review , assign to , test , ...) . Not to mention and custom workflow
> actions / controllers and related side-effects happening at once .
> This makes me wander whether it's better (correct ?) to focus on
> workflow actions rather than fields when analyzing this particular
> subject from a user experience perspective .
>
> > At this point I really have to see what those with more knowledge of ui
> > design will come up with though.
> >
>
> beyond UI , or UX ... it may also be about domain / business logic ,
> and workflow semantics
> ;)
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Olemis Lang <ol...@gmail.com>.
On 11/27/12, Gary Martin <ga...@wandisco.com> wrote:
> On 27/11/12 16:00, Olemis Lang wrote:
>> On 11/23/12, Gary Martin <ga...@wandisco.com> wrote:
>> [...]
>>> 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.
>>
>> Yes. I notice a gap here (unless I'm missing something ...) , and it
>> is related to ticket workflow . Inline edits have to pass through
>> workflow . Ideally we could always force `leave` action on in place
>> edits but if Modify Ticket section won't be there then what shall we
>> do ?
>>
>
> I wouldn't say that changes to the ticket details imply a change of
> ticket status within the workflow so I was hoping to leave this as a
> separate proposal.
>
A change of ticket status ? Well , no . You are right . That's what
built-in leave action is for . However IMO edits must always pass
through workflow . If action=leave nothing remarkable happens though .
> However, it does seem worthy of comment as there are a few
> inconsistencies.
yes
> For example, it would be nice to be able to change the
> "assigned to" user but the ability to do that is dependent on workflow
> too. Meanwhile "reported by" could be considered an in-place edit. A
> similar thing happens with the status and ticket type fields that are
> close together. The attempts to change the workflow related items would
> probably have to either send you to the "Action" control or present you
> with the control somehow.
>
I'd rather prefer to see workflow actions when editing other fields as well .
OTOH , editing «owner» leads to the ambiguous situation when there are
many choices to assign a ticket to somebody (e.g. info request ,
review , assign to , test , ...) . Not to mention and custom workflow
actions / controllers and related side-effects happening at once .
This makes me wander whether it's better (correct ?) to focus on
workflow actions rather than fields when analyzing this particular
subject from a user experience perspective .
> At this point I really have to see what those with more knowledge of ui
> design will come up with though.
>
beyond UI , or UX ... it may also be about domain / business logic ,
and workflow semantics
;)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Gary Martin <ga...@wandisco.com>.
On 27/11/12 16:00, Olemis Lang wrote:
> On 11/23/12, Gary Martin <ga...@wandisco.com> wrote:
> [...]
>> 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.
> Yes. I notice a gap here (unless I'm missing something ...) , and it
> is related to ticket workflow . Inline edits have to pass through
> workflow . Ideally we could always force `leave` action on in place
> edits but if Modify Ticket section won't be there then what shall we
> do ?
>
I wouldn't say that changes to the ticket details imply a change of
ticket status within the workflow so I was hoping to leave this as a
separate proposal.
However, it does seem worthy of comment as there are a few
inconsistencies. For example, it would be nice to be able to change the
"assigned to" user but the ability to do that is dependent on workflow
too. Meanwhile "reported by" could be considered an in-place edit. A
similar thing happens with the status and ticket type fields that are
close together. The attempts to change the workflow related items would
probably have to either send you to the "Action" control or present you
with the control somehow.
At this point I really have to see what those with more knowledge of ui
design will come up with though.
Cheers,
Gary
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Olemis Lang <ol...@gmail.com>.
On 11/23/12, Gary Martin <ga...@wandisco.com> wrote:
[...]
>
> 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.
Yes. I notice a gap here (unless I'm missing something ...) , and it
is related to ticket workflow . Inline edits have to pass through
workflow . Ideally we could always force `leave` action on in place
edits but if Modify Ticket section won't be there then what shall we
do ?
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Peter Koželj <pe...@digiverse.si>.
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
<jo...@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 <pe...@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 <ga...@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 <ju...@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 <pe...@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 <ol...@gmail.com> wrote:
> > >>>>>>>>
> > >>>>>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
> > >>>>>>>>
> > >>>>>>>>> On 05.10.2012 05:17, Olemis Lang wrote:
> > >>>>>>>>>>
> > >>>>>>>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>> On 04.10.2012 18:33, Olemis Lang wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On 10/4/12, Gary Martin <ga...@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> *
>
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Gary Martin <ga...@wandisco.com>.
Joe,
If we don't we could potentially provide a site map if it is considered
useful more generally. I quite like that solution, though I could equally
imagine that those links could still be somewhere on the page for no-js
situations. I suppose it could even still be quite discreet. Anyway, we
shouldn't think this through too far. Let's just make sure that there is
some fallback for now.
Cheers,
Gary
On 27 November 2012 17:14, Joe Dreimann <jo...@wandisco.com>wrote:
> I like the fallback for the Quick Ticket button. For the Apps drop down,
> (we should really rename that to *More*) we could alternatively link to the
> site map (do we have a functional site map?).
>
> - Joe
>
> ________________________
> @jdreimann - Twitter
> Sent from my phone
>
> On 27 Nov 2012, at 16:54, Gary Martin <ga...@wandisco.com> wrote:
>
> > On 27/11/12 15:56, Olemis Lang wrote:
> >> On 11/26/12, Joachim Dreimann <jo...@wandisco.com> wrote:
> >>> On 26 November 2012 06:49, Peter Koželj <pe...@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.
> >>> 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.
> >>
> >> Yes . Sometimes javascript solution is not available (e.g. disabled,
> >> blocked by firewalls, unexpected errors ...) and pages should fallback
> >> to non-JS behavior . There are even browsers like Netsurf built
> >> without JS support ...
> >>
> >> {{{
> >> #!sh
> >>
> >> $ apt-cache show netsurf
> >> Package: netsurf
> >> Priority: extra
> >> Section: universe/web
> >> Installed-Size: 1248
> >> [...]
> >> Description: Small portable web browser with CSS and Unicode support
> >> NetSurf is a multi-platform lightweight web browser. Its aim is to
> provide
> >> comprehensive rendering of HTML 4 with CSS 2 in a small resource
> footprint
> >> while remaining fast.
> >> [...]
> >>
> >> }}}
> >>
> >> BTW , some parts of the site are not looking good on Netsurf . If that
> >> deserves some attention , please let me know to create a new ticket
> >> with screenshots .
> >>
> >> Unfortunately at the moment that also means that e.g. mainnav and
> >> create ticket shortcut menus won't work . We should take a look at
> >> that too .
> >
> >
> > Yeah, I suspected as much.
> >
> > Is there a particular reason that these buttons cannot fall back to
> being links? I wouldn't mind the Create Ticket button being a link to
> /newticket with the potential side effect of being able to open /newticket
> in a new tab. Actually, I can't think of a good place for the Apps to link
> to at short notice. Would there be any problems with having all the menu
> items visible, perhaps wrapping when there are too many, when js is not
> available?
> >
> > It does not need to be a particularly beautiful solution, we just need
> to let users access the links that they would otherwise lose. All without
> compromising on the experience for those with js enabled.
> >
> > Cheers,
> > Gary
> >
>
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Joe Dreimann <jo...@wandisco.com>.
I like the fallback for the Quick Ticket button. For the Apps drop down, (we should really rename that to *More*) we could alternatively link to the site map (do we have a functional site map?).
- Joe
________________________
@jdreimann - Twitter
Sent from my phone
On 27 Nov 2012, at 16:54, Gary Martin <ga...@wandisco.com> wrote:
> On 27/11/12 15:56, Olemis Lang wrote:
>> On 11/26/12, Joachim Dreimann <jo...@wandisco.com> wrote:
>>> On 26 November 2012 06:49, Peter Koželj <pe...@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.
>>> 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.
>>
>> Yes . Sometimes javascript solution is not available (e.g. disabled,
>> blocked by firewalls, unexpected errors ...) and pages should fallback
>> to non-JS behavior . There are even browsers like Netsurf built
>> without JS support ...
>>
>> {{{
>> #!sh
>>
>> $ apt-cache show netsurf
>> Package: netsurf
>> Priority: extra
>> Section: universe/web
>> Installed-Size: 1248
>> [...]
>> Description: Small portable web browser with CSS and Unicode support
>> NetSurf is a multi-platform lightweight web browser. Its aim is to provide
>> comprehensive rendering of HTML 4 with CSS 2 in a small resource footprint
>> while remaining fast.
>> [...]
>>
>> }}}
>>
>> BTW , some parts of the site are not looking good on Netsurf . If that
>> deserves some attention , please let me know to create a new ticket
>> with screenshots .
>>
>> Unfortunately at the moment that also means that e.g. mainnav and
>> create ticket shortcut menus won't work . We should take a look at
>> that too .
>
>
> Yeah, I suspected as much.
>
> Is there a particular reason that these buttons cannot fall back to being links? I wouldn't mind the Create Ticket button being a link to /newticket with the potential side effect of being able to open /newticket in a new tab. Actually, I can't think of a good place for the Apps to link to at short notice. Would there be any problems with having all the menu items visible, perhaps wrapping when there are too many, when js is not available?
>
> It does not need to be a particularly beautiful solution, we just need to let users access the links that they would otherwise lose. All without compromising on the experience for those with js enabled.
>
> Cheers,
> Gary
>
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Gary Martin <ga...@wandisco.com>.
On 27/11/12 15:56, Olemis Lang wrote:
> On 11/26/12, Joachim Dreimann <jo...@wandisco.com> wrote:
>> On 26 November 2012 06:49, Peter Koželj <pe...@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.
>>>
>> 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.
>>
>
> Yes . Sometimes javascript solution is not available (e.g. disabled,
> blocked by firewalls, unexpected errors ...) and pages should fallback
> to non-JS behavior . There are even browsers like Netsurf built
> without JS support ...
>
> {{{
> #!sh
>
> $ apt-cache show netsurf
> Package: netsurf
> Priority: extra
> Section: universe/web
> Installed-Size: 1248
> [...]
> Description: Small portable web browser with CSS and Unicode support
> NetSurf is a multi-platform lightweight web browser. Its aim is to provide
> comprehensive rendering of HTML 4 with CSS 2 in a small resource footprint
> while remaining fast.
> [...]
>
> }}}
>
> BTW , some parts of the site are not looking good on Netsurf . If that
> deserves some attention , please let me know to create a new ticket
> with screenshots .
>
> Unfortunately at the moment that also means that e.g. mainnav and
> create ticket shortcut menus won't work . We should take a look at
> that too .
Yeah, I suspected as much.
Is there a particular reason that these buttons cannot fall back to
being links? I wouldn't mind the Create Ticket button being a link to
/newticket with the potential side effect of being able to open
/newticket in a new tab. Actually, I can't think of a good place for the
Apps to link to at short notice. Would there be any problems with having
all the menu items visible, perhaps wrapping when there are too many,
when js is not available?
It does not need to be a particularly beautiful solution, we just need
to let users access the links that they would otherwise lose. All
without compromising on the experience for those with js enabled.
Cheers,
Gary
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Olemis Lang <ol...@gmail.com>.
On 11/26/12, Joachim Dreimann <jo...@wandisco.com> wrote:
> On 26 November 2012 06:49, Peter Koželj <pe...@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.
>>
> 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.
>
Yes . Sometimes javascript solution is not available (e.g. disabled,
blocked by firewalls, unexpected errors ...) and pages should fallback
to non-JS behavior . There are even browsers like Netsurf built
without JS support ...
{{{
#!sh
$ apt-cache show netsurf
Package: netsurf
Priority: extra
Section: universe/web
Installed-Size: 1248
[...]
Description: Small portable web browser with CSS and Unicode support
NetSurf is a multi-platform lightweight web browser. Its aim is to provide
comprehensive rendering of HTML 4 with CSS 2 in a small resource footprint
while remaining fast.
[...]
}}}
BTW , some parts of the site are not looking good on Netsurf . If that
deserves some attention , please let me know to create a new ticket
with screenshots .
Unfortunately at the moment that also means that e.g. mainnav and
create ticket shortcut menus won't work . We should take a look at
that too .
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Joachim Dreimann <jo...@wandisco.com>.
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 <pe...@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 <ga...@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 <ju...@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 <pe...@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 <ol...@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
> >>>>>>>>
> >>>>>>>>> On 05.10.2012 05:17, Olemis Lang wrote:
> >>>>>>>>>>
> >>>>>>>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> On 04.10.2012 18:33, Olemis Lang wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 10/4/12, Gary Martin <ga...@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> *
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Peter Koželj <pe...@digiverse.si>.
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 <ga...@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 <ju...@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 <pe...@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 <ol...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
>>>>>>>>
>>>>>>>>> On 05.10.2012 05:17, Olemis Lang wrote:
>>>>>>>>>>
>>>>>>>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 04.10.2012 18:33, Olemis Lang wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 10/4/12, Gary Martin <ga...@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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Gary Martin <ga...@wandisco.com>.
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 <ju...@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=**
>>>> 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 <pe...@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 <ol...@gmail.com> wrote:
>>>>>>>
>>>>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
>>>>>>>>> On 05.10.2012 05:17, Olemis Lang wrote:
>>>>>>>>>
>>>>>>>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 04.10.2012 18:33, Olemis Lang wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 10/4/12, Gary Martin <ga...@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
>>>>>>>
>>>>>>>
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Peter Koželj <pe...@digiverse.si>.
On 5 November 2012 16:17, Jure Zitnik <ju...@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=**
>>> 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 <pe...@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 <ol...@gmail.com> wrote:
>>>>>>
>>>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
>>>>>>>
>>>>>>>> On 05.10.2012 05:17, Olemis Lang wrote:
>>>>>>>>
>>>>>>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 04.10.2012 18:33, Olemis Lang wrote:
>>>>>>>>>>
>>>>>>>>>>> On 10/4/12, Gary Martin <ga...@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
>>>>>>
>>>>>>
>>>
>>
>
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Jure Zitnik <ju...@digiverse.si>.
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
> 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.
> Other than that, a submit all changes button would probably work well.
+1
Cheers,
Jure
> Cheers,
> Gary
>
> On 5 November 2012 10:21, Joachim Dreimann <jo...@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 <jo...@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=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 <pe...@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 <ol...@gmail.com> wrote:
>>>>>
>>>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
>>>>>>> On 05.10.2012 05:17, Olemis Lang wrote:
>>>>>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
>>>>>>>>> On 04.10.2012 18:33, Olemis Lang wrote:
>>>>>>>>>> On 10/4/12, Gary Martin <ga...@wandisco.com> wrote:
>>>>>>>>>>> On 04/10/12 16:54, Joachim Dreimann wrote:
>>>>>>>>>>>> On 4 Oct 2012, at 12:01, Gary Martin <ga...@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
>>>>>
>>
>
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Gary Martin <ga...@wandisco.com>.
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.
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.
Other than that, a submit all changes button would probably work well.
Cheers,
Gary
On 5 November 2012 10:21, Joachim Dreimann <jo...@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 <jo...@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=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 <pe...@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 <ol...@gmail.com> wrote:
> >>>
> >>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
> >>>>> On 05.10.2012 05:17, Olemis Lang wrote:
> >>>>>> On 10/4/12, Branko Čibej <br...@wandisco.com> wrote:
> >>>>>>> On 04.10.2012 18:33, Olemis Lang wrote:
> >>>>>>>> On 10/4/12, Gary Martin <ga...@wandisco.com> wrote:
> >>>>>>>>> On 04/10/12 16:54, Joachim Dreimann wrote:
> >>>>>>>>>> On 4 Oct 2012, at 12:01, Gary Martin <ga...@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
> >>>
>
>
--
Gary Martin
Lead Developer | WANdisco <http://www.wandisco.com/>
*
*
**
*Join us this October at Subversion Live
2012<http://www.wandisco.com/svn-live-2012>
*