Json.human.js: Json Formatting for Human Beings | Hacker News Reader

Json.human.js: Json Formatting for Human Beings

marianoguerra.github.io

155 pointsmarianoguerra69 comments

Open articleView on HN

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 :)

The library that website is built on is Open Source. We use it for an internal project at work.

I think a tree view make for more sense for navigating JSON. The table view of the parser is very confusing for any JSON with lots of nesting.

If you add an assignment at the beginning, you can do this in your browser console :)

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.

e.g. ["\"foo\"","bar"] translates to:

"foo"

bar

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?

will open issues for both:

* https://github.com/marianoguerra/json.human.js/issues/5

* https://github.com/marianoguerra/json.human.js/issues/6

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 { )

Thanks for the quick response. I guess I should have opened issues myself, but I have some irrational fear about using github features.

>something more than color to avoid causing trouble to colorblind people I think it's a good idea.

I think what you have is decent. Bold for numbers. Italics for literals.

Making arrays stand out is tough. Perhaps you could do some zebra striping on arrays. Or use bullets outside of each array value that mimics a list?

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.

question: why the github fear? :)

Without derailing this thread, tldr: social anxiety around contributing to OSS. That sounds pretty dumb I know.

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.

> 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".

They already stand out as a list by the fact that they contain multiple items.

You know, it's funny but I find the pretty-printed JSON easier to read than the formatted HTML.

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)

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/

Was just about to post this same thing, huge plus one. JSONView is a life saver, highly recommended.

can't live without it to work with JSON APIs.

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/)

Another vote for JSONView.

Ditto. Between the indentation, colorization, and tree collapsing, I don't need much more from a JSON viewer.

I love it too. Maybe this should be dumped into a Chrome Extension for 'non-technical' people?

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).

since css classes tell you what's inside you can recover it completely, also I was thinking on using HTML5's data- to store the data there too.

the next next step would be to provide in place edition with validation :)

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).

that would be cool, let's track it here: https://github.com/marianoguerra/json.human.js/issues/7

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 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 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.

I always try to use the right tool for the job.

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).

Where do you see this being used?

[1] http://krumo.sourceforge.net/

[2] https://chrome.google.com/webstore/detail/prettyprint/nipdlg...

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).

I did something similar a few years ago with the HTML5 JSON Report Format: https://github.com/ServiceStack/ServiceStack/wiki/HTML5Repor...

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).

Here's a live preview of it in action: http://servicestack.net/ServiceStack.Northwind/customers/ALF...

And the JSON service it's wrapping: http://servicestack.net/ServiceStack.Northwind/customers/ALF...

This reminds me of ColdFusion's cfdump:

https://www.google.com/search?q=coldfusion+dump+object&tbm=i...

http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0...

the world is a circle

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.

now someone mentions it here, full circle :D

I use http://james.padolsey.com/javascript/prettyprint-for-javascr... at work in a debugging interface for AJAX requests. Sometimes having JSON pretty-printed in the sidebar is more convenient than clicking on it to expand it in the console.

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.

author here: let me know if you have any questions

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.

thanks!

I created an issue for that:

https://github.com/marianoguerra/json.human.js/issues/2

also one to customize the display of booleans (sometimes on/off, yes/no are better than true/false)

https://github.com/marianoguerra/json.human.js/issues/3

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.

It's the same idea as treeIt, a script I made a while ago: https://github.com/alessioalex/treeIt

Edit: treeIt can be used also in Node, has tests written for it and you can customize the HTML template for it.

Don't use zebra coloring on tables. Edward Tufte strongly advises against this; see http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0... esp.

I will read that later, I opened an Issue to remind myself :)

https://github.com/marianoguerra/json.human.js/issues/1

thanks, didn't know it was a bad practice.

This would be a fantastic option for the admin interface's of JSON document stores like CouchBase, ElasticSearch or RethinkDB.

JSON is easy to read, but can get hard to visually parse when the payload is large.

I built something like this, but with the added functionality of admin-style inputs, much like what you seem to be looking for.

It's working (not done yet), but I've got an update on my local that I need to iron a bit before I commit.

Oh, and the name sucks.

https://github.com/dclowd9901/lscenery

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.

Why are non-technical people looking at JSON?

I don't know of a particular example. I only mentioned that in the context of the json.human.js library apparently targeting non-techies.

This is awesome.

It's funny, I didn't think it would be useful until I actually checked it out, because I personally find JSON to be fairly readable.

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.

that's the reason for this lib.

thanks for the awesome part :D

I actually think the source example on that page is far more readable than the HTML formatted output.

Maybe I'm not human. Captchas have been telling me this for a while.

Or just use QML: http://en.wikipedia.org/wiki/QML#Basic_syntax

My go to JSON viewer continues to be http://json.parser.online.fr

I find the the input format much easier to mentally parse, and it's more compact too. Maybe I am not human.

I have the same doubt sometimes.

happy programmers day! :)

That's funny because JSON is enough readable by itself. My life has changed a lot.

Should have called it humon.js. Missed opportunity.

I actually find easier to read raw json....

s/loosing/losing/

thanks! fixed and pushed, should update in some minutes.

Also to/too in "to technical"

thanks, fixed and pushed.

HN is like a free proof reader as a service :P

when two words have similar pronunciation I may write the wrong one.

for me it's more easier to read json than html formatted one.

Reply on news.ycombinator.com