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>
REST - we recommend Retrofit, and don't have plans to do anything else here.
sqlite - please check out Room from Architecture Components (soon to exit alpha, already pretty stable)
permissions, transitions - haven't done work here but will look into, ask people who do
cache - we're aware there's a gap here. if there's a library here you think i should look at, let me know.
outdated info / blog posts - we're looking at how to improve developer.android.com to make sure people get the latest guidance. i'll see if we can expand scope to include blog posts. btw, if anyone has recommendations for how to address people finding outdated answers on StackOverflow ... i'm all ears.
too much time & attention - definitely agree with the general point, and for RecyclerView specifically yes, I think we can make this simpler.
Android Studio UI - we have some very good UX people now, but (1) it will take time for their work to launch and (2) there's only so far we can move from IntelliJ's approach, which is very much "we'll give you lots of options and you can customize to simplify"
btw, we don't have a problem with recommending good, well-maintained third-party libraries. no reason to reinvent the wheel.
(although lawyercat wants me to note that a recommendation is not a guarantee of fitness, if it causes your machine to blow up we're absolved of all blame, etc.)
Now that I spend some time thinking about Android, other things popped back to my mind.
# back-stack - For all the time I spend in Android I wished there where a tool to log/see the current state of the back-stack. I tried hard to have a correct mind-model of it, but too often the app behaved differently, so I did fallback to try-and-error which consumed a lot of time and was very frustrating.
App navigation is too hard, there are too many places where you specify navigation bits and too many tools/code paths to implement it. I would suggest to move all navigation/back-stack settings from the activity/manifest into >>one<< separate file for all screens of the app where all navigation settings are displayed and all possible navigation flows are modeled – with the possibility for Google to later add a graphical representation, like done for the xml layout preview. As a plus, transition effects could be specified in that file too. I assume this would be a looooooot of work :)
# A code coverage tool like it exists for Go is super helpful. It highlights lines that are tested and which are not, take a look at Visual Studio Code, with the Go extension installed: http://i.imgur.com/7mvRjLC.png
# Bundle/Intent data - Passing data to another activity is too cumbersome. Maybe this is something that could be solve by annotations. I always wrote factory methods like newMyActivity(...) to have the code all in one place, but writing such code always felt like a wast of time. Implementing Parcelable (the auto-generation function was god send), is jet another boilaplate code piece you have to update as soon as something changes, so it helps not that much.
# Resource folder - This is an old complain but it holds. If you have a medium to big size app your layout resource folder grows way too big. Because it is not possible to create sub-folders you have to invent ugly long names. Maybe a per-activity layout folder would help here, without introducing too many folder-layers (those could later be auto-merged into a single folder by a tool).
# App resources - It is difficult to know if your app uses too much resources. There are resource-viewers hidden somewhere in Android-Studio UI (you have to know that they exist). I would wish if I would get automatically a warning, if something exceeds a common threshold, so that I can try to be a better citizen without spending too much time there. Optimizing resources is something to do later, if there is ever time for it (depends on your boss). As dev it would be easy for me to tell a tool (maybe in the manifest.xml) that my app should have low/medium/high disk/network/memory usage, but observing if that assumption holds is time consuming. If e.g. I would classify the app as low disk usage, but for some reason the disk is accessed all time, there is probably something wrong. Telling devs that they consume to many resources might be an easy way to improve battery-duration for all of us -> it's hard to do something right, when you don't know that you do it wrong.
# The Context object - I struggled for quite some time to learn all the wrapper-objects that contain a Context and should therefor not be kept in memory. I don't know what kind of advice I would give a new dev to circumvent the context pitfall, this is unexpectedly a hard one.
# Image zoom - When working with images I was surprised to find out that there is no flag which allows the user to pinch-zoom into it. Implementing image pinch-zoom took way too many lines of code and was way more complicated than it should have been (I don't know what the current state of this problem is, maybe it got solved in the meantime). If not, there should be really a simple way to get this feature, maybe it would need a new image tag, like zoomable-image or so, but it should exist.
# Image-to-full-size - There is the common pattern, that you have an image and when touched, it should be displayed fullscreen. As far as I know you have to hand-write that code. Attached to this use-case is effective image loading, like loading only the pixels into ram you know can be displayed, or ignoring the alpha channel... This image handling util could be extended by having the possibility to load the next image by fling-pushing the current image to the left/right. Right now you write a lot of boilerplate code and maybe miss quite a lot of optimizations if you don't read enough about the topic.
# LayoutInflater - The inflate() method was for a long time confusing to me, because of the attachToRoot param. It should be easy, for some reason it is not. Do a google search about the topic, people are confused :)
# Custom views - For years there was not much information on how to create custom views. Than there appeared an official tutorials about how to extend the View class. I feel like the docs miss here something. When I was in the need of a custom view I always extended a view-group container, not the View class itself, because it's much simpler and gets the job done. There should probably be more information about that kind of custom view, the we-extend-the-view-class is the most complicated and maybe also a very rarely needed use-case (btw, I never used canvas to do anything). https://developer.android.com/training/custom-views/create-v...
# Menu items - Should probably be handled by a builder too, instead of a couple of callbacks (there are too many activity-callbacks, leading overall to spaghetti-code).
# Multi-layout - I wonder if Google ever thought about having a multi-layout-container, which would depending on your display size, displaying/hiding different views automatically. On the left a nav-pannel, mid the content and on the right, optional content pages. Such a setup feels like a classic setup. You can code it yourself, which would take ~3-6 classes and a lot of glue code (and documentation look-ups therefor). I wonder why there is not something like this already (maybe there is, and I have just missed it).
# Video-cast for experienced Android developers - For Go there is JustForFunc https://www.youtube.com/channel/UC_BzFbxG2za3bp5NRRRXJSw which hits a lot of nails. Watching a grand master Go dev doing a code-review or implement a little gem gives you more insights into his thoughts and tooling than 10 blog posts ever could. JustForFunc is pure awesome, entertaining and has a really good time-to-value rate. Even after years of experience with Go, I learned quite a lot watching Francesc Campoy code.
I should probably also let you know that I loved the code inspection features of Android Studio. They really did make a big difference and helped me to keep my code clean (especially the resource files). For the value that inspections give you, they are IMHO a bit to hidden in the UI. Also Dagger2 did help a lot. The difference between code without and with Dagger2 is like day and night. Maybe Dagger2 should be pushed more. Ah, and Kotlin is awesome, sooo much better than Java. </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.
iOS: docs are so good you'll find yourself reading way past what you actually need, just for fun. They're great. APIs generally well thought out. Examples current. Xcode's sometimes frustrating, but not that bad. Worst part's the signing process which remains prone to breaking for mysterious reasons (this is probably less true if you have just one project that's always current, but if you have historical projects that need upkeep and you bounce between different apps it's bad) and I still have to look up again how to get all the parts working if I go more than a few months without messing with it, because I can't seem to keep it in my head.
Android: most docs amount to half-assed Javadoc output. Longer-form sections frequently contain bad advice and outdated examples. When the examples aren't outdated they always seem to avoid demonstrating the particular use you need them to, as if by magic. APIs themselves sometimes weirdly bad (see, at least as of ~6 months ago, the Android google maps address search API being significantly worse than the Javascript one). New UI elements are frequently a duct-tape-heavy veneer over existing UI elements that lacks customization you'd expect to exist, unless you resort to reflection, and generally feel like something the summer interns threw together. Support for all that pretty Material UI stuff is laughable.
And while I know there isn't an iOS public bugtracker to compare it to and that that's also kind of a bad situation, the Android bugtracker is mostly useful as a source of either comedy or suicidal ideation, depending on your demeanor. You'll learn what I mean if you spend much time with Android.
For Android your best bet is to read everything Square (yes, that Square) has written about it, and follow their patterns and use their libraries wherever possible. See:
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.
Maybe it was just my friend group, but I feel like Facebook had a nice period shortly after it switched from profiles to walls, but people actually thought about what they were posting instead of spamming it constantly. Then between the spam from inane facebook games (via the API access you mentioned, I think I have ~100 of these blocked still because of how they gobbled up the whole feed at the time) and now the giant number of content farms, the news feed is attention grabbing yet useless for anything actually social.
Someone please steal this idea:
- Social network where you get 1 post per day. Text status, link, photo, whatever.
- You have a couple of free "bonus posts" each month for when you really want a second post.
- Monetize by selling additional posts, but the cost ramps up exponentially.
I'm sure it's not destined for facebook-level gajillions of dollars, but there's got to be some market for a sane social network that you can actually keep up with, right? Instagram is working for me right now, but maybe only because I don't know that many people on it. I've tried FB and twitter and basically checked out of both.
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.
This phenomena seems more like, uhh, forgetting that lots of people haven't built the mental framework that makes things obvious to you. Not sure how else to describe it. Like, it'll just assume a lot of detailed knowledge as just something that everyone easily gets, and the very specific system they built on top of it is the only thing that needs to get documented.
>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.
It's not clear. Human moderators are not the magic pill that fixes everything. Google has taken enough flak for injecting far too much liberal bias into their system and human moderators will only outrage more people. You may see it as righteous when opinions you don't like are swept off of websites you use. Everything is neat, tidy, and non-challenging to you. It's a bit Orwellian to me.
Google has an automated API in beta to detect toxic comments. I've been playing around with it and it works pretty well and could solve the human moderation problem.
I don't think human moderators are the clear fix at all.
Both Facebook and Twitter employ a large number of human moderators, and they still regularly make judgment calls that are comically bad - defending stalkers while suspending their victims, suspending users that are the target of coordinated harassment campaigns, etc.
The reality is that when you have an army of people who need to churn through a vast amount of content per day, without the time or authority to look at the full scope and context of user interactions, they will make lots of bad calls. Doubly so if the moderators live half a world a way and have little awareness of the culture and norms of users they're asked to evaluate.
Add this to the fact that the really obvious abusive comments can and are already being moderated by automated systems, it means the human moderators are overwhelmingly exposed to the trickiest, least cut-and-dry situations.
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.
I know where your coming from because this annoys me when I share videos too, but this is the choice of the video creator. So although YouTube are facilitating it, I'm not sure it's their "fault" if users choose to set a particular ad format (https://support.google.com/youtube/answer/2467968?hl=en-GB) - they could have it set to banners instead of skippables for instance.
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.
I've been playing around with flutter, and saw a lot of code similar to this. Where is this style from? I've written apps in Java for Android but never encountered such style.
The post refers to this as problematic because developers fail to map the code spatially. While I agree, I also find this kind of code very unreadable and unelegant. I'm interested in what others think. Isn't this a part of the UX? It becomes a bit hard for me to maintain proper context with this way of writing code.
Notice how we're auto-inserting "synthetic" comments to clearly mark the closing parens/brackets. So far, the feedback has been very positive, it helps improve scanning and reading the code.
My suggestion about the child / children thing: make it more obvious by calling it 'one_child'. Maybe not as beautiful but I guess that > 50% developers don't have English as their native language.
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.