Task List

gitcoin-front-end.md

Tasks

An Intro

I came across Gitcoin in December on a reddit channel! Sounded interesting, looked it up and started checking out the code base. In my head: Oh this looks fun! ( Not another dog-eat-dog setup ) Focuses on helping people learn + make money + network.

What do you like about it ?

Gitcoin as a product is beautiful. But if I've got to comment only the front-end code base -> I wouldn't say it's the best. It's got a lot of clunky code which needs to be cleaned up. As months passed, things started improving.

• Alisa set up a design styleguide === common theme
• Folks like me, kenneth, easwari have stated adopting it and redesigning the pages one at a time

The most important is that's even if it's clunky, it's simple. Anyone who's eager to learn and has decent front-end skills can contribute

What are some things you would improve & What steps would you take to make progress towards an improved front-end infrastructure?

I've combined the answers for those two

All these are stated keeping in mind what the community would be comfortable working with. Adopting a new infra framework just cause it's cool and new would not gel well with the Gitcoin community.

Note : All these suggestions are meant to be accomdated once we've redesigned Gitcoin.

1. Style Guide Document

What

Creating a generic design doc (not just a style guide)

Why

If we could make it as a pseudo library with good documentation stating this is how a component looks and this would be the code to use it. Anyone working on the code -> would refer to the styleguide and just copy the code over. I've sort of done it within our codebase. (This needs to be moved over to a document )

Example: Bootstrap

Stuff like this can be avoided . If that does load, olafghanbizadeh :

Yeah, I asked because I would like to know the class names of the new form-styling

2. Integrate webpack / task runners like gulp / grunt

What + Why

• Integrate babel for ES6 features which would make the code neater + easier to write. We'd be able to use let, const rather than var === less chances of bugs. Babel would take care of consuming ES6 code and spitting out JS which supports all browsers. Using this would take away those extra rollbar errors which Mark keeps reporting. (Plus functions like map, reduce etc help the codebase be more readable. Check out the code examples here)

    var foo = function (name) {
      return "Hi " + name;
    }
  
    const foo = name => ("Hi " + name); // Isn't this neater?

• Adopt SCSS / SASS. This would help in sticking to the styleguide as we'd be able to declare variables within out base.scss file and refer them throughout the codebase. Plus CSS code becomes soo much easier to maintain + Browser support
  Within our repo , we've got different color codes through out. Wouldn't it be nicer if we could have them all defined as variables in a file vars.scss and reuse them everywhere

    .parent {...}
    .parent .child-1 {...}
    .parent .child-1 div {...}
  
    /* SCSS */
    .parent {
      ...
      .child-1 {
        ...
        div {
          ...
        }
      }
    }

• I haven't used webpack extensively but this a minimal setup and with this if we bundle the right resources -> faster load time -> happy user. We aren't just talking bundling js files. - css, fonts, images

  Before

  

  After Bundling

  

  This would be coupled with other tools like minify / flatted (which reduces code size)

  How

  Ideally if end up using webpack, we could start up by adding ES6 support and paralley integrating SCSS which might be tricker My conversation with ola

  So I spoke to a few folks at Uber like company in India , they were telling me that the right way to do it -> would be rather than compile all scss files into a single main.css file, the right way to do it -> would be split into bundles whatever is common across for all pages would be one single css file (which could be cached to increase performance) while every page would have an additional file which contains resources only it needs. I haven't done this before, hence the ping

For starters we could simply produce one huge main.css files and see take it from there

3. Mobile / Tablet

What + Why

I'm aware that most of our users are in Gitcoin on their laptop + desktop. Even though Gitcoin isn't meant to be used 100% -> folks still check it out and a bad UI + UX == Not a very good first impression. This is a high priority. Ian -> saw his profile on Gitcoin -> on a smaller screen -> whole UI broke -> Bad UX -> Disappointed Ian ( I've spoken to vivek about this cause this )

Since we've decide to stick using bootstrap , we should define responsive breakpoint as per their design.

---

4. Shift the frontend to a different repo

What

I've worked on a decent number of projects at office / personal. I'm aware that having a single codebase seems a lot easier to keep track early on but on the long run things get a little complicated/ I had built out a stock market analyzer (nothing fancy) A node server which provided APIs which can be consumed by the client react app Splitting it out as two components made maintenance easier

Why

Advantages of doing so :

• Clear division between the frontend and backend == Easier Testing
• Backend would only be responsible for talking to the blockchain and provide APIs which our frontend component would consume
• Right now we've got more

I know this would slow down the process but this should be started in parallel. Olaf is already on it I believe. This could be done as a node app. If we had to pick one React is a popular choice. It's got kickass community support ( I picked it up to an extent while working on coldoutreach. It's not too complicated ) Not sure if redux + typescript is an overkill for our use-case (I haven't worked with those), will have to talk to Kames / Kenneth / Mitch / Easwari about it (the architecture call)

---

5. Dashboard

What + Why

TBH this was brought to my notice by Alisa.

We've got a profile page + bounty filters from the issue explorer in Gitcoin. Folks like to see their progress/activity (When they've worked on a lot of stuff -> seeing it up on the dashboard gives them satisfaction ) It didn't strike me until I was working on multiple issues that keep track of what I've submitted etc is something which should be readily available. The activity log on each of the active bounties. (You could say that issue explorer offers filters but I'm talking about a more personalized experience, to engage our users)

If you were a bounty hunter and you’ve worked on tons of issues If I wanted to know what are your bounties status / new developments (Eg: submissions are yet to be accepted ) As a external user could how easy it is to get that information in a few seconds.

How

When we redesign the profile page, I propose to design it as a dashboard right from the start. Stuff I should be able to do :

• see my active bounties (about to expire)
• recent activities on my bounties ( when someone else jumps in )
• which issues are pending submission
• be reminded of any submissions which I'm yet to accept / reject as a bounty owner

IMP: If we do the activity log for issues -> it would be wrong to not add in notifications when your bounty has changes status) for actions not initiated by me. Eg : As an issuer -> it would be nice if I get a notification on the website when a new submission has been made / someone has started working on it. As an hunter -> when my submission has been accepted

---

How would you involve the Gitcoin community?

This section would address the how mentioned in the above section.

• Start building a style guide ( a simple static webpage with all our components along with code ) This can be taken up by a community member. THIS IMHO SHOULD BE DONE ASAP As we revamp the design -> each time a component is added/ updated , whoever updated the UI will be asked to update the design document.

• The community has already readily aggreed on SCSS + Babel adoption. webpack bundling needs a good amount of work -> so for now. I'd encourage intergrating SCSS + Babel. One page at time -> we update the styling and JS

• Also as pages are redesigned - mobile support is a must. It need not have all the functionality but nothing should break

• Sit down and discuss with folks who've done and reach a consensus on if react the right stack to build the front-end app on. (Debate if redux is needed ) Additionally when I was talking with algae12 (he did a neat job of designing the toolbox ), he hinted out that moving away from bootstrap is something we should consider. We use bootstrap primarily for the grid system. Ton of the css we use right now -> is customized. There are tons of lighter libraries which we could use. I know this a huge step and lot of folks are comfortable with bootstrap but I would urge atleast discussing this

• I would say CSS + HTML + ES lint ( but that's happening as we refactor + redesign the code base )

Post Redesign

• I would wait until we have fixed up the website and then worry about. If it's the react-redux, I'd recommend using create-react-app comes with everything integrated. Webpack + SCSS setup. No hassle \m/ Rather than bootstrap - We'd integrate with ant ( again used it for coldoutreach for the first time and loved it)

Extra: Beyond Code

Overall flow for on-boarding new users

What + Why

Gitcoin is not another website. When I landed on Gitcoin the first time I was lost. Yes the overall idea is clear.Putting up bounties seem relatively easy but claim bounties is a whole different story We should draw a flow diagram (paper mock up / sketch ) where we focus of new customer on-boarding I pinged a few folks to ask doubts the first time I did it (sort of made me feel dumb == not the experience you'd want for a user ) An example : A first time user -> no ether -> will have to struggle to find faucet -> feels frustrated -> leave or ping on Gitcoin sack to find the faucet page.

How

I'd say we first establish a flow depicting the new users on-boarding lifecycle -> evaluate how we make the user feel comfortable. Once we are fixed on that (In our heads this is really clear -> cause we've are familiar with the flow ) It might result it a simple flowchart / video / guided demo the first time a user signs up.

Labels (within our repo)

What + Why + How

Defining a standard labels for the github issues we post for Gitcoin/web(@mbeacom is already on this ). Open Source Contribution in countries like India is picking up. Having a friendly invitation IMO is the perfect way to encourage newbies to develop a bond with the community. I first started off with node-js and labels like easy-picking + mentor-available were encouraging + showed that the community was willing to guide/teach you. I would love for folks to have that with Gitcoin.

API refinement

What + Why + How

We've got APIs resource / sub-resource definition right but all of it revolves around bounties. If in our roadmap, we would like apps/dashboards built around our users, we should also provide rest endpoints modeled around users /v1/users/<github-id>, Most of the products follow swagger standards and integrate with swagger-ui which makes APIs interactive out of the box -> makes it easy to use. Yes they have Django support

Post integration (if we do this ) we can remove the documentation from README.md as the swagger-ui API doc generated would suffice

(PS In our profile page , I'd don't see an API call being made which returns a JSON response. Also mark is bettering the API as you read this, and I've asked him to sort of show me how he does it, so that I can help out \m/ )

Multiple Submissions (Complicating stuff)

What + Why

Right now we flow is as follows

• issuer puts up a bounty
• Mark starts work
• I ignore the rules and start work , submit before him
• Kevin accepts mine instead (could be because he's got a deadline / he just saw my name first)
• Mark has an un-pleasant experience with Gitcoin

^This seems like a competitive environment. I know it's not intended to be used this way but in our current setup it is possible (we regulate it here but as Gitcoin grows -> issues flow in from different issuers, what can we do to avoid this ? )

My proposal Submissions are restricted to one claim. Only scenarios where multiple submissions are allowed are when people are collaborating aka a bounty with multiple tasks

We won't be able to use the bounties network out of the box

• we'll have to build a facade -> 1 bounty in Gitcoin == set of bounties in the bounties network.
• put it a feature request to the bounties network
• build it out on our own ( probably not a good idea )

This brings in complications like :

• More the tasks -> More the transaction fees
• What if one user is planning on claiming it all, the hunter will have to pay more fees

Is Gitcoin just for bounties / more

Our motto : Grow Open Source casts a big web on a lot of things but at it's core, Gitcoin is all about bounties Would it make sense for other tools to reside within Gitcoin (aka toolbox) ? This had been brought up in a github issue and after reading it , it made sense in my head. If Gitcoin is more than just bounties -> then no issues. Else would it make sense to abstract those away into a smaller product ?