incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Dreimann <joachim.dreim...@wandisco.com>
Subject Re: [Apache Bloodhound] #146: Inline editing of objects
Date Fri, 30 Nov 2012 16:04:18 GMT
The look won't change that much, so I'm not sure a wireframe would be that
helpful. I will restate Gary's last 'reset' email though:

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.
*
*
*[ point 5 removed because discussion indicated this won't be necessary ]*
*
*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.

I believe this should be the basis of our work going forward. Specific
details should be decided in the implementation phase.

Cheers,
Joe


On 28 November 2012 10:47, Peter Koželj <peter@digiverse.si> wrote:

> 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
> guarding
> > >>> 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=leave 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 «owner» leads to the ambiguous situation when there are
> > 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:
> >
>



-- 
Joe Dreimann
UX Designer | WANdisco <http://www.wandisco.com/>
*
*
*Transform your software development department. Register for a free SVN
HealthCheck <http://go.wandisco.com/HealthCheck-Sig.html> *

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