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 nontechnical people.
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, any idea?
> 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")
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".
someone in the comments here said that zebra stripes are a bad practice and linked to some resources about that, so guess zebra stripes won't do (I'm also using them for objects, so they won't stand out as lists but as collections of things together with objects)
someone pointed out on an issue that empty lists and empty objects can't be differentiated, so a solution that handles both would be cool.
Re: list styling - you can make the whole list a different colour and also "extract" it with different borders. Consider indenting items more visibly - either more leading space or a more visual left border (e.g. something that looks like [ or { )
A icon prefix for each item. For example, taking from bootstrap glyphicons, icon-comment for strings, icon-calculator for numbers, and icon-check for booleans.
I agree. The "code" in the example page is, to me, easier to understand than the "human-readable" output.
For me, it's about spacing efficiency (I can see more at once), formatting (e.g., italic is not as easy to read as roman faces), and color (green on grey? huh?).
But I've always been a fan of plain-text in general. I'd much rather use plain-text markdown than MS Word, or edit code in plain files as opposed to an IDE. Plain text, to me, is much more WYSIWIG than any GUI tool I've used. But I understand that not everyone thinks the same way.
Yes, but non-technical project members may not. This is pretty useful to pretty-print this information so it's readable in design docs, etc (it doesn't replace the json raw data, just explains it a bit better)
the lib from this article is more tailored for apps that want to display arbitrary json to a broad range of users. As someone asked, there are not many uses, but I have one in my web app (http://event-fabric.com/)
This is great! And nicely written--it would be very easy to modify this to format things differently. Eventually, it would be cool to have the conversion go both ways. That way it could be incorporated in a CMS (arbitrary structured content being passed around as JSON but displayed and edited in HTML).
the next next step would be to provide in place edition with validation :)
Definitely! Take a look at http://createjs.org/--it will probably help (in fact, I've been using it for a different project and if I have time I might be submitting a pull request to you in the next week or so).
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.
YAML was my first thought as well. Why not a library that converts back and forth and displayed the YAML in a pre tag or textarea? Then you could edit the YAML and after converting back still have valid JSON.
YAML is a superset of JSON, but as long as the YAML used to convert to JSON started as JSON, there shouldn't be a problem.
I use INI for configs most of the time, too, but if I ever need multiple-nesting or lists, I don't really have any choice but YAML. It's not common that I need that, but it can be useful for really big applications.
pyyaml provides the option of using the cyaml loader, but I dunno about the dumper.. if you're experiencing delays with reading, try setting Loader=cyaml or whatever.
I can understand the usefulness of things like Krumo[1] for PHP but I am struggling to understand the use-case for this. With a language like PHP you don't have direct manipulation abilities (without debugging using an extension) so it makes sense that you need to format the data before you send it to the client but with JS you have the ability to inspect the JS directly. Also I think JSON (with spaces/indentions/linebreaks) is extremely readable (Especially with things like PrettyPrint[2] installed).
I made it because my app (http://event-fabric.com/) receives arbitrary JSON and one of the options you have is to inspect what is going through the steps, so I need the ability to format arbitrary and possibly nested JSON in a pretty way but without hidding the JSON structure because the app is to actually inspect and manipulate that JSON.
until now I was using a pretty printer but the result was too "technical" for non programmers to see (at least that's my opinion).
It's been baked into http://www.servicestack.net web service fx and lets you see a human readable view of every web service response when called from a browser (i.e. Accept:text/html).
It's also has dynamically sortable table rows and is also completely static/stand-alone. It's just a static template that wraps an embedded JSON response and converting it to HTML on the fly and injecting it the page (all client-side / use view-source).
I was looking this morning at a lib to do this and I couldn't find one, but at one stack overflow question someone posted a screenshot of the ColdFusion tool and I said "that's what I need" and then I decided to do it myself.
nice, I didn't found it this morning when looking for it, maybe since it says prettyprint for javascript it didn't rank high on the search results for my query.
Great work! Would be nice to add an option to convert json key names to human-friendly names(passed as a separate key value array). So a key like full_name can appear as "Your Name:" to the end user.
It might be good enough (and less complicated) to just optionally prettify camelCased and underscore_separated field names (to "Camel Case" and "Underscore Separated", respectively).
I've been using a library called prettyprint.js for quite some time that basically does the same thing but a bit prettier and from what I remember is basically a port of sorts of Coldfusion's cfdump: https://github.com/padolsey/prettyPrint.js
I've used this library recently to help the QA's better understand a JSON API's output.
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.
yep, JSON is really readable when indented and colored, but if you need to display it to non technical people something more "tabular" may be a better solution.
http://jsoneditoronline.org/
Easy to use, and makes working with complex JSON a snap.
The source is also available:
https://github.com/josdejong/jsoneditor/