Jonny, Barry and I had a really great call with Jouni and Pierre from Aragon and Simona from bounties network. We all want to build a design system together, and they have both made really great starts, which they are going to integrate under https://lorikeet.design. Pierre is working on moving everything from https://ui.aragon.one across, and Simona will make sure all the https://components.bounties.network stuff gets put in that repo too, and that we figure out how to split "base level" components from branded ones, such that we can really develop the framework for an ongoing and neutral community design system that can be used easily by anyone. I really think this is an awesome opportunity (having tried to organise this kind of thing before, largely failed, and having learnt some lessons along the way).
a. We have a common repo, and people with the necessary skills, time and commitment have all agreed to work in it: https://github.com/lorikeetui/
b. A lot of the initial work has already been done by Aragon and bounties.network - both teams known and awarded for their designs. There is an email thread summing up what they will be doing as next steps.
c. We all use the same tools - GitHub, React, (even including React Spring and other animation frameworks) and Figma.
d. This sort of interoperability between projects is rare, and is a big opportunity to do something broadly useful, not just design in silos.
e. This should actually help align our design at Status in general more with community standards and needs.
I cc’ed Andrei and Maciej into the thread, but would like anyone and everyone’s feedback on this if you feel so inclined.
Makes sense, watched the lorikeet demo at devcon and was impressed. Post Devcon I’m left with the impression that success is tied very closely to collaboration with other orgs in web3 that have similar principles to ours.
After checking out Aragon’s manifesto I think it overlaps with our principles nicely.
Was an area of design discussed and where we can add value? For DAO’s to work, there needs to be communication between people. We have a wealth of knowledge about decentralised communication and designing for it. I think there would be nice synergy for design the communication components when partaking in a DAO or chatting with a bounty member.
Hey @Graeme - yes, indeed. As mentioned, BN has most of your basic “web2” https://components.bounties.network done. Aragon can fill in the rest, and are also beginning work as they mentioned at DevCon on “multi-stage components”, like those required for pending transactions.
I think we can most effectively help by coming up with and building some “DApp-specific” components based on our existing work with he voting and ENS names DApp, and that we can also help significantly on the design side of things, seeing as we all agreed to use Figma and GH which is exactly our current workflow anyway. There’s no need for a DAO or anything fancy here either: we have a common set of needs (enable DApp developers to use and build interesting stuff easily), a common set of tools (React, Figma, GH, even the animation frameworks like Spring we all share!), and people with the skills to pull it off - hence my punting this so hard.
Ya the front end work on both Dapps took long due to creating or modifying the components from material UI. I’m sure the results page + quadratic vote picker would be of interest, they have taken the most amount of work out of the voting dapp front end work.
Here are my more considered, and (hopefully) more general thoughts.
What is really “blocking” the design team?
Yes, there are conflicting personalities and views. In the case of @Ned, I think this is fine. I’m excited to see what he comes up with for the branding and websites and think that is a great place to start with more experimental and orthogonal things. But is this really the root cause? I don’t think so. I think it’s simpler: there is too much work, and not enough people with the right skills to do it.
How do we fix this?
Is the right approach to try and hire more designers and developers specifically to work on component libraries and “internal” needs? This doesn’t seem to have worked very well so far, if you’ll forgive me saying - https://design.status.im has been live for many months now.
As an illustration of the sort of broad (and rare) skillset we really need, and one of the many answers to why this project is qualitatively different to something like Material Design: who in Status even knows what radspec is? Who has an opinion on whether we should have components that support it out-the-box? (@julien and @yenda other examples include pretty much all “multi-stage” components that handle any “blockchain” logic: peding txes, signed messages etc. Also, non multi-stage components like long address strings).
I think the right approach is to collaborate with the people who have already demonstrated that they have the necessary skills; help them build components we will find useful at Status, but do it in a shared repo, and build them in such a way that they are neutral first, and can then easily have Status styles applied if needed. If we contribute only what we need “internally”, but using this method and repo, then we can essentially kill 2 birds with 1 stone and (hopefully, if we get it right) we can have our cake and eat it, too. (We can also endlessly string bad cliches together to our heart’s content )
@julien and @andrey this does actually bring up a good, slightly longer-term question.
What is the progress with being able to load custom code in extensions? If we can’t do that, then I agree, we’ll need to discuss more what developers building with Status tools will need for their lives to be super easy. However, I really would think it would be a whole lot more awesome if we could load custom code someday i.e. building with Status toolsought to be exactly the same as building with other tools except you get to go to Pluto if you want, too…
Not sure if it is relevant to how extensions will be written, but it jogged my memory of App Store guidelines:
2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps.
Am I right in assuming that that is why you both want some sort of language-agnostic spec that could be used by people building extensions? Could you detail a little bit more about what exactly that might look like beyond a Figma library like this?
Extensions will just reuse and expose whatever components are already created at the status level. I don’t expect that we will need much more than what is already available.
Something like figma is perfectly fine.
And here I was dreaming of whole DApps as single extensions with their own custom interfaces that could even sideload in chat like that WeChat example @Graeme once showed us, or exploding red envelopes and other surprises Thanks for the clarification though
)
Thanks for the clarification though 