We're pleased to announce the latest quarterly "rock" build of Omniscope, version 2020.1 b20848. A rock build marks the end of a development phase (2020.1) with a build that has passed extended manual and automated testing and is suitable for production deployments.
Notable new features:
New report user experience
The interface for designing reports in Omniscope Evo has been significantly improved. We’ve removed the right sidebar in design mode to give more space to the report itself. In the left sidebar, Views tab, browse Omniscope’s rich array of “views” (charts, tables, visualisations etc.) and add to the current page by dragging or clicking:
The Data tab shows the fields in a selected report data source, and lets you customise their formatting:
And if a view in the report is selected, you can drag and drop these fields into the view to configure the view’s axes and data-driven styling:
The Settings tab, without a view selected, shows page-level settings. Here, Image is expanded, showing how I’ve configured an image to blend over the report, as introduced in 2019.3:
But if you have a view selected, the Settings tab shows view-specific settings. Here, I’m searching for “title” within all the options for the selected Bar view. This also shows how the primary controls for the selected view are now attached directly around the view, which helps understand how they relate to the selected view and its axes:
When focusing/zooming into a single view, a thumbnail appears at the bottom of the sidebar, letting you see where the view sits within the report. You can click on the thumbnail to pick another view. It’s another way to explore your data, with more space given to each view:
And if you have a larger screen and still want the right sidebar, the pin button lets you bring it back:
Undo in reports
We’re a little embarrassed it took us so long, but you can now undo your configuration edits within a report. Delete a view or change a setting by mistake? It’s one click to bring it back:
Drag and drop files
We’ve made it easier to work with files in Omniscope Evo. You can drag and drop files onto the welcome page, and upload them individually or in a group:
When you upload a data file (CSV, XLSX etc.), you’ll be offered to create a project for it…
... immediately showing the data within:
Sort and search files
In the Welcome page file list, you can now sort...
… and search (within the subtree of files, providing they have the same security scope):
You can also bookmark the page URL, to be able to revisit the same “query” in future.
Within a report, you can attach files to the project. Attachments are part of the project, and are copied and exported/imported with the project. For example, the new Map view lets you attach GeoJSON files:
The Image and Content views, and report image setting, also let you attach image files this way. See the previous example (further above) of a lighthouse image attachment.
Community blocks, and the new custom block
A while back, we introduced community blocks: a Github repository of blocks developed independently of the Omniscope release cycle. These are a lightweight way for both Visokio and 3rd party developers to provide workflow blocks that provide niche or missing functionality on-the-fly without needing a new Omniscope update, using Python or R code. We use these ourselves as part of our bespoke solutions, and to prototype new functionality; it’s also a way for our partners and clients to share their efforts. As an end user, you can use these blocks just like core blocks (though not to the same high standard), using the Add Block menu:
For example, here I’ve added the Interval join community block (also see demo of this block), which lets you join two datasets by matching each left record by whether its date/number is within an interval defined by two right date/number fields. The block provides some options to the end user:
But if you open the Design tab, you’ll see how it was built (in R), and can customise or adapt if desired:
To code from scratch, find the Custom block in the Add Block menu (currently experimental). We support Python and R coding languages (this may expand in future), and provide automatic package dependency management. Here’s the Design tab of a blank new custom block, which by default passes data through, ready to start coding:
If you have developed a reusable Custom block and want to share with others or keep for future use elsewhere, you can export as a zip file...
… and import into another project using the Add Block menu:
If you want to publish it on our Github repository, submit a pull request there, or instead simply export as a zip and send it to firstname.lastname@example.org.
This ROCK introduces the ability to tailor reports dynamically to the visiting user. We expect this functionality to expand in future, but currently you are able to restrict which rows/records the user sees based upon their authenticated user name or group name.
This allows you to create one report with one master dataset, then let only Client A see Client A’s records, Client B see Client B’s records, and Administrators see all records, for example. Data seen in the report is automatically filtered server-side on the fly, securely.
This simple demo shows it working:
Here, the 2nd input contains a record for each “scenario”. This is used to configure the restrictions when accessing the report externally on its Sharing URL. Note that multi-tenant reports use data-driven configuration, so although the example above uses a Text Input block to provide this configuration, you can scale to much more complex configurations by querying an external database of users and using a chain of blocks as needed. For example:
In report sharing settings, a Multi-tenant configuration section lets you choose this input:
And that’s it. When “sally” logs in, she sees records where the “department” field has value “sales”, an so forth. With one central configuration for the report and data source. For full docs, see here.
Experimental Map 2 (layers) view
We’re in the process of greatly expanding our mapping functionality in Omniscope Evo, with the goal to replace the existing Map and Choropleth views with a single, simple yet powerful, multi-layered new Map view:
This new Map 2 (layers) view is now available in experimental form, meaning you can explore it and use it with the caveats that: we may change it in breaking ways in future versions, it has some missing key functionality, and may have some minor instabilities. Ultimately, likely in the next quarterly ROCK, it will appear as the only “Map” view, replacing existing Map and Choropleth.
The new view lets you add multiple layers in the view configuration. Each layer will be composed on the same map, with data coming from report data or from an attached or externally referenced GeoJSON, ESRI Shapefile (SHP) or Google Earth KML file. You can also add geo-located images and videos, with other map layer types coming soon:
For example here’s a choropleth (region-fill) of part of the UK, provided using an attached GeoJSON file, live-joined to report data using a match between attributes in the GeoJSON and the report data, coloured to show aggregate metrics, with raw points of record data overlaid on top. The default base map (from Mapbox) has been turned off in this case:
For further reading, see our Knowledge Base article Using the Map view.
Some other minor changes:
For a more detailed list, see the changelog.
Development of the next version (2020.2) is well under way with the first builds available soon. Some features to look forward to, many of which will appear in 2020.2:
"Create working copy + publish" methodology
If, for example, you have a production server, and a dev/test server or local desktop installations, you’ll have an easier way to work safely, by creating “working copies” of a master project, playing to your heart’s content without affecting the master, and publishing back only when ready, with a simple user experience throughout.
We will build upon this recently added block to let you work directly within your IDE (e.g. Jupyter, R Studio) to code and debug your scripts, whether building blocks for use in a workflow, or doing ad-hoc data science needing to invoke Omniscope programmatically.
The new Map view
We’ll continue developing the experimental new Map view to wholly replace the existing Map and Choropleth views, including additional new functionality such as point-to-point/spider plots, raster tiles, vector tiles with configurable sub-layers, and micro charts/pie overlays.
Further Report and View configuration UX improvements
We’ll be adding a new Exploring mode, for when you’re exploring new data in Omniscope, looking for insights, rather than fine-tuning a beautiful dashboard. It will allow you to explore and configure in one flat experience, without needing to select views or switch modes.
We’ll also be restructuring and improving the view options, to make them much more logical and easier to navigate, and consistent across different types of view.
We’ll be implementing much more intelligent defaults for reports, views and filters, so there’s less clicking needed to discover your data, visualise with colour, or create reports.
As usual, please let us know your feedback at email@example.com. Have fun!