On 22 Feb 2016 7:57 am, "Thomas Pfeiffer" <[email protected]> wrote: > > On Sonntag, 21. Februar 2016 11:24:46 CET Dirk Hohndel wrote: > > > On Feb 20, 2016, at 10:21 PM, Dirk Hohndel <[email protected]> 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 > [email protected] > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
