#802 Treasury Proposal: UIs for easier creation of assets on Statemine and asset transfers
Creation of new asset on Statemine for a user who had no prior interactions with this chain is a relatively complex process. Similarly, when doing assets transfers on Statemine, several factors need to be considered to make it successful.
We propose to develop user interfaces, which would create great UX for both processes.
Team:
We're Ethworks, a blockchain software-house. For the Polkadot/Kusama community, we've implemented the Bounties UI and worked on 2 other UI-related grants: 1, 2.
Details:
You can find all the relevant proposal details in this doc
Show More
Overall 100 % of users are feeling neutral. The discussion revolves around Library Extraction in Microsoft for PolkadotJS UI, with questions raised about complexity reduction and flexibility while maintaining generic solutions. Suggestions include developing a new app instead of separate solutions, creating mockups/wireframes, including documentation within each MS, and considering maintenance for future compatibility.
AI-generated from comments
Hello @krzysztof_ethworks
I would have a few Questions & Remarks:
Library Extraction
Q: what is "Library Extraction" in your MS, why not making a lib from the beginning on ?
Complexity vs Flexibility
Q: the interaction is indeed complex as it is very generic. What are your plans to reduce complexity while keeping your solution generic enough so it does not break with upcoming updates ?
Polkadot.js App
Q: instead of a separate solution, did you consider developing a new App for the PolkadotJS UI ? That would save you some DNS & Co work while allowing way more people to run your solution locally. You could also benefit from the many reusable components available in polkadot.js
Wireframe
Q: To support your proposal, I think a mockup/wireframe would help a lot to see where you plan on going. That does not have to look nice so pen/paper works (although Figma does help as well here if you feel fancy)
Doc
R: each MS should contain its own doc and examples, those should not get pushed (and expedited "if time allows" at the end)
Hi @chevdor , thank you for your feedback and questions.
Re: Library Extraction
The idea is to first write a small app, and then extract the parts that can be reusable and useful to other projects and developers. Similar to how some web frameworks were born - eg. Rails were extracted from existing app. The reason we want to go that way is twofold:
- Before we have a small working app we may not guess properly what parts are best shared as a library.
- We want to have a demo app anyway.
In theory, we can go the other way around (lib first, app later). In my opinion it's mostly a matter of developer preferences.
Re: Complexity vs Flexibility
I don't think we will reduce the complexity much. What we'll do is provide a way to easily see the steps, and have feedback on every one of those. Then it becomes easy to create UX guiding through the process.
To be generic, we will make the code chain-agnostic as much as possible. So one will be able to run it against Kusama/Statemine, Polkadot/Statemint or any local or test setup. As for compatibility with future changes, I guess the only reasonable thing we can offer here is maintenance. I'm not sure things like creating facades or other abstractions in the code would help in the fast-moving substrate space.
Re: Polkadot.js App
We've worked with Polkadot.js Apps and we find this environment too restricting in terms of providing the level of UI/UX we'd like to have. Thus, we'd rather do a separate app. That said, it will be possible to use the extracted library in the Polkadot.js Apps. We may even do it as part of the proposal.
Re: Wireframe
Sure, it's possible. I believe we can prepare sth next week.
Re: Doc
Agreed.
Hey @chevdor, here are the figma wireframes. Looking forward to hearing your thoughts.
Discover similar proposals
