These are some questions about theme customization and how it can fit into the flow of a no-code/low code one-click-deploy method.
Based on the Figma:
When getting started with the Flexible DAO Interfaces template are people navigating to the Public Assembly DAO site? or a separate Flexible DAO Interfaces Demo Site?
- When users click “copy our template” where does it take them? A separate deploy site from the demo site? Similar to how Neosound has a deploy site, - or - would it be better to have the process of preparing contracts and themes happen within one site?
- I started to think about why there would potentially be a separate deploy site. My initial understanding is that it’s because there are multiple values that would need to be initialized if people want to use the onchain theming route.
- Something I think we should take into consideration is that there’s only one ThemeRegistry that exists for flexible-dao-interfaces/PA. Is the goal to help DAO’s establish their own registries and promote the concept of an “onchain brand kit’? This would be cool because it can help promote consistency and data integrity amongst multiple products coming out of DAOs. (ex: After they have a DAO site, then can reuse their themeRegistry to build a DAO wallet application with the same design tokens.)
If there was a deploy site, my first thoughts on the steps towards a vercel deployment would be:
1. Users deploy a DAO site AdminAccess contract.
2. Then they deploy their own ThemeRegistry. (You need an access contract for this step)
3. Then, if they don’t already have a JSON with design tokens for their theme prepared, they use presets from the PA ThemeRegistry (can they?), - or - would it be better that they use the “Theme Editor” to set those values right way?
With preset themes (Light/Dark/Stylized) we can promote consistency, but an open-ended custom editor , similar to the one that was illustrated in the proposal can promote more individuality. The one concern with having a custom theme editor with sliders is that there are constraints with letting people decide whatever value they want, because not all values can work for the design template.
However, a slider can still work if there are predefined values and things like a ranges of fonts. I am having trouble understanding if this is a different thing than a single theming json file and I’m not sure this can be initialized onchain in the registry.
Also, If they make their own theme from an editor would they be able to export their new theme as a JSON file? Even if we aren’t doing onchain theming, exporting the theme json could be cool.
4. Next steps, if can export/prepare a JSON file with design tokens, then they would have to upload the JSON file to IPFS to receive a URI link. (Can this step be automated?)
- After they have a themeURI link, it would need to be initialized to the deployed themeRegistry from step #2, this is a onchain transaction that results in the user being provided a dataContract address (0x27248fghs), and themeIndex. Update changes to an existing theme within a registry is also a transaction, so how difficult is this?
- What’s more useful for theme creators to remember: the themeURI, the dataContract address, or the themeIndex? I understand that all these point to the same json in the end.
5. After the new theme is initialized in the ThemeRegistry, would they deploy the template to Vercel with these environment variables:
1. chain ID, (Mainnet or Testnet)? 2. DAO address?, 3. DAO site admin access pass?, 4. DAO themeRegistry?, 5. Alchemy Provider?
- Should users be a DAO member to be considered admin and control the theme of the DAO website? Is there anyway we can use the Nouns Protocol hooks to make this access process smoother? Can the template be deployed without DAO address initialized?
- Can we consider that some people may not already have their DAO address before doing this step, if they don’t have a site they can’t deploy their nouns builder DAO.
- How does the registry know what theme is the default to upload the site from?
- Can I see how a front end application would fetch a themeURI from a registry to make into consumable CSS objects?
- I am thinking about if there is supposed to be a custom hook for any IPFS themeURI link to be consumed into the template, was that something that was discussed already?
- After you save changes to an existing the theme, is that a transaction to automatically add it to the registry? Can they update/chose which themeRegistry to save it to?
- When adding people to the site admin contract why does it have to be an ABI of the admin instead of something like the regular address or ens name?