
Developer UX at Google - mswift42
https://medium.com/@taodong/how-i-do-developer-ux-at-google-b21646c2c4df
======
thibran
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...](https://developer.android.com/guide/components/images/activity_lifecycle.png)).
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.

~~~
ashark
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.

~~~
mercer
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.

~~~
ashark
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:

[https://github.com/square/flow](https://github.com/square/flow)

[https://github.com/square/retrofit](https://github.com/square/retrofit)

[https://medium.com/square-corner-blog/simpler-android-
apps-w...](https://medium.com/square-corner-blog/simpler-android-apps-with-
flow-and-mortar-5beafcd83761)

and so on.

------
enkay
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.

~~~
lnanek2
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.

~~~
seastonATccs
API access to social media have ruined them.

~~~
wlesieutre
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.

------
yttrium
Funny this should come up - This past month I've been exploring building web
apps using [http://www.material-ui.com/](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.

~~~
pjmlp
Sadly Android developers don't share the same experience.

It was required lots of vocal complaints for them to start having any kind of
Material Design support on Android libraries.

~~~
leipert
material-ui.com is not an official library by Google.

~~~
yttrium
Correct, it's a react wrapper that implements the Material UI guidelines.

------
mft_
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.

~~~
jypepin
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.

~~~
mjw1007
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.

~~~
ThrustVectoring
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.

For all that I love Datomic, their docs are a particularly egregious example
of this, IMO. See:
[http://docs.datomic.com/query.html](http://docs.datomic.com/query.html)

~~~
dalfonso
Curse of Knowledge
[https://en.wikipedia.org/wiki/Curse_of_knowledge](https://en.wikipedia.org/wiki/Curse_of_knowledge)

------
ernsheong
Never heard of Flutter ([https://flutter.io/](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!

------
grabcocque
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.

~~~
mswift42
What's terrible about YouTube's UX ?

~~~
DanBC
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...](https://support.google.com/adwordspolicy/answer/6012382?hl=en-
GB) 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.

~~~
cheetos
The way to fix comments is clear: human moderators. Since this can't br
automated (yet), Google doesn't do it.

~~~
iratewizard
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.

~~~
applecrazy
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.

------
nxc18
This is rich coming from Google. If only they put a fraction of the time they
put into this into the Android SDK they'd have a much better product.

------
V-eHGsd_
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.

------
ktta
This[1] was linked to in the post.

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...](https://gist.github.com/anonymous/6dcf061bad914e1a0d18653eda789e65#file-
row_column-dart)

~~~
sethladd
(disclaimer: I'm on the Flutter team)

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](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 :)

~~~
ktta
That looks a lot better! Thanks for working on these little improvements too.

------
pmontra
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.

