incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <pe...@digiverse.si>
Subject Re: [Apache Bloodhound] #146: Inline editing of objects
Date Tue, 06 Nov 2012 06:08:44 GMT
On 5 November 2012 16:17, Jure Zitnik <jure@digiverse.si> wrote:

> On 11/5/12 12:44 PM, Gary Martin wrote:
>
>> Individual confirmation on every field? That sounds like the same thing as
>> an immediate save. I think that so far the consensus is that we don't want
>> that.
>>
>
> +1

    +1

>
>
>  I've been using a few developers at apachecon as sounding boards as I am
>> worried that things might be more complicated than necessary. The solution
>> that would seem most efficient would be that all the fields that are
>> editable are considered to be in an editable state already. The problem
>> with this is then how it is made abundantly clear that a field is editable
>> - and it would be nice to see when a field has been edited too.
>>
>> I am not yet convinced that a button to make all fields editable is the
>> right approach at the moment - it seems like a step you shouldn't need.
>>
>
> I think that the ticket could be shown as read only initially, with the
> scroll spy component being visible from start (I think that was discussed
> in another thread already). As the scroll spy already includes the 'Modify
> ticket' button, clicking that button would enable 'edit mode' which would
> replace ticket fields inline (read only for editable) - that is, w/o
> scrolling to the 'Modify ticket' section. So, I would go for one button to
> enable the 'edit' state and one button for submission.


+100 :)


>
>
>  Other than that, a submit all changes button would probably work well.
>>
> +1
>
    +1

>
> Cheers,
> Jure
>
>
>  Cheers,
>>      Gary
>>
>> On 5 November 2012 10:21, Joachim Dreimann <joachim.dreimann@wandisco.com
>> **>wrote:
>>
>>  I notice that there were no replies to my last message (see below) and
>>> the
>>> ticket has therefore been put on hold. We've made no progress in a whole
>>> month on an issue all seemed to agree was important.
>>>
>>> The question remains:
>>>
>>>> Should we enable the 'edit' state for all fields using one button and
>>>>
>>> submit using one button, or should we take Jira's approach of asking for
>>> individual confirmation on every field?
>>>
>>>
>>> - Joe
>>>
>>> On 5 Oct 2012, at 20:10, Joe Dreimann <joachim.dreimann@wandisco.com**>
>>> wrote:
>>>
>>>  Ok, that sounds like we have a decision: All are in favour of
>>>>
>>> non-immediate saves for edits.
>>>
>>>> Now, should we enable the 'edit' state for all fields using one button
>>>>
>>> and submit using one button, or should we take Jira's approach of asking
>>> for individual confirmation on every field?
>>>
>>>>
>>>>  http://www.youtube.com/watch?**feature=player_detailpage&v=**
>>> EsQ__dR6Nrw#t=59s<http://www.youtube.com/watch?feature=player_detailpage&v=EsQ__dR6Nrw#t=59s>
>>>
>>>> I'm bringing up Jira because it's used in a very similar context as
>>>>
>>> Bloodhound.
>>>
>>>> Cheers,
>>>> Joe
>>>>
>>>> ________________________
>>>> @jdreimann - Twitter
>>>> Sent from my phone
>>>>
>>>> On 5 Oct 2012, at 09:29, Peter Koželj <peter@digiverse.si> wrote:
>>>>
>>>>  I too am strongly against inline editing causing auto-save. Ticket
>>>>> changes must be intended and atomical!
>>>>> 1. Tickets are versioned and this messes up the ticket history
>>>>> 2. Multiple ticket notifications get sent out
>>>>> 3. Any ticket statistics get incorrect
>>>>> 4. In bigger enterprise environments tracking systems are integrated
>>>>>
>>>> with
>>>
>>>> other infrastructure, which means unintended inconsistencies are
>>>>>
>>>> propagated
>>>
>>>> to other systems as well
>>>>> 5. Companies will offen grant their customers access to tracking system
>>>>>
>>>> and
>>>
>>>> last person that I want to burdon with this, is my client.
>>>>> 6. If this works only for half of the tickt's fields, it is
>>>>>
>>>> inconsistent!
>>>
>>>> And the problem will just be worse when we try to get rid of that
>>>>>
>>>> "Modify"
>>>
>>>> section.
>>>>>
>>>>> I do find the proposed concept appealing for things like user
>>>>>
>>>> preferences
>>>
>>>> but even for that we would need to weight pros and cons.
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Oct 5, 2012 at 9:52 AM, Gary Martin <gary.martin@wandisco.com
>>>>>
>>>> wrote:
>>>>
>>>>>
>>>>>> Olemis Lang <olemis@gmail.com> wrote:
>>>>>>
>>>>>>  On 10/4/12, Branko Čibej <brane@wandisco.com> wrote:
>>>>>>>
>>>>>>>> On 05.10.2012 05:17, Olemis Lang wrote:
>>>>>>>>
>>>>>>>>> On 10/4/12, Branko Čibej <brane@wandisco.com>
wrote:
>>>>>>>>>
>>>>>>>>>> On 04.10.2012 18:33, Olemis Lang wrote:
>>>>>>>>>>
>>>>>>>>>>> On 10/4/12, Gary Martin <gary.martin@wandisco.com>
wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 04/10/12 16:54, Joachim Dreimann wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4 Oct 2012, at 12:01, Gary Martin
<gary.martin@wandisco.com
>>>>>>>>>>>>> >
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 03/10/12 20:50, Olemis Lang wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>> As a user using a web application with the server
50 hops away
>>>>>>>>>> with
>>>>>>>>>>
>>>>>>>>> a
>>>>>>>
>>>>>>>> 1.5 second ping time, I'd be very, very pissed off if every
click I
>>>>>>>>>>
>>>>>>>>> make
>>>>>>>
>>>>>>>> generates a POST request to somewhere; even if it's an async
XHR
>>>>>>>>>>
>>>>>>>>> (even
>>>>>>>
>>>>>>>> worse! then I don't know in what order the server actually
receives
>>>>>>>>>>
>>>>>>>>> the
>>>>>>>
>>>>>>>> requests).
>>>>>>>>>>
>>>>>>>>> ... if you take a look at #146 attachments you'll notice
that my
>>>>>>>>>
>>>>>>>> first
>>>>>>>
>>>>>>>> proposal included submit button for select fields . I was
told to
>>>>>>>>> revert that .
>>>>>>>>>
>>>>>>>> Hmm. "Told to" implies hierarchy.
>>>>>>>>
>>>>>>> ... or respect to the opinions of the experts , and Joachim is
the UI
>>>>>>> expert . When I have radical objections to other people's thoughts
>>>>>>> and
>>>>>>> ideas (e.g. on the subject of WikiMacros ) or even when I agree
but
>>>>>>> there are underlying technical decisions that make it impossible
to
>>>>>>> realize some ideas then I express my opinion . This time I don't
>>>>>>> think
>>>>>>> it was the case . /me studying and learning about UI design ,
etc ...
>>>>>>> but that's just work in progress . Hence most of the time I won't
>>>>>>> criticize UI decisions beyond «evident» issues I might notice.
>>>>>>>
>>>>>>> So to clarify my position , in this particular case i.e. #146
, I
>>>>>>> declare myself a completely happy neophyte and *so far* I have
no
>>>>>>> strong arguments in favor or against any of both approaches .
Please
>>>>>>> get to an agreement . In the meantime , if I have something to
say
>>>>>>> I'll say it . Just let me know what needs to be done to continue
work
>>>>>>> needed to finish patches  for #146 , please .
>>>>>>>
>>>>>>> ;)
>>>>>>>
>>>>>> This is why we need more decisions to be made here. No one person
is
>>>>>>
>>>>> going
>>>
>>>> to be right on every decision.
>>>>>>
>>>>>> For some reason I didn't get the impression from the discussion in
the
>>>>>> ticket that it would result in immediate edits. If more people were
>>>>>> watching the discussion, this might have been caught earlier as
>>>>>>
>>>>> something
>>>
>>>> that people would frown upon. Maybe.
>>>>>>
>>>>>> Anyway, personally I want to see in-place edits implemented such
that
>>>>>>
>>>>> the
>>>
>>>> changes are not sent immediately but should be submitted with a single
>>>>>> button.
>>>>>>
>>>>>> I would probably be attempting to effectively use the existing form
to
>>>>>> send the data - I suspect that at some point we will want the old
form
>>>>>> hidden but it should probably be available for js disabled situations.
>>>>>>
>>>>>> For me, that would be enough work on the ticket. After that we can
>>>>>>
>>>>> build
>>>
>>>> on that work with things like indicating which fields are edited and
>>>>>> perhaps making it easier to comment on the changes (the comment field
>>>>>>
>>>>> is
>>>
>>>> way down the page on long tickets). I would also be interested in
>>>>>>
>>>>> whether
>>>
>>>> people would want to see a confirmation that the user should move away
>>>>>>
>>>>> from
>>>
>>>> a page when there are edits that are not submitted.
>>>>>>
>>>>>> Cheers,
>>>>>>    Gary
>>>>>>
>>>>>>
>>>
>>
>

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