Check out our website at ipfs.tech.
For papers on IPFS, please see the Academic Papers section of the IPFS Docs.
MIT.
Interactive showcase of projects and products built using IPFS, the InterPlanetary File System.
Home Page: https://ecosystem.ipfs.tech
Check out our website at ipfs.tech.
For papers on IPFS, please see the Academic Papers section of the IPFS Docs.
MIT.
A schema for all the options within the app, both those specified in #30 and the essential config for the app, like the source of truth for accepted categories.
Now that we've got space for an embedded video, we need to source the individual videos.
I'll add a column to the Airtable sheet and start populating these as I'm able ...
This page displays a single project and all information available on that project, as shown in the high fidelity designs.
It is the most comprehensive instantiation of the project model, and will often link off-site to resources like docs, repositories, case studies, primary websites, etc.
Each project will have a dedicated and human-readable path (also known as a slug).
Create initial comms/marketing plan using previously created ideation template - particularly as regards blog post, social media, newsletter promo.
Ideally the documentation for this repo wouldn't just live in a readme.md
, rather it should be fragmented into an information architecture and perhaps put into a Github Wiki (associated with this repo).
The one thing I'm not sure about is whether Github-based repo wikis transfer on clone.
The ability to sort results by available criteria.
The hero section, in the context of the Ecosystem app, refers to the entirety of the section below the navigation, but above the page's core content.
It contains the heading (and on other IPFS properties can include an image, although this is not the case for this Ecosystem Directory.
It should be split from the navigation, because it requires some state-based functionality.
Most importantly, it needs to alter the heading based on which filters are selected. The heading should reflect the filter state, as should the URL fragment/parameters.
Just dropping this in the issue queue so we don't lose track of it as we get closer to launch. ๐
@jessicaschilling I'm not sure who the correct person is to whom I should assign this, so I'm throwing it at you for the moment ๐
It would be great to get this directory up and running on 2 separate Fleek builds/urls for our 2 primary branches, this way we can get visual feedback on development fairly quickly. Giving the Fleek app access to this repo would be great as well so that we can see (directly in this repo) the โ for when a build has completed an an X if the build fails. The information to input would be as follows:
โโโ master
branch
Environment variables
NODE_ENV=production
SERVER_ENV=production
Build command: npm ci && npm run generate
Docker Image: fleek/nuxtjs:node-12
โโโ develop
branch
Environment variables
NODE_ENV=production
SERVER_ENV=development โ this is important
Build command: npm ci && npm run generate
Docker Image: fleek/nuxtjs:node-12
CC @orvn
Relayed from @thattommyhall: Filter panel chiclet doesn't do what's expected upon multi-selection โ "in my head you are filtering for any of N industries, not each of N".
Indeed, this is an expected e-commerce pattern โ example from Amazon:
Regardless of final approach to "or" vs "and", let's consider the following:
Per discussion with @orvn and @D3AS8A, we'll need a minimum of roughly 50 participants in the directory at launch in order for the treemap to be useful. More is, of course, better.
Ref: https://airtable.com/tblxBjPTzHXiUVZAA/viwpijXTIFraPRkhE?blocks=hide
A header and footer, whose theme is based on the design for this project, as well as the overall theme for IPFS properties.
Note that this issue/task covers a static header and footer, whose content will be stored in a json
file, within the repo.
At a later date, there will be an option to import a custom header and footer per IPFS org-wide requirements. This feature isn't available yet.
Nonetheless, developing a static and themable header/footer is essential for the support of future repository forking.
Per @autonome, we will need to add an alternative means of visualizing the data so that it can be presented as a static image with all data on display, most likely in a slide-deck context. This has been socialized as a treemap, so unless there's a compelling reason to use a different method, suggest we stay with that. This doesn't need to be specifically part of the ordinary presentation of the rest of the app, but it would be a nice touch to invoke it by a "view as treemap" element or similar.
Requirements:
Using this issue as a holding pen for pre-launch items โ we can split out into separate issues later as need be.
main
and develop
branches (can't currently do this on private repos) to keep from automatically deleting those when they're head branchesmain
branch to Fleekcname
for ecosystem.ipfs.io.
) to route to Fleekmain
Countly
) is configured on production branch (main
)While designing the ecosystem layout we knew it would need to be flexible across vastly different brands and design systems. Once the layout was finalized we took a short amount of time to stretch the design possibilities within template by applying an alternate design framework. Here's the results (VERY quickly mocked up!)
Populate the non-project text for the site (that is, text that isn't sourced from the project database).
Text is currently in lorem ipsum - I'll chip away at PR-ing those changes.
If you sort by alphabetical order and go to page 2, then switch to sorting by time on IPFS you'll end up on page of that sort instead of resetting back to page 1 (which is how GitHub issues and I think most other places do it).
Confirm that an IPFS-based deployment of Nuxt can run at both root domain (app.website.tld) and via gateway access (gateway.ipfs.io/ipfs/cid).
Ref: conversation beginning in https://github.com/ipfs/website/issues/410#issuecomment-799723865
Currently, the app is functional, but lacks the visual appeal and tacit cohesiveness that interaction development facilitates.
This ticket includes:
Furthering on #46, we have a list of categories and their tags defined here.
This is based on exporting the fields from the Airtable and parsing them. This file, taxonomy.json
is the source of truth for all categories and tags. This means that if a project tries to invoke a category or tag that isn't defined in the master taxonomy, it doesn't get displayed (presumed a typo or some other kind of error).
However, the content in this file is a little long-winded right now. I believe you mentioned wanting to truncate and formalize the naming for these tags and categories, correct?
A script is required which pulls data from the CRM and transforms it into our project model (#10, doc).
This script:
A minor potential blocker that needs to be researched is exporting images from the CRM. Since they're all SVGs, we might want to optimize them too, with a tool like svgo
.
Pagination of the Ecosystem index page, including and search or filter state that may be accessed.
Pagination will be reflected in the URL with parameters.
The following need to be identified:
The 404 page must follow IPFS specific 404 page routing
We need to create a workflow for adding orgs to the directory in the long term โ either folks who ask to join, or orgs we identify in our day-to-day.
CC @autonome โ if this is no longer your area, please let me know who to talk with. Thank you!
Once this work is in a finished enough state to recommend forking for others' projects, create a less IPFS-specific "boilerplate" version in (probably) the ipfs-shipyard org in order to give others both a clean starting point and to provide an example of how the app can be set up to meet a variety of needs. The work might involve:
We've decided to separate taxonomies, i.e., the definition of allowed categories and tags, into its own file. This will be separate from other settings (see #30 and #43).
Taxonomies need to be created, and then imported based on the actual data we currently have available.
This is a blocker to progress at the moment.
It seems slightly weird to me to have "other" in the logical middle of the list ahead of much more important categories like NFTs, DeFi, etc. Can we adjust to put those popular categories earlier in the list (ex before "integrations") and move "other" to the very far left?
In the build process, the directory with the projects (content/projects/*.json
) should be traversed and its contents needs to be written into the manifest.
Initial development work on this directory has been taking place concurrent to other teams' work on a PL-wide CRM database. While it's not practical to add this directory's source data to the CRM database while both items are under active development, it's reasonable to expect we can consolidate these prior to launch.
We'll need data structures for:
(The latter two might could potentially be combined)
Requirements:
Each project should be its own object which will exist as a json
file (as opposed to a large json
structured as an array of objects)
All models should be structured such that they are extensible and fault tolerant (i.e., missing an expected, or containing an unexpected value does not cause issues)
{
"projects": [
{
"id": 1,
"name": "Hello World",
"attributes": {
"foo": "value",
"bar": "value"
} }
]
}
In this example all optional attributes are nested within an attributes
object
The responsive design for project pages.
This will include a slider that enables the CTA cards and stats to be swiped. Most other content will simply collapse down into a smaller set of columns per the grid, but some adjustments will be needed to polish the mobile and tablet views.
A panel on the ecosystem index that allows control off all filter states, including chiclet selection, input field (string) search and clearing selections.
When the filter panel is accessed, the state of the ecosystem index becomes more purposeful, hiding elements like the segment chart and featured slider.
Filtering should occur in real time, and should feel haptic for the user. Fortunately this is exactly what SPAs like Vue are designed to do.
This issue is for accumulating fixes (functional and visual) that need to be made prior to a successful soft launch of this site. I'll continue to add items to the checklists in this original comment as I find them; for the sake of expediency, please feel free to work any unchecked items in the meantime, and leave notes in subsequent comments. ๐
Featured projects
section - but how?Home
shouldn't open in a new tab|
instead of /
as divider|
instead of /
as dividerFeatured projects
and All projects
headers text bigger; 1.75rem
looks nice, but please tweak if that doesn't work within an existing typography hierarchyView All
should take the user to all projects for that category (so in the example below they'd go to all projects in Other)Alphabetical (A-Z)
, Alphabetical (Z-A)
, Time on IPFS (newer)
, Time on IPFS (older)
class="filter-category sub-heading"
customizable in json? If not, can it please be? margin: 6px 6px 1.5rem;
font-weight: 600
and add underline on hoverfont-weight: 600
and add underline on hoverHome | Ecosystem directory | All projects
or, once a filter is invoked, Home | Ecosystem directory | Filtered results
if that doesn't mean massive logical heavy lifting.?/filters=enabled
query param breaks site Breadcrumb should read fixed in #141Ecosystem directory
(note lowercase) rather than IPFS Ecosystem
Please make h1
line-height smaller, as it looks awkward when project names run to multiple lines. line-height: 1.2;
looks good if it doesn't mess with your type hierarchy.
Ditto with the titles in class="card case-study"
, please.
As with front page, please make "Key info" header bigger (1.75rem
or whatever is consistent with your overall type rules)
Please make class="description"
text the same size/line-height as class="company"
, and knock the opacity of class="company"
back to 0.7
to fake a gray (or some other solution that doesn't cause too much pain in the skinnable CSS)
For Project Website
button, please lowercase "website" (fixed in #141) and make color/hover behavior the same as for the Subscribe
button in the footer
For tag chicklets, please make the text white and background #34797D
on hover
Please make text link colors (e.g. website, repo links) #34797D
instead of the ice blue currently used
Please reduce the line-height for class= statistic
in the big-number boxes, as they're really tough to read when a line breaks:
For the Key info
section at narrower widths, please add some space after each category/value pair so it's clearer what categories are attached to what values:
At narrower widths, the grid injects a fair amount of dead space to the right of everything above the accordion chicklet section. Possible to mitigate this?
I'm afraid I'm still tripping up at the Featured projects
callout looking like it's actually giving information about the project on the detail page rather than being info on other projects. Can we please put this section in a pale grey box similar to the big-number boxes?
At narrow mobile widths, the arrows to go between big-number boxes are counterintuitive and tough to use. I believe I saw a comment elsewhere about this, but flagging here in case not.
Clicking chicklets on detail pages takes the user to a URL that makes sense, but displays just like the ordinary front page. I believe this is under discussion elsewhere, but just flagging here for inclusion.
This is a slider that appears at the top of the ecosystem index, below the segment chart.
It shows projects that are featured, and its contents are controlled by a setting.
The slider should support a custom scroll-bar like element, shown in the design.
This slider moves whole slides, there should be no state where the user can freeze a partially obscured slide out of the viewport.
The slider should respond to scroll when a cursor is hovered over it, and gesture controls on mobile (horizontal swipe/slide).
Complete hi-fi design mockups suitable to passing to dev team.
Artifacts to be reviewed/iterated Friday 9 April at 12:30 ET (10:00a MT).
Furthering off of the PoC #7, the segment chart/worm chart needs cleanup for:
The ecosystem index page's core content will be a grid of cards, where each card represents a project.
These cards will be togglable between two states: grid or list view. Each view is visible in the high fidelity designs.
Toggling a view will write a param to the URL.
In either state, cards/project containers will adhere to a responsive grid, ensuring that they reorient on devices of different sizes.
Complete next round of design iteration:
To be discussed Friday 26 March at 12:30 ET (10:30a MT)
This application should be SEO and social friendly, allowing admins to control which metadata will appear in seach engines and social sharing.
Additionally, it should use json-ld
style microformats for structured data.
This container is a specialized design that can be injected into any external site.
It can be seen in the high fidelity design, however, this implementation is highly specific to the IPFS ecosystem project. This feature will be need to be customized if this repository is forked for other instantiations.
This embeddable object will:
An analytics implementation with Countly should track the following:
Because this is an SPA, we'll need to account for not only conventional navigation, but also virtualized.
In addition to the model for projects/entities, a data structure is needed to set parameters around the application's functionality.
This should be extensible, and should include a list of required settings.
Some of the settings that will be proposed in this issue will be quality-of-life in nature; i.e., they won't be absolutely necessary for this instance of the project (however, it's good to think of them in advance to ensure the most extensibility).
As mentioned in https://github.com/ipfs/website/issues/410#issuecomment-811600672:
Artifacts to be reviewed/discussed Friday 9 April at 12:30 ET (10:00a MT).
Project cards should be abstracted into their own component
The responsive view, down to the mobile breakpoint of the ecosystem index. This includes:
Making this an issue for the sake of visibility to @andyschwab โ Andy, can you please protect the two branches below as I don't have enough access? Thank you!
develop
main
and develop
branches from auto-deletion upon PR mergeThis is a large issue that will continue to stay open until this project meets the standard outlined in the design
The app should be regression tested in:
(Even though some of these are Chromium-based, or share it won't hurt to at least smoke test on these other browsers).
Mobile:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.