AquaMail Forum
English - Android => General Discussion => Topic started by: g6agarwal on October 09, 2014, 10:35:39 pm
-
Android l is coming within 2 or 3 weeks will aquamail UI also change after that update??
And will scope for further enhancements in app increase in android l?
Just general discussion!!
-
Some work needs to be done I think. Kostya could say how much time it would cost.
-
Yeah, I know that it will -- nobody's going to move the pre-Christmas shopping season -- but the current emulator images are still looking kind of rough.
What are your expectations from Aqua on Android L?
- Should every message you've read show in the "recent items" list (formerly known as "recent apps")? My understanding that every web browser tab will (based on info from Google I/O).
- "Master button" on every screen rather than the current action bar (icons) along the bottom? What is that *one* action? Compose? Refresh? Search?
-
You're only saying it because you've discovered "pull to refresh" :)
So you're actually OK with easy access to just one action? And extra steps for all the others?
There is a joke here in Russia about Google's idea of a perfect UI -- and it predates Android L by a few years -- a single button labeled "do this thing I need done".
Corollary -- no, *perfect* UI has no buttons at all, and "this thing you need done" is already done.
:)
-
Good joke by Mr. Kostya.. Well i voted for search option.
Just wondering how lock screen notification for aqua work.. What content will be displayed like sender name, subject, etc
I found something regarding material design may be helps others.
http://designmodo.com/material-design-resources/
-
That was not a joke.
Read the design guide -- it promotes the idea of having one "master button" -- for the screen's "primary action".
This means -- other actions will not be accessible as buttons, and will take more taps to get to.
For example, the "select all" button, refresh, or search (in a folder).
Taking "select all" as an example. I get questions on how select "all" messages at once, so more taps is a big deal to those users -- and adding even more, does it seem like a joke?
Material design guide is also "preliminary" and has inconsistencies. Let's talk about selection again:
http://www.google.com/design/spec/patterns/selection.html
"long-press and two-finger touch may be extended by a drag gesture to select multiple items when initiating selection"
Long press and drag is already used in Android for drag and drop, since 3.0.
And about those buttons again -- "icons along the bottom in portrait mode" first appeared in Android 4.0, and it still works in 4.4.
In Android L preview, it doesn't work when using the "material theme". I did report this as a bug a few months ago, it's still not fixed in the preview build from a few days ago.
Does this mean that "icons along the bottom" are gone? So I'll be *forced* to use "one big button per screen" (and at most two buttons along the top) layouts? Existing users won't be happy. Still funny?
Sure, I can join the choir, just watch me --
"With Android L, Google makes a bold departure from old and rusty design metaphors, and breaks through into the world of brand new, intuitive, appealing design that combines intuitive usability with pleasing aesthetics"
-- but when you start working through the details, it just doesn't seem so shiny anymore.
-------
On the other hand -- I don't understand what *specifically* users expect from "Android L and material design", other than "oh, it's Android L and material design"? Anything?
I did understand how with Android 3.0, it became possible to write apps with side by side layouts. I've done that. Then swiping became fashionable, ok, here it is (navigation drawer, message actions).
But the notion that computer interfaces are supposed to mimic layers of paper, with ink "under" and "above", and sliding pieces everywhere...
Huh?
Maybe I'm just too dumb.
-
Not dumb at all Kostya. I've got no interest in Android L or material design per se. Just interested in having an efficient user interface over a reasonably fast OS.
One big button? What a moronic idea. What's the 'primary action' when you're reading an email - mark read, delete, forward, reply? (Unless Google has had a breakthrough on telepathic buttons of course.)
Frankly, the current user interface on AM is pretty darn good on both phone and tablet. Side by side on the tablet is a really obvious development for larger screens and the way you've implemented swiping makes a lot of sense - except I still use that old-fashioned row of buttons on the bottom of the screen myself.
Please don't give in on this one!
-
@Paris Geek --
Yes, I've seen how EverNote does it. Their animation is very nice.
But all you've done is made the "overflow button" (three dots) float -- so it overlaps the window content -- and by doing that, added a bit more space for content along the bottom.
So it's a tradeoff -- but:
While the "regular menu" is cleanly separated from window content, that is, no overlapping -- a floating "big button" will overlap 1) account and folder message counts 2) stuff in message lists 3) message text.
It is possible to animate the "big button" away upon content scroll (see Google+), but now you're making the user do additional stuff (i.e. scroll just to make the button animate away), which wasn't necessary before.
And don't forget that "material" title bar is thicker than before (56dp vs. current 48dp), so there is more space taken away at the top.
Those are just some of the specifics that come to mind -- and to me, they make the whole idea very questionable.
Devil's in the details, and I can see him grinning.
Why does it work in G+?
1 - The stuff that the "big button" can overlap with is fairly large -- and not being able to see some of it is not a big loss. Compare this to overlapping a portion of message text or message list items, different, isn't it?
2 - The "feed" screen always has enough stuff for scrolling -- which is what makes the big button move away. Compare this with a message or a message list that happens to end at the bottom of the screen, far enough to overlap, and not far enough to warrant scrolling, again, quite different, no?
@grumpy --
Can you be more specific? What are you finding inefficient in the user interface right now?
-
@ Kostya
What am I finding inefficient in the user interface right now? Nothing! it was the usual British understated way of saying 'good job, old chap!'
It was also a plea not to go for the 'one big button' approach. I don't know how much discretion you have as a developer once Android (HEL)L rolls out but I'm a great believer in 'if it ain't broke don't fix it'. Had a look at some of the screenshots posted by Paris Geek - yuk! (sorry PG). I completely agree with your response.
-
Chacun a son gout, I guess - as ever!
-
I too like the new design. I agree with Mr geek.
-
... except I can't tell the "new" G+ from the "old" G+...
The "one big button thing" in G+ is nice, but -- in my view -- it works for a specific reason, and I tried to explain it above.
Yes, it moves away, and the animation is smooth (by the way, what are we discussing exactly -- how smooth or how functional that UI is?), but when this "big button" overlaps something important (e.g. text in the message list), then you're forcing the user to perform additional actions (scrolling).
Forcing the user to do more stuff, to get the same thing done, is a step backwards, and I don't care if it's called Android L or Immaterial Theme, or what.
So, bottom line -- not difficult to do, but doing it in the same way as in G+ would be a step backwards in user convenience (once he/she gets past the initial "woo-hoo, that's an effing big button!").
Needs more thought.
Now, the title bar... Yes, have seen it, looks nice. BTW - if you scroll up and down quickly enough, you'll see gaps between the title bar and the expandable panel below it.
BTW, anyone seen this?
https://plus.google.com/111661559774274998746/posts/UhhaZruMGBs
-
...
BTW, anyone seen this?
https://plus.google.com/111661559774274998746/posts/UhhaZruMGBs
Yes, I have seen your post and Screenshots. Looks very nice.
-
For what it's worth: I agree with your arguments about ergonomics, Kostya, and vote to keep the buttons.
I am always in favor of ergonomics rather than looks.
-
If I can just think of a way to combine the two...
BTW -- the SDK for Android L is supposed to go final tomorrow.
I'll see if they kept the ability to put that icon bar along the bottom -- when using the new "Material theme". Was broken in all preview versions.
-
I found some screenshots from "Android L's" Gmail app which I attach here.
-
That one looks to be Gmail. The news are from end of June.
http://phandroid.com/2014/06/25/android-l-google-apps-material-design/
The "regular" Email in Android 5.0 doesn't want to run at all. Crashes immediately after adding an account.
https://code.google.com/p/android/issues/detail?id=77634
But enough to notice that it's yellow, not cyan.
-
That one looks to be Gmail. The news are from end of June.
http://phandroid.com/2014/06/25/android-l-google-apps-material-design/
...
That's right...
-
Hey look what I found on them Interwebs...
( yep, the shadow is wrong, but I only had 15 minutes for messing with some XML files )
-
Well without bottom action things become more complex.
Like select all, read unread etc,
We have to do more steps to do all these right?
Or we can say swiping will be more usable after this.. But for option like select all and mark as read, delete etc how will it work.??
I appreciate these festiv colour themes and thanks for Mr kostya for this. but this ONE BIG BUTTON IS HORRIBLE as for usage purpose.
Well as Mr kostya posted google closed his bug report so we will have to make our mind for this ONE BIG button or there is other way out?
-
Let's consider the message list screen.
"New message" can float.
Refresh and search can be icons in the top bar (yes, there is pull to refresh, but it's nice to have a button too, I think).
This leaves "select all" -- and I've been thinking about a gesture, a vertical swipe like pull to refresh, but on the left side, over the contact images / checkboxes.
I'll *have* to do the floating button, but will be able to make it optional on Android 4.0 - 4.4 (keeping the current "icon bar on the bottom").
-
... uuh
Anyone aware of this matter with Android 5.0 — Lollipop:
Android L is for Lockdown
http://www.xda-developers.com/android/android-l-lockdown/