Create interactive ecosystem directory

[jessicaschilling]

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.

• Feature prioritization workshop results/notes (added 23 Feb 2021)

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:

• Initial “Featured” view, where featured builders are chosen by the core team and easily modified periodically via PR
• Additional views by industry/subject:
  • Browsers
  • Ecommerce & marketplaces
  • Content (including hosting, streaming, CDNs)
  • Non-fungible tokens (NFTs)
  • Decentralized finance (DeFi)
  • Prediction
  • Social media
  • Data (including machine learning)
  • Persistence & archiving (including pinning)
  • Data governance
  • Identity
  • IoT
  • Integrations
  • Games & VR/AR
  • Other
• For industry/subject views with many builders, display alphabetically but with option for bumping high-impact ones to a specified position at the front
• For each builder, include:
  • Org/product logo (visual treatment of logos needs to consider that this summary view may be embedded in visually complex surroundings)
  • Hover state or similar introductory/teaser interaction with the following info:
    • Org name
    • Product name, if different
    • Short description of product (language should lean heavily on dweb aspects)
    • "Learn more" CTA
• Clicking “Learn more” (or the logo itself if not in the hover state) goes to detailed view of entire ecosystem (in modal or new page) with that builder highlighted
• A “View the entire ecosystem” link leads to detailed view of entire ecosystem (in modal or new page)

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:

• A sortable/filterable discovery mechanism for finding builders with similar concerns/aims to yours, using the following as parameters:

  • Industry/subject type(s) (multi-choice filter)

  • Product focus (this needs refining, particularly vis-a-vis overlap with industry/subject):

    • Web hosting/publishing
    • Academic/research data
    • Public/community data
    • File sharing
    • Dev tools
    • Pinning/object storage
    • Package managers
    • Mobile
    • Music
    • GLAM (galleries, archives, and museums)
    • Infrastructure
    • Education
    • Video
    • IP/reputation management
    • Community/mesh networks
    • Medical data
    • Supply chain
    • Streaming

  • IPFS enablers/benefits (multi-choice filter):

    • Developer enablement
    • Freedom from corporate/government interference
    • Disaster resilience/recovery
    • Data integrity
    • (others to be added at indeterminate date)

  • Tools/implementations used (multi-choice filter):

    • go-ipfs
    • go-lipb2p
    • IPFS Cluster
    • js-ipfs
    • js-ipfs-https-client
    • js-libp2p
    • pinning services
    • (others to be added based on collab surveys)

  • Size/scale factor as demonstrated by "big number" metrics (TBD - not for initial release, but should be built with this in mind)

• For each builder, include:
  • Org name
  • Product name, if different
  • Industry/subject type(s) (clickable to invoke a filter)
  • Product focus (clickable to invoke a filter)
  • IPFS enablers/benefits for this project (clickable to invoke a filter)
  • Tools/implementations used
  • Several-sentence description of product, focusing on its relevance within the dweb
  • "Since 20XX", i.e. year IPFS was added to project (note: in practice, population of this field may be sparse and may need to be hidden for initial release)
  • Affordance for one to four "big number" metrics, i.e. number of nodes, speed figure, percentage advantage (note: in practice, population of this field may be sparse and may need to be hidden for initial release)
  • Website link, if one exists
  • Repo link, if one exists
  • IPFS Docs case study, if one exists
• Note: This detailed view needs to take into consideration the potential for being visually overwhelming once it includes many builders, and take measures to reduce this (may require drilldown views?)

Additional requirements

• Must present as well with a data set of 20 builders as with 200
• Must avoid a “there’s a lot to unpack” reaction in simpler views relevant to the concerns of diverse users, e.g. developer, engineering manager, or the reporter who just wants to find a big-name builder to interview for a news story
• Need to offer unique URLs to detailed view as individual builder drilldown, or search/filter result drilldown, for direct linking or social shareability (including sharing cards)
• Detailed view needs to account for the display of individual builders about whom not much is known (i.e. fields only partially filled) without it looking empty
• Both the summary and the detail view must be able to be output as “flat” to be dropped into static websites as needed, and need to consider different deployment methods in general:
  • As static gateway-hosted page that can be included as an iframe (sans furniture, if there is any)
  • As a component included in another project (primarily ipfs.io, blog.ipfs.io)
• Must be able to easily add or remove items from existing parameters (i.e. add an industry/subject type) in the future without breaking anything
• Must be easily updated via PR, with the awareness that in future we may use Forestry to enable additions and updates AND/OR pull data from a CRM via API (requirements change: data source of truth will live in third-party DB and updated via re-importing JSON from that DB, so update request flow is out of scope here)
  • In the meantime, must include well-written checklist in PR template to make submission as easy and standardized as possible
• Needs easy mechanism for viewing results in staging, ideally using IPFS (Fleek?)
• Must implement the following metrics using Countly:
  • Most popular searches/filters
  • Most popular builders for clicking into detail view
  • Depth of engagement: how often user moves from summary to detail view
  • Most-clicked outbound links

Legacy documents

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

• Original product requirements document

[jessicaschilling]

Update, 23 Feb 2021

• Feature prioritization workshop with @orvn and Diana Santaguida at Agency Undone (their additional notes to follow in this issue's comments)
• Generated feature priority document that will be used as source of truth for next stage of work
• Next steps:
  • Iteration on requirements-based wireframes, with sync session 5 March to discuss/refine
  • Build wireframes to low-fi prototype, with review session 16 March

[D3AS8A]

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:

• Feb 24-March 4th : user stories, wireframe req. audit, xd file org
• March 5th: submit and discuss initial wireframes
• March 6-15th: implement change requests/feedback, develop prototype
• March 16th: submit and review prototype with Jessica
• Next: Pending feedback and any change requests, move into UI and mid fidelity

[orvn]

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:

• Information architecture and data structure, specifically as it pertains to URL and breadcrumb behavior
• Adjustments to the ecosystem browsing experience, particularly how filters work, and foreseeable edge cases around them
• Adjustments to the singular product page, especially the flow and order of sections and content, accounting for extreme cases (null and many)
• General rules surrounding mobile behavior
• Ideation and rules around a visual treemap
• Ensuring consistency with other IPFS properties and new IPFS initiatives
• Various other edge cases

Next steps

• Continuing with lo-fi prototype (as mentioned in previous updates)
• Continuing testing of any potential technical limitations

cc: @jessicaschilling & @D3AS8A

[orvn]

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

• Nuxt is to Vue as Next is to React:

  • It's the server-side rendered version of Vue, ensuring that it serves up bot and SEO-friendly content (which Vue doesn't do on its own, since it's a frontend-only Single Page Application that heavily manipulates the DOM)
  • Nuxt is a large, well-known, and popular project that most Vue developers either actively use or have come across

• VuePress is similar in implementation: pages are compiled into a static site and served server-side

  • However VuePress Is mostly designed for content-based projects, like blogs or documentation
  • VuePress use cases are built around having a substantial amount of text, and using Vue to provide additional functionality around interactivity (custom components, routing, etc.)

---

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:

• Nuxt will run in static mode: so it will compile into a static site
• Therefore it will still be usable on IPFS, and via Fleek
• The application can be switched into a fully progressive web app, with a dynamic backend, without significant overhead (if there's ever a need for it in the future, I know that that's unlikely)
• Nuxt will make the process of serving up endpoints for injecting the embedded container (CTA/summary view) easier
• Content will still be editable via markdown; or json, in the case of structured data, and PRs can still be made to amend data
• We could still integrate with Forestry at a later date, so provide more polished content management
• We have used Nuxt for other PL projects before, so we can port some useful base functionality over to accelerate development

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]

[FEEDBACK REQUESTED] @zebateira @jdiogopeixoto @cwaring -- I mentioned @orvn's comment above in our ipfs.io replatforming discussion in ipfs-inactive/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?

@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]

@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]

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]

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]

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]

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

[orvn]

@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]

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]

I mentioned @orvn's comment above in our ipfs.io replatforming discussion in ipfs-inactive/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]

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:

• Nuxt vs VuePress and IPFS gateway paths
• Abstraction of app theme SCSS for other projects
  • Which is feasible, but will require some additional polish for the new instances
  • Documentation for this project: theming would require a more substantial doc
• Potential treemap modifications
• Filter panel variations:
  • Collapsible vs persistent
  • Absolute overlay vs columnar (i.e., part of the main grid layout)
• Featured products section boundaries and behavior (on the ecosystem index page)
• Search as a substring match rather than a fuzzy search (for now)
• Singular product layout polish: success metrics, h1/h2/content hierarchy, logo positioning and whitespace

Next steps

• PoC for Nuxt IPFS gateway paths
• Tie up of the lo-fi changes established today
• Move the design to mid-fi, which will be more visually on-brand
• Next touch point on Friday, Mar 26

cc: @jessicaschilling & @D3AS8A & @emilymariahh

[orvn]

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:

• A new type of chart, displayed as horizontal segments instead of a treemap, which solves a number of hurdles including:

  • More ecosystem content above-fold
  • Feels like it’s meant to supplement something (whereas the treemap felt more of a standalone component)
  • Works well metaphorically with IPFS and concepts (and computer science concepts at large)

• Minor adjustments for mid-fi design of index and singular views

• Review of new mid-fi design for embedded view

• Consensus on miscellaneous other areas like: filter input placement, pagination, button position, heading position, URL formatting

Next steps

• Implement changes in high-fidelity version, which will have exact content and positioning
• Release Nuxt IPFS routes module and inform PL team
• Work on proof of concept for segment chart, especially visual logic
• Next touch point on Friday, Apr 9

cc: @jessicaschilling & @D3AS8A & @emilymariahh

[orvn]

Update, 13 Apr 2021

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

Key areas:

• Clarity around standalone treemap/logo-map requirement

  • (not directly shown in the ecosystem directory or embedded view)

• Review of high-fidelity designs and confirmed details before dev handoff

• Review of alternate visual treatment intended to test styling variability

• Progress with segment chart

Next Steps:

• Develop data models
• Internal design to dev hand-off scheduled for April 16
• Next major touch point scheduled April 23

cc: @jessicaschilling & @D3AS8A & @emilymariahh

[orvn]

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:

• Branching strategy, protections and commit conventions
• Header and footer will eventually be pulled in as a package
  • Static header/footer implementation in the meantime
  • This implementation will support future forks
• Hero variants (light and dark blue)
• Submenus and the state of the navigation currently
• Content to be added (by @jessicaschilling) as json with content areas become available
• Development of the project model, and some questions and clarifications to future-proof it
• Priority of essential features and functionality first
  • Design-related polish to be applied after a working version is shippable

More recently we went over:

• Process of transforming projects from the Airtable to our json schema
• Various settings and parameters that change the global behavior of the app
• Abstraction of features in such a way that it supports forking with minimal edits to the codebase
  • Ideally we'd keep as much as possible in settings values and theme styles
• Development progress

Development progress:

• Develop models
• Nuxt app structure, modules, other imports
• Path structure, URLs, params
• Segment chart with interactivity and responsive behavior
• Featured slider
• Header and subheader transition into search/focus state
• Singular page (excluding polish)
• Pagination

Next Steps:

• Transformation of data from Airtable to json structure
• Continue development, especially filtering functionality, list view
• Next major touch point scheduled May 21

cc: @jessicaschilling & timelytree

[jessicaschilling]

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/!