Possible improvements on data file template/schema

[lmammino]

I'm not sure that having a huge amount of json files is a great idea, but in case we keep going in this direction there's probably more space to optimize the template file format.
I would just raise a convenient discussion to establish the best format together before moving on.

Just some generic premises (in random order) we need to take under considerations:

• We need something that should be easily "parseable", and editable, even on github. So JSON seems to be an optimal choice for this purpose (also YAML might be worth considering)
• We need to build a script (or something) that reads all the data files and should be able to sync all the edits within a central repository (e.g. a database)
• We need to be able to validate the data files (so that we can skip the incomplete/incorrect ones)
• It might be good to figure out a (simple) strategy to make the data file schema updatable (new fields)
• The files should provide data that should be easily made "searchable"

Here's my proposal, starting from the original template file:

{
    "name": "Library name. E.g. gulp",
    "dependencies": ["nodejs"],
    "environments": ["frontend", "backend"],
    "audience": "", // <--- Not sure what it means
    "description": "A task / build runner for automating tasks such as ",
    "features": [
        "Killer feature number 1",
        "Killer feature number 2"
    ],
        "stability": "alpha, beta or stable",
    "website": "The official site url",
        "repository":"The url of the repository (in case it's an open project)",
    "similar": ["grunt", "gnu make"],
        "used by": [
             ["organisation1", "organisation1 website"],
             ["organisation2", "organisation2 website"]
        ]
}

A quick overview of what i changed with some other reasoning:

• Language -> Dependencies: does it really matters how a tool has been built? I think it matters only to be sure to have the right dependencies before installing it. So why not use an array of dependencies?
• Environment -> Environments: It's better to have an array here (eg. reactJs is both backend and frontend). I am not sure if it's an useful thing to have/maintain tough... we would need to create a set of predefinied enviroments. And I am also not sure it provides a lot of value to the end user. Maybe it's better to skip it.
• stability : this can be useful to have (to evaluate among similar tools)
• Official -> Website: it just makes more sense to me 😉
• Repository : can be also really useful (all the package managers includes this info). We can also use this info to pull other informations like github stars, commits, contributors, etc. at a later stage
• Similar: I think it's better to have just an array of names here (essentially references to other data files)
• Used by: This can be cool to evaluate the quality/notoriety of a tool (eg. used by facebook/twitter/google/airbnb, etc.)

[d4nyll]

Regarding all five of the first set of bullet points - MongoDB would be perfect for the job

• It uses JSON (actually BSON, but close enough)
• The JSON can be stored into the database directly
• We can certainly validate files using a script, checking that the JSON contains the required fields
• Since MongoDB is NoSQL, we can change the schema easily without having to update the entire collection (the equivalent to table in SQL)
• MongoDB provides methods for searching through the database (find())

[d4nyll]

• I like the dependencies field because it's often useful to know what things are built from. The reason why I had languages is because maybe a developer would want to contribute to a tool and they are good with JavaScript but not so much with Ruby, then they can search for all tools written in JS. So language and dependencies should both stay I think.

• People using wwwoolbox should immediately know what the tool does, and I think whether it's front-end or backend is very important. There are not too many environments we have to define - server, client, and then further break it down to android, ios, mobile, windows, linux, osx etc. E.g. Meld is a great diffing tool, I want to know _immediately_ whether I can use that on Windows, or Mac or Linux.

• Stability definitely, but this can be quite subjective. Maybe do it in terms of the latest version number - the drawback of this is that it'll be quickly out of date. An alternative can be to specify the year it started - but older frameworks are not always more stable. So maybe an array of the major releases can be shown -

  Began - 23 JAN 2013
  v1 - 12 DEC 2013
  v2 - 07 MAY 2014
  v3 - 21 MAY 2015

• Website - yes

• Repository - yes

• Similar - I thought about an array but I also want some information regarding how the tools are related. Two may do the same thing but one is super-outdated. I want this information to be there immediately without the user having to click through. So it can be an array of objects?

• Used by: That's good, we can pull some data from stackshare maybe

[d4nyll]

Next, we need to think about which properties should be required and which ones are optional.

name, description, language, dependencies, environment for me are all required fields. The rest are optional. Thoughts?

[lmammino]

@d4nyll, I do agree with almost everything.

Just two arguments:

• stability: most of the frameworks/libraries are explicit these days about their stability. Anyway I do agree that it could be hard to find a precise rule that is valid for every possible package. At the same time your solution seems to be too much complex and hard to mantain. Maybe it's better to skip this field at all. We can otherwise add an optional attribute called "firstReleaseDate" (or something like that) that could reflect better your idea and also be more maintainable (not subject to versioning).
• focus/environment: you spoke about Meld, which is a useful tool (desktop app to be precise) to use during software development but it's also a very generic tool not strictly related to front-end development (or web development in general). How broad we want the selection to be? I think a too generic scope would be really hard to standardize and maintain. Maybe it's better to focus (eg. only frameworks and libraries for web development)

[d4nyll]

The thing with firstRelease date is that it's not a good indication of stability. But you can argue my approach is not great neither. So let's say we skip that field for now and we can always add it later

[d4nyll]

Regarding focus - I want it to be _any_ tools that a person involved in web development could possibly use, so even Adobe PhotoShop and Illustrator. The idea is that ANY tool a web developer might need to know, we will list it.

A designer might say he'll do the work in Illustrator and give it to you. But illustrator is not free so the web developer goes to wwwoolbox and type in Illustrator and they find Inkscape is a free alternative. And he can use Inkscape to open the file and help him get the HTML and CSS pixel perfect.

Going back to Meld - that is a tool I use often for web development - either that or diffchecker online - for example if the last commits (by someone else of course!) broke things I use it to debug through the possible culprits.

I definitely don't want to limit it to frameworks alone. BitBucket is not a framework but it's a great tool for example.

Of course we should focus on a small area first - one that we are familiar with - web development - and we may advertise it as such. But in the long run, it'll definitely include other tools from related fields, such as web design and system administration.

[d4nyll]

TL;DR we should focus on one area - web development frameworks and libraries - but do not set that as a limit if someone else wants to contribute in a different area.