On 11/5/12 12:44 PM, Gary Martin wrote:
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 want
that.
+1
I've been using a few developers at apachecon as sounding boards as I am
worried that things might be more complicated than necessary. The solution
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 editable
- and it would be nice to see when a field has been edited too.
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
discussed in another thread already). As the scroll spy already includes
the 'Modify ticket' button, clicking that button would enable 'edit
mode' which would 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 to enable the 'edit' state and one button for submission.
Other than that, a submit all changes button would probably work well.
+1
Cheers,
Jure
Cheers,
Gary
On 5 November 2012 10:21, Joachim Dreimann <[email protected]>wrote:
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 whole
month on an issue all seemed to agree was important.
The question remains:
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 for
individual confirmation on every field?
- Joe
On 5 Oct 2012, at 20:10, Joe Dreimann <[email protected]>
wrote:
Ok, that sounds like we have a decision: All are in favour of
non-immediate saves for edits.
Now, 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
for individual confirmation on every field?
http://www.youtube.com/watch?feature=player_detailpage&v=EsQ__dR6Nrw#t=59s
I'm bringing up Jira because it's used in a very similar context as
Bloodhound.
Cheers,
Joe
________________________
@jdreimann - Twitter
Sent from my phone
On 5 Oct 2012, at 09:29, Peter Koželj <[email protected]> wrote:
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 <[email protected]
wrote:
Olemis Lang <[email protected]> wrote:
On 10/4/12, Branko Čibej <[email protected]> wrote:
On 05.10.2012 05:17, Olemis Lang wrote:
On 10/4/12, Branko Čibej <[email protected]> wrote:
On 04.10.2012 18:33, Olemis Lang wrote:
On 10/4/12, Gary Martin <[email protected]> wrote:
On 04/10/12 16:54, Joachim Dreimann wrote:
On 4 Oct 2012, at 12:01, Gary Martin <[email protected]>
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 «evident» 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
going
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
from
a page when there are edits that are not submitted.
Cheers,
Gary
