Kirigami design question

[Thomas Pfeiffer]

On Mittwoch, 30. März 2016 21:06:21 CEST Dirk Hohndel wrote:
> Thomas,

> Based on some of the feedback we have been getting from testers on iOS
> (I'm sure you have seen some of it here) I have been wondering if we
> should consider a change to the Kirigami design...
> 
> Right now the bottom layout shows a right angle/arrow in the lower left
> corner (main drawer), an action button in the center (optional) and a
> left angle/arrow in the right corner (context drawer).

In the current Kirigami version, the symbols for the global and context drawer 
were changed to match those on Android, but that's just a detail.
 
> Would it be possible to have instead the angle for the global drawer plus
> up to four action buttons? The center one could be bigger and be the
> default action, to the right (where we have the context drawer handle) one
> could have a virtual back button, then half left could be an auxiliary
> "positive" action (so "add dive", "do something"), and half right could be
> an auxiliary "negative" action ("delete", "cancel").

We are still considering allowing two more buttons at the bottom (smaller 
buttons to the left and right of the main action button), but I would not 
suggest using them for the purpose you suggest.

I'm still not ready to give up on "swipe to go back" yet, because it should be 
easier to execute - especially when using with one hand - than pressing a 
button at the bottom of the screen.

I know that it can conflict with "swipe to switch between dives" in 
Subsurface's case. On the other hand, the only situation where it would 
conflict is when going back to the dive list, and with the breadcrumb header 
(available in the Kirigami version you are about to port to) and the global 
drawer, users still have two ways to go back to the dive list. Furthermore, 
the fact that you're using swipes to switch between dives means you assume 
that just flicking through them is a much more common action compared to going 
back and forth between dive list and individual dives.

Can you point out where else swipe to go back wouldn't work, or where users 
have reported problems with it (I may have missed that particular feedback)?

As for the "positive action": That is what the Action Button usually does. Can 
you point me to cases where the "positive action" would not be the main 
action?

The way I suggest thinking about action placement (I'll also put that into 
official Human Interface Guidelines once it's proven to work) is:

- Main action / Confirm: Action Button
- Go back / Cancel: Swipe left
- Secondary actions which are almost as commonly executed as the main action: 
Additional buttons at the bottom
- Every other contextual secondary action: Context drawer
- Every global action: Global drawer

> I think this would be more intuitive to iOS users (based on their
> feedback). I also think this is easier to use than having to open the
> context drawer. And at least in the case of Subsurface so far, this covers
> everything we ever need to do.

The context drawer should only be used for less common actions. I got the 
impression that deleting a dive wasn't really a common action, so opening the 
context drawer for it should not be much of a problem. I'd generally not 
suggest to put it right next to the edit button, because even though we have 
the undo action, it can still get annoying if users regularly delete dives 
just because they missed the edit button.

> Of course one could keep this extensible and allow to have the right most
> button instead be one that opens a context drawer after all.
> 
> What do you think? Too crazy? Too cluttered? Or maybe worth a try?

My main feedback is: Seriously give "swipe to go back" another try. It may 
feel a bit strange at first, but it's a pattern which is adopted more and more 
in Android applications and it works pretty smoothly actually.

I'm not completely against putting additional buttons at the bottom, but given 
that they are less comfortable to reach than gestures, I'd only use them if 
nothing else works.

Let's work together on this and see if we can find a better solution. If we 
can't putting a virtual back button at the bottom is still a last resort 
option.

Cheers,
Thomas