Far as I can tell this is a really different use case from most markup languages:
- Set up a Google doc.
- Point a bunch of non-technical users (like reporters) at the doc to fill in content.
- Continually parse what they're doing into JSON that can be formatted and pushed live as soon as it's in decent shape.
It looks kind of like YAML/TOML/etc., but it's coming from a different place. You're not trying to make a .INI file a little friendlier for a human programmer -- you're trying to make a collaborative Google doc a little friendlier for a parser. Any design process that didn't start with an unstructured doc, and add the minimum amount of structure necessary to get something useful out, is going to end up with the wrong tradeoffs.
"You're not trying to make a .INI file a little friendlier for a human programmer -- you're trying to make a collaborative Google doc a little friendlier for a parser."
That's exactly what we were aiming for. TOML, which I think is brilliant for config files, was actually a bit of an inspiration for this.
But for our use case, which typically involves longer copy blocks, TOML still felt closer to something a developer might grok than to something a reporter would intuitively understand.
It's also worth noting we make abundant use of other formats in our interactive graphics — from JSON to CSV to YAML — when the data is much more structured and unlikely to be touched by a wider group of people in the newsroom.
This is pretty clearly not a solution to all structured data; but rather, just the subset that we want to be easy to write and edit.
I hadn't heard of TOML before today, and it looks like TOML goes a long way towards an easy to understand markup.
But even something as minimal as TOML still relies on several programming concepts for its syntax: the use of the equals sign for assignment, that strings need to be quoted, using "#" to begin comments. They're very basic concepts, but still concepts that need to be taught in programming 101.
The place where syntax errors in a live interactive graphic is dangerous is when it's public and a copy editor goes in to fix a typo. Even if they aren't familiar with every concept in AML (like square brackets to denote arrays), when they're fixing that typo, the only line they're editing is:
- Set up a Google doc.
- Point a bunch of non-technical users (like reporters) at the doc to fill in content.
- Continually parse what they're doing into JSON that can be formatted and pushed live as soon as it's in decent shape.
It looks kind of like YAML/TOML/etc., but it's coming from a different place. You're not trying to make a .INI file a little friendlier for a human programmer -- you're trying to make a collaborative Google doc a little friendlier for a parser. Any design process that didn't start with an unstructured doc, and add the minimum amount of structure necessary to get something useful out, is going to end up with the wrong tradeoffs.