Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAGMZAuOUEqpLorfX798UPVZjsGKqfs7P+KxxATCQ6NXroOn5TQ@mail.gmail.com>
References: <058.57224df07188c14f36645fb9758197c6@incubator.apache.org>
	<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.7060601@wandisco.com>
	<CAGMZAuOhi=25NoguqCqr5H0onT0151kFAPir18E0uNt0f=MAdg@mail.gmail.com>
	<50B5086B.1060807@wandisco.com>
	<CAGMZAuOUEqpLorfX798UPVZjsGKqfs7P+KxxATCQ6NXroOn5TQ@mail.gmail.com>
Date: Wed, 28 Nov 2012 11:47:14 +0100
Message-ID: 
 <CAJSKAshvXaxreuAX_xaZoRunMoC99_1RLM6Cf7a2dE_FZZmfCg@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=bcaec554de2ebecda304cf8be368

--bcaec554de2ebecda304cf8be368
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 <olemis@gmail.com> wrote:

> On 11/27/12, Gary Martin <gary.martin@wandisco.com> wrote:
> > On 27/11/12 16:00, Olemis Lang wrote:
> >> On 11/23/12, Gary Martin <gary.martin@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 guardi=
ng
> >>> 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=3Dleave 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 =ABowner=BB leads to the ambiguous situation when there ar=
e
> 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:
>

--bcaec554de2ebecda304cf8be368--