1st year anniversary at @pronovix, yay 🎉
Software Engineer at Typeform
Anabella describes "the OAuth dance" by explaining her first encounter with it and what she and her team at Typeform learned from this experience.
2 main use cases
Authentication - login
Feature integration - the app will request data on a recurrent basis to provide a new, enhanced feature. This application needs to be registered in the provider’s platform to know who is asking for information: need a redirect URI
4 steps in the OAuth dance
The app identifies itself through the user’s browser (public channel) requesting for specific information to be sent to a specific place
If everything’s OK with the above request Typeform will generate a consent screen. Interaction from Typeform to the user through the user’s browser. It contains: basic info, requested scopes, accept or cancel call to actions (pain point: error screen was blank - user cannot know what the problem is)
From Typeform to My app’s redirect URI endpoint through the user’s browser a temporary code is sent to be used in the final step.
Token request from app straight to Typeform without the browser. It contains client secret, temporary code, redirect URI.
Token granted from Typeform straight to the app without the browser.
How is the token used?
When the app wants something from Typeform, the unique token identifies:
which user does the data belong to
which app is requesting it and
whether it has the permissions to request that data.
Test your guides with junior devs to find your blind spots - documentation should be aimed at this group
Have descriptive error states
Give people a map they can follow
Provide dev tools
Technical Writer/Editor at Cossack Labs
Karen summarizes the points to remember when you want to make your site GDPR compliant.
GDPR: enforces a security standard on documentation
APIdocs: something that can make GDPR more doable, more understandable for your users
The vicious circle of ignored documentation: Docs are hard to read -› People don’t read docs -› Why bother? Nobody reads docs anyway
GDPR on the surface
Use human language that users actually want to read
Intend to be concise and informative
Describe clearly what you are taking from people, what kind of data interaction is taking place
The secret life of docs beyond the surface:
Database storing emails and passwords
If you store your users’ data you are responsible for them - even if users are being “irresponsible” and use the same password for various sites - it is you responsibility in the first place to secure their passwords on your site
Use simple words in explanations
Keep your sandbox user data clean
Use warnings about security measures
Inform users about GDPR
There is no silver bullet for GDPR - you have to think for yourself - what data you need for what - minimize stored data
Webex Developer Relations at Cisco
Adam gives us the six principles for cracking a great developer experience both on internal and external developer portals.
Be user-centric: you can only provide a great developer experience (DX) if you have a deep understanding of the goals of your users.
Good/Great DX is your competitive advantage- so many substitutes for a developer product (other product, open source, even build one for themselves - overconfidence of the developer)
Reduce onboarding efforts - helps both provider and developer, on internal and external portal: saves time and effort
Internally it can also motivate tool building
6 principles of creating great DX
1. Easy to understand
What it is and isn’t designed for - documentation should be authentic and trustworthy - don’t market
Use terminology that your users do - don’t try to be unique with it - don’t make them learn you
2. Easy to use
Ease of signup
Tryout option without commitment - don’t use gatekeepers (keys, documentation, sandbox)
Provide in several programming languages
3. Easy to build
SDKs, code samples (use multiple styles), make the right thing the easy thing
Have consistency both in docs and in API design - API style guide
4. Easy to get help
Error messages in docs to make sure they’re easy to find
Status page - honest and overcommunicating
5. Easy to trust
Uptime - trustworthy, honest
Clear communication about business plans
6. Easy to maintain
For the provider
Has to be baked into the product design
User experience is not only about (visual) design and it's not about the company it's about the users (hence the name, remember my Kitchen Radar 3000 in my session this morning) @akalsey #apidaysparis #APIdays pic.twitter.com/horqcMXl9Y— API Handyman (@apihandyman) December 11, 2018
Information Architect and Technical Content Writer at Pronovix
Developer eXperience (DX) can play a crucial role in achieving business goals, but how can an organization motivate the developers who use its APIs?
Kathleen examines 23 public-facing developer portals in the banking and fintech industry: what features can reduce API friction?
According to the 6 stages of the downstream developer journey, you can opt for:
Landing page, API catalogue (stage 1: discover & research),
Blog, use cases, try-out & test options, trust signals like changelog, legal documentation (stage 2: evaluate),
Onboarding process elements, onboarding documentation, self-service support elements (stage 3: get started),
API references, FAQ pages, support options in 1 place, community page, discussion forum (stage 4: develop & troubleshoot),
Developer documentation, blog (guest post, interview), ask for feedback, events (stage 5: celebrate),
Release notes, status page, versioning info, legal documentation, revealing future plans (stage 6: maintain).
Throughout her talk, Kathleen gives us hands-on examples of tips and tricks, best practices and patterns.
1st year anniversary at @pronovix, yay 🎉