search

near / data-platform

Near.org Data Platform Initiatives and Epics: Recommendations, Search, Analaytics
1 stars 0 forks source link

:large_blue_diamond: [Epic] Component Discovery Feed Interface #19

Closed TiffanyGYJ closed 2 months ago

TiffanyGYJ commented 11 months ago

Description

Add a 'components' tab next to 'all posts' and 'following'. The feed should look exactly like the posts feed, and have a 'post' saying 'I just published a Component A' with a user profile. The viewer should only see posts like this for people they follow. In case the don't follow anyone who publishes components, they see a prompt to find developers on the contributor board.

The implementation should use QueryAPI widgets indexer. The indexer should be efficient for filtering components from people the viewer follows.

Success Criteria

### Child Issues
xuan-ytr commented 9 months ago

@TiffanyGYJ, could we define a few things for this feature for traceability? I'm putting my assumptions on the side , please validate or fill in any gaps.

Core questions

Additional questions

image

Let me know if you prefer to chat about some of these items on a call before our next sync on Thursday so we can move into design explorations.

TiffanyGYJ commented 9 months ago

Core questions

  • User - Who does the problem impact? Who are we building this feature for? Developers who work for founders? independent developers? OSS developers? (uncertain which type, or all)

The act of trying to find interesting components does not differ from these three types you listed above. So I would say this is more for developers who are looking to explore, use or save interesting components.

  • Motivation - What is the user trying to accomplish? Their incentives? Get the most up-to-date list of potentially useful components for their build when they log in to near.org; users may be incentivized by solving current development pain points and discovering new and useful components, or find ideas for new components they want to build (do we have research to back this? I vaguely remember that we may have heard a signal for this during a developer interview)

They are usually in a exploratory and browsing mode in this case, meaning they don't have a particular type of component in mind they want to find but more hoping to look at what works were done by the developers they follow. As a result, there is a level of social intention here as well.

  • Expected outcomes if this feature is successful? (Uncertain how we will measure this, please advise)

    1. CTR of components from this feed
    2. Retention of browsing this feed
    3. Number of developers following other developers
    4. Time spent on feed

  • Problem - what user problem are we solving for? (Can we get any more granular than general component discoverability? Is this about surfacing quality components in a visible way?)

Ultimately this is about component discoverability which is part of the key to facilitate BOS's open web and composability strategy. One level down, you are right that this is about surfacing quality components by strengthening association between strong developers and make their works discoverable since we have discovered from the user research that developers trust other competent developers. In addition, there is also a level of social element here to follow each other's work to intensify the network effects.

  • Impact - what downstream effects are caused by the problem? How severe? What impact is the product opportunity creating? (i.e. If new components of quality are not discoverable, then we will not be able to retain and convert any new developers that we onboard into repeat users or long-term contributors)

Completely on point on the example you provided here. In addition, for a developer network to be successful, we need to strengthen developer's reputation with their works and make them discoverable.

Additional questions

  • When are the design and engineering deadlines?

The POC/MVP of this should be a fairly straightforward one. Since we have validated this need from our previous user research and we need now is to have this feature out and see people's reaction and usage pattern to validate further with quantitative data. We hope to get a simple design out by EOW (Dec1) and Eng done before EOY 23.

  • Do we have time for a quick round of internal user testing before committing to designs?

For this feature at the stage of POC/MVP, I believe we can skip to a simple implementation to test directly and tag this feed as so that devs are aware this is in progress.

  • What surfaces on near.org can we play with? I.e. if the social feed is no longer the front page, would it make sense to consider another location and another form factor for this feature?

The social feed layout will not change in short term, so we can continue using this. I would not replace featured component since that is highly clicked and used by devs. However, I am open to play around other surfaces, open to ideas.

  • How will we populate the component feed? How will it be updated?

Indexer will be created here to update. This will include components that are published by devs that user follow.

  • What are the default components to show for new users who haven't followed anyone?

If this user has not followed anyone, we will link them to the contributor board to follow more devs. we will populate the feed with components that are published by accounts like near, eugene, illia and some other reputable dev accounts.

  • Will this replace the sidebar on near.org page? (see ss below)

No. this sidebar has so far proven to be helpful for communities to find most helpful components.

xuan-ytr commented 9 months ago

@Kevin101Zhang @TiffanyGYJ @sarahmills latest design iteration, pending design review and sync with Kevin on interaction design. image Functionality Notes:

xuan-ytr commented 8 months ago

Design in review.

xuan-ytr commented 8 months ago

V2 of design in review Design thinking worksheet (WIP summary of motivations, problems, outcomes)

Kevin101Zhang commented 7 months ago

blocked on https://github.com/near/queryapi/issues/494

xuan-ytr commented 7 months ago

Completed design QA / fit & finish with @Kevin101Zhang today. Spec here.

  1. Decided to hide stars and forks from view unless a component has at least one star or one fork [done]
  2. Swap out current icons for phosphor icons to adhere to design system.

This feature is ready for production as soon as item 2 is done.