Developer UX at Google
medium.com
medium.com
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.
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:
https://github.com/square/flow
https://github.com/square/retrofit
https://medium.com/square-corner-blog/simpler-android-apps-w...
and so on.
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.
From this page we launched in May: https://developer.android.com/topic/libraries/architecture/l...
If it didn't do that, it would be able to avoid having the 'on create' line appear to pass through the 'destroyed' state.
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>
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"
thanks for the brain dump! very helpful.
(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>
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.
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.
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.
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.
For all that I love Datomic, their docs are a particularly egregious example of this, IMO. See: http://docs.datomic.com/query.html
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.
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.
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.
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.
or refusing to delete photos of women and their ex-partners when they've been killed by their ex-partners.
http://www.bbc.co.uk/news/uk-england-gloucestershire-3461822...
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 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
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.
[1]: https://gist.github.com/anonymous/6dcf061bad914e1a0d18653eda...
We're looking at ways to make it easier to glance at and understand Flutter code. Here's one experiment: https://github.com/Dart-Code/Dart-Code/issues/383
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.
Feedback welcome (via the GitHub issue :)