Closed toiletgranny closed 1 year ago
KubaMikolajczyk
commented
2 years ago (2nd iteration) Pen & Paper Loom: https://www.loom.com/share/9e188dc25a2e464c9049958a3a4f35f1 Files: https://www.figma.com/file/VzPBMpUnGjGOHMSW2ZHbGY/Creator-tokens?node-id=1227%3A42024
toiletgranny
commented
2 years ago Rough note re next steps for this week (mid-fi):
KubaMikolajczyk
commented
2 years ago Mid-fi Mockups are done and all are described in the video below (23 min - watch in x1.5). Loom: https://www.loom.com/share/29af5710d62b4bf19fee9037d8591f74 Files: https://www.figma.com/file/VzPBMpUnGjGOHMSW2ZHbGY/Creator-tokens?node-id=1698%3A124955
dmtrjsg
commented
2 years ago Firstly, thank you @KubaMikolajczyk for this video, sheer excitement to watch and very well executed designs! Overall this is one impressive piece of work 🏆
Comments:
Multiple Recipes
Price Widget
Scrolling
Holders
Vesting and Cliff
Screen 1
Screen 2
Screen 3
bedeho
commented
2 years ago Fantastic video, just loved it, and the fact that you made these demos - in made everything so crystal clear.
Be aware that we don't reall have a distinct sense of being a verified channel vs. a verified token. If we signal a channel as being verified by having a checkmark or something, than it seems sort of inconsistent to have this second verification symbol along the ticker. If what we really want is some sort of warning or something, then perhaps we should be communicating that in a very specific way, because its not even clear what it means that $TJS is Unverified, the way it is presented now.
I think a major characteristic we have to communicate early is the situation where this token is permissioned, and also indicate to the user whether they are in fact among the set of people who can hold the asset, or perhaps already does? Understanding this is also relevant to your ability to actually buy the token.
It would be good if there was some action the user could take to get in touch with issuer to learn about getting on the whitelist?
I think we should also show something like when the token was launched?
As I have said before, the nominal price of a token does not really have much meaning, because different tokens have different supply. Really marketcap is the real indicator of value. At pest, showing price as a second field can be relevant, but I would show supply as well.
It is misleading to think in terms of large cap assets like BTC or ETH, where unit price is really important, because most of the time, the person viewing this page has never seen this asset before, and also, supply dynamics may be much more volatile compared to this big established assets.
I think the two distinct sales need to be more clearly distinguished. They have very different terms economically (fixed price vs increasing, timed vs. untimed), and the distinction should be visible in some way. For public sales, do we have some sort of standalone page for the sale? if so, we shuold def. allow opening this.
As mentioned above, we should take into account the case where the user cannot buy because they are not on the whitelist. Showing a Buy button+failure dialog is not great in these cases.
Note 1: There is no reason to have a distinct Sale ended variation here, this is such a unique state which there is no direct purpose in communicating on this page. When the creator closes the sale, the AMM is not automatically opened, so there is no reason to treat this state as different from simply there being no public sale or AMM active.
Note 2: The only reason to show the Active revenue split is to show a paused sale, so if there is no sale ongoing to begin with, we do not need to show this variation.
The intro video is really really key to this experience, but I think we are missing the fact that almost no creators coming and trying this out will have such a video to begin with, and most will not go out of their way to stop creating a creator token, producing a video, then coming back and using that video. They will all just skip it, and they will only set the video to the extent that they find they are having some success with the experience. In the future when the product has been shown to work well, then creators will probably know to do this from the get go, but we cannot expect this level of investment for early stages of our product.
This means that we need a really solid variation of this page where there is no video, and probably should be thinking of that as primary. Simply omitting the video and moving all the content up may work fine.
I think this actually also will even apply to the about section and benefits screen, we need really robust empty states here, and we should not assume its in general going to be very long
The main goal here, as I understand it, is to give a more detailed breakdown of what is on the page, and far along you are, so as to manage the otherwise long page we expect this to become.
But given my claims above, I think it actually solves for a problem we are very unlikely to have near term. I would much rather add this once we end up seeing big long pages and things getting wieldy. Adding it later has no overhead that I can anticipate.
I also think the potential for how much heavy lifting such a ToC can do is unclear, becuase the page really only has two sections as it stands: Benefits + About. I dont think it makes sense lifting out substructure from these sections into the ToC, as I don't think people will read them there.
This looks great, but I am afraid this is just way way too complex on the composer side, in particular embedding and uploading images is going to be significant work, but also non-standard things like dividers and Joystream specific embeddings. I would suggest we just go with a bare bones text only Markdown editor, where we can get something off the shelf that we can style, and thats it. We are doing something similar in Pioneer. We don't want to sink lots of resources into this part at this stage, because it's not a key part of the product thesis. Again, extending this later has no overhead that I can see.
LOCKED, show % of their own holdings that are vesting. I think we also should change the title here to be VESTING specifically, because tokens can also be locked just to revenue splits, but those are very short term constraints, and not what people are looking to learn, but it can be really misleading if you read this table at the wrong time.As Dmitry says, there is really nothing meaningful like this we can show here. Also, you want to think of these schedules as showing how much you can access as a function of time, and so it would be increasing monotonically, like Dmitry points out.
So I am not really sure about this one column vs to column question. I do think the problems you mention with the one column page seem soluable, specifically
What makes unclear to me still is that I feel like I don't know which one of the two approaches: two column vs (fixed) one column is able to best deal with waht I assume is going to be the dominant state of this screen for the next 6+months after lauch
Which one deals best with this?
Buy $TJS: public saleTokens to exchange: Here I agree that how much you are getting needs to be really prominently emphasised, and also this title is very indirect, should be something simpler like Spend or Use or something.Since we will need some visual way to show vesting schedules, I would show that here as well,as people may not understand these terms like vesting and cliff in isolation. In general I am a bit concerned about whether people will understand this idea that they dont get all the tokens liquid right away, even with such visuals.
Looks good!
I really like the ideation here, but I want to yet again try to start simpler. So lets just do the simplest thing we can, which is to just distinguish holders from non-holders, I feel everything else goes outside of MVP scope.
bedeho
commented
2 years ago Worth adding some price dynamics to the widget e.g. over last 7 days? as a small undercopy
I don't think this is worth the effort now. Price charts carry no real information, its just a decoration in this context. Perhaps the only value is that it signals some sort of trading activity, but very indirectly, if we want to show this, its better to just give a trading volume number or something.
We've discussed two-column scrollling in context of comments and reactions and arrived to conclusion that full page scrollable would work best (usability, smaller screens, mobile), so suggest to maintain this approach here as well.
I very much agree. I would be concerned about it not just being inconsistent, but also providing a bad UX because the user may end up inadvertendently scrolling the wrong area, and having to be much more careful about this than they are used to.
To my memory we agreed to remove this generalised chart from this page. (worth adding to checkout imho so will add this point below for diff screen)
For Token Value Fiat denomination, suggest to show value in USD instead of X usd = 1 joy. This way we save user from calculations in their head.
Perhaps both? Could there not be a need for seeing also just $JOY price?
You will receive "X" - I think this warrants a bigger font, almost similar to what you invest. Emotionally this would ensure some sort of parity, without sub-conciously dwarfing the value of acquired tokens.
100%
Vesting and Cliff chart here will be easy to do, so worth adding here?
Agreed.
KubaMikolajczyk
commented
2 years ago Thank you @bedeho for your feedback - let me ask you a lot of questions :)
Verification. Be aware that we don't reall have a distinct sense of being a verified channel vs. a verified token. If we signal a channel as being verified by having a checkmark or something, than it seems sort of inconsistent to have this second verification symbol along the ticker. If what we really want is some sort of warning or something, then perhaps we should be communicating that in a very specific way, because its not even clear what it means that $TJS is Unverified, the way it is presented now.
Are we going to implement some kind of verification into the system for those 2 verifications or are those going to be done manually over discord? I will change the way to communicate the unverified state for the users.
I think a major characteristic we have to communicate early is the situation where this token is permissioned, and also indicate to the user whether they are in fact among the set of people who can hold the asset, or perhaps already does? Understanding this is also relevant to your ability to actually buy the token.
Will do.
It would be good if there was some action the user could take to get in touch with issuer to learn about getting on the whitelist?
What do you have in mind? Like a chat? Or rather a modal they can display with rules? I would suggest the latter - a simple modal trigger by some btn on token page to show the whitelisting rules - there in modal creator could write a simple msg and include a link to the external platform of their choice. That should be easy enough to implement and we should cover the issue.
I think the two distinct sales need to be more clearly distinguished. They have very different terms economically (fixed price vs increasing, timed vs. untimed), and the distinction should be visible in some way. For public sales, do we have some sort of standalone page for the sale? if so, we shuold def. allow opening this.
We have a standalone page for creating a sale - all purchases, sales, transactions in the viewer and holder part are using modals. Even if we would create a standalone page - there is no much more to present than on AMM sale - as the only thing that public sale has which AMM doesn't - is the amount of tokens on sale.
As mentioned above, we should take into account the case where the user cannot buy because they are not on the whitelist. Showing a Buy button+failure dialog is not great in these cases.
Yes, we need those variations for the whitelists badly - experience described above is a no go :D
Note 2: The only reason to show the Active revenue split is to show a paused sale, so if there is no sale ongoing to begin with, we do not need to show this variation.
I will make two different paused states - one when there was a sale and second when there wasn't.
and most will not go out of their way to stop creating a creator token, producing a video, then coming back and using that video.
Adding a video intro, benefits & about - should not be a part of creating token experience. I'm designing it right now to be a separate element which you can trigger after creating a token - this way the creator has time to come back to it and change it when the intro video is ready.
I think this actually also will even apply to the about section and benefits screen, we need really robust empty states here, and we should not assume its in general going to be very long
I will work with little to no content situations too. (But my token page will be really long though 😅 I feel it)
Table of Content. But given my claims above, I think it actually solves for a problem we are very unlikely to have near term. I would much rather add this once we end up seeing big long pages and things getting wieldy. Adding it later has no overhead that I can anticipate.
Alright, I will leave it to post MVP.
About. This looks great, but I am afraid this is just way way too complex on the composer side, in particular embedding and uploading images is going to be significant work, but also non-standard things like dividers and Joystream specific embeddings. I would suggest we just go with a bare bones text only Markdown editor
As I work currently on the publisher part of this experience, I researched few libraries for using markdown and it looked like embedding the image is included in all of them - maybe its not that huge element to be included in the scope - as I feel that it might be really wanted by the creators. I hope we could leave this as a part of the scope and that you will change your mind a bit after watching a new update from creator/owner experience and adding those elements. (Additionally I have to add that we are speaking here about embedding an image which is hosted outside of the platform - at least for MVP - if that changes anything :) )
Token details. What is "transaction volume", is it
Transaction volume would be a total volume of all transactions with this token, something opensea is using to show how "busy" certain collection is. They call it total volume
I don't understand what the % change indicators are for total quantities. Like total revenue, the % change must refer to some time period, which is here unstated. Given that I am suggesting we go for totals only, I would just drop them, even though they bring a nice visual balance to the box.
In this flow I put the information about time in the tooltip that is shown when you hover over the pill with the change. And there are also other ways we can use to state the period of time for those changes. With that said I'm trying to see if you feel definite about removing this as this can not only bring a nice visual balance but more importantly serve the purpose of getting you some valuable indicators with just a quick scan. You can quickly scan multiple pages and track their changes but instead if you can only rely on totals - theiy can give you less information about the tendencies in the project.
As Dmitry says, there is really nothing meaningful like this we can show here. Also, you want to think of these schedules as showing how much you can access as a function of time, and so it would be increasing monotonically, like Dmitry points out.
Do I understand it correct that you want to remove the vesting & cliff chart? Or you just suggest to make it increasing monotonically like Dmitry pointed out and still keep the chart on the page?
Composition. Which one deals best with this? -
I will find out which one deals better with all scenarios :)
Buy $TJS: public sale. I think you should also add a line for how much the issuer is receiving explicitly, since they are a beneficiary during a public sale.
So the creator/owner of the token receive some amount from the public sale - are they also going to receive a small % from the AMM sales?
Since we will need some visual way to show vesting schedules, I would show that here as well,as people may not understand these terms like vesting and cliff in isolation. In general I am a bit concerned about whether people will understand this idea that they dont get all the tokens liquid right away, even with such visuals.
Do you suggest we should add the chart here ? (Do we keep the chart of the vesting in cliff on the token page in token details?)
bedeho
commented
2 years ago Are we going to implement some kind of verification into the system for those 2 verifications or are those going to be done manually over discord? I will change the way to communicate the unverified state for the users.
Well first off, what I am saying is that there is only one verification discussed up to this point: for the channel.
How exactly this happens depends on the policies of the DAO, they will need a uniform way that works across a range of applications built on top of Joystream, not just Atlas.
I think we should not dwell on this for now, it's of secondary importance.
What do you have in mind? Like a chat? Or rather a modal they can display with rules? I would suggest the latter - a simple modal trigger by some btn on token page to show the whitelisting rules - there in modal creator could write a simple msg and include a link to the external platform of their choice. That should be easy enough to implement and we should cover the issue.
I think we need to standardise the way the creator informs users who can get verified, if any, and what they should do. So I think we should allow the creator to control whether display any such information at all, if they opt for "no", then we don't show any sort of "learn more" or similar button. Assuming the creator wishes to explictly describe who can get verified, and how they can proceed, we can allow the creator to provide perhaps a short two sentences that we display, and then a URL where they can redirect the person. This URL could be a Discord channel, a forum or whatever they like.
This is relatively low effort on our part, but still leaves it flexible however creators want to connect with third parties.
Additionally I have to add that we are speaking here about embedding an image which is hosted outside of the platform - at least for MVP - if that changes anything :) )
It helps, but I am still sticking to my guns here :D I see no penalty in simply doing it in a later iteration.
Do I understand it correct that you want to remove the vesting & cliff chart? Or you just suggest to make it increasing monotonically like Dmitry pointed out and still keep the chart on the page?
Remove it, it really does not make sense in general, a single person may be subject to many different such schedules at the same time.
The only alternative here if we want to distinguish a single schedule is to describe it as something like "initial vesting schedule", and only display it while it is in effect, but I don't know if people will fully understand.
I think I would just opt for not showing it for now, it can be added later without penalty, and with the benefit of more information.
So the creator/owner of the token receive some amount from the public sale - are they also going to receive a small % from the AMM sales?
The owner receives everything from the public sale, minus whatever cut the platform takes. The owner does not receive anything from AMM sales.
Do you suggest we should add the chart here ? (Do we keep the chart of the vesting in cliff on the token page in token details?)
Yeah basically.
KubaMikolajczyk
commented
2 years ago I agree with your feedback above thank you for taking your time to reply. Just one question:
The owner receives everything from the public sale, minus whatever cut the platform takes. The owner does not receive anything from AMM sales.
Deso has FR (which is a founder reward)- it's a % that creator gets from purchases of his coin - they also use AMM - they give a cut of the money to the creator from sales. And I think we should have a similar option, otherwise, there is no point in selling your coin over AMM as you literally give away your revenue split shares for no income. It wouldn't make sense to not reward creators from AMM sales. Do you see it differently?
bedeho
commented
2 years ago And I think we should have a similar option, otherwise, there is no point in selling your coin over AMM as you literally give away your revenue split shares for no income. It wouldn't make sense to not reward creators from AMM sales. Do you see it differently?
If one assume the market price in the AMM does not already reflect the value of future splits, then this is true _but the creator only cares to the extent he is a $CRT holder also. But keep in mind, Deso also has this, the coins are initially quite cheap, and you have to buy them yourself to capture the value. Moreover, keep in mind that if you still think the problem is very severe, then the transaction fee on AMM sales really will not help. Remember, there is no direct link between AMM fees and the value of $CRT sold, if price of $CRT is too low, which is what you are assuming. So you will still give the creator possibly way less revenue than the real value of the $CRT which is duliting their holdings. Lastly, keep in mind that the AMM featuere is not meant to be a revenue driver, but liquidity, and that helps the creator both directly and indirectly, and so that important benefit has to be balanced against the risk of dilution.
For these reasons, as well as avoiding changing this feature so late, I say we ought to just keep it as it is for now. This can be added later.
This phase can include activities such as sketching, prototyping, and discussing potential solutions internally, preparing for conducting usability tests (work tracked in a separate issue).
The expected outcome is a video walkthrough of happy paths for all user stories mentioned in the epic, along with links to Figma designs and prototypes.