Android alpha -832 with experimental mobile components change

Thomas Pfeiffer thomas.pfeiffer at kde.org
Fri Feb 12 13:17:56 PST 2016


On Freitag, 12. Februar 2016 08:55:29 CET Dirk Hohndel wrote:
> > So I'd say that the duplicated controls actually do cause "harm".
> 
> > This is a point where you have to decide:
> Interesting. I hadn't thought of it that way.
> But that causes this question to become MUCH harder.
> It's the ultimate fallacy in software development. It's always easier to say
> "yes" to a new feature, to say "we support both" when there are two ways to
> do things, to "add another preference/option" so each group of users gets
> what they ask for.

Of course it is. Let me tell you me favorite anecdote on this topic:
It was the year 2008 (jeez, how time flies!), I had my first contact with KDE 
just a few months ago through a project called "Season of Usability" (kind of 
like GSoC for usability).
It was at Akademy, the first time I met KDE contributors in real life who 
weren't usability experts.
One maintainer came to us and asked "How do I make this feature usable?". I 
looked at the feature and thought "Why on Earth or anywhere else in the 
universe would anybody want such a feature???". I asked the maintainer that 
(worded a bit differently, of course), and the answer was quite shocking for 
me: 
"It doesn't make much sense to me either, but the guy who wrote the bug report 
requesting it just wouldn't shut up, so eventually I just went ahead and 
implemented it to make him stop bugging us".

> But you are of course right, you create a much stronger user experience by
> saying "we do THIS and not THAT"...

I'm glad that you agree with me there :) 
Let me be clear: I am not against giving users options in general (otherwise 
I'd probably not have lasted long in KDE). Sometimes different users actually 
have different needs, and if there are enough of both kinds of users to 
matter, it can make perfect sense to provide a config option.

What I encounter far too often, however, is giving users an option as "the 
easy way out" of a tough design question, before having put enough energy into 
looking for a design that will benefit the vast majority of users.

> Thanks, Thomas, for giving good advise and increasing the level of
> discomfort and pain for this maintainer.

Always a pleasure, that's what I do :P 
Nobody said making great software was a painless process ;)

> > Either you aim for full consistency
> > with Material Design apps even if it's an ergonomic disadvantage, then you
> > should ditch the handles at the bottom and use only the buttons in the top
> > bar (plus dragging the action button if there is one).
> 
> Well, if we go for full consistency then there is no Action Button, either -
> almost no Material Design applications have that concept.

I beg to differ. For me, the "reference Material Design applications" are 
those made by Google themselves, so let's check those that I have on my phone:
- Photos: has one
- Calendar: yup
- GMail: uh-huh
- Maps: Yessir!
- Google+: affirmative
- Youtube: oh yeah
- News & Weather: Nope (because it's purely for browsing and reading stuff, no 
main action in sight)
- Phone: Yup, and it's even in the center here
- Hangouts: you bet
- Contacts: check
- Downloads: Nope (I'd have no idea what it would do there, anyway)
- Chrome: Nada (people would have killed them if they'd lay a button over 
every website)
- Calculator: Nu-uh (well, it's a calculator. They could have turned the "=" 
button into a FAB, but there would have been no benefit to that)
- Camera: Okay, it's not round and doesn't have a transparent background
- Clock: Ha, another one where it's in the center!
- Docs, Sheets, Slides: Jawoll!
- Earth: No FAB in sight
- Fit: Didn't get to the main view without filling in all kinds of data, so I 
dunno
- Google: None, because all UI it has is that one search field
- Keep: nothing here
- Google Play, Books, Music, Games, Movies: Niente (well, they are store 
browsers, so the only place where they could have used the FAB is for the 
"Install" button in the details page)
- (Google) Settings: Nothing to see here (I wouldn't know what to do with 
there, either)

So, if we count those I've put in one line as one, we have  11 out of 22 that 
definitely have a FAB. In those that don't have one, it would have made little 
sense to use one.

Google uses a FAB everywhere there is a clear primary action (and sometimes 
even where I would actually disagree that there is one, like in Hangouts). The  
difference is that they don't use it as a standard UI element which is present 
in every screen regardless of whether there is a primary action (and in the 
version which is currently in master, our components don't do it anymore, 
either).

> > Or you take the bold step to diverge from the norm for something better
> > adapted to the larger phones we have these days and drop the buttons in
> > the
> > header.
> > There are definitely good arguments for both positions, but you have to
> > make a decision.
> 
> I've played with the new transparent arrows (actually, for us it's now just
> one arrow as we don't have a context menu anywhere). And I must say I
> really like them. I'd go a tiny bit more transparent (maybe 0.4 instead of
> 0.5). But that's bike-shedding.

I wouldn't call that bike-shedding, I'd call it attention to detail. What 
Marco did there was more of a prototype for trying it out, I don't think he 
had the time to optimize transparency values yet, so feedback is surely 
welcome there as well!

> I've been working this morning to make another experimental binary that
> switches us all the way back to "Plasma Mobile" style. Remove the menus in
> the top bar. Make the top bar thinner to make more space available and move
> the actions that we had in the top bar into a context menu.
> 
> Ironically, that's actually the version that gives us the MOST screen real
> estate. Because the areas under the Action Button and the two handles is
> usable (you can see what's there) and a smaller top bar will give more
> space overall.

*g* This is not ironic to me at all, given that one of the core principles 
behind our design was "Space is limited, and content is king." [1], and it was 
exactly that principle which made us want to get rid of a permanent toolbar.
Looks like we have done a good job in that department, then :-)

> And then we can see how the "I want my hamburger menu" camp of our users
> responds.

Seriously: I'd listen to them only if they can provide a reason why they want 
it, and why it's superior to the drag-out handle at the bottom.

> > Heaving a page title at the top makes sense, as long as there are no
> > controls in that hard-to-reach area.
> 
> I think this is where we hear the difference in perception. Some of our
> users (I tried to bounce the emails that weren't copied to you) don't see
> it this way at all. My guess is that they have 4" phones. We actually had
> one user point out that to him the lower corners appear harder to reach
> than the upper corners.

Possibly. One of the users in my test also had a rather small phone where he 
could easily reach the top with one hand.
Another reason could be that they always use their phone with both hands, 
where their ball of thumb may cover one of the lower corners of the screen.

Our design is more optimized for single-handed use. If all else fails, we 
might end up with a setting after all for people who use their phone mostly 
with both hands.

> > The thing is: Whatever you do in user interface / interaction design, you
> > will never make _everybody_ absolutely happy. It's not possible. What you
> > should aim for is a design that makes significantly more people happy
> > than unhappy. That's the best you can do, at least for an application
> > that people use by choice.
> > If you're designing something that everybody _has_ to use without
> > alternative, things are different, but that's really a rare case.
> 
> Yes! We are going to make Subsurface mandatory.
> 
> YU VILL LIKE IIT (spoken with Arnold-style German accent)

*LOL*

[snip]

[1] https://sessellift.wordpress.com/2015/10/15/behind-the-scenes-of-the-kde-phone-hig-part-one-basic-assumptions/





More information about the subsurface mailing list