Hacker News Reader

Comment by jgunsch | Hacker News Reader

Hey, eng lead here for the APIs Explorer. Despite the site's ancient appearance, we're not killing it, and have some plans in the works. (You can see some of the work we've been doing on developers.google.com, with "Try this API" on the right [1]).

Feedback I'm interested in: What do you use the APIs Explorer for? What features would you like to see?

[1] https://developers.google.com/google-apps/calendar/v3/refere...

View on HN

> ancient appearance

You mean usable and fast without needless animation like everything in material design?

You say "without needless animation"; I say "makes me, as someone with a sensory integration disorder, able to refocus my eyes to the new text more quickly." (And then someone else says "makes me, as someone with the other kind of sensory integration disorder, overwhelmed and distracted and so hinders my fluency.")

Accessibility is not a scalar; some people need things that other people don't; some things X people need hurt Y people, and vice-versa. The animations might not help you, but they help someone.

Then we should give users a choice some how? You'd think this could be a solved issue ~20 years in.

If the animation were done in pure CSS, UA stylesheets could suppress it handily.

Suggestion to improve the UX for some users by having them write CSS stylesheets? Count me it ;).

Nothing personal, but this sounded a bit surreal to me.

"UA stylesheets" is sort of an intermediary format these days; you don't write them yourself, you use a browser or browser extension or a piece of native accessibility software that generates them for you in response to your described needs.

FWIW iOS has a reduce animation accessibility option. No idea if it's somehow enforced on apps or Google voluntarily respect it in their apps though.

By your own argument, animations != accessibility. Animations MAY be a matter of accessibility for some people and an accessibility problem for others - real accessibility would be making it optional instead of the default.

My actual argument would be to do real usability testing to see whether either of the options (more animations; less animations) helps, on average, if made the default.

An analogy: the way we use capital letters in English helps to guide and reorient the eyes of people who are dyslexic. But English's capital letters also help in the same way—just to a lesser degree—the people who aren't dyslexic. It turns out that capital letters are just a good idea on average, like e.g. the wheelchair ramps built into sidewalk curbs.

Now, there are probably at least a few people in the world who can read English text better without capital letters for whatever strange reason. But if the average person can read better with them there, then it's better to enable them and make disabling them an option, rather than to disable them and make enabling them an option. The average person, not thinking of themselves as needing assistance, wouldn't look in the options for an "enable capital letters" option. And so the average person, who could have been helped by the assistance, would have QALY left on the table—and that's a large amount of QALY when multiplied by the number of "average" people, compared to the two groups that have specific, recognized problems that they'll know usually have solutions in options menus.

Great resource, I've used this often from client computers to look at some basic data before offering support.

I use most of the advertising related APIs on a daily basis. I am very happy that I can take a look at a client's account, at the client's desk, before access is provided.

An API explorer for Doubleclick for Publishers seems to be missing from the list, I presume due to the increased complexity of DFP it was not included, are there any plans to include DFP in here?

This site loads incredibly slow. What is actually happening in between the time I get a Google frame with blank content and the content finally appearing?

The extreme sluggishness is a problem I've also noticed on the Google Careers site.

I would really like to see sample inputs. Or for example, when exploring an api funciton on i.e. the NLP landing page, why not have an "Export this to the API explorer"?

I would remove 'Google' from the sorting. So you don't have that big amount of APIs once you scroll down a bit starting with Google, at that point Google is a filler word - I would expect Google Ad Experience to be sorted with the other Ad APIs.

Maybe a google history type integration. Logged in, show what searches I have done that brought me to what api pages.

-Download a postman collection.

-Comments per api. There is valuable information in the section of REDIS docs

Minor nits:

- if I close the try-it-now side bar, it comes back every time I click on a new API

- The try-it-now is slow to load

- the side nav is poorly discovered. It's hidden by the Try it Now side pane.

Full disclosure: I lead the overhaul and modernization of my companies developer documentation site.

This is a valuable resource for developers trying to integrate with google services. The API explorer is the what I go to after reading the API documentation. The Google API explorer is a lot more usable compared to some of the swagger/openAPI based ones.

Have you guys considered switching to swagger-ui (https://github.com/swagger-api/swagger-ui)?

This is not to say Google API explorer is bad or swagger-ui is better.

Disclosure: I'm top contributor to Swagger Codegen but not Swagger UI.

Very nice resource! Casually browsing on iOS I noticed it crashes the tab...

Features would you like to see:

* be able to display my own APIs, not just Google's

* make it open source, under a suitable license.

Swagger/OpenAPI's UI is great & open source. It is based on the OpenAPI standard. Why isn't APIs Explorer doing it too?

Reply on news.ycombinator.com