SourceCred

Proposal: Web of Cred

#1

Web of Cred

Initiative Description:

The historical point of departure for the web-interface was a React based system where the data interface was tightly bound to the web interface. This Initiative seeks to address these concerns by decoupling the data rendering from the user interfaces and ultimately creating reusable widget types that will be consumed internally and available for third-party use.

There are four major areas of activity:

  1. CredSperiment
  2. Generic Frontend
  3. Observable Notebooks
  4. Widgets

Please note: I will update this topic to address concerns raised in the comments.

Benefits:

  • A separation of concerns will allow for other implementation approaches to be used and third-parties to quickly (hopefully) design and show their project’s cred.
  • Making a collection of visualisations will make the interface more engaging and potentially uncover new “information”
  • Decoupling allows for more rapid development.

Implementation plan A:

  1. Create a new Branch with UI Folder using Quasar
  2. Rig data exchange
  3. Create pure Vue D3 display components (minimal - no use of Quasar)
  4. Solicit Feedback

Implementation plan B:

  1. Design Observable Notebooks
  2. Extrapolate Notebooks into Widgets
  3. Rebuild “Prototype” Site with Widgets
  4. Solicit Feedback

D3 Components:

  • “Unfurling Fern”
  • Force-Graph
  • Cred Genesis (Tree)

Mermaid Flowcharts?

Features:

  • Color Mapping
  • Timeline (SLICE)
  • Granularity (ZOOM)
  • Analyzer
  • Detail Modal (For any entity or group of entities)
    • Report Card
    • Mana Balance
    • Backlinks

Estimated Work (hours):

Lots

Dependencies:

  • Forthcoming

References

  • Forthcoming

Links to contributions:

#2

One thing that I am not really sure about is whether we should maintain the UI / website in the Monorepo - or set it up as another distinct repo…

#3

I really like the idea of having observable notebooks be the playground for experimenting with widgets like this. The only issue is that it will block on extracting the core SC modules so they can be used as a library. I actually really want to do this for a ton of reasons, but we need to write an initiative for it and scope what work is involved.

#4

I too like this idea especially. The code for which I’ve done some work to move here https://github.com/sourcecred/payouts However, why stop there and not build the UI too?

And as widgets and the notebook show. The “scores” format is one such decoupling attempt. Though it definitely doesn’t cover a use-case like the cred explorer frontend. Especially when you’re looking to bring back the drill-down feature that legacy cred had in it’s UI.

1 Like
Cred Analysis Notebooks
#5

I think what you mean by this is that there exists a “neutral” data format which we’re using in the /api folder. https://github.com/sourcecred/cred/tree/master/docs/api/v1/data/projects/QHNvdXJjZWNyZWQ However it is a lot of data and would really benefit from a solid client library to effectively wield what’s in there.

Would this make sense as one of the first refactoring goals when moving to modules?

#6

Yeah, I think being able to regen cred analysis from the data files there would be a great first goal from the module switch. So that we can start replacing our hardcoded frontend with observable notebooks. (Once we use notebooks to experimentally find the best patterns, widgets, and analyses, we may “re-productionize” them into dedicated frontends.)

It’s worth noting that the data files there contain the whole graph, but only compressed cred. Specifically, the cred file only has data for the top contributions and for the contributors, but not for every contribution. So we do need the client libraries in order to re-generate the full distribution. We can also look into a more space-efficient way to encode the full cred so that it becomes feasible to serialize it all.

#7

Love this visualization

IMAGE%202019-10-09%2022%3A12%3A58
IMAGE 2019-10-09 22:12:58.jpg1280×565 87.5 KB