We know there are many challenges around User Experience (UX) for end-users who are trying to use decentralized applications but what about the developers who build those applications? Their experience is often under appreciated. In this meetup, we'll dig deeper into what developer experience (DevX) really means, the state of it on today's platforms and how we can improve it in the future. We'll survey the landscape and tear down a couple of existing platforms. Following the talk, we'll move to a panel discussion with developers of apps on multiple different platforms about the pros and cons of development on each platform. Learn more about NEAR Protocol, a scalable blockchain and smart contract platform, at https://nearprotocol.com

1. DevX: Where developer tools meet UX
Product, Design and Development
December 12, 2018

2. User Experience (UX)
“The overall experience of a person using a
product such as a website or computer application,
especially in terms of how easy or pleasing it is to
use.”
2

3. User Interface (UI) != User Experience (UX)
3
Unattractive
but highly
effective.
Beautiful,
Iconic… and
impossible to
pour.

4. Usability != User Experience (UX)
4
Usability is achieving a goal
with the maximum:
1. Effectiveness
2. Efficiency
3. Satisfaction
UX encompasses the ENTIRE
experience a user has while
interacting with a product or
service.
Was it delightful?
Will the user return?
Science Art

5. UX is a journey
UX covers the user’s
experience during their
entire journey from the very
first interaction with a
product to their last.
Along the way, they pass
through lots of interfaces.
5

6. Step 1: The platform’s customers are developers.
Step 2: The developer’s customers are end-users.
To be effective, platforms have to win them both.
Platforms have 2-step product/market fit
6

7. Designing for end-users is sexy
7

8. Designing for developers is hard
8

9. DevX (also called DX) is the subset of user experience
specifically addressing the experience of developers.
Developers are sufficiently different -- and important -- that
it’s worth specifically distinguishing them from end-users.
This is what we’ll discuss today.
Developer Experience (DevX)
9

10. Today’s Topics
1. Components of DevX: What Developer
Experience is and its key concepts.
2. Case Studies of DevX: A walkthrough of initial
interactions with the EOS and Ethereum
platforms.
10

11. About Me
I’m Erik Trautman and I run operations at NEAR Protocol, a
scalable blockchain and smart contract platform on a mission to
bring the technology to a billion devices around the world.
I also care deeply about creating great products, educating people
and building rich ecosystems.
My background is in markets, open-source software development,
startups and education. And general nerdery.
11

12. Roadmap
1. Components of DevX
2. Case Study: Ethereum
3. Case Study: EOS
4. Analysis
12

13. Roadmap
1. Components of DevX
2. Case Study: Ethereum
3. Case Study: EOS
4. Analysis
13

14. Who is our user?
An experienced developer
comfortable with:
1. Command line
2. Web languages
3. Version control
4. Deployment
Reading documentation is
familiar.
14

15. Key differences between DevX and end-user UX
Developers operate across multiple tools simultaneously (eg text editor,
CLI, webpages, etc) so you can’t control the whole experience.
Creating an app is not a defined purchase or use case but rather a
creative process of solving problems and writing code.
Developer environments are highly customized and might include dozens
of different setups for command line, OS, IDE and even keyboards.
The common interface is TEXT.
15

16. Blockchain system architecture: How DApps work
16
● Blockchain
● Nodes
● Wallets
● Libraries
● APIs
● ...

17. Experiential touchpoints for developers
17
Developing on a single platform encompasses a lot of touchpoints:
1. API Design: Naming, abstractions, organization, invocation
2. Documentation: API reference, tutorials, demos
3. Tooling: Language, CLI, text editor, test frameworks, build tools,
logging/debugging, instrumentation (block explorer), runtimes
4. Support: Libraries, scaffolding, forums, chat, blog posts

18. DApps require a constellation of tools
18

19. ...unfortunately, dev tools, education and support are
most often developed with power users in mind first,
preventing new users from ramping up.
We’ll focus on new users for now.
New users != power users
19

20. Assumption: You’ve just heard of FOOchain and want to test it out.
1. Gather Info: “Learn FOOchain”, “foochain quickstart”, etc.
2. Install: Download the tools and verify it’s all set up
3. Develop: Write that “Hello, world” app
4. Deploy: Try to get it up on TestNet
5. Productionalize: Add more functionality, libraries, testing, etc.
Launch!
Interrupt: Errors! Support! Conceptual holes! Broken docs!
Typical flow for a new project
20

21. Roadmap
1. Components of DevX
2. Case Study: Ethereum
3. Case Study: EOS
4. Analysis
21

22. Developer Jane (experienced but not a blockchain developer) just found
out about Ethereum and wants to give it a shot.
She found her way to deploying Hello, World.
Case study: Ethereum
22

23. “Why is there nothing
affiliated with Ethereum?”
Searching for tutorials
23

24. “So far, so good, except
developing on mostly
non-ethereum 3rd party
packages feels slightly
sketchy”
Install dependencies
24

25. “This feels scary. I want to quickly try
out a dev environment, and it’s now
telling me to do a complicated
password management procedure
where if I fail, somebody can steal all
my ether. I am considering giving up
at this point!”
Install Metamask
25

26. “Migrating*? What am I
migrating? I don’t have an
existing app! Who came
up with this vocabulary?”
“This tutorial was
published yesterday and
is already out of date.”
* Ruby on Rails term
Start the tutorial coding
26

27. “The errors required 2
fixes - updating version of
compiler and rewriting the
constructor definition
using the new
non-deprecated syntax.”
Errors
27

28. ...and more errors
28

29. “If you are designing a
language which has a
mapping construct, why
doesn’t the mapping
construct keep track of its
own size? Be nice to your
developers.”
Solidity
29

30. “But why did things
change in ganache? Is
this how it’s supposed to
be? What happens if I run
out of test account
resources?”
Ganache
30

31. “It’s actually awesome
that there is a testing
framework and a tutorial
for running tests.”
“How am I going to run
these tests on something
like a travis? Is this
framework basically a
demoware?”
Testing
31

32. Client
“Exploring the original
source code was soothing
and entertaining due to
cute doggie pictures in
the solution. whew.”
32

33. Metamask fail
“Apparently I made the
wrong choice. Game over
(spinner spins endlessly
with no indication of what
went wrong and no option
to cancel out)?”
33

34. Metamask again
“I am on a test environment, and this
wants to use my main account. This
should never happen.”
“A blockchain n00b may be stuck on
this screen for a long time. What’s gas
limit? What’s gas price? Do I have to
give them a credit card? What’s gas
price? What’s GWEI? No tooltips.”
34

35. Success! App complete.
“Yay”
35

36. Debriefing Ethereum
Pros:
1. Got it to work :)
2. Testing framework!
3. Ganache helps a lot
36
Cons:
1. No authoritative docs / tutorials or
tools to trust (reliable?)
2. Lots of boilerplate to write
3. API versioning problems
4. Lots of exposure to Metamask UX
5. Unexpected math issues (security)
6. Lots of assumptions about
language/concept familiarity

37. Roadmap
1. Components of DevX
2. Case Study: Ethereum
3. Case Study: EOS
4. Analysis
37

38. Erik (exposure to web dev only) just found out about EOS and wants to
give it a shot.
I found my way through Hello, world and built an ICO-style token but never
actually deployed anything to TestNet.
Case study: EOS
38

39. “Where is the official
tutorial?”
“Found it?”
Searching for tutorials
39

40. “Lots of confusing stuff
around keys and wallets
and nodes right up front”
Install dependencies
40

41. “Wait, so I’m running a block
producing node now? Didn’t
know that… where’s the tail
output you normally get from a
server?”
“Dang, that’s a lot of arguments”
Node
41

42. “Aww yeah, apparently I’ve been
producing blocks the whole
time!”
“How do I turn this node off..?”
Node 2
42

43. “What’s my mental model
supposed to be for this
wallet? I’m opening and
closing and locking and
unlocking it.”
“Not sure what I did but it
gave me a couple of test
users. Cool.”
Wallet and users
43

44. “Seems straightforward if
I knew C++.”
“The CLI doesn’t get me
to ‘wow’ here.”
Hello, World
44

45. “What the hell is a
ricardian clause file?”
“I lost my password.
Where’s help support?”
Errors
45

46. “What’s my mental model
supposed to be for this
wallet? I’m opening and
closing and locking and
unlocking it.”
“Not sure what I did but it
gave me a couple of test
users. Cool.”
Let’s do an ICO!
46

47. “Wait, how do I deploy
this to testnet?”
“Where’s the
`alice.respond_to(SEC)`
command? She’s totally
going to jail.”
We’re rich now
47

48. Debriefing EOS
Pros:
1. Docs are generally pretty
well-written, though lack
educational/concept support
2. Log output is helpful
48
Cons:
1. Lots of detailed steps needed
constantly. Pushing args and
doing compilation gets old fast.
2. Debugging support very thin
3. Resources are still quite scattered
4. Naming is tricky conceptually
5. The default tutorial is boring

49. Roadmap
1. Components of DevX
2. Case Study: Ethereum
3. Case Study: EOS
4. Analysis
49

50. DevX principles
Macro
1. It’s still UX!
2. Version clearly and
consistently always
3. Create canonical tooling and
references if possible
50
Micro
1. LOTS of code examples and
ideally REPLs
2. Focus on microcopy, inline
help and tooltips. Text rules!
3. Errors should include
intent-aware suggestions

51. Zooming out: Blockchain provides new primitives at a cost
51
New Primitives
1. Identity: Accounts, wallets,
ownership, SPAM
protection, universal login
2. Transactions: Micro,
instant, direct (P2P)
3. Cryptography: Verify
behavior, process integrity
More Hassle
1. Cost: Expensive, per-Tx
2. Complexity: Nodes, wallets,
blockchains, keys
3. Performance: Slow vs DB
4. Maintenance: Poor
upgradability

52. Looking ahead at blockchain DevX
1. Need more focus on the small things (eg
microcopy)
2. More IDE’s (both local and web) coming
3. Immediate error support (messages,
traces) must improve significantly
4. Community error support will continue to
improve but versioning is a real problem
(eg Stack Overflow)
5. MUCH better education/tutorials needed
52

53. Thank you!
53

54. Panelists
54
1. Viktor Radchenko, Founder of Trust Wallet
2. Amhed Herrera, Software Engineer at Harbor
3. Jehan Tremback, CEO of Althea (althea.org)
4. Chris Li, founder of Forge Labs