61–70 of 71 posts
I'm using Jason.app[1] on OS X which does this wonderfully (as desktop app). [1] https://github.com/tbrannam/Jason
Agreed, Jason.app is really handy for browsing, validating, prettifying, and minifying JSON. I think the outline view is even less friendly for a non-technical person though, listing every value as a name/data-type/value row.
I really enjoy JSONView for solving this problem. Chrome extension: https://chrome.google.com/webstore/detail/jsonview/chklaanhf... Original firefox extension: http://benhollis.net/software/jsonview/
I use this almost daily, lets you easily format/compact and edit JSON through a GUI: http://jsoneditoronline.org/ Easy to use, and makes working with complex JSON a snap. The source is also available: https://github.com/josdejong/jsoneditor/
nice! didn't know about it. in my case I needed a library to use it in a web app. bookmarked anyway for personal use :)
I dump my JSON as YAML. Even if you are not using YAML for saving data (and I don't -- in Python at least PyYAML is orders of magnitudes slower than the built-in JSON), it is nicer to read.
Pretty funny considering JSON is self described as "easy for humans to read and write." If your target is nontechnical folks, I wonder if it would be useful to go a step further and: - Remove quotes from strings. They're already formatted differently. - Remove array indices. - Unescape strings. The context and formatting should still be enough for devs, but I can't imagine quotes or indices do anything for nontechnic…
about removing quotes from strings, I tought about it, and I think as long as some other display property is different (to differentiate the number 4 from the string "4") and something more than color to avoid causing trouble to colorblind people I think it's a good idea. the array indices I was thinking on having it as an option, I would like 'something' to make them standout as lists even when no index is displayed…
Earlier quoted context omitted.
Agreed, Jason.app is really handy for browsing, validating, prettifying, and minifying JSON. I think the outline view is even less friendly for a non-technical person though, listing every value as a name/data-type/value row.
Why are non-technical people looking at JSON?
Earlier quoted context omitted.
I use YAML for configs, as an option for API endpoints, and sometimes for debugging. Anything else that's computer-to-computer is JSON.
I still like INI for configs. It's extremely simple and hard to mess up, and I think it's more readable than JSON.
I always try to use the right tool for the job.
Pretty funny considering JSON is self described as "easy for humans to read and write." If your target is nontechnical folks, I wonder if it would be useful to go a step further and: - Remove quotes from strings. They're already formatted differently. - Remove array indices. - Unescape strings. The context and formatting should still be enough for devs, but I can't imagine quotes or indices do anything for nontechnic…
about removing quotes from strings, I tought about it, and I think as long as some other display property is different (to differentiate the number 4 from the string "4") and something more than color to avoid causing trouble to colorblind people I think it's a good idea. the array indices I was thinking on having it as an option, I would like 'something' to make them standout as lists even when no index is displayed…
The problem is that for most people the technical and subtle difference between 4 and "4" does not have any meaning except that "the system" apparently differentiates for some reason. Subsequently they will (implicitly) attach some meaning to the difference, but, as they don't have a background in information, their understanding probably does not correspond with the reasons why you implemented this difference. For example, they could think that "4" means "about four", or "four is important", or "four", or whatever.
Unless the difference between "4" and 4 is or becomes relevant to the user, the user should be prevented to have to differentiate between the two. And "because the system asks for it" doesn't really make it relevant to most users.
I do understand the problem, of course. Without some function attaching meaning to the JSON fields, a program cannot know if a 4 has to be 4 or "4". That means you have to make a rule one way or the other. The question you should ask yourself is: which one is best in your situation given the audience you target. Possible rules:
- a numerical number on its own, however written, is interpreted as 4 instead of "4". So, "4", " 4", 4, " 4 " will all be interpreted as 4. - all primitive fields are all strings. The program has to attach meaning to them. So, 4, "4", " 4", are all "4" - there is a difference between "4" and 4. If you want the number, use 4, if you want the text four written in numericals, use "4".