Kirigami 1.0 feedback

[Thomas Pfeiffer]

On Sonntag, 3. April 2016 23:35:29 CEST Dirk Hohndel wrote:
> > Is deleting a dive using the context drawer so unwieldy that it has to be
> > avoided at all cost?
> 
> I actually have found that it's good that you challenge my ideas here...
> I looked at a bunch of Android and iOS apps and at how they initiate
> actions. Almost no one uses a context menu for actions. It's for odds and
> ends, if it exists at all. And remarkably often it's stuff that's
> redundant or should better be done a different way.
> 
> iOS Mail app has in the "view mail" screen (I guess comparable to our dive
> view) 5 buttons (no kidding) at the bottom (flag, file, delete, reply,
> start new mail), and three buttons in the top (back, previous, next).
> 
> No guestures at all besides scrolling.
> 
> Gmail on iOS has five buttons spread around in the top and along the top
> right (back, file, delete, star, reply), plus a context menu in the top
> right corner (right in the middle between all the buttons) which then
> opens as a kind of drawer from the top to add six more buttons, oddly
> covering two of the existing buttons. It frankly doesn't feel like a
> context menu at all, but like a "here are some more buttons"-button.
> 
> Gmail on Android has four buttons on top: one on the left (back), three
> grouped towards the right (file, delete, mark-unread), then a context menu
> in the top corner (this one opens to a desktop style drop down menu with
> six text selections that all seem things you rarely do... so perfect for a
> context menu, I guess). Then there is another button to star a message
> at the end of the subject line, another button below that (are you still
> with me?) in the third row with the auther to reply and (I kid you not) a
> second context menu with five more options, several of which are redundant
> with some of the other buttons and even entries in the other context menu.

The "desktop style dropdown menu" (it's officially called "overflow") was the 
first thing where we thought "Hey, we can do waaay better than that!", because 
there is no other way to open it than reaching one of the hardest-to-reach 
points on the screen.
The menu drawer can be opened comfortably by edge swipe, but the overflow is 
hidden behind a tiny button.
That was the reason why we decided to use another drawer for the contextual 
actions, with all the niceties it brings with it.

> Do they even have UI designers over there? Wow.

They do, and I'm sure they have very good ones, but they make some decisions 
that I for the life of me cannot explain. I can only blame it on "design for 
committee" and hope that no individual designer ever wanted to end up with 
some of these things.

> G+ app.
> Android. Four buttons bottom row, fifth "main" button above that to the
> right. Another button on top (search), next to it the context menu (only
> three entries: "refresh" (should be gesture), "send feedback", and "help"
> (why are these in a context menu andnot the global menu) and in the other
> corner their global drawer with another five entries in one mode and a
> little button to switch to a different mode with four more options.
> 
> Holy poop.

The G+ app is a mystery to me as well. I bet at least 80% of what people do 
with it is scroll through their feed, 18% are split between commenting and 
writing posts, and the remaining 2% are for some administrative tasks.

I have no idea why one needs so many buttons for that, especially given that 
if there is any app where "content is king" should be the mantra, it's this 
one.

Maybe the designers refuse to accept that communities and collections aren't 
as cool as they think they are and feel they can make people use them more by 
shoving them in their faces.

> Interestingly the layout on iOS is almost identical, only the global
> drawer is needlessly different and has some things that it doesn't have on
> Android and in return is missing somethings it has on Android.

Yay consistency!

> Why am I listing all this.
> 
> Because I need people to challenge me so Subsurface-mobile doesn't end up
> a disaster like this.

We really wanted to keep as many controls out of the way as possible, and keep 
only the frequently used ones in the main UI.
 
> - maximum of three buttons, all in the bottom row. SOLD. Except. See below.
> - one or two menus, global drawer consisten wherever you are, context
>   drawer if we really need it - I really hope I can avoid needing it at
>   all
> - where possible smart gestures to help (like swiping list entries to
>   reveal actions on them)
> 
> BUT (and you knew there would be one): Swipe for "back key" is hard for
> us. We can't really do it when looking at dive details, and it feels
> really alien to iOS users. And the back key on iOS is always, always,
> always, in every app, even the crazy ones, in the top left corner.
> 
> My current thinging is that I may end up doing just that in the iOS
> version. Having a back button somewhere that isn't a corner feels very
> weird when I play with it. I see why you don't want a button in a bottom
> corner. So I think I will just implement my own back key in
> Subsurface-mobile and only enable this on iOS and have it in the top left
> corner. I wish Kirigami would consider that ALL Kirigami apps that run on
> iOS will have this very same situation and just add the standard back
> button on iOS in its standard position - but it's your project, your
> choice.

As I already stated in my reply to sebas: Yes, you have convinced me that a 
back button makes sense for iOS. And yes, having it somewhere in between other 
buttons doesn't feel right, so the usual top-left corner makes sense.
I don't think it should be forced into every application, though. There should 
be a global option to show it everywhere or not.