Design question on "delete dive" [was: Re: new beta and new alpha]

[Rick Walsh]

On 22 Feb 2016 7:57 am, "Thomas Pfeiffer" <thomas.pfeiffer at kde.org> wrote:
>
> On Sonntag, 21. Februar 2016 11:24:46 CET Dirk Hohndel wrote:
> > > On Feb 20, 2016, at 10:21 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> > >> I was a bit disappointed not to be able to delete my bogus dives from
> > >> Subsurface-mobile.  Would that be hard to implement?>
> > > This I don't think I'll get to tonight.
> >
> > So I'm wondering about the user interaction flow for this one.
> > Because I don't want to make it too easy to delete a dive. But I don't
want
> > it to be TOO much of a pain, either.
> >
> > So how about this:
> >
> > user selects the dive - dive details are shown.
> > user decides to delete that dive.
> > context menu (right drawer) contains a "delete this dive"
> > you tap this and then there is a confirmation dialog that slides up
from the
> > bottom of the screen - you have to click "yes, really delete" within 5
> > seconds or it just cancels the delete
>
> > Does that sound reasonable? Too weird?
> > The reason I suggest this is because the Mobile Components contain a
timed
> > dialog with only one option to click on - it looks nice and it does
exactly
> > the interaction I suggest above. So doing this would be fairly straight
> > forward. Whereas doing something else (like a typical pop up with yes/no
> > buttons) would require a bit more digging and figuring out.

I think I'd prefer the timer, but really any method that isn't too
complicated is good. It's necessary occasionally, but don't envisage it
being used all that often. I agree the option should go in the right
drawer. If only one option in the right drawer is odd, we could add a
discard option - particularly if/when Subsurface-mobile is ported to ios,
where there is no Android back button.

>
> The component gallery on Plasma Mobile has a slide-in dialog component
with
> two buttons in it, so there must be something that can do this.
>
> That said, confirmation dialogs are not really a nice user interaction,
since
> they feel like the system doesn't trust the user to know what they're
doing.
>
> What's almost always nicer than confirmation, however, is undo. What we
have on
> Plasma Desktop is that when you remove a widget from the desktop or
panel, you
> get a notification with a big "Undo" button on it.
> In the background, the widget isn't really removed yet until the
notification
> expires. We do the same for deleting manually installed widgets from the
> system.
>
> I'd recommend the same here. While this is not as "safe" as what you
suggest
> (the user might accidentally tap "Delete" and then for some reason miss
the
> undo dialog, but that's quite an unrealistic scenario), it should feel
much
> better for the user. The system executes the command without asking for
> confirmation, but gives the user an easy way to roll back if it was
issued by
> accident.
> If they really wanted to delete, they have to do nothing. If they realize
> deleting isn't what they wanted to do, they just hit the undo button.
>
> It's kind of like "better ask for forgiveness than permission", though in
this
> case it's also better for the one who gets asked (or rather doesn't get
> asked).
>
> This should be done with a notification with an action, though (there is
> definitely a component for that, or maybe that is actually the one you're
> referring to), since a dialog would block the user from doing something
else.
>
Having an undo option would be ideal, but implementing it sounds like a lot
of work.

> > Yeah, I'm lazy. And to be honest, I think that the Mobile Components are
> > very well designed and if they don't contain that typical dialog than I
> > have to assume that's for a reason...
>
> Thank you for your trust in our design :)
> That said: If there is not component for some interaction, I'd not advise
to
> automatically assume that we have explicitly decided against it. The
component
> set is not complete yet.
> In such cases, the safe way would be to ask me or Marco instead.
>
> Cheers,
> Thomas
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160223/a807c731/attachment.html>