Joystream / atlas

Whitelabel consumer and publisher experience for Joystream
https://www.joystream.org
GNU General Public License v3.0
100 stars 45 forks source link

Mention Content Focus for Atlas GW onboarding flow #3319

Closed dmtrjsg closed 1 year ago

dmtrjsg commented 1 year ago

Context

Multiple gateways set up covered here will not rule out content-vertical focus, as a way to build up a congruent value proposition by external operators.

Gleev, operated by JSG as the prime example of this case is planned to focus on Web3/ Crypto vertical only.

For the benefit of end users of Gleev the idea is to inform them on all entry points to the app, about the specific focus of the app, be it content, business model, cause or any other point of differentiation.

This issue attempts to capture all relevant places

YPP adaptation is covered in a separate issue:

:point_up: Importantly the designs (and implementation) must be done in such a way that will make it easy for external operators to configure this content to their purposes without rebuilding the pages in a custom ways.

Scope

  1. Introduce a global variable allowing gateway operators to describe the app's content focus so that it can be later referenced in the UI. Ideally, the content focus description is contained within 25 characters (at most), and a few examples of usage are provided for a gateway operator, e.g.:

    • "Your {{contentFocus}} creator journey starts here" Example: Your web3 & crypto creator journey starts here
    • "Welcome to {{appName}}, a video platform focused on {{contentFocus}} content." Example: Welcome to Gleev, a video platform focused on web3 & crypto content. >> this will be hardcoded on Gleev side.
  2. Introduce an App KV component based on the designs, docs, and changelog, which can be found here

    Note @drillprop Please let me know on Discord once you get to this, as we need to discuss the matter of keeping illustration assets in the Figma file. Thanks!

  3. Introduce a Welcome dialog component based on the designs, docs, and changelog, which can be found here,

  4. Update the Sign in dialog component based on the designs, docs, and changelog, which can be found here,

  5. Update the Studio welcome screen based on the designs, docs, and changelog, which can be found here,

┆Issue is synchronized with this Asana task by Unito

toiletgranny commented 1 year ago

Alright, @bedeho, @dmtrjsg, @kdembler, my recommendations for addressing this issue are ready to be reviewed! Find out all about it from:

dmtrjsg commented 1 year ago

@toiletgranny nice work, we've got all of the ingredients to finalise it, well done!

Comments:

 Creators

ahah before I watched further typed the below 😅 and seen exactly that later down the line. So yes we need

Copy and imagery update are good, but we need to re-inforce the message that this platform content is curated and solely focussed on the broad theme of Web3 and Crypto. Perhaps membership creation is not best for this as may result in drop outs more than we want, but for the create channel journey the info banner I believe should be inserted very prominently as this is v important for creators specifically to get it. For Gleev the interstitial message could be as strong as "non-crypto content will be curated out and consistent violation of content vertical may result in membership blacklisting" + I acknowledge checkbox In terms of implementation safest to make all compoments configurable from some sort of a config file customisable interstitial with headline + image + paragraph copy + cehckbox + cta.

@bedeho is there a possibility / does it make sense to say that we can blacklist memberships with repeated violation?

Viewers

Welcome to Gleev - good idea. Cookies - let's pls keep separate.

The important part that it has to be easily customisable, not only for content verticals but for a cause/ business model possible specific variations of the gateways.

 Other points

Welcome interstitial backgound image: Let's be frugal on the scope and implement the static image. Easier to customise and welcome interstitials usually people just skip so imho not worth overinvesting

Re little menu - too early to predict what the spread of the instances is so I would not go with this particular approach. ☝️ however its a very good idea to have a backlink to other Atlas instances, the page we are doing as part of marketing website redesign. but let's not highlight the categories pls.

dmtrjsg commented 1 year ago

Draft issue is created:

bedeho commented 1 year ago

@bedeho is there a possibility / does it make sense to say that we can blacklist memberships with repeated violation?

Currently no, but its not clear that it would really work anyway, if someone is motivated to just publish regardless of the mismatch, they can change their info and just reupload videos again.

bedeho commented 1 year ago

Nice job!

dmtrjsg commented 1 year ago

@bedeho not against this

and overloading the otherwise just annoying cookie thing was a great idea.

but would this not be going for less flexibility from the customisation POV?

My reasoning: interstitial may be optional, while cookies is common for all.

toiletgranny commented 1 year ago

@bedeho: Just to set the stage: my assumption is that the way a creator lands on the studio sign-in page is via some action ni gleev, e.g. YPP landing page, not Joystream.org. I expect almost no creators to start there.

Either we mean the same things but use different names, or your assumption is wrong. The Studio landing page (Figma link) is where you're redirected upon clicking on the "Claim your channel" button on Joystream.org, or "Sign up now" button on YPP LP.

@bedeho: [...] If we see everyone struggling with dealing with Figmal, or making bad screenshot versions, then we could double down on this component approach, but even then we would need to leave it open for people to do something totally different.

Noted.

@bedeho: Tweaking the copy seems like a super potent and cheap approach, worked very well, together with the new visuals it should do the trick for anyone paying any attention at all. @dmtrjsg: Copy and imagery update are good, but we need to re-inforce the message that this platform content is curated and solely focussed on the broad theme of Web3 and Crypto.

I'm not entirely sure, but it feels like you, @bedeho, found the copy and visual changes enough, while you, @dmtrjsg, voted for including this Content focus dialog on top of it. If that's the case then I'd need a final decision regarding this Content focus dialog (Figma link) and the blacklisting aspect.

@bedeho: Content focus dialog seems like a nice touch, and overloading the otherwise just annoying cookie thing was a great idea. @dmtrjsg: Welcome to Gleev - good idea. Cookies - let's pls keep separate. + but would this not be going for less flexibility from the customisation POV? My reasoning: interstitial may be optional, while cookies is common for all.

@dmtrjsg I agree about the lost flexibility ease of customiztion, but displaying two popups at once during your first visit is a far worse situation. For this reason, I'd again vote for keeping cookies and welcome message as part of the same modal.

@dmtrjsg: Welcome interstitial backgound image: Let's be frugal on the scope and implement the static image. Easier to customise and welcome interstitials usually people just skip so imho not worth overinvesting

I'd say dynamic thumbnails are 50% of what might make this dialog effective. I also don't think this will cost a lot to implement: we're fetching the most popular videos anyway (In the "Most popular" section on the homepage) so it doesn't seem like a huge overhead to just reuse a few thumbnails in the dialog (@rafalpawlow, @drillprop can you guys confirm or deny while @kdembler is away?). I'd strongly recommend for keeping the thumbnails dynamic.

Regarding the "Easier to customise" part, just wanted to make sure my understanding is correct that even if I, as a gateway operator, don't appreciate the genius and excellence of the default welcoming dialog, I'm still able to change the code of the app to, for example, scrap the dialog completely, or just replace the entire image section with something else? Is this correct?

@dmtrjsg Re little menu - too early to predict what the spread of the instances is so I would not go with this particular approach. ☝️ @bedeho I think the icon system thing was a bit much, I don't think it would help that much, but most importantly it would not really be feasible.

Noted, although I feel like I need to clarify that my intention was to display Joystream-level categories there, not the "display" ones.

rafalpawlow commented 1 year ago

I'd say dynamic thumbnails are 50% of what might make this dialog effective. I also don't think this will cost a lot to implement: we're fetching the most popular videos anyway (In the "Most popular" section on the homepage) so it doesn't seem like a huge overhead to just reuse a few thumbnails in the dialog (@rafalpawlow, @drillprop can you guys confirm or deny while @kdembler is away?). I'd strongly recommend for keeping the thumbnails dynamic.

Indeed, this should not be a big problem from a technical point of view. On the other hand, I am worried about three things. First, if for some reason a few thumbnails are not available, it will completely ruin the visual effect. Second, you have to reckon that you may need some loading state until the query and asset are resolved. And thirdly, you lose control over the visual aspect of the dialog, it may happen that something you wouldn't necessarily want to greet the user with appears there. WDYT @drillprop?

bedeho commented 1 year ago

Copy and imagery update are good, but we need to re-inforce the message that this platform content is curated and solely focussed on the broad theme of Web3 and Crypto.

I don't think I am understanding what you are suggesting here, but I don't think there is any room for confusion about what Gleev is for from this page, let alone from the prior funnel and referral process which will be the lead generator for the person to land here to begin with. People will not just show up willing to participate spontaneously without context.

I agree about the lost flexibility ease of customiztion, but displaying two popups at once during your first visit is a far worse situation. For this reason, I'd again vote for keeping cookies and welcome message as part of the same modal.

I'm not sure what flexibility of value we are concerned about, what would they want to do which we would block here? I personally find the cookie popup thing to be a real UX-rat poison,so being able to bundle with a more useful message like this is a win.

drillprop commented 1 year ago

Indeed, this should not be a big problem from a technical point of view. On the other hand, I am worried about three things. first, if for some reason a few thumbnails are not available, it will completely ruin the visual effect. Third, you have to reckon that you may need some loading state until the query and asset are resolved. And thirdly, you lose control over the visual aspect of the dialog, it may happen that something you wouldn't necessarily want to greet the user with appears there. WDYT @drillprop?

I don't have anything to add here, fully agree. It's definitely doable, but the loading state will be an issue, and I'm not sure if showing skeleton loaders in this particular case will be a good experience.

toiletgranny commented 1 year ago

As this issue has been put on hold, I haven't had a chance to thank @drillprop and @rafalpawlow for your input on this. Your comments made me realize that having a Welcome dialog with a dynamic illustration containing video thumbnails is not a suitable option for this case, so instead, I opted for a static image that can work across multiple instances of Atlas and multiple content themes.

image

And so, it's all ready to be implemented, according to the above agreements. Here's the final scope of work:

  1. (cc @dmtrjsg) Introduce a global variable allowing gateway operators to describe the app's content focus so that it can be later referenced in the UI. Ideally, the content focus description is contained within 25 characters (at most), and a few examples of usage are provided for a gateway operator, e.g.:
    • "Your {{contentFocus}} creator journey starts here" Example: Your web3 & crypto creator journey starts here
    • "Welcome to {{appName}}, a video platform focused on {{contentFocus}} content." Example: Welcome to Gleev, a video platform focused on web3 & crypto content.
  2. Introduce an App KV component based on the designs, docs, and changelog, which can be found here

    Note @drillprop Please let me know on Discord once you get to this, as we need to discuss the matter of keeping illustration assets in the Figma file. Thanks!

  3. Introduce a Welcome dialog component based on the designs, docs, and changelog, which can be found here,
  4. Update the Sign in dialog component based on the designs, docs, and changelog, which can be found here,
  5. Update the Studio welcome screen based on the designs, docs, and changelog, which can be found here,
dmtrjsg commented 1 year ago

@toiletgranny looks great and does the job of informing the users about what the content is going to be about.. I believe we need to take one extra step and put the message across for the creators that all non Crypto content will be filtered out and removed from the app. Since welcome screens are not a good fit for it, shall we add some sort of confirmation controls to either channel creation or publishing new videos? Or both?

@bedeho cc

bedeho commented 1 year ago

Looks great ;)

toiletgranny commented 1 year ago

@dmtrjsg I could use a little help to understand what it means for a video to get filtered out in this specific context. For example, If I upload a video of kittens to Joystream, via Gleev, is it going to be taken down from the entire ecosystem and become unavailable on other gateways too?

You also mentioned that a video could be removed from the app, and I just wanted to make sure that's technically possible. So far, I've been led to believe that I, as a gateway operator, can only specify Joystream video categories (the global ones) that are available in the app. But does it work on individual videos as well?


In regards to how we communicate this, I believe it all comes down to how big of an issue we think this could become. My take on this is that the list of video categories Gleev supports (to which I, as a user, can be exposed either on the Discover page or during the video upload process) might be enough of a hint on its own for everyone to understand that this is the type of content that's welcomed on Gleev. In other words, if I, as a video publisher, upload a kittens video to Gleev and assign it to the "Trading" category (because it's about as irrelevant as all other Gleev categories), then I should be aware I'm not doing right. Therefore, it should come to me as no surprise if my video gets taken down somehow.

But If you guys feel like this could happen more often, I would suggest getting started by exploring the least intrusive ways of injecting this message into the app first and then working our way up to make it more prominent if necessary.

An example of what I would consider a non-intrusive way of communicating this would be adding a tooltip to the video category select form field, like in the below example.

image

Here's a bit more intrusive take on this, which I would not recommend now, based on my knowledge.

image

dmtrjsg commented 1 year ago

@toiletgranny thanks for your considerations 🙏 Please find the answers and suggestions below:

  1. How videos will be removed.

The way I understand content curation in this context is that the videos will be spotted by the content curators and marked as "curated", with implications of them being removed from categories, discover and search, as well as marked as "curated" when accessed via direct URL.

In terms of the mechanics of curating, I understand that if spotted via content curator roles, these will be added to the file which filters them out on app level, using this feature:

  1. upload a kittens video to Gleev and assign it to the "Trading" category (because it's about as irrelevant as all other Gleev categories), then I should be aware I'm not doing right. Therefore, it should come to me as no surprise if my video gets taken down somehow.

yes, but we want to minimise the work for limited resource of content curators which is a finite team of people. For any process its best to capture and prevent errors upstream so at the point of origination is best imho.

  1. Re implementation: Can we entertain the option to inform the creators at the point of creating channel that All non-crypto content will be filtered out and removed from app with a checkbox "Acknowledge" this way we don't need to annoy them each time new video is uploaded but ensure everyone gets the message..?

Keeping tooltip is also good imho.

toiletgranny commented 1 year ago

@dmtrjsg Thanks for taking the time to lay it down for me, appreciate it!

In regard to implementation, I understand your point of view on prevention. And to that extent, I do believe that the recommendations included in my previous comment would still work.

My main concern with bringing this up during channel creation flow is that it might send a message that can be easily misinterpreted due to unfortunate timing. I mean, this is literally the very beginning of your publisher journey. Not only on Gleev but on the entire Joystream ecosystem. And to kick it off like this, by having you acknowledge that your videos might be filtered out if they're not web3 & crypto related, although reasonable, might be risky due to emotions that are typically associated with taking content down.

Anyway, if you still feel like it's the way to go, then here's a dialog I imagine we could display before redirecting the user to the channel creation flow. Here it is in Figma.

image

dmtrjsg commented 1 year ago

For crypto creators I don't see how this would hurt, but this should be shown after the channel meta data is populated and before the signing modal is triggered.

Also copy needs updating:

"Supporting Web3 and Crypto Community

Gleev is built to support and cater for the Web3 and Crypto worldwide community, and its content is strictly curated to adhere to that vision. All videos not related to our mission will be removed from the app by the content curation team."

@bedeho pls feel free to chime in if you have a different view on this before this goes to implementation for Mainnet.

bedeho commented 1 year ago

Not super easy to distill precisely what is at stake here, but my assumption is: how invasively should we warn creators about content alignment when they create a channel?

If so, then I do not think it is advisable to add this sort of splash warning in the flow. The focus and purpose of the app will be clear from the context external to the signup flow, people will not spontaneously show up without it, and the cost of the mistake is low. Worst case, we add such a dialogue later, but I suspect that if there is such profound confusion at this sage, then this dialogue will do only a very limited amount of good to ameliorate that.

yes, but we want to minimise the work for limited resource of content curators which is a finite team of people. For any process its best to capture and prevent errors upstream so at the point of origination is best IMHO.

Be aware, curators do not manage what videos channels belong to any longer. The appropriate filtering will be done on Orion.

dmtrjsg commented 1 year ago

@toiletgranny ok in this case we will go with the tooltip, as this def would not get in the way or cause confusion.

Re content curation @bedeho so the reporting function will only build up the list of reported assets and its the dev team that would need to re-deploy the app to filter them out, on a periodic basis? I'd like to understand the process better..

bedeho commented 1 year ago

Re content curation @bedeho so the reporting function will only build up the list of reported assets and its the dev team that would need to re-deploy the app to filter them out, on a periodic basis? I'd like to understand the process better..

Currently, filtering does not work in a way which is really practical at almost any scale, we need server-side dynamic filtering, and Orionv2 has this. However, I am not suggesting that reporting is the only or primary means by which you filter content that is out of scope, seems more likely that operator reviews all new content as its uploaded. Just looking at caption+title seems like it may be sufficient in most obvious cases, and ambigous cases will require review. Orion could even work in away where it by default filters before content has been accepted, if this is the mode the operator wants to run in. Anyway, I am just speculating here, perhaps reporting will also be useful for this.