JSON Settings

In all of my most recent web apps there is an Edit Settings as JSON… option in the Settings menu. This displays a dialog box that allows you to edit each applications configuration data as either a hierarchical tree list or directly as JSON text. JSON stands for JavaScript Object Notation and refers to a simple human-readable text format for representing data objects as hierarchical key-value pairs. Whilst all of these configuration values can be set and interacted with via the main user interface, they are all enumerated in and editable via this dIalog.

Explanation

Way back when I was an academic, one thing I still vividly remember was trying to use software to interactively demonstrate stuff live during a lecture or presentation. Even if you were able to get things up and running beforehand for the opening demonstration, this invariably meant everyone watching bemusedly as you hunt around your file system for the next model to load and then launch several different dialogs to adjust all the settings and parameters required to get exactly the right view or configuration for each subsequent one.

Having done this with lots of different types of software over many years, much of it my own, I have become quite opinionated on this subject and the JSON settings editor in my current web apps is the result. Being able to simply drag and drop a file onto the browser window that can control every aspect of the application and its model is a godsend. Whilst I fully understand that it may not be the most obvious or best solution for everyone, it does have some interesting and useful features.

First off, the JSON settings data simply stores the web application’s current state, so by using the controls in the main user interface you can edit, save and load settings in each app without ever even seeing any JSON. Thus the majority of users probably won’t need it or even know it’s there.

However for those who do, the kind of low-level control that text-based human-readable configuration files allow can be really useful and provide much needed flexibility. That is why most developer tools still use them extensively. The JSON format used here is small, mostly self-explanatory and easily edited even outside the software using any text editor. You can easily copy/paste an existing configuration and very quickly tweak it into a new one, save multiple copies with only slight variations, or even email it to colleagues as part of the body text or as an attachment. It is fully cross-browser and cross-platform compatible, even on phones and tablets.

Importantly, the structure and layout of this configuration data directly reflects the class hierarchy in each application’s tutorial scripting API, making it a particularly useful visual reference. Also, as the configuration data for each application is broken into distinct sections, you can even reuse the same JSON files in different apps as they will only read the common sections they recognise and ignore everything else.

Obviously the web apps currently available on my site are not likely to be crucial to anyone’s livelihood or wellbeing, so I acknowledge that this might be solving a problem that doesn’t yet exist. However, imagine someone emails you some settings data and you receive it on your phone. Instead of having to save it locally somewhere and hoping that you can then access that same location from within a web browser in order to load it in, you can simply select the settings you need, copy them onto the clipboard, open the web app, display the editor and paste them in - or even clean them up a little if you want before you accept them.

In a multi-platform, multi-device, multi-browser, multi-vendor age, something as primitive as copying and pasting text between applications seems a funny way to be future proofing something, but there you go…