In the previous chapters, we looked at the application life cycle and the different roles of users: the consumer and the contributor. Having established the basic requirements, in this chapter we will dive into the details of app creation and discuss how it is done. We'll also look at best practices of visualization and how to employ them using Qlik Sense.
In this chapter, we will discuss the following topics:
- The process of building an app
- Data connectors
- The data model viewer
- Sheet objects—visualizations
- Best practices
- Migrating QlikView applications into Qlik Sense
Often the initial step in building an app is that you have some data that you want to analyze, but you don't necessarily know exactly what you want to look for in the data. As a business user, you can—and should—just load this data into Qlik Sense and start developing. Our experience is that the best way to develop the app is to start without first defining the requirements.
The reason is that when you load data and start to create visualizations, you learn from data. This knowledge is very important once you start defining what you want to analyze. Hence, you should first develop a basic app, then take a break and evaluate what you learned. Now is the right time to start formulating the requirements.
Another common case is the opposite situation: you know that you want to calculate a specific KPI, for example, supplier efficiency, but you don't necessarily know what data you need to be able to do this. In this case, you need to start with some research about where to find the relevant information, that is, in which database and in which tables.
If you define a larger project, you will use what you know as a starting point for the requirement specifications for your app. The following questions might pop up:
- Data: Which data sources should be used? Which tables should be used? How should the tables be linked? Are there common keys? Is there more than one source for the transactions? Are there tables missing? How should the customer hierarchy be resolved?
- KPIs: Which calculations should be made? You could consider turnover, profit, cost, delivery accuracy, or product quality. Which definition of gross margin should be used? How should the given discount affect the calculation of a salesman's bonus? Which accumulations are needed: year-to-date or month-to-date?
- Dimensions: How should the KPIs be displayed? You could consider showing them per year, per customer, per salesman, per region, or per product. Which comparisons should be made: year-over-year or month-over-month? Are there drill-down hierarchies that need to be defined?
- Security: Is the data confidential? Who gets to see what? Can we allow offline usage? Is the authorization data driven or static? Do we need to include authorization information in the data model, or can we postpone the decision around security?
You will soon realize that creating the requirement specification is not an easy task.
Discovering exactly what users, stakeholders, and sponsors want you to create is often the most difficult part of a business intelligence project. The communication between IT experts and nontechnical business users is often full of misunderstandings and misinterpretations. Business users often don't know what they want until they see it, and they frequently can't articulate their expectations in languages that IT experts use to design systems.
Few business users will know what a data model really means, so expecting them to be able to exactly define the requirements in technical terms is futile. Experienced authors can extract this information through discussions and clever questioning, but the number of people who are able to do this within an organization is limited.
IT professionals often frame their requirement questions in technical language, for example, "Which table in the database should be used?" or "Which fields should be used to calculate the KPI?". However, business users may not have the technical knowledge to respond to these questions. Business users often explain their expectations in a technically vague language, which is not specific enough for designers to develop solutions.
On the other hand, the business user is the customer. The very reason why we develop an app in the first place is to supply the business user with a tool to analyze and learn from data. So, the requirement specifications must focus on the business user.
The solution to this communication problem is to use a step-wise implementation, where the app developer iteratively finds the requirements, develops the app further, tests what has been done, and finally evaluates the app together with the business user. The evaluation will lead to new requirements and to changes or refinements of the old requirements. The steps must be small and the typical cycle is hours or days.
In other words, you discover the requirements together with the business user. As the development proceeds, the app will converge to the needs of the business user.
The iterative development process
This means you cannot begin your app development with a detailed requirement specification. Rather, you should start with a very basic specification containing information about some of the needed data sources and ideas of some of the required visualizations.
Hence, irrespective of whether you are a business user or an app developer responsible for data modeling and difficult formulas, you should start by spending an hour or so to load the data and create some graphs with the goal to learn from data. Then, you are in a much better position to define or discuss requirements further.
The first step in building the app is to load the data. The data can be one single table or several tables linked logically by key fields. Key fields are fields that exist in more than one table and link rows in one table with rows in another. Together, they form a data model. The next chapter will discuss the data model, so, for the moment, we will not get into the details of this.
When you have a data model, you can start building the layout, which consists of different objects, for example, lists, graphs, tables, and filter panes, placed on different worksheets. The objects can contain formulas that define different calculations that will be calculated as the users make their selections.
The previously explained development model assumes that you have both a developer and a business user that participate in the development process. In real life, you will notice that the initial development efforts will usually be like this, but as the app takes shape, the business users will want to do more and more on their own—which is good. After all, the goal is to have business users who are self-sufficient and create apps as much as possible on their own.