Kirigami 1.0 feedback

[Dirk Hohndel]

On Mon, Apr 04, 2016 at 03:02:05AM +0200, Thomas Pfeiffer wrote:
> On Sunday, 3 April 2016 11:42:31 CEST Dirk Hohndel wrote:
> 
> > Well, doesn't need to be blurred home screen. Could be the blurred copy of
> > what you are moving. Or just an oddly shaded area. Just so it looks
> > intentional.
> 
> Yes, and our visual designer is already working on a background image/pattern 
> for that :)

+1

:-)
 
> > > I would let it to be three at most..
> > 
> > I'd like at least four so I can replace the context menu spot with a single
> > button instead
> 
> Having a drawer handle on one side but a single button on the other side could 
> look and feel unbalanced, and could lead to a downright confusing situation 
> should you, at any point in the future and at any point in the application, 
> ever need at least one more button and therefore a context drawer, because 
> then the same thing would in one screen execute an action but in another open 
> a drawer.
> 
> 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.

Do they even have UI designers over there? Wow.


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.

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.


Why am I listing all this.

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

- 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.

/D