Elevating Developer Experience(DX) in Web3 / Sasha Tanase, Daniel Luca

Transcript

laughs hello everyone hi good to see so many new curious faces and hungry to learn some things some new things so let me introduce myself I'm Sasha tanase I'm a designer and researcher collaborating and contributing to the threshold Network formerly known as New Cipher Network and keep Network I am part of the core team who is building tbtc the first fully decentralized Bitcoin to ethereum Bridge and I am also the co-founder of web3 ux user panel I like to say that my job is

to transform extremely complex products into palatable bits and I'm Daniel um I've been in this space since 2017 I was a developer entrepreneur before I started by building an analytics platform as part of consensus I moved on to consensus diligence where I did security Audits and security research I helped found a stablecoin and now I run the tech platform at edenblock and we do investments in seed stage companies So today we're going to learn what is this DX or developer experience what is the impact of DX and we are going to

present you the great guideline which me and Daniel have put together and you will also have an appendix which means that you will be able to check the tptc client code diary study and the Mina protocol diary study so um let's learn what developer experience is well is the equivalent of user experience when the primary user of the product is a developer but don't get fooled by the fact that the primary user is a developer and it means they are highly technical usually the products designed for developers are really bad and the experience is quite traumatic so

due to the fact that developers are more of a technical Persona the products ux owners end up believing the developer is a power user but that's kind of wrong because developers deserve Solutions as well designed as non-technical people foreign users and even though they are like this we throw at them the most cumbersome Solutions power user is a super deceitful term that makes you forget that developers are normal users too and they will appreciate and benefit from Simple Solutions just like everybody else

so we have to kind of help the developers to become power users because they're not power users when they start using your product you have to unlock that potential and that is done you know over time uh you present a new tool a new SDK a new library they're not gonna know to use it right away it takes a little bit of time and guidance so in order to build a developer-centric product you need to make sure that your product is taking into account three pillars best practices user experience and developer needs foreign conference and why should we care about

the X you will ask me well ethereum consistent consistently draws 20 to 25 percent of the developers coming to web3 from January 2022 to December 2022 ethereum monthly active developers Group by five percent which means that ethereum is onboarding more developers and the need for straightforward processes may be higher than ever a positive DX can increase adoption and retention and the growth of a chains developer community and if you're still not convinced here are some stats you can actually check

the report afterwards it was done by Electric Capital developer report okay so a little bit about the importance of DX um over time we've said that blockchain is not getting adoption because the ux is bad and in the last few years we kind of realized that the user in the ux is actually a developer they first need to build something on your protocol in order to bring it to the users so they're not the first person who touches your protocol or what you've built so that means that we have to build things with the developer in mind and helping them on board your protocol

um so for example you might have an SDK an SDK just provides some kind of abstractions on top of your your protocol it does require some resources to build that and um you don't need to know a lot of about the internals of the protocol so an SDK definitely helps in that sense for example you have sdks for unit swap that help you use their protocol which is more complex than it actually seems but the SDK makes that very easily accessible so you have other things like by economy which does a count abstraction and they also have an SDK and then you can use that SDK to onboard Developers sometimes you just have Smart contracts

so that means that you didn't have the resources the time and the people to build sdks you just have those smart contracts so the initial design that you did will affect you quite a lot and will affect the amount of people that understand how to uh expand your protocol how to use it as a Lego piece and build something on top of it but you can also have you can think about developers when you're launching a new blockchain you're not going to have users like users that have web uis right away you're going to have developers they need to build stuff they need to know how to query the chain they need to interact with it directly well you also have web widgets like small pieces of HTML code that can live

within your product um having good DX can reduce the cost of growth so it's much easier to grow your user base it's much easier to integrate and help others use your product and it does it's much easier to scale your product it's also good when you're building stuff to not spend too much time on helping users you have to spend some time so to be connected with them but you want to focus more on adding more features and building more um building more within your product in your protocol okay so I think it's important to

describe that this this framework this great framework is not something it's not a git um repo it's not a template it's more of a guideline it's something that can help you plan your product and help you understand how to talk to a developer how to have them in mind whenever you're creating something it's more like a set of principles and guidelines to guide you throughout the process so okay we start with um G which stands for good documentation uh this is probably one of the most complicated things you have to understand your audience what is their background what questions

do they have do they need help installing tools um it has to be clear and simple in the first stage you kind of want to guide your audience to get to a to a success stage and even if you don't present all the bells and whistles that you have you have to help them Reach that success thing like build the hello world of of the application that initial success will pay for the struggles they can take to build something more advanced um you it also it's very important to have it up to date it's easy to have it up to date when you're creating it right now but it's difficult to keep it up to date over time a trick to do that is

whenever you're growing your team you have new people coming in you don't tell them a lot about your product or about how it works you let them go through the documentation if they find something that is not up to date they can they can do a pull request they can build something so this way you know that the onboarding process for the developer is still smooth of course you need to have examples and tutorials Engineers work very well by doing stuff by writing code by changing that code after that examples and tutorials are very very important and it's good to think about how to organize your information um

you can think of it like you know getting started installing tutorials reference API FAQs all of that but it's important to have in mind that you have to organize your your information another important thing is you have two types of users one user is the developer who will use the SDK or the library to build something and you will have another type of user the one that can be a contributor so they can contribute to what you're building and maybe the documentation will be different in different cases because you need to set some PR guidelines some issue guidelines for all of that so it's

good to have that in mind um now the r starts for for robustness and in software development it's important that the system is robust so that means even in the presence of a stressful environment has to work correctly so you kind of have to be paranoid assume that everybody's trying to destroy your product they're not doing the actions in the right order you have to assume your user is maybe stupid so they don't know exactly what to do and or maybe they forget um dangerous implements refers to protecting in your libraries protecting the things that are shouldn't be

interacted with so that means private properties methods that should be hidden don't allow them to be used directly if they shouldn't be interacted with and it can't happen is that you might have a few things that are very very unlikely to happen so you assume that you shouldn't do anything there you should still write code that protects your users for for from that okay so now I have an example that tries to lay out an example of robustness let's say we have this class so people will instantiate this class they need to call connect and after that they can call get

to extract data a user might instantiate the class and use get right away without connecting so what you can do is you can add connect in the Constructor you're protecting the users from themselves what if for example you don't want to connect on instant serialization so you might add something like an argument that is defaults to true but you can set it to false so it doesn't connect right away so you're kind of trying to protect the user from itself every time foreign stands for error handling which is

crucial for any system and in order to have good error messaging you should label them correctly which means the error will communicate to the user how important this error is if you label a fatal error as an info you will mislead the user and they may suffer big consequences because of that this will make the user lose trust in the product and even stop using your product you have to be specific which means the error message will tell the user exactly what is wrong and can help guide the user towards a solution the error message needs to be instructive and verbose verbose error message will

describe in detail what is the issue the user encounters and will have a hold hand approach by telling the user what are the next steps and what they actually need to do in order to solve the error you have to be non-blaming when you're writing your error messages it's not the user's fault that you haven't given them the exact information and you haven't offered them good instruction you would also need to do error messages in plain language even though the errors are addressing the devs explaining an issue in plain language will go a long way and it's better to avoid using terms that you've

coined and nobody else understands you would also need to add severity grades it's super important because and this way the user understands what's the impact within this system and then you can also add error codes this way a user can see exactly in the documentation the code and help them troubleshoot and what do you think guys this error is telling you what it doesn't matter what you think because the issue with this error is that whenever you would have an error this

would show so not very useful how about this error well this one is definitely better but it can be improved right now in this error we don't know what uh address needs to be registered and also we have to know where the threshold dashboard is by heart we don't have a link okay so regarding accessibility I think it helps a lot of its Community First um you're gonna have developers who first find your GitHub repo and that has a readme with installs and whatever

try to onboard them in the community first so like make them join the Discord server or the telegram whenever they have problems they're not going to be stuck waiting for you to respond the community can help that helps tremendously um make sure that you provide support So when they open issues PRS even with PRS help them write better code help them respect the standards no barriers to entry or low barriers to entry means that you it's good not to have you know um credit card if you want to test the product or Implement something or it's even easier if you have a testing environment that can people use

um no email confirmations whatever temporary or permanent uh for example temporary impairments are when your user may have a broken arm or they may be drunk or high however there are also uh permanent impairments like users who are color blind or they have astigmatism such as myself so every time you're designing something it's no matter the duration of the import impairment you should actually be super inclusive and

make sure you accommodate any type of user and Festival we have a right to the last one possibility is extremely critical for the developer experience because it impacts maintainability reliability and overall the quality of software if you want to do documentation testing and task success the easiest way in web 3 is to set up a diary study which is also known between researchers as the poor man's ethnographic study um we have a couple of examples by the end of the presentation uh you will need

a minimum of five participants you will give the participants a big task like let's say setting up a node and you will give them a longer period of time to finish the task this will allow users to complete longer tasks and you will need to be there observing them living and breathing onto their necks and because they're going to log into their Diaries all of the actions they have needed to take and all of their all of the emotions they're experiencing regarding modularity your system can be modular so if you want to test

only a part of it you can kind of fast forward the user to that step and that helps testing with very very specific specific things but also helps with development and integration tests and all of that deterministic helps if you can reproduce the errors you can reproduce the states can you actually save the state and regenerate it at a later stage and it helps a lot if you have a testing environment and also can be kind of a development environment think of it like GitHub um code spaces where you can just instantiate a machine that is on top of a GitHub repo

we learned how it impacts a product and we also learned the great framework which stands for good documentation robustness error handling accessible and testable we also added a couple of links you can check out to see later on about the studies where that we have conducted but there's no problem we also have created the QR code and you can actually check the presentation deck and you have everything there thank you thank you very and um any questions um have you built your own tools to

actually make this this developer experience a little bit uh more concrete maybe more tabularized than in the current docs.project dot whatever because it's very simple there it's not really open sometimes people it's still quite let's say scattered the communication of the community in a Discord then there's a docs and and so on so there should be something better than Discord we all know that but have you built your own tool so um we did started working on a framework the thing is we kind of need to develop a framework for typescript or for go for rust for all of that and then

you can add some good practices within the repo so like the CI will Auto generate documentation for me or I have some good templates for issues or for PRS and that helps a lot but it definitely doesn't solve all of the issues because I'm not going to have too much communication on GitHub even though you can have uh Wiki you can have uh something like a forum on GitHub so you can actually do that people are not necessarily used to that so we are working on something like that but I don't think we can provide something that solves everybody's issues because everybody wants things a bit different so we're gonna

launch this I think at ECC but everybody can do their own it's just a good set of practices no thank you see you at ECC [Music] okay thank you [Applause] [Music]