Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
Sender: peter@xlii.si
In-Reply-To: <a945cd9f-734a-4a62-a58e-b44dc36606c9@email.android.com>
References: <058.57224df07188c14f36645fb9758197c6@incubator.apache.org>
	<073.22cbd29bca7f36a5c6331d575709d440@incubator.apache.org>
	<CAGMZAuMtFY4cRmB8UBOp9JwTi8_00zADFZo5zfeiBQj1wusejw@mail.gmail.com>
	<506D6C76.1090505@wandisco.com>
	<102201E8-01B8-4785-A126-F4463B3DBEF5@wandisco.com>
	<506DB268.5060908@wandisco.com>
	<CAGMZAuPbk_oSXZvvBM7zw6dJayWbvno4bKNMTy96iQdb6fEyMw@mail.gmail.com>
	<506DD5FB.80704@wandisco.com>
	<CAGMZAuMD2-o2qGPaoD2U5BTJA0eLgXcssQ2c-aU=P9zSi2A4qQ@mail.gmail.com>
	<506E55AF.7000907@wandisco.com>
	<CAGMZAuNT+Lysf8NDTp6OMch7BkGrgA5gKO8V2=E0cBbzw--pBA@mail.gmail.com>
	<a945cd9f-734a-4a62-a58e-b44dc36606c9@email.android.com>
Date: Fri, 5 Oct 2012 10:29:09 +0200
Message-ID: 
 <CAKE9Bs-Zzqk-v-MJiJrYKTbcSXqZYt_voYEWGcsH6fBFMDEbXg@mail.gmail.com>
Subject: Re: [Apache Bloodhound] #146: Inline editing of objects
From: =?UTF-8?Q?Peter_Ko=C5=BEelj?= <peter@digiverse.si>
To: bloodhound-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=e89a8f23482d75fd0104cb4baad9

--e89a8f23482d75fd0104cb4baad9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 =C4=8Cibej <brane@wandisco.com> wrote:
> >> On 05.10.2012 05:17, Olemis Lang wrote:
> >>> On 10/4/12, Branko =C4=8Cibej <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 =C2=ABevident=C2=BB 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 goin=
g
> 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 fr=
om
> a page when there are edits that are not submitted.
>
> Cheers,
>     Gary
>

--e89a8f23482d75fd0104cb4baad9--