What is a typical data portal?

A data portal is a digital or web-based point of access to a collection of data that may be general, tailored to a company, industry, or geography. The simplest of data portals can be classified as horizontal or vertical. Experts across the field use varying terms to classify data portals by complexity/feature; these include marketplace portals, search portals, media portals, access portals, and geographical portals.

Vertical Portal

“When a portal focuses on one particular industry, or domain, it is categorised as a vertical portal. They offer specific industry or vertical information, articles, tools, research, and statistics.” — Greg Rossi, Zuar

Horizontal Portal

“When a portal has a broad range of content, interests, or topics, it is categorised as a horizontal portal. The content on a horizontal portal is meant for a general audience. This kind of portal tries to present something for every user.” — Greg Rossi, Zuar

The application or users of the data portal determines the applicable portal type. Integration, consistency, and personalization are essential components to successful data solutions and portals.

Whether a data portal focuses on an industry or range of industries, a full fledged data portal addresses 6 data elements:

• How and where data is sourced
• How, where, and with whom data is shared
• Methods used to store data
• Methods that are available to transform the data
• How the data is analysed and interpreted
• How the data is presented to end users

Data custodians that make a data portal request have varying levels of data savviness, however this level of savviness is not always a reflection of the data maturity or culture of an organisation. Through our engagements on SCODA we have learnt that it is essential to understand the data maturity of city organisations that make data portal requests as this contributes to the success or shelving of a data product.

‍

Why does everybody think they need a data portal?

Data portal requests are often based on a need to improve the accessibility of/to data, this accessibility is often linked to large sets of data that organisations or governments that want to: organise better, share with a wider audience, structure , analyse or interpret, collect, and/or use internally or externally. The need to make data more accessible is especially applicable to our work with South African cities and city data, but the answer to a data portal request is nuanced and is influenced by the flow of data within the organisation and how the organisation presents its data. There is a presumed data maturity that is attached to a data portal request, this presumption can make or break the success of a data solution.

However, because modern organisations and government bodies have data built into their systems and processes — whether the said organisation realises it or not, a full-fledged data portal isn’t always the most efficient way to achieve data accessibility. Organisations often make a request for a data portal because they want to share data more efficiently or effectively, in-depth user engagements can reveal that the development of a data portal is not necessary but rather an improvement along the existing data value chain is more beneficial.

‍

How does SCODA empower portal users to understand and use data?

To simplify our data portal we looked at traditional tools like dashboards for inspiration as they are already in use in the traditional data portal environment. Our use of dashboards when creating solutions for cities is of varying degrees and the dashboards are of varying complexities, the complexity of the dashboard solution we create is tailored to the city we are working with or other end users.

The products we create have a bit of narrative attached to them that allows the user to understand the data that is being visualised, without necessarily engaging with the raw data. We use brief narratives of data to empower people to read and understand the dataset they are viewing, but also so that they can potentially understand more about a different dataset they may encounter later.

An example of a tailored solution (tailored to the end-user not necessarily city representatives) within the SCODA project is what we are calling the Data Explorer. The Data Explorer allows users to look through all the SCODA indicators and create a very simple visualisation of what the indicator represents. The indicators used in the Data Explorer are visualisations that add value to indicators that are often described using words or numbers, as opposed to visually. This feature allows us to understand the use of city indicators beyond the uses described in the codebook.

We also develop mapping tools like the Demographic Modeller to understand very table-based data and interpret that more mathematically or visually because we have experienced that not a lot of people are trained to understand table-based numbers. Through communication with various city representatives, we have been able to make the shift toward a more visual interpretation of data and see how we could use visualisation in communicating effectively from a city perspective. Use cases like the Durban EDGE Open Data Portal are a demonstration of how the SCODA approach can be adopted by a city and we are hoping to see more of that.

‍

How do we apply design thinking and a user-centric approach to South African city data portals?

Design thinking plays an essential role in the solutions we offer and how we pivot when a solution we’ve created is not suitable for the user. As an organisation, we don’t know all the answers, we have tools and skills; but not all the answers.

User-centric needs assessments enable us to dig into the fundamental data challenges of a city. The needs assessments allow us to focus on the pain points that a city is experiencing with its data as an organisation, but they also allow us to identify what is working so we can attempt to dissolve the pain points without dismantling systems and processes that work. This approach also allows us to be honest and acknowledge when we cannot address an organisation’s data pains (temporarily or long term).

When working with cities, we have to embed solutions or new systems into an existing framework, as opposed to clearing the decks and starting over. Cities have unique and independent systems that are built into the national and local governance framework. This independence of systems can be a challenge because these systems are not always compatible as they have been developed in isolation. User engagements are a tool we use to navigate and connect pre-existing systems within and between cities. These engagements also allow us to cause as little friction as possible in implementation.

User-centric engagements can yield rich results, these use cases speak to the demand for user-centric solutions but coupled with design thinking it allows us to identify parallel processes. In certain instances, data ingestion (often in an electronic form), data sharing (often a portal or dashboard), and information management systems can be executed as parallel processes — from a project management perspective.

User engagements can give us insight into the data readiness of city representatives and an in-depth understanding of city processes. An awareness of the data readiness of a city organisation as well as awareness of city processes shapes how we engage with the next city or a different department within the same city.

With the development of a tool or multiple tools for a new city, there are a lot of data governance learnings. Some of these learnings are on the data governance aspects such as data cleansing, data privacy, and data availability in the city context. These aspects are often considered softer data elements but are key considerations of data solutions like SCODA, as there is a level of readiness that’s required before one can render a data portal the most suitability-data data solution.