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.
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.
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.
>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.
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.
[+] [-] thibran|8 years ago|reply
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.
[+] [-] lukasb|8 years ago|reply
[+] [-] ashark|8 years ago|reply
[+] [-] enkay|8 years ago|reply
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|8 years ago|reply
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.
[+] [-] tbolt|8 years ago|reply
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.
[+] [-] chickenfries|8 years ago|reply
[+] [-] hockeybias|8 years ago|reply
[deleted]
[+] [-] yttrium|8 years ago|reply
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|8 years ago|reply
It was required lots of vocal complaints for them to start having any kind of Material Design support on Android libraries.
[+] [-] mft_|8 years ago|reply
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|8 years ago|reply
[+] [-] jrs95|8 years ago|reply
[+] [-] dnadler|8 years ago|reply
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.
[+] [-] ernsheong|8 years ago|reply
[+] [-] grabcocque|8 years ago|reply
[+] [-] sokoloff|8 years ago|reply
[+] [-] eddz|8 years ago|reply
[+] [-] fridek|8 years ago|reply
[+] [-] mswift42|8 years ago|reply
[+] [-] nxc18|8 years ago|reply
[+] [-] V-eHGsd_|8 years ago|reply
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|8 years ago|reply
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...
[+] [-] sethladd|8 years ago|reply
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 :)
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] pmontra|8 years ago|reply