Layout Tips for Developers
This post describes basic qlik view objects layout tips and design, themes, dimension limits, containers, calculated colors, as well as a couple of useful advanced object usage settings (alternate states and set analysis).
Your KPI story
It may not be the qlik view developers job to interview business users of a proposed application or solution, but it’s helpful to know how dimensions and measures are derived from the business side. Your qlik view efforts will develop an applications that takes the result of those business user interviews and delivers actionable intelligence or allows business discovery for a particular issue or question.
There are two main sets of questions that will help reveal what the real key performance indicators (KPIs) are. These KPIs are what’s really important to track-the KPI story. The rest of the data is supporting data. The questions that usually reveal KPIs are:
What business issues concern you? What answers do you need? How often will you need them? This set of questions will help you understand what the KPIs are and how often they should be reported. this will also help you understand what other supporting information is needed and how often, as well as ant target value you will need to set the KPIs. For instance, if a sales executives wants to know if his or her team is on track to make the sales quota, he or she might need to have targets for the week, month, quarter, and year.
When you get the answer of what concerns them, what other questions will you have? What actions will you take based on this answer? Again, this diving deep into the questions will help you under stand the supporting issues for the KPI, and help you understand what actions are taken at what target values.
Your qlik view applications should track KPIs that are useful to an organization. The old adage instructs us that every thing of value should be measured. While these measurements (or metrics) can be valuable, they are not, in themselves, KPIs.
In order to be useful to business users. KPIs should be important, show the past, present, and future, and also contain a target (or planned) value. For instance, an online retailer may track the number of visitors to a website, but it is really sales that should be tracked. Past sales, current sales, and a trend showing where the sales are going all are included in a sales KPI while site visitors are important, and add color and supporting arguments to the KPIs, site visitor values by themselves are not KPIs.
Dashboards and reports contain metrics (less often, KPIs); metrics are numeric values (sales amounts, number of people, and number of orders), examples may be sales orders (say dollars) by a time dimension (quarters, years). Time dimensions come with hierarchies (year, quarter, month, day, for instance),And when speaking of time and other dimensions, one refers to the granularity of a metric (is it by week, month or year? Is it by country, region, or city?)in qlik view, we can define that drill-down hierarchy in the chart itself by forming a drill-down group.
Regarding the time dimensions, one of the most powerful features of qlik view is the ability to create multidimensional charts, such as sales by region by time period. It’s natural for qlik view applications to have this feature, due to the associative nature of qlik view, as a time stamp is usually associated with any sales.
Subscribe to our youtube channel to get new updates..!
KPIs are values showing how well a metric is performing compared to a target. The KPI is often in the form of a ratio, index, or percentage. Are we 30 percent above target for this year? What about for the quarter, month, week, and day? KPIs simply that there are defined target numbers across all grains of time or other dimensions.
Qlik view markets itself as a business discovery tool (formerly called a decision support tool), but often is used for interactive reporting purposes. This form of qlik view applications doesn’t totally harness its business users. The following descriptions of scorecards, dashboards, and reports may be useful in your discussions of business intelligence projects:
Scorecard: this is a very focused but high-level report, usually containing a few KPIs and supporting metrics, devoted to one specific strategic goal. The score card may also consolidate all the KPIs and operational metrics, perhaps based on a weighted scale for each KPI or metric, to derive one total score for the scorecard. An example of a scorecard may be employee satisfaction, where employee survey scores and numbers for employee separation and retention are considered. The scorecard is typically used by the highest level of the business.
Related Page: How To Rename Fields Using Mapping Table - QlikView
Dashboards: often, dashboards are less strategic and more operationally focused. Such dash boards may focus on specific areas of the business, such as call centers, sales, or human resources. Dashboards are usually larger than a typical scorecard, and contain more data than is contained in charts and tables. Operational KPIs and metrics may be contained in dashboards, so that users can act upon that data. Dashboards are used by everyone from line managers to executives.
Reports: reports are the most common business intelligence tool in use today. Reports are often static, containing charts and tables. They can be complex as well, with drill-down and linked sub reports available.
The ability to create consistency in your QlikView document and also between the QlikView documents is quite essential. Consistency helps you to create easy to navigate dashboard.
Best practices in any user interface (UI) also apply to qlikview applications, and one of the most important design considerations is consistency. If you follow a set of rules while creating a QlikView document, you will notice that consistency automatically follows. It allows users to learn how to navigate the applications faster, be more efficient, and focus more on the data rather than the interface. Once consistency has been established, users can readily transfer that knowledge of application navigation and data interpretation to other applications and contexts.
User Interface consistency : e.g: same looking captions and usage of consistent colors
Data model consistency : e.g: naming of key fields
Related page: IntervalMatch Function In QlikView Scripting
Some key points of consistency are:
1. Design a user application to all areas of good user interface design in mind. Research thoroughly, get user feedback, offer layout options to users, and solicit feedback with experienced UI designers and developers.
2. Once you have a good design developed that meets the best practices of UI theory, try to use it consistently on all your qlikview applications.
3. Keep the layout of all the objects the same on all tabs of a qlikview application, with similar alignment and arrangement on the sheet and in the charts, with the same sheet dimensions.
4. Maintain consistent color in sheet and chart objects. Assign meanings to colors rather than arbitrarily assigning colors to chart elements, for example, red could mean losses, and blue could mean gains (be careful of using red and green in the same chart or sheet, for red-green color blindness is common). Also, colors could be lighter or darker based on how old or recent the underlying data is.
5. Use the same font colors and sizes in similar areas of the applications.
6. In charts, keep the title bar in the same format and look, and keep the legend or axis title in the same area on all charts, if possible.
7. Align text in tables in the same way (right or left justified).
8. Maintain the same sort order in all chart objects, if possible (lowest to highest, highest to lowest, axis sort, and sort by values or text).
Related Page: How To Concatenate Two Tables In QlikView
Layout Best Practices
If you are a developer, the odds are that you are more concerned with a working, functional application than the applications look and feel. But knowing some key points about the user interface layout will make your product more usable.
Some key points in layout best practices, in no particular order, are:
Avoid crowded objects and charts. Some UI experts suggest no more than 6 to 8 charts for a qlikview desktop application (per sheet), and no more than 4 charts per sheet for a mobile-or tablet-formatted application.
Colors are a big source of design mistakes. Not more than 3 colors must be used. Don’t use red and green on the same chart or sheet, to avoid the red-green color blindness issue. This is a big topic, and usability authors like Stephen have some great suggestions on the topic of color. Some of his tips are to avoid darker colors in bar charts, but use the darker colors in thin lines and scatter charts (the greater volume of ink, the less dark colors are needed). Avoid using too many colors, and avoid randomly assigned colors. The colors should have meaning. Use the persistent colors feature in the chart’s colors tab, in the chart properties This will ensure dimensions retain the same specific color in the charts and in the application.
Choose the best chart for the job. for example, use line charts or bar charts for comparing a dimension over time, and use stacked bar charts and pie charts for comparing parts to a whole. Study excerpts written by Stephen for chart type tips and standards. Note that pie chart (and perhaps gauge charts) should be used sparingly, and keep data as the foremost concern over style. This is another large topic best researched elsewhere. Spend time on learning about data visualization techniques.
Some experts advise not to use more than 10 sheets in your qlikview application, and even less in mobile applications.
Consider using a getting started tab to help users learn to navigate, link to other tabs or qlikview applications, or link to qlik view help.
Use descriptive names for sheets/tabs and objects.
Understand the screen resolution needed for end users, for the desktop, and for mobile.
Selected fields should always be visible, and the most selected fields should be located at the top of the sheet.
When the charts are finished or you have a draft version, uncheck allow move/size in the layout tab of the chart properties dialog to limit inadvertent movement of charts in the application.