search

ipfs / ipfs-website

Official IPFS Project website
https://ipfs.tech
MIT License
32 stars 16 forks source link

Create interactive ecosystem directory #61

Closed jessicaschilling closed 3 years ago

jessicaschilling commented 3 years ago

Objective

Replace the existing canonical ecosystem diagram with an interactive, information-rich directory that effectively illustrates how IPFS adds critical value and tech enablement for IPFS builder orgs, projects, and industries. Presentation must be at, at minimum, two levels of detail:

  1. Embeddable summary "widget" version (example placement) presenting the most impactful info
  2. Detailed version (to be viewed in its own page, and can in itself contain several drilldown views) with additional details on each builder

Latest status documents

These items are evolving, but the latest will always be listed here. Check back regularly.

Draft features/requirements

It's safe to assume that these requirements are roughly accurate, but please keep in mind that details can change as the project develops. Always assume that materials under "Latest status documents" above are the source of latest truth.

Features: Summary view

An at-a-glance view of top IPFS implementers and the tangible value that IPFS provides them. Includes the following features and requirements:

Features: Detailed view(s)

A not-overwhelming, easily searchable/filterable showcase for exploring how builders leverage IPFS to succeed and the ways in which IPFS provides value. This detailed view may include additional drill-down views subject to prototyping and refinement, but overall includes the following features and requirements:

Additional requirements

Legacy documents

Please note that these may be outdated as project requirements continue to develop, and should be used for reference only.

jessicaschilling commented 3 years ago

Update, 23 Feb 2021

D3AS8A commented 3 years ago

Call: Requirements and Prioritization

Refined requirements to include the following: 

* Application Req: Ecosystem Index Page/ Discovery View
    * to include alternate list view, with logos 
* Application: Project Profile Page/ Detailed Information Page 
    * to display and segment all associated tags/filters (linked to top level category pages)  
* Embeddable Object: CTA Section/ Preview View
* Application: Category Index Pages / Category Specific (top level) Search Results Pages

Next Steps:

orvn commented 3 years ago

Update, 5 Mar 2021

We had a touch point today where we honed details in the context of low fidelity designs. Key areas we covered were:

Next steps

cc: @jessicaschilling & @d3as8a

orvn commented 3 years ago

Stack discussion

@jessicaschilling I'd like to start an exploratory discussion here about an alternate stack—still based on Vue.

We've been talking about the potential upside of using Vue/Nuxt in place of VuePress for this project.

Platform Nuances

Distinctions

Since the IPFS ecosystem is interactive, a great deal of the functionality isn't really content or page-based. Instead it's state-based (i.e., what's the state of a series of filters and other user inputs).

The benefits of using Nuxt are:

The VuePress docs themselves have a section about Nuxt, where they stipulate when it's better to use VuePress:

Nuxt is capable of doing what VuePress does, but it’s designed for building applications. VuePress is focused on content-centric static sites and provides features tailored for technical documentation out of the box.

In other words, while Nuxt has a static mode that's comparable, it behaves more like an application. VuePress is designed to behave like a content website.

jessicaschilling commented 3 years ago

[FEEDBACK REQUESTED] @zebateira @jdiogopeixoto @cwaring -- I mentioned @orvn's comment above in our ipfs.io replatforming discussion in https://github.com/ipfs/website/issues/412, but want to confirm that none of you have any issues with the directory being built on Nuxt as part of a larger IPFS/PL website ecosystem. Can you please weigh in?

@orvn -- please note that the same requirements of the "teaser" version to be embedded in various external sites still apply. Correct that this platform decision would have no impact on that work?

orvn commented 3 years ago

@orvn -- please note that the same requirements of the "teaser" version to be embedded in various external sites still apply. Correct that this platform decision would have no impact on that work?

@jessicaschilling it would actually the embeddable piece easier to implement. I mentioned this above, but I didn't use the word teaser (see embedded container (CTA/summary view)) in my previous comment.

cwaring commented 3 years ago

The only reservation is regarding the IPFS requirement, if the end static application is required to run at both root domain (app.website.tld) and gateway access (gateway.ipfs.io/ipfs/cid) then this needs to be evaluated first.

orvn commented 3 years ago

The only reservation is regarding the IPFS requirement, if the end static application is required to run at both root domain (app.website.tld) and gateway access (gateway.ipfs.io/ipfs/cid) then this needs to be evaluated first.

The legacy Slingshot site (which is on static Nuxt) does get served up by that path: gateway.ipfs.io/ipfs/Qmf3...HortQf

Except none of the relative paths for resources work because those are separate CIDs. Does this help shed light on anything @cwaring?

cwaring commented 3 years ago

Actually you may not be aware of the background behind this. In the past if you were using the IPFS browser extension then you would get redirected to a gateway url whenever a _dnslink entry was detected. So it was important for sites to work at multiple path depths (with relative assets) in order to not break the functionality.

Thankfully we now have a root origin support in IPFS so we can access any site from b32cid.ipfs.dweb.link or b32cid.localhost so this doesn't break websites.

However for legacy support many gateways still only support /ipfs/cid access so all of our primary websites are designed to work in both scenarios. It also means you can ipfs get cid a static website to a local folder and run it without a web server.

Our VuePress implementation works for both these cases so it would be nice to know if Nuxt can do the same. Webpack sites often have trouble due to dynamic requires and forced absolute paths in the build output but it is possible to hook into the config and dynamically configure the basepath for webpack and vue router. You can see an example of how I did that here: https://github.com/cwaring/vuepress-plugin-ipfs

Being Pragmatic and given that this is no longer a critical breaking feature I personally wouldn't say it's a hard requirement, however this should be established early on with whoever is signing this project off because it might not be possible to implement at the end.

If you know a way that Nuxt does this out of the box then we have all bases covered! Keen to have your input around this.

jessicaschilling commented 3 years ago

@cwaring @orvn I'm afraid we do need to consider this a hard requirement.

orvn commented 3 years ago

@cwaring @orvn I'm afraid we do need to consider this a hard requirement.

Understood @jessicaschilling, will look into viability and find out if this is a blocker. At the moment I'm optimistic (I suspect it's not a big hurdle).

Actually you may not be aware of the background behind this. In the past if you were using the IPFS browser extension then you would get redirected to a gateway url whenever a _dnslink entry was detected.

Ah, you're totally right. I didn't know about the legacy behavior. Thanks for explaining.

Webpack sites often have trouble due to dynamic requires and forced absolute paths in the build output but it is possible to hook into the config and dynamically configure the basepath for webpack and vue router.

For our part of the build process gulp does all the extra compilation we need, but nuxt itself is pretty deeply coupled with Webpack it (VuePress too, I think?). We can definitely use this approach to transform path structure during compile time cc: @timelytree who has done this before on nuxt, and probably has other insights to add to this issue discussion.

You can see an example of how I did that here

Thanks! I'll have to read some IPFS docs and test a few things, but this does feel like the kind of thing that's doable for nuxt as well (without taking up excess time).

cwaring commented 3 years ago

Great! I'm also starting on a Nuxt app this week so I'll see how elegantly it can handle relative paths now. The less hacking we have to do the better 🤞

zebateira commented 3 years ago

I mentioned @orvn's comment above in our ipfs.io replatforming discussion in ipfs/website#412, but want to confirm that none of you have any issues with the directory being built on Nuxt as part of a larger IPFS/PL website ecosystem. Can you please weigh in?

Sounds good to me 👍 The issue with the relative paths is something that needs to be tackled but like @orvn said, it's doable.

orvn commented 3 years ago

Update, 16 Mar 2021

Today we started by briefly talking about the technical stack. We then reviewed prototype feedback, how it fits into the lo-fi design, and what alterations may be necessary. Key areas we covered were:

Next steps

cc: @jessicaschilling & @d3as8a & @emilymariahh

orvn commented 3 years ago

Update, 30 Mar 2021

In a touch point yesterday we reviewed mid-fidelity designs, with the IPFS brand standards applied, as well as an enhanced mid-fi version of the embedded view. We also spoke about nuxt compatibility with IPFS Gateway routes, which now works (a nuxt [module is available here]()).

Key areas we covered were:

Next steps

cc: @jessicaschilling & @d3as8a & @emilymariahh

orvn commented 3 years ago

Update, 13 Apr 2021

We had a new touchpoint yesterday where we reviewed high fidelity designs and new specifications.

Key areas:

Next Steps:

cc: @jessicaschilling & @d3as8a & @emilymariahh

orvn commented 3 years ago

Updates, 23 Apr — 14 May 2021

We had several touchpoints over the last 3 weeks, including one today. During this time, we kicked off development and hit milestones.

In early touchpoints, we covered:

More recently we went over:

Development progress:

Next Steps:

cc: @jessicaschilling & timelytree

jessicaschilling commented 3 years ago

We've soft-launched https://ecosystem.ipfs.io, so will close this issue. Follow along with wrap-up and future work at https://github.com/ipfs/ecosystem-directory/!