incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@wandisco.com>
Subject Re: [Apache Bloodhound] #146: Inline editing of objects
Date Thu, 04 Oct 2012 18:31:23 GMT
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:
>>>>>    - 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


Mime
View raw message