You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Olemis Lang <ol...@gmail.com> on 2012/10/03 21:50:35 UTC
Re: [Apache Bloodhound] #146: Inline editing of objects
On 10/3/12, Apache Bloodhound <bl...@incubator.apache.org> wrote:
> #146: Inline editing of objects
[...]
> Comment (by olemis):
[...]
>
> New features
> are :
>
> 1. Wiki toolbar buttons are usable now
[...]
> 1. In place edits take place and are reflected correctly in the UI .
[...]
At the moment major pending improvements related to this ticket are :
- Decide how to notify in-place modifications (verbose vs quiet ,
configurable ? , ...)
- Do not show «Click to edit» placeholder in assigned wiki textarea fields
- In-place editors for description (+ tags) inside well
- Implement in-place editing for ticket view inside a single component
- Error handling
- Recovery strategy
About the later , there should be informative elements to know whether
in-place submission failed (e.g. on collisions ... ) . What about at
least using validation states [1]_ to highlight in the UI ticket
fields for which submission failed .
.. [1] Validation states
(http://twitter.github.com/bootstrap/base-css.html#forms)
--
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>.
Typo: I actually meant: "... by saving tickets without explicit save
action ..."
On Thu, Oct 4, 2012 at 5:58 PM, Peter Koželj <pe...@digiverse.si> wrote:
> Even if I ignore possible user confusion by saving tickets with explicit
> save action,
> wouldn't this actually trigger multiple ticket change notification and
> create multiple ticket history entries?
>
> Peter
>
> On Thu, Oct 4, 2012 at 5:54 PM, Joachim Dreimann <
> joachim.dreimann@wandisco.com> wrote:
>
>> On 4 Oct 2012, at 12:01, Gary Martin <ga...@wandisco.com> wrote:
>> >> On 03/10/12 20:50, Olemis Lang wrote:
>> >> - Decide how to notify in-place modifications (verbose vs quiet ,
>> >> configurable ? , ...)
>> >
>> > Does this mean that each change individually updates the ticket on the
>> server? I thought that we would be going with users submitting all changes
>> once they are happy with the new state of the ticket.
>> >
>>
>> I would expect every radio button / drop down change to save immediately,
>> users should only need to confirm textfields or similar where incomplete
>> information would be very likely if we save after every letter or when the
>> box loses focus.
>>
>> Joe
>>
>>
>
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Olemis Lang <ol...@gmail.com>.
On 10/4/12, Peter Koželj <pe...@digiverse.si> wrote:
> Even if I ignore possible user confusion by saving tickets with explicit
> save action,
> wouldn't this actually trigger multiple ticket change notification and
> create multiple ticket history entries?
>
yes , that's the case . It also happens that e-mail notification is
sent , of course, *IF* we decide these changes should be notified ,
like it happens after applying the patch . That's why I asked
;)
--
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>.
Even if I ignore possible user confusion by saving tickets with explicit
save action,
wouldn't this actually trigger multiple ticket change notification and
create multiple ticket history entries?
Peter
On Thu, Oct 4, 2012 at 5:54 PM, Joachim Dreimann <
joachim.dreimann@wandisco.com> wrote:
> On 4 Oct 2012, at 12:01, Gary Martin <ga...@wandisco.com> wrote:
> >> On 03/10/12 20:50, Olemis Lang wrote:
> >> - Decide how to notify in-place modifications (verbose vs quiet ,
> >> configurable ? , ...)
> >
> > Does this mean that each change individually updates the ticket on the
> server? I thought that we would be going with users submitting all changes
> once they are happy with the new state of the ticket.
> >
>
> I would expect every radio button / drop down change to save immediately,
> users should only need to confirm textfields or similar where incomplete
> information would be very likely if we save after every letter or when the
> box loses focus.
>
> Joe
>
>
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>
*
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Joachim Dreimann <jo...@wandisco.com>.
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 Joe Dreimann <jo...@wandisco.com>.
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 Peter Koželj <pe...@digiverse.si>.
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 Gary Martin <ga...@wandisco.com>.
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 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 .
;)
--
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 Branko Čibej <br...@wandisco.com>.
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:
> [...]
>>>> I don't like the inconsistency there. Personally I would store up the
>>>> changes, marking which fields are altered in some way and provide a
>>>> means to submit those changes as a set.
>>>>
>>> That's the way in-place editing works [1]_
>>>
>>> .. [1] jEditable # How does in place editing work?
>>> (http://www.appelsiini.net/projects/jeditable)
> [...]
>> Ticket changes should be complete and intentional,
> +1
>
>> not
>> something that happens because some bit of code downloaded from
>> somewhere happens to "work that way".
>>
> I think you are misunderstanding my previous comment . Firstly
> in-place edits happen one at a time , at least that's what they are
> meant to be . What I said should be interpreted as «that's the common
> way of doing things» , not as /me saying «we have to do it that way
> because everybody does» . I did it that way because I was told to do
> it that way . Indeed ...
>
>> 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. Ain't no such thing in an Apache
project. What gives? If you don't agree with someone's ideas about a
feature, surely the thing to do is to discuss the various pros and cons
on this list. The log for that ticket isn't exactly a glaring example,
but it's worrying.
-- Brane
P.S.: Yes I know that BH development is funded. <mentor>Regardless,
things should happen by consensus of project members, clearly expressed
on the mailing list, not because of "told to".</mentor>
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Olemis Lang <ol...@gmail.com>.
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:
[...]
>>
>>> I don't like the inconsistency there. Personally I would store up the
>>> changes, marking which fields are altered in some way and provide a
>>> means to submit those changes as a set.
>>>
>> That's the way in-place editing works [1]_
>>
>> .. [1] jEditable # How does in place editing work?
>> (http://www.appelsiini.net/projects/jeditable)
>
[...]
>
> Ticket changes should be complete and intentional,
+1
> not
> something that happens because some bit of code downloaded from
> somewhere happens to "work that way".
>
I think you are misunderstanding my previous comment . Firstly
in-place edits happen one at a time , at least that's what they are
meant to be . What I said should be interpreted as «that's the common
way of doing things» , not as /me saying «we have to do it that way
because everybody does» . I did it that way because I was told to do
it that way . Indeed ...
> 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 .
[...]
> Right
> now it looks like someone's crowing, "Look ma, no hands!" just before
> they fall on their face.
>
I'd rather say it looks like
kid - Hey ma , what is Polyethylene terephthalate for ?
ma - It's used to produce plastic bottles , like those for soft-drinks ... :)
dad - Oh no ! At Hong-Kong they raise building from the ground up with that
PS: Please decide what you are going to do about this feature so that
I can continue with it . I'm hoping we'll still can reuse at least the
custom visual editors already implemented in submitted patches .
--
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 Branko Čibej <br...@wandisco.com>.
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:
>>>>> - Decide how to notify in-place modifications (verbose vs quiet ,
>>>>> configurable ? , ...)
>>>> Does this mean that each change individually updates the ticket on the
>>>> server? I thought that we would be going with users submitting all
>>>> changes once they are happy with the new state of the ticket.
>>>>
>>> I would expect every radio button / drop down change to save immediately,
> FWIW , that's the way it works now
>
>>> users should only need to confirm textfields or similar where incomplete
>>> information would be very likely if we save after every letter or when the
>>> box loses focus.
>>>
> Text and text area fields submit information on clicking Submit button
> and cancel edits on blur and on ESC key pressed . Nonetheless the
> later is the only way to cancel wiki text area edits because wiki
> toolbar will not work if editor vanishes on blur .
>
>> I don't like the inconsistency there. Personally I would store up the
>> changes, marking which fields are altered in some way and provide a
>> means to submit those changes as a set.
>>
> That's the way in-place editing works [1]_
>
> .. [1] jEditable # How does in place editing work?
> (http://www.appelsiini.net/projects/jeditable)
As someone coming from the version-control world, and because issue
tracking contains /some/ elements of version control if only because it
maintains a history timeline ... I think this sort of thing requires
just a bit more thought than pointing at an implementation of some UI
component. Ticket changes should be complete and intentional, not
something that happens because some bit of code downloaded from
somewhere happens to "work that way".
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).
I very strongly suggest you all take another look at in-place editing
from an issue-tracking functionality and usability point of view. Right
now it looks like someone's crowing, "Look ma, no hands!" just before
they fall on their face.
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Olemis Lang <ol...@gmail.com>.
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:
>>>> - Decide how to notify in-place modifications (verbose vs quiet ,
>>>> configurable ? , ...)
>>> Does this mean that each change individually updates the ticket on the
>>> server? I thought that we would be going with users submitting all
>>> changes once they are happy with the new state of the ticket.
>>>
>> I would expect every radio button / drop down change to save immediately,
FWIW , that's the way it works now
>> users should only need to confirm textfields or similar where incomplete
>> information would be very likely if we save after every letter or when the
>> box loses focus.
>>
Text and text area fields submit information on clicking Submit button
and cancel edits on blur and on ESC key pressed . Nonetheless the
later is the only way to cancel wiki text area edits because wiki
toolbar will not work if editor vanishes on blur .
>
> I don't like the inconsistency there. Personally I would store up the
> changes, marking which fields are altered in some way and provide a
> means to submit those changes as a set.
>
That's the way in-place editing works [1]_
.. [1] jEditable # How does in place editing work?
(http://www.appelsiini.net/projects/jeditable)
--
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 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:
>>> - Decide how to notify in-place modifications (verbose vs quiet ,
>>> configurable ? , ...)
>> Does this mean that each change individually updates the ticket on the server? I thought that we would be going with users submitting all changes once they are happy with the new state of the ticket.
>>
> I would expect every radio button / drop down change to save immediately, users should only need to confirm textfields or similar where incomplete information would be very likely if we save after every letter or when the box loses focus.
>
> Joe
>
I don't like the inconsistency there. Personally I would store up the
changes, marking which fields are altered in some way and provide a
means to submit those changes as a set.
Cheers,
Gary
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Joachim Dreimann <jo...@wandisco.com>.
On 4 Oct 2012, at 12:01, Gary Martin <ga...@wandisco.com> wrote:
>> On 03/10/12 20:50, Olemis Lang wrote:
>> - Decide how to notify in-place modifications (verbose vs quiet ,
>> configurable ? , ...)
>
> Does this mean that each change individually updates the ticket on the server? I thought that we would be going with users submitting all changes once they are happy with the new state of the ticket.
>
I would expect every radio button / drop down change to save immediately, users should only need to confirm textfields or similar where incomplete information would be very likely if we save after every letter or when the box loses focus.
Joe
Re: [Apache Bloodhound] #146: Inline editing of objects
Posted by Gary Martin <ga...@wandisco.com>.
On 03/10/12 20:50, Olemis Lang wrote:
> On 10/3/12, Apache Bloodhound <bl...@incubator.apache.org> wrote:
>> #146: Inline editing of objects
> [...]
>> Comment (by olemis):
> [...]
>> New features
>> are :
>>
>> 1. Wiki toolbar buttons are usable now
> [...]
>> 1. In place edits take place and are reflected correctly in the UI .
> [...]
>
> At the moment major pending improvements related to this ticket are :
>
> - Decide how to notify in-place modifications (verbose vs quiet ,
> configurable ? , ...)
Does this mean that each change individually updates the ticket on the
server? I thought that we would be going with users submitting all
changes once they are happy with the new state of the ticket.
Cheers,
Gary