Interface Design : Increase Feature Focus + Decrease Brand Focus

[kamescg]

First, shoutout to @jclancy93 for laying down the foundation. Great to see the little green "Fund Issue" button everywhere on GitHub now :)

I would like to officially propose user interface adjustments to increase features focus and decrease branding focus.

Currently a significant amount of space is dedicated to non-essential interface elements. From a product design perspective it makes sense to minimize the "brand focused" design and add "feature focused" design/features. Chrome Extensions are already small to begin with too...

Potentially a lot of information can be intersected with the Gitcoin platform, so adding Menus, Modals, Popovers, and other data focused components could help increase future feature roll out.

[owocki]

woah, these are beautiful :) much more visually engaging than the sad little table i put together.

hey @pixelantdesign thoughts on this?

[owocki]

I would like to officially propose user interface adjustments to increase features focus and decrease branding focus.

love this

[PixelantDesign]

@owocki

• I like the personalization and richness of the visual design.

• I also like the open/funded/fulfilled concepts, but not seeing how they connect or are denoted in the list items below it.

• I think there is an opportunity to distinguish between the search and share being styles...could be confusing from a users perspective as they perform two different functions.

• Deep diving into a list item via an accordian might be less cumbersome than a popup since the user is already in a chrome extension panel (avoiding popup within a panel).

Otherwise, Great suggestions @KamesCG!

[kamescg]

1. Future designs will continue to adhere to existing branding.

2. I haven't fully thought through every mechanic, but those open/funded/fulfilled would be for filtering of bounties, like on the main site.

3. Yes. It's a suggestion to bucket together tasks from a single organization/project. This is assuming the platform will grow and developers will probably end of creating strong relationships with a handful of projects, as opposed to many small ones.

4. Great suggestion. I'll switch to an accordion, instead of modal.

5. I'll keep playing around.

woah, these are beautiful :) much more visually engaging than the sad little table i put together.

Only so much time in a day.

[PixelantDesign]

@KamesCG I was also thinking it could be useful to be able to search/filter by project name, all project, type of work (design, dev, etc).

[kamescg]

@PixelantDesign I would be happy to help implement a more dynamic search filter.

I haven't looked at the current API (just the return data), but looks like a decent amount of metadata is returned in each bounty.

"metadata": {
        "githubUsername": "owocki",
        "experienceLevel": "Intermediate",
        "projectLength": "Hours",
        "tokenName": "ETH",
        "issueTitle": "small module design: waiting room quote",
        "bountyType": "Feature",
        "issueKeywords": "web, gitcoinco, JavaScript, Python, HTML, CSS, Shell",
        "notificationEmail": "ksowocki@gmail.com"
    },

Possibilities?

Option 1: Store all the bounties locally in Browser storage. Filter, map, reduce a Redux store and return search results from cached results. Use ServiceWorkers to regularly maintain fresh data store.

Option 2: Dynamically query/filters requests via API and return results in JSON.

It looks like the current API suited for dynamic ?order_by=web3_created&idx_status=open&network=mainnet requests? I know Python is the backend, but I haven't looked any further then that. Would it simply be a matter of mapping requests to the current API or does the current need additional filtering capabilities?

Personally, I find the idea of constantly pinging a server for filtering requests to be overkill. And, probably also an unnecessary expense. The current code pings the server on every load, which could be maybe 10's, 50's, or 100's of extra requests in a users lifetime.

The Chrome Extension could probably benefit from a Redux Store maintained in the background.js, which will maintain a local app/bounty database. Both, the Popup and Content Scripts could easily transmit data from the primary store Background script.

In other words, ship the entire bounty database on application initialization and let the user search from there.

What could be slick is minimizing the server's roles entirely and getting users to pass each other data between WebRTC, but that's probably a whole'nother conversation.

[gasolin]

Looks cool!

Though put a step back for the style change, should we consider align some key styles (background, button..., etc) between the web site and the extension? The current morden page is the tool page https://gitcoin.co/tools

The extension and the web page look pretty different now and will looks more different by applying the new style.

[kamescg]

@gasolin For the most part, I think it's been somewhat decided we won't be using the prototype :)