Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of joachim.dreimann@wandisco.com
 designates 74.125.82.175 as permitted sender)
Subject: Re: [Apache Bloodhound] #146: Inline editing of objects
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>
 <CAKE9Bs-Zzqk-v-MJiJrYKTbcSXqZYt_voYEWGcsH6fBFMDEbXg@mail.gmail.com>
 <FACE2CA5-E6E4-4A40-9D5E-2E63E4F7CB55@wandisco.com>
 <BECF47E3-5D4B-4366-9045-D4B571E11B29@wandisco.com>
 <CAEZ-ge5LzqChUeZmeN39taiQuLdaj59pfjMdV=7W4rPm4tV3nw@mail.gmail.com>
 <5097D87E.40801@digiverse.si>
 <CAJSKAsjoias5bD59a9vmHukx2JrovS_PerN1EzNvjhHRZc_4cg@mail.gmail.com>
 <50AFC584.7060
 601@wandisco.com>
From: Joe Dreimann <joachim.dreimann@wandisco.com>
Content-Type: text/plain;
	charset=utf-8
In-Reply-To: <50AFC584.7060601@wandisco.com>
Message-Id: <03C75057-3858-495E-9C9F-D6E28401FE8E@wandisco.com>
Date: Fri, 23 Nov 2012 19:15:08 +0000
To: "bloodhound-dev@incubator.apache.org"
 <bloodhound-dev@incubator.apache.org>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)

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 vi=
ew state - to avoid confusion users should only be able to leave the edit st=
ate by submitting or reversing their changes.

That way a submit button in the view state is only needed for the 'new comme=
nt' section.

- Joe

________________________
@jdreimann - Twitter
Sent from my phone

On 23 Nov 2012, at 18:50, Gary Martin <gary.martin@wandisco.com> wrote:

> OK,
>=20
> Given the lack of further discussion, I will attempt to propose a solution=
 that begins to fit the requirements:
>=20
> 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.
>=20
> 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 consi=
dering if this fits with the current mechanisms for guarding against conflic=
ts dues to concurrent edits.
>=20
> Cheers,
>    Gary
>=20
> On 06/11/12 06:08, Peter Ko=C5=BEelj wrote:
>> On 5 November 2012 16:17, Jure Zitnik <jure@digiverse.si> wrote:
>>=20
>>> On 11/5/12 12:44 PM, Gary Martin wrote:
>>>=20
>>>> 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 w=
ant
>>>> that.
>>> +1
>>     +1
>>=20
>>>=20
>>>  I've been using a few developers at apachecon as sounding boards as I a=
m
>>>> worried that things might be more complicated than necessary. The solut=
ion
>>>> 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 edita=
ble
>>>> - and it would be nice to see when a field has been edited too.
>>>>=20
>>>> 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 discusse=
d
>>> in another thread already). As the scroll spy already includes the 'Modi=
fy
>>> ticket' button, clicking that button would enable 'edit mode' which woul=
d
>>> 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 t=
o
>>> enable the 'edit' state and one button for submission.
>>=20
>> +100 :)
>>=20
>>=20
>>>=20
>>>  Other than that, a submit all changes button would probably work well.
>>> +1
>>     +1
>>=20
>>> Cheers,
>>> Jure
>>>=20
>>>=20
>>>  Cheers,
>>>>      Gary
>>>>=20
>>>> On 5 November 2012 10:21, Joachim Dreimann <joachim.dreimann@wandisco.c=
om
>>>> **>wrote:
>>>>=20
>>>>  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 who=
le
>>>>> month on an issue all seemed to agree was important.
>>>>>=20
>>>>> The question remains:
>>>>>=20
>>>>>> 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 f=
or
>>>>> individual confirmation on every field?
>>>>>=20
>>>>>=20
>>>>> - Joe
>>>>>=20
>>>>> On 5 Oct 2012, at 20:10, Joe Dreimann <joachim.dreimann@wandisco.com**=
>
>>>>> wrote:
>>>>>=20
>>>>>  Ok, that sounds like we have a decision: All are in favour of
>>>>> non-immediate saves for edits.
>>>>>=20
>>>>>> Now, should we enable the 'edit' state for all fields using one butto=
n
>>>>> and submit using one button, or should we take Jira's approach of aski=
ng
>>>>> for individual confirmation on every field?
>>>>>=20
>>>>>>  http://www.youtube.com/watch?**feature=3Dplayer_detailpage&v=3D**
>>>>> EsQ__dR6Nrw#t=3D59s<http://www.youtube.com/watch?feature=3Dplayer_deta=
ilpage&v=3DEsQ__dR6Nrw#t=3D59s>
>>>>>=20
>>>>>> I'm bringing up Jira because it's used in a very similar context as
>>>>> Bloodhound.
>>>>>=20
>>>>>> Cheers,
>>>>>> Joe
>>>>>>=20
>>>>>> ________________________
>>>>>> @jdreimann - Twitter
>>>>>> Sent from my phone
>>>>>>=20
>>>>>> On 5 Oct 2012, at 09:29, Peter Ko=C5=BEelj <peter@digiverse.si> wrote=
:
>>>>>>=20
>>>>>>  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 sys=
tem
>>>>>> 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
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Fri, Oct 5, 2012 at 9:52 AM, Gary Martin <gary.martin@wandisco.co=
m
>>>>>> wrote:
>>>>>>=20
>>>>>>>> Olemis Lang <olemis@gmail.com> wrote:
>>>>>>>>=20
>>>>>>>>  On 10/4/12, Branko =C4=8Cibej <brane@wandisco.com> wrote:
>>>>>>>>>> On 05.10.2012 05:17, Olemis Lang wrote:
>>>>>>>>>>=20
>>>>>>>>>>> On 10/4/12, Branko =C4=8Cibej <brane@wandisco.com> wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> On 04.10.2012 18:33, Olemis Lang wrote:
>>>>>>>>>>>>=20
>>>>>>>>>>>>> On 10/4/12, Gary Martin <gary.martin@wandisco.com> wrote:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> On 04/10/12 16:54, Joachim Dreimann wrote:
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> On 4 Oct 2012, at 12:01, Gary Martin <gary.martin@wandisco.c=
om
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>> 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 receiv=
es
>>>>>>>>>>> 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 bu=
t
>>>>>>>>> there are underlying technical decisions that make it impossible t=
o
>>>>>>>>> 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 n=
otice.
>>>>>>>>>=20
>>>>>>>>> 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 . Plea=
se
>>>>>>>>> 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 w=
ork
>>>>>>>>> needed to finish patches  for #146 , please .
>>>>>>>>>=20
>>>>>>>>> ;)
>>>>>>>> This is why we need more decisions to be made here. No one person i=
s
>>>>>>> going
>>>>>> to be right on every decision.
>>>>>>>> For some reason I didn't get the impression from the discussion in t=
he
>>>>>>>> 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 th=
at
>>>>>>> the
>>>>>> changes are not sent immediately but should be submitted with a singl=
e
>>>>>>>> button.
>>>>>>>>=20
>>>>>>>> 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 f=
orm
>>>>>>>> hidden but it should probably be available for js disabled situatio=
ns.
>>>>>>>>=20
>>>>>>>> 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 fie=
ld
>>>>>>> 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 awa=
y
>>>>>>> from
>>>>>> a page when there are edits that are not submitted.
>>>>>>>> Cheers,
>>>>>>>>    Gary
>=20