# SourceCred UI Design and Development

**URL:** <https://discourse.sourcecred.io/t/sourcecred-ui-design-and-development/470>\
**Category:** The CredSperiment\
**Created:** [December 26, 2019, 8:59pm UTC](https://discourse.sourcecred.io/t/sourcecred-ui-design-and-development/470 "2019-12-26T20:59:57Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![burrrata](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.sourcecred.io/burrrata/32/135_2.png) [@burrrata](https://discourse.sourcecred.io/u/burrrata)\
**Post date:** [December 26, 2019, 8:59pm UTC](https://discourse.sourcecred.io/t/sourcecred-ui-design-and-development/470/1 "2019-12-26T20:59:57Z")

</div>

> [@Discourse Plugin Upgrade: tracking wiki updates](https://discourse.sourcecred.io/t/discourse-plugin-upgrade-tracking-wiki-updates/462/2):
>
> Note that for the special case of initiatives and artifacts and such, I expect that a lot of the work will move out of the Discourse and into a dedicated UI within 2020.

Do you have an idea in mind of what this might look like?

Here’s my thinking:

- Pro: Better UI so that Initiatives and Artifacts are less beurocratic and Cred flows are more precise.
- Con: If users are split between platforms that can create breaks in UX. A lot of Ethereum communities have this problem where 90% of all engagement happens on web2 platforms, but then they have to leave the experience to use a separate web3 app for voting or payments or something. As a result, they don’t.

Having the entire UX of the SourceCred game all in one place could be great for engagement. Have we already fully exhausted the possibilities of using Discourse for Boosting, Initiatives, and Artifacts?

---

<div class="post-metadata">

**Author:** ![decentralion](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.sourcecred.io/decentralion/32/7_2.png) [@decentralion](https://discourse.sourcecred.io/u/decentralion)\
**Post date:** [December 26, 2019, 9:11pm UTC](https://discourse.sourcecred.io/t/sourcecred-ui-design-and-development/470/2 "2019-12-26T21:11:19Z")

</div>

> [@burrrata](#):
>
> Having the entire UX of the SourceCred game all in one place could be great for engagement. Have we already fully exhausted the possibilities of using Discourse for Boosting, Initiatives, and Artifacts?

Agree that we want the whole UX in one place. Let’s consider the different [UI pieces we want](https://discourse.sourcecred.io/t/sourcecred-beta-roadmap/422/3):

- An interface for interactively diving into Cred (how much cred does this Initiative have? Where does that cred come from? Where does it flow to?)
- An interface for exploring one’s own Cred and how it’s changed over time
- An interface for seeing how much Grain one has and how it’s changed over time
- An interface for boosting things (requires that the backend know how much Grain you have, and a way to commit the changes)
- An interface for editing and creating artifacts/initiatives

I posit that many of these are basically impossible to build into Discourse. Therefore, as we build out the game, most of the key functionality will be outside of Discourse. Once that happens, since we will want the whole UX in one place, we’ll want to move the initiatives and artifacts out of Discourse and into our dedicated UI.

This will also be easier for beta users, who may not all be using Discourse.

---

<div class="post-metadata">

**Author:** ![burrrata](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.sourcecred.io/burrrata/32/135_2.png) [@burrrata](https://discourse.sourcecred.io/u/burrrata)\
**Post date:** [December 26, 2019, 9:33pm UTC](https://discourse.sourcecred.io/t/sourcecred-ui-design-and-development/470/3 "2019-12-26T21:33:42Z")

</div>

> [@decentralion](#):
>
> - An interface for interactively diving into Cred (how much cred does this Initiative have? Where does that cred come from? Where does it flow to?)
> - An interface for exploring one’s own Cred and how it’s changed over time
> - An interface for seeing how much Grain one has and how it’s changed over time

I’m not an expert here, but my initial assumption is that a lot of this could be done via regular checkpoints that are put on IPFS. There would be a server that takes in data from the Discourse/GitHub API, then runs the SourceCred algorithm on it, then creates checkpoints on that data in regular intervals. Then a “Cred Explorer” front-end could be built for end users to find data they want. It would be like a block explorer for a blockchain, but for SourceCred - and instead of data coming from a blockchain it would come from Discourse, GitHub, etc…

> [@decentralion](#):
>
> - An interface for boosting things (requires that the backend know how much Grain you have, and a way to commit the changes)
> - An interface for editing and creating artifacts/initiatives

The “backend” here could be the “Cred Explorer.” It could track the history of any SourceCred instance over time (in this case SourceCred core) and send compute relevant data. When users boost a Thread, Initiative, or Artifact that data would get fed to the Cred Explorer. Boosting could be accomplished via a special emoji (like this one :sourcecred:) and that could even be made possible as a reaction (like likes, but with other symbols) via the [Retort plugin](https://meta.discourse.org/t/retort-a-reaction-style-plugin-for-discourse/35903). We can currently edit Initiatives and Artifacts via Discourse wikis and the [Initiatives plugin](https://discourse.sourcecred.io/t/write-the-initiatives-plugin/269) is being made to support that.

  

Seems like for an MVP we could have a Cred Explorer to run the SourceCred protocol and provide a nice UI to view the graph, but the game itself could be played via channels like GitHub, Discourse, and whatever else we integrate. This way we can focus on designing, testing, and validating the core game mechanics before anything else.

Also might be incorrect here as to what is and is not technically possible, but this is my initial impression.

---

<div class="post-metadata">

**Author:** ![decentralion](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.sourcecred.io/decentralion/32/7_2.png) [@decentralion](https://discourse.sourcecred.io/u/decentralion)\
**Post date:** [December 26, 2019, 9:40pm UTC](https://discourse.sourcecred.io/t/sourcecred-ui-design-and-development/470/4 "2019-12-26T21:40:34Z")

</div>

> [@burrrata](#):
>
> I’m not an expert here, but my initial assumption is that a lot of this could be done via regular checkpoints that are put on IPFS. There would be a server that takes in data from the Discourse/GitHub API, then runs the SourceCred algorithm on it, then creates checkpoints on that data in regular intervals. Then a “Cred Explorer” front-end could be built for end users to find data they want.

This is quite similar to how the [prototype](https://sourcecred-archive.github.io/credsperiment-progress-report/timeline/sourcecred/widgets/) works, except we use GitHub Pages for hosting rather than IPFS. @wchargin looked into using IPFS back in the day, but the performance and reliability were nowhere near the quality we’d get from using web hosting (e.g. GitHub pages).

> [@burrrata](#):
>
> Boosting could be accomplished via a special emoji (like this one :sourcecred:) and that could even be made possible as a reaction (like likes, but with other symbols) via the [Retort plugin](https://meta.discourse.org/t/retort-a-reaction-style-plugin-for-discourse/35903).

Features that Boosting needs:

- You need to know your Grain balance
- You need to know how much the node has already been boosted (will affect how much of the future cred you get from your boost)
- You need to choose how much of your Grain balance you want to “spend” on a boost (50? 100? 1000?)
- You need feedback on whether your boost was successful (-\> your Grain balance goes down) or if it failed (you didn’t have enough Grain)

I don’t think we can do this without having our own dedicated UI.

---

<div class="post-metadata">

**Author:** ![burrrata](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.sourcecred.io/burrrata/32/135_2.png) [@burrrata](https://discourse.sourcecred.io/u/burrrata)\
**Post date:** [December 26, 2019, 9:47pm UTC](https://discourse.sourcecred.io/t/sourcecred-ui-design-and-development/470/5 "2019-12-26T21:47:43Z")

</div>

> [@decentralion](#):
>
> Features that Boosting needs:
> 
> - You need to know your Grain balance
> - You need to know how much the node has already been boosted (will affect how much of the future cred you get from your boost)
> - You need to choose how much of your Grain balance you want to “spend” on a boost (50? 100? 1000?)
> - You need feedback on whether your boost was successful (-\> your Grain balance goes down) or if it failed (you didn’t have enough Grain)

Good point. I was thinking that the SourceCred protocol could figure out all that stuff, but since boosting happens via Grain the user would want to specify how much to boost, and before they make that decision they would want to know who else had boosted and how much. They’d also want to see what’s boosted so that they engage with the highest leverage content. That’s not possible currently via Discourse.

So would we have to fork Discourse and create our own version that has Boosting, or would we just have a separate website people go to that lists things that are boosted? If the later, would people then have like a dashboard of their current open boosts that are in play as well as other boosts that they could participate in? Also, the most important part about Boosting is what is being boosted. It’s very important that the experience of boosting is closely tied to the experience of engaging with content. How would we do this if Boosting is siloed in a separate app? Would it maybe be like a browser extension or something that overlays more information onto the core experience?

---

<div class="post-metadata">

**Author:** ![decentralion](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.sourcecred.io/decentralion/32/7_2.png) [@decentralion](https://discourse.sourcecred.io/u/decentralion)\
**Post date:** [December 31, 2019, 12:01am UTC](https://discourse.sourcecred.io/t/sourcecred-ui-design-and-development/470/6 "2019-12-31T00:01:30Z")

</div>

> [@burrrata](#):
>
> So would we have to fork Discourse and create our own version that has Boosting, or would we just have a separate website people go to that lists things that are boosted? If the later, would people then have like a dashboard of their current open boosts that are in play as well as other boosts that they could participate in? Also, the most important part about Boosting is what is being boosted. It’s very important that the experience of boosting is closely tied to the experience of engaging with content. How would we do this if Boosting is siloed in a separate app? Would it maybe be like a browser extension or something that overlays more information onto the core experience?

Forking Discourse and trying to build within it would impose a lot of cost/complexity for the system, and make SourceCred less usable for projects that don’t use Discourse. So we’ll want to build our own UI for it.

The SourceCred UI will include first-class support for Initiatives and Artifacts; those will no longer be canonically represented by Discourse threads. However, we could have @credbot automatically create a Discourse thread for each initiative if we want to have a place to discuss it, if we find that valuable. The SourceCred UI will also import data from GitHub, Discourse, etc; this is necessary so artifacts/initiatives can link to activity there. This also means we’ll be able to search for pull requests, threads, etc, in the SourceCred UI, and boost them there.

We could then build a browser extension for GitHub / Discourse which makes it easy to navigate from a post on GitHub/Discourse directly to the matching node in the SourceCred UI.

---

<div class="post-metadata">

**Author:** ![burrrata](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.sourcecred.io/burrrata/32/135_2.png) [@burrrata](https://discourse.sourcecred.io/u/burrrata)\
**Post date:** [December 31, 2019, 12:04am UTC](https://discourse.sourcecred.io/t/sourcecred-ui-design-and-development/470/7 "2019-12-31T00:04:19Z")

</div>

Cool. So raw data would get fed from various channels like Discourse, GitHub, Twitter, etc… to the SourceCred server, then that server would process the data according to the SoruceCred protocol and layer on the Cred/Grain boosting, voting, etc… and then a client would display all that data in a UI that has UX optimized for SourceCred gameplay?

---

<div class="post-metadata">

**Author:** ![decentralion](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.sourcecred.io/decentralion/32/7_2.png) [@decentralion](https://discourse.sourcecred.io/u/decentralion)\
**Post date:** [December 31, 2019, 12:14am UTC](https://discourse.sourcecred.io/t/sourcecred-ui-design-and-development/470/8 "2019-12-31T00:14:18Z")

</div>

> [@burrrata](#):
>
> raw data would get fed… to the SourceCred server, then that server would process the data according to the SoruceCred protocol and layer on the Cred/Grain boosting, voting, etc… and then a client would display all that data in a UI that has UX optimized for SourceCred gameplay?

Yes, precisely.