• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Applying Design Priciples to APIs - 2 of 4
 

Applying Design Priciples to APIs - 2 of 4

on

  • 13,573 views

 

Statistics

Views

Total Views
13,573
Views on SlideShare
1,254
Embed Views
12,319

Actions

Likes
4
Downloads
59
Comments
0

13 Embeds 12,319

http://blog.apigee.com 12071
https://blog.apigee.com 140
http://blog.sonoasystems.com 91
http://translate.googleusercontent.com 5
https://blog.edit.apigee.net 2
http://localhost 2
http://webcache.googleusercontent.com 2
http://www.afterjohn.appspot.com 1
http://zmezk2.appspot.com 1
http://ip52.216-86-157.static.steadfast.net 1
http://three.rdaili.com 1
https://fiberprox.eu 1
http://www.google.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Hi, I’m Brian Mulloy with Apigee.\n\nWelcome to part 2 of our 4 part series:\n\napplying universal principles of design to APIs.\n\n\n
  • we are considering principles drawn from the book: Universal Principles of Design.\n\n
  • our approach is simple: \n\nwe’ll introduce a design principle\nview it in the context of our experiences with APIs\nand based on what we see, we’ll create a checklist of best practices\n\n
  • let’s get started with our second session:\nPart II: Don’t overwhelm\n\nour goal in this session is to punctuate the well-known maxim that more isn’t always better\n\n
  • engineers, especially talented software engineers, can create one solution flexible enough to solve many problems.\n\nengineers often view flexibility as a limitless virtue.\n\nin general, however, there is a tradeoff between flexibility and usability. \n\nthink of a simple remote control for one device versus a complicated universal remote for multiple devices.\n\nor a stand-alone screwdriver versus a swiss army knife.\n\nin each case the more flexible design is also more difficult to use.\n\n\n
  • in the world of APIs, a flexible API leads to more diverse apps.\n\nwhereas, better usability leads to more initial developer adoption.\n\ndo we have to choose between the two?\n\n
  • yes and no\n\nin our experience, it is often difficult to anticipate the future needs of API-dependent apps.\n\neven the most focused initiatives require significant flexibility in design.\n\nour feeling is that APIs are inherently more like swiss army knives than single-purpose tools.\n\nso, even with the Flexibility-Usability tradeoff principle in mind, we have to favor flexibility for our API.\n\nbut we also want usability. so what do we do?\n
  • because we can’t compromise on systematic flexibility\n\nwe must find and eliminate unnecessary complexity from all other parts of our design.\n\nwe need to optimize usability.\n\n
  • in other words, an API must be flexible, but it doesn’t have to be unnecessarily complex.\n\nWe are aware of the flexibility-usability tradeoff.\nAnd we know good APIs are inherently flexible.\n\nSo, we must optimize usability.\n\nthe flexibility-usability tradeoff principle is the foundation for this session.\n\nIt amplifies the importance of the remaining 3 design principles.\n\nlet’s take a look.\n
  • as they create applications, developers make hundreds or even thousands of simple decisions.\n\nthe faster they make decisions, the faster an app gets made.\n\nthe better the decisions they make, the better the app.\n\nHick’s law states that for simple stimulus-response tasks, the time it takes to make a decision is a function of the number of available options.\n\nThe more options we give our developers about our API the longer it will take them to build apps.\n\nlet’s take a look at an example where unnecessary complexity collides with Hick’s Law.\n
  • \n \nDigg allows their API users to indicate the response format in two different ways:\n* through the accept header\n* or through an optional type param\n* if the type argument is specified it overrides the accept header\n\nfor a developer making a simple decision about a response format, these options will slow him down.\n\n
  • Foursquare, on the other hand, gives developers one, simple way to specify the response format.\n\nthe foursquare developer will be able to make his decision about the format syntax quickly and move on to his next task. in this case there is no decision to make at all.\n\n
  • how can we help our developers make decisions more quickly?\n\nwe can eliminate unnecessary decisions from their workflow.\n\n
  • knowing that developers make hundreds of simple decisions as they create applications, we can help by eliminating superfluous choices from our API design so that our developers can build apps faster.\n\n
  • As the API team, we’re going to have to do a lot with limited resources. It will be easy for us to get overwhelmed.\n\nwe can have a greater impact on the success of our API by keeping in mind the 80/20 rule.\n\nA high percentage of effects in any large system are caused by a low percentage of variables.\n
  • importantly, 80% of an APIs use will come from 20% of it’s features. \n\nby using API analytical tools we can understand which features are in the 20% and which are not so that we can improve our product roadmap and invest in highly-used features.\n
  • likewise, 80% of an APIs errors will come from 20% of our components. \n\nby using API analytical tools we can understand which components are in the 20% and which are not so that we fix the highest impact bugs first.\n
  • knowing that we have limited resources and much to do\n\nwe can have a greater impact on the success of our API by keeping in mind the 80/20 rule\nInvesting in highly-used features and Fixing high-impact bugs\n
  • when a developer approaches a new API there are many resources competing for his attention.\n\nan experienced developer understands some resources will be more important than others.\n\nas we present information to our developers we should consider the Inverted Pyramid principle.\n\nlet’s take a look.\n\n
  • there are many ways to list the resources in our API.\n\none approach that is NOT very valuable to a developer\nalso happens to be very common:\n\nalphabetically\n\nlet’s think about it: in order for a person to use an alphabetical listing he must know a few things about what he seeks in advance.\n* not only the overall concept like a person, user or customer\n* but the specific word that he wants: person\n* and how to spell it: P-e-r-s-o-n\n\nhaving this much information and with docs on the web he might as well use the browser’s search capability to find the resource more quckly.\n\na traditional alphabetical listing of API resources doesn’t teach a developer anything he doesn’t know already.\n\nand we’ve lost an opportunity to communicate an important aspect of our API.\n\n
  • from the time we design our API we will have an idea about which resources are most important.\n\nthen as we accrue data about actual API usage we can adjust our understanding of the relative importance of resources.\n\nwe can help developers learn our API by listing our resources by importance.\n\nlet’s look at a few examples.\n
  • twilio seems to list their resources in the chronological order one would use them when creating an app:\n\n* create an account\n* find the available numbers\n* deal with calls\n* move onto conferences\n* and so on.\n\n
  • foursquare is about people going to venues, checking in and providing tips.\n\nand we can see their resources are listed in that order.\n
  • likewise twitter, who has accrued an enormous amount of data about their API usage, \nlists their resources in what seems to be in order of importance:\n\nwith timeline, tweets and people leading the way.\n
  • knowing that a developer approaching a new API has to discern which resources are most important \n\nwe can use the inverted pyramid principle to present information to our developers in a way that communicates the relative importance of the components of our API.\n\n
  • that wraps our second (much quicker) session on design principles.\n\nby being careful not to overwhelm our developers or ourselves...\n
  • we added 6 more tangible actions to improve our API initiative\n
  • in the next session we’ll cover part 3: Don’t Reinvent the Wheel\n\nwhere we’ll tackle 3 more design principles\n\nstay tuned\n\n\n
  • \n

Applying Design Priciples to APIs - 2 of 4 Applying Design Priciples to APIs - 2 of 4 Presentation Transcript

  • Applying
Design
Principles
to
APIsPart
2
of
4Brian
Mulloy@landlessnessApigee@apigee
  • amazon.com
  • Four
PartsI. Empathize Development
Cycle
●
Errors
●
VisibilityII. Don’t
Overwhelm Flexibility‐Usability
Tradeoff
●
Hick’s
Law
●
80/20
Rule
●
Inverted
PyramidIII. Don’t
Reinvent
the
Wheel Advance
Organizer
●
Consistency
●
Self
SimilarityIV. Be
Beau<ful Aesthe<c‐Usability
Effect
●
Cost‐Benefit
●
Immersion
  • Part
II:
Don’t
Overwhelmi. Flexibility‐Usability
Tradeoffii. Hick’s
Lawiii. 80/20
Ruleiv. Inverted
Pyramid
  • “ As
the
flexibility
of
a
system
increases,
its
usability
 decreases. Flexibility‐Usability
Tradeoff Universal
Principles
of
Design
  • Myriad
apps
or
developer
adop<on?
  • Favor
flexibility
  • Op<mize
usability
  • Flexibility‐Usability
TradeoffUniversal
Principles
of
Design✓ Favor
flexibility✓ Op<mize
usability
  • “ The
<me
it
takes
to
make
a
decision
increases
as
the
 number
of
alterna<ves
increases. Hick’s
Law Universal
Principles
of
Design
  • Digg*Accept: application/json?type=json* The type argument, if present, overrides the Accept header. Note: I also used this example in Teach a Dog to REST
  • Foursquare/venue.json
  • Eliminate
unnecessary
choices
  • Hick’s
LawUniversal
Principles
of
Design✓ Eliminate
unnecessary
choices
  • “ A
high
percentage
of
effects
in
any
large
system
are
caused
 by
a
low
percentage
of
variables. 80/20
Rule Universal
Principles
of
Design
  • Invest
in
highly‐used
features
  • Fix
high‐impact
bugs
  • 80/20
RuleUniversal
Principles
of
Design✓ Invest
in
highly‐used
features✓ Fix
high‐impact
bugs
  • “ A
method
of
informa<on
presenta<on
in
which
 informa<on
is
presented
in
descending
order
of
 importance. Inverted
Pyramid Universal
Principles
of
Design
  • Does
alphabet
soup
taste
good?
  • List
resources
by
importance
  • Inverted
PyramidUniversal
Principles
of
Design✓ List
resources
by
importance
  • End
of
Part
II:
Don’t
Overwhelmi. Flexibility‐Usability
Tradeoffii. Hick’s
Lawiii. 80/20
Ruleiv. Inverted
Pyramid
  • Part
2:
Checklist✓ Favor
flexibility✓ Op<mize
usability✓ Eliminate
unnecessary
choices✓ Invest
in
highly‐used
features✓ Fix
high‐impact
bugs✓ List
resources
by
importance
  • Four
PartsI. Empathize Development
Cycle
●
Errors
●
VisibilityII. Don’t
Overwhelm Flexibility‐Usability
Tradeoff
●
Hick’s
Law
●
80/20
Rule
●
Inverted
PyramidIII. Don’t
Reinvent
the
Wheel Advance
Organizer
●
Consistency
●
Self
SimilarityIV. Be
Beau<ful Aesthe<c‐Usability
Effect
●
Cost‐Benefit
●
Immersion
  • THANK
YOUQues%ons
and
ideas
to:Brian
Mulloy@landlessnessbrian@apigee.com