Open pjcozzi opened 3 years ago
Technically, this could be possible with not tooo much effort, given the existing infrastructure of the project explorer. Much of the project explorer was written generically (for somewhat arbitrary projects). Generalizing this to "articles" would probably be doable.
(Leaving out the question about the "level" of which this generalization could/would take place: Ranging from copy+pasting the whole thing, calling it glTF-Article-Explorer
and adjusting structures like https://github.com/KhronosGroup/glTF-Project-Explorer/blob/master/src/interfaces/IProjectInfo.ts , over adding some sibling structures in this repo (like an IArticleInfo
), up to the point where it becomes totally agnostic of the contents, with an IEntityInfo
and a schema-like JSON file describing the "entity properties" and "filterBy-properties" or whatnot...)
But for me, it's hard to estimate the "demand" for that, i.e. whether people would really use this to search for information. (Google is just too powerful). One intermediate/preliminary step could be to think about whether (or how) the articles could be structured in the README. Similar to the original structure for projects in the README, which had some hierarchy/information like "Exporters" / "C++"
and such. One could consider classifying the articles, with classes like "overview"
, "comparison"
, "feature-description"
, "conversion-tutorial"
or so, to see whether this shows some depth, or multiple dimensions that could sensibly be searched/filtered along.
@javagl sounds like there could be a schema that is input to glTF Project Explorer to define the fields to turn it into glTF Article Explorer, or anything else for that matter. It would be cool. At Cesium, we certainty want to do something like that for (1) 3D Tiles, and (2) Cesium apps.
Specifically for glTF articles, I previously just tracked: title, date, and author. More per-article metadata would be amazing, but I think most of the value is in tracking the articles, showing momentum, providing the community a central knowledge base, etc. so a very low tech / lightweight solution could be fine if folks want. I'd just love to see some work to track glTF articles even if it is the same "edit the README.md" approach.
@javagl also might be worth a look at what Vulkan, WebGL, and others do.
Similar to how we use to track glTF ecosystem projects in the glTF GitHub repo's README, presentations and articles are still there:
However, we/I are not tracking them as much as we use to.
Should there be a Project Explorer-ish approach to this? Or is it simply a matter of keeping the README.md up-to-date?