Google should do this for regular Android APIs. The frequency you have to look up special-android-things is stunning –> disrupts your flow = very bad
There are way too many things you have to keep in your head on Android to get things right (https://developer.android.com/guide/components/images/activi...). The approach Google took here - do what ever you want, we won't tell/force you, is pure wrong (I'm a bit exaggerating, but still).
Developers wasted millions of hours of dev-time and therefor money to figuring out how to do basic things, like saving application state when the device is rotated or another app comes to foreground (testing state-changes is also complicated). There were complains about how state-saving is handled, but Google ignored them for many many years. Every platform has good and bad points, acknowledged, but not having a clear-line, a way how things should be done, is to me indecisive leadership and a very big mistake I would not have expected from Google.
Last AndroidIO things got better with the introduction of so called "Architecture Components" (among other things a SQLite ORM and guide how basic things should be done, finally). I wonder what took them so long.
Hi, I work for Google on Android developer UX, including Architecture Components and the Support Library. Looking to collect as much feedback as I can. Requirements+approach+pain points preferred, but if you prefer to just vent I'll also take it as data. Thanks, and sorry to spam the thread.
For a start, the image that thibran posted could be fixed. It isn't consistent about whether the bordered rectangles represent represent onFoo() calls or the state after their calls.
The page it comes from says « the colored ovals are major states the Activity can be in ».
There should be a coloured oval for the (rather common) state where the Activity is the background after onStop(), and the two arrows coming out of onStop() should come out of that oval.
my last Android dev job was two years ago, I try my best to give you some feedback. Lets start with expectations. I expect that tasks performed by the majority of Android developers are actively supported by Google and are as easy as possible, with as few code lines as possible.
# REST - A lot of apps consume REST APIs. REST is almost the standard way to communicate with the outside world. Therefor the Android framework should include APIs to consume and send REST-requests and parse JSON easily (a support-rest lib would be nice, too). Depending for one of the main use-cases on third-party software is not okay.
# SQLite - Android really needs a support-sqlite library. Right now you have to use SQL features of the lowest supported api level, which means you are stuck in the past (if you want to stick with the default).
# Permissions - https://developer.android.com/training/permissions/requestin... - Handling permissions for older and new devices is a nightmare. I would expect to be able to declare the need for a certain permissions in – lets say 10 seconds – but figuring out how to get the permission bits right took fare longer (maybe 1 hour) and if I had to do it again, it would probably need again one hour. Instead of half a screen of boilerplate code and an activity-callback like onRequestPermissionsResult(), it would be nice if there where a PremissionBuilder, which would allow to easily setup permissions (spreading code all over the activity to do a basic thing is not that great).
# Cache - https://developer.android.com/topic/performance/graphics/cac... - Almost every dev needs & should cache data to improve app responsiveness and use the network less... To my knowledge there is no easy >>general<< caching mechanism in Android (maybe support-cache in the future ??). There is LruCache, but using it means almost writing all caching stuff yourself. Okay, there is Glide for images, which should probably be part of Android, but beside of that, void :). What would I expect? An API which lets you declare how something should be fetched, how many bytes/how long it should be in memory and if and how it should be saved to disk. Caching is such a general problem, I wonder why it hasn't been solved long time ago (we don't need the perfect solution, we need a solution – since it's such a common problem I don't feel like its my job as app-dev to solve it, I can, but I shouldn't do it).
# Effects/Transitions - During my Android years creating custom effects was very complicated and frustrating. Opening Qt Quick Designer for the first time and seeing how easy it is there, I was kind of shocked.
# Outdated information/blog posts - When researching a topic it is very easy to come along outdated knowledge. This is a real problem, since you don't know what you don't know. Sometimes I did things, just to learn later that there is a newer/better Android API. Since Google has not much control over it, I would suggest that Google keeps track of their own blog posts/articles and move them after some time into an archive or put a big (orange) banner on top of them, telling the reader that the content is outdated. Managing the produced textual output might be boring, but it seems to be necessary. I don't know if any company has ever done something like this... but, it would be great.
# Android takes up too much time & attention - Its difficult to describe the cause, but overall I felt like I did fight way too much with the framework, even after years of experience with it. I never had the time to care about things like battery saving APIs and such. It's sad and I wish I could have spend some more time following best-practices. Overall I think Android has to become simpler, I assume most people don't spend a huge amount of time learning all the bits of a given topic, they just want to get things done. Fare too often you have to know hell of a lot of things in Android, write a lot of code, like for RecyclerView with a custom Adapter (most people probably need a custom adapter, even the example is already cluttered) https://developer.android.com/training/material/lists-cards.... ... it's just too much code for such basic functionality.
# Android Studio UI
... has too many buttons, even for things like copy & paste, back & forward and may other buttons, I doubt those are use that often (we are experts, not computer novices). I know I can customize the UI, but still I wish the default was less overloaded :)
I acknowledge the huge amount of work Google did to make Android better over the years and things got really better. The introduction of the support library was stellar, thanks!
</brain-dump>
Going back and forth between Android's SDK and docs and Apple's for iOS is like alternating between navigating a labyrinth with a floor of hot coals and, somewhere, the howls of wolves, and relaxing in a nice warm bath with a glass of wine and a good book.
The converse side of this is when you do hit something that isn't covered by the iOS documentation (and also can't find some random WWDC talk) you are completely stuck with no avenue to find out the answer, whereas with Android you can pull up the AOSP source and often find the answer to the question yourself.
As someone about to take the plunge into mobile development (and slightly leaning towards iOS over Android), I'd love to hear some elaboration on your experiences.
Really? Because as an Android developer I have the exact opposite experience - navigating around Apple's iOS documentation feels like digging through obsolete webpages where bunch of parameters and methods aren't documented at all (especially around bitmap processing and some other older APIs).
Google has some of the worst UI/UX. For all the other great stuff they do, this is one area where they really shouldn't be teaching others but learning from them.
From the barely usable Gsuite admin console to the indecipherable API docs (and developer console), I can't think of a single product where I can intuitively find the setting or option I'm looking for.
Not to mention they often miss the most important thing to the developers: what the developers can do with the exposed API. The Google Plus API was super locked down, for example, you could only post actions from your app from some pre-approved list. That's very limiting. If a developer came up with something cool, like say trading cards, there likely wouldn't be a verb for them. Facebook was much better in that you could post anything, but had to go through app approval.
I don't think the article's methods would be very good re fixing this since when they asked developers to accomplish goals with the API and tracked them, they already decided what would be written.
I have to agree, but some products are still really great and have only improved over time. Gmail and Search come to mind.
Material design, while pretty, doesn't hold up usability-wise for all applications. It's a case where the consistency of switching between Google products is improved but at the cost of usability and UX of each individual product.
Funny this should come up - This past month I've been exploring building web apps using http://www.material-ui.com/. They have some of the best documentation I've ever seen for a front end framework. Easy code examples right in the component that you can play with and then peek at the source code.
It makes such a difference to be able to see the output and then quickly look at the source code. Really wonderful development experience.
I'm glad that Google is thinking along these lines - as an amateur coder, I often find the UX of some of their products (e.g. AppEngine, YouTube API) terrible, often related to documentation not actually being comprehensive enough.
And further, if only the Pandas team would also think about this a little more - surely the most frustrating, least intuitive module I've ever had the misfortune to encounter in Python.
I often joke how google's documentation is the perfect example of documentation written by geniuses / very smart people.
Often you find the way the API is designed more complex than it should/could be, and documentation missing to things that might not be so obvious for everyone.
Google maps is also a good example of such API that has a stiffer-than-required learning curve imo.
I'd expect documentation-only-for-very-smart-people to be complete, correct, and rigorous, but lacking in examples, rationale, and perhaps organisation.
That's not at all what I see in the documentation for Google's public libraries and frameworks.
>surely the most frustrating, least intuitive module I've ever had the misfortune to encounter in Python.
Interesting... I've had the complete opposite experience. I've found it to be pretty intuitive and easy to use. Some of the documentation could certainly be better.
Never heard of Flutter (https://flutter.io/) till now. I hope the project succeeds. I just don't think React Native is the way forward. And native everywhere is just costly for smaller teams/solo devs. All the best to Flutter!
Given the increasingly poor state of some of Google's biggest properties (YouTube is a prime offender, its user experience only ever seems to get worse) I'm obviously surprised to hear this.
To be fair, this post is about Google's UX for developers, which is admittedly very good. The APIs and supporting documentation and guides for many of Google's properties usually do an excellent job at appealing to skill levels that range from beginner to expert.
Google has tens of thousands of employees. It's also an incredibly diverse place where all kinds of mindsets manifest in different products and publications.
The chromecast experience is awful for me. I think the assumed I'd only ever have one youtube tab open but that's now how I use youtube. I Ctrl/Cmd Click videos, have lots of window open, want to be able to add and/or control the chromecast youtube playback from all tabs but only one is active and even then it's pretty awful. No way to set the playback position if you've gone off looking for more videos to play back. If you're watching any kind of lectures/ted talks or anything else that you'd like to playback at a faster speed there's no way to do it.
it's also super flaky often getting lost/unresponsive. I have to manually disconnect chrome, close all the youtube tabs and start over.
Other non-chromecast youtube issues are the fact that it knows everything I've watched but still 5% to 25% of the stuff it's recommending is stuff I've already watched. If they want me to watch more it really needs to be 100% new stuff.
The hidden ways to find my own videos or playlists always drive me nuts. Because the UI changes based on width the options disappear.
Another minor grievance, playlists with deleted videos don't show the titles. I have playlists with missing videos. I'd like to know what I lost. The name of the deleted video would be super helpful.
A major one for me is the volume controls on chromecast. Chromecast is built into my TV (Sony Android). The issue is no device I've ever owned in my life controls the TV volume from the device. Instead at most it controls it's own output level to the TV but the TV itself controls its own volume. So, the Chromecast youtube experience is that the volume control in the webpage directly controls the TV's volume. You can imagine this has woken up my neighbors serval times late at night when it decides to set my TV at full volume
When I open a video for watching it later, I pause it immediately when I expect the initialization of the player to be finished. The player has a bug that makes it resume playback when the initialization has actually finished in the background.
YouTube remembers where you stopped watching a video.. sometimes. Maybe. Usually it just plays from the beginning anyway.
The "already seen" marker on a thumbnail is very often missing.
Recommendations are awful.
Subscriptions have been broken intentionally so that you just see a subset of the new videos. Many YouTubers are warning about this problem.
YouTube unsubscribes people randomly from channels and denies that this actually happens.
The volume control slider is hidden by default for no reason.
The bar with the video controls overlaps the video content for no reason. It could simply be placed below the video and be always visible. The current design only makes sense in fullscreen mode. This is an example for harmful consistency in UI design.
Comments are often toxic, and there doesn't seem to be a way to fix that.
It's impossible to know without watching something whether it's full of swearing or homophobic / misogynistic / transphobic hate speech.
Ads are not targeted to the actual viewer, but to some combination of regular browser user and main youtube user. this means that children will be shown ads for alcohol or gambling. (note this goes against what Youtube says here about complying with local law: https://support.google.com/adwordspolicy/answer/6012382?hl=e... Note that this is something all ad networks get wrong, and it's likely they're going to see regulation in the uk at some point if they don't fix it.)
It's hard to know before clicking a link whether it's sponsored content or not. (in the UK sponsored videos need to be clearly identifiable before the user clicks the link or clicks play. in the US sponsored content needs to be clearly identified).
If two people (eg a parent and their child) watch Youtube the recommendations fail hard. If a single person watches youtube the recommendations are pretty poor.
As a visitor, I want to watch a video that someone linked.
The chance that I first want to see a non-skippable video (or video skippable only after 5 seconds) is vanishingly small yet that's what the YouTube UX frequently provides.
my favorite google ux story is that the "ux study" behind drive.google.com switching to some weird, pseudo filesystem with double click to open (in a webpage!) was based on a user study with 12, twelve, participants. half of them were not completely dumbfounded by a web page that required you to double click to interact with an element. not completely dumbfounded meant that they either clicked twice initially (2 IIRC), or clicked once, waited fewer than 5 seconds, and then tried double clicking.
the big joke, at least while I was there, was that ux for random tools kept changing because they kept hiring ux engineers who needed to change something, anything, just to get promoted.
Readit News
There are way too many things you have to keep in your head on Android to get things right (https://developer.android.com/guide/components/images/activi...). The approach Google took here - do what ever you want, we won't tell/force you, is pure wrong (I'm a bit exaggerating, but still).
Developers wasted millions of hours of dev-time and therefor money to figuring out how to do basic things, like saving application state when the device is rotated or another app comes to foreground (testing state-changes is also complicated). There were complains about how state-saving is handled, but Google ignored them for many many years. Every platform has good and bad points, acknowledged, but not having a clear-line, a way how things should be done, is to me indecisive leadership and a very big mistake I would not have expected from Google.
Last AndroidIO things got better with the introduction of so called "Architecture Components" (among other things a SQLite ORM and guide how basic things should be done, finally). I wonder what took them so long.
The page it comes from says « the colored ovals are major states the Activity can be in ».
There should be a coloured oval for the (rather common) state where the Activity is the background after onStop(), and the two arrows coming out of onStop() should come out of that oval.
my last Android dev job was two years ago, I try my best to give you some feedback. Lets start with expectations. I expect that tasks performed by the majority of Android developers are actively supported by Google and are as easy as possible, with as few code lines as possible.
# REST - A lot of apps consume REST APIs. REST is almost the standard way to communicate with the outside world. Therefor the Android framework should include APIs to consume and send REST-requests and parse JSON easily (a support-rest lib would be nice, too). Depending for one of the main use-cases on third-party software is not okay.
# SQLite - Android really needs a support-sqlite library. Right now you have to use SQL features of the lowest supported api level, which means you are stuck in the past (if you want to stick with the default).
# Permissions - https://developer.android.com/training/permissions/requestin... - Handling permissions for older and new devices is a nightmare. I would expect to be able to declare the need for a certain permissions in – lets say 10 seconds – but figuring out how to get the permission bits right took fare longer (maybe 1 hour) and if I had to do it again, it would probably need again one hour. Instead of half a screen of boilerplate code and an activity-callback like onRequestPermissionsResult(), it would be nice if there where a PremissionBuilder, which would allow to easily setup permissions (spreading code all over the activity to do a basic thing is not that great).
# Cache - https://developer.android.com/topic/performance/graphics/cac... - Almost every dev needs & should cache data to improve app responsiveness and use the network less... To my knowledge there is no easy >>general<< caching mechanism in Android (maybe support-cache in the future ??). There is LruCache, but using it means almost writing all caching stuff yourself. Okay, there is Glide for images, which should probably be part of Android, but beside of that, void :). What would I expect? An API which lets you declare how something should be fetched, how many bytes/how long it should be in memory and if and how it should be saved to disk. Caching is such a general problem, I wonder why it hasn't been solved long time ago (we don't need the perfect solution, we need a solution – since it's such a common problem I don't feel like its my job as app-dev to solve it, I can, but I shouldn't do it).
# Effects/Transitions - During my Android years creating custom effects was very complicated and frustrating. Opening Qt Quick Designer for the first time and seeing how easy it is there, I was kind of shocked.
# Outdated information/blog posts - When researching a topic it is very easy to come along outdated knowledge. This is a real problem, since you don't know what you don't know. Sometimes I did things, just to learn later that there is a newer/better Android API. Since Google has not much control over it, I would suggest that Google keeps track of their own blog posts/articles and move them after some time into an archive or put a big (orange) banner on top of them, telling the reader that the content is outdated. Managing the produced textual output might be boring, but it seems to be necessary. I don't know if any company has ever done something like this... but, it would be great.
# Android takes up too much time & attention - Its difficult to describe the cause, but overall I felt like I did fight way too much with the framework, even after years of experience with it. I never had the time to care about things like battery saving APIs and such. It's sad and I wish I could have spend some more time following best-practices. Overall I think Android has to become simpler, I assume most people don't spend a huge amount of time learning all the bits of a given topic, they just want to get things done. Fare too often you have to know hell of a lot of things in Android, write a lot of code, like for RecyclerView with a custom Adapter (most people probably need a custom adapter, even the example is already cluttered) https://developer.android.com/training/material/lists-cards.... ... it's just too much code for such basic functionality.
# Android Studio UI ... has too many buttons, even for things like copy & paste, back & forward and may other buttons, I doubt those are use that often (we are experts, not computer novices). I know I can customize the UI, but still I wish the default was less overloaded :)
I acknowledge the huge amount of work Google did to make Android better over the years and things got really better. The introduction of the support library was stellar, thanks! </brain-dump>
From the barely usable Gsuite admin console to the indecipherable API docs (and developer console), I can't think of a single product where I can intuitively find the setting or option I'm looking for.
I don't think the article's methods would be very good re fixing this since when they asked developers to accomplish goals with the API and tracked them, they already decided what would be written.
Material design, while pretty, doesn't hold up usability-wise for all applications. It's a case where the consistency of switching between Google products is improved but at the cost of usability and UX of each individual product.
Dead Comment
It makes such a difference to be able to see the output and then quickly look at the source code. Really wonderful development experience.
It was required lots of vocal complaints for them to start having any kind of Material Design support on Android libraries.
And further, if only the Pandas team would also think about this a little more - surely the most frustrating, least intuitive module I've ever had the misfortune to encounter in Python.
That's not at all what I see in the documentation for Google's public libraries and frameworks.
Interesting... I've had the complete opposite experience. I've found it to be pretty intuitive and easy to use. Some of the documentation could certainly be better.
it's also super flaky often getting lost/unresponsive. I have to manually disconnect chrome, close all the youtube tabs and start over.
Other non-chromecast youtube issues are the fact that it knows everything I've watched but still 5% to 25% of the stuff it's recommending is stuff I've already watched. If they want me to watch more it really needs to be 100% new stuff.
The hidden ways to find my own videos or playlists always drive me nuts. Because the UI changes based on width the options disappear.
Another minor grievance, playlists with deleted videos don't show the titles. I have playlists with missing videos. I'd like to know what I lost. The name of the deleted video would be super helpful.
A major one for me is the volume controls on chromecast. Chromecast is built into my TV (Sony Android). The issue is no device I've ever owned in my life controls the TV volume from the device. Instead at most it controls it's own output level to the TV but the TV itself controls its own volume. So, the Chromecast youtube experience is that the volume control in the webpage directly controls the TV's volume. You can imagine this has woken up my neighbors serval times late at night when it decides to set my TV at full volume
YouTube remembers where you stopped watching a video.. sometimes. Maybe. Usually it just plays from the beginning anyway.
The "already seen" marker on a thumbnail is very often missing.
Recommendations are awful.
Subscriptions have been broken intentionally so that you just see a subset of the new videos. Many YouTubers are warning about this problem.
YouTube unsubscribes people randomly from channels and denies that this actually happens.
The volume control slider is hidden by default for no reason.
The bar with the video controls overlaps the video content for no reason. It could simply be placed below the video and be always visible. The current design only makes sense in fullscreen mode. This is an example for harmful consistency in UI design.
It's impossible to know without watching something whether it's full of swearing or homophobic / misogynistic / transphobic hate speech.
Ads are not targeted to the actual viewer, but to some combination of regular browser user and main youtube user. this means that children will be shown ads for alcohol or gambling. (note this goes against what Youtube says here about complying with local law: https://support.google.com/adwordspolicy/answer/6012382?hl=e... Note that this is something all ad networks get wrong, and it's likely they're going to see regulation in the uk at some point if they don't fix it.)
It's hard to know before clicking a link whether it's sponsored content or not. (in the UK sponsored videos need to be clearly identifiable before the user clicks the link or clicks play. in the US sponsored content needs to be clearly identified).
If two people (eg a parent and their child) watch Youtube the recommendations fail hard. If a single person watches youtube the recommendations are pretty poor.
As a visitor, I want to watch a video that someone linked.
The chance that I first want to see a non-skippable video (or video skippable only after 5 seconds) is vanishingly small yet that's what the YouTube UX frequently provides.
the big joke, at least while I was there, was that ux for random tools kept changing because they kept hiring ux engineers who needed to change something, anything, just to get promoted.