In QlikView development followed the 80/20 rule. 80% of the time was spent getting the data model right, once that was perfect the front end user interface (UI) came together very quickly. This post looks at how field names should be handled in Qlik Sense and how the differs from development practice often employed by QlikView Developers.

In Qlik we have to think about how the tables are linked and one of the first things we learned is how to alias a field to prevent a synthetic table. Lets look at part of the data scheme from the Northwind database:

 

 

Here we have two tables with fields highlighted (Suppliers and Employees). If these were brought into Qlik without renaming these identical fields the tables would link via large synthetic table which is not what we want at all!

 

We know these two tables are not linked directly in any way. Certainly not by the address fields. To break them we only need to rename (or remove) fields from one of the tables.

By renaming the effected supplier fields with a Prefix ‘Supplier’ we resolve the problem and remove the link table. This is an accepted approach and often no further action was taken on the field names in the Employee table.

Qlik Sense should be treated differently with more time  spent on the field names. 

In Qlik Sense the field names play a bigger part of the user experience (UX), Here I’ve renamed the fields more inline with how Qlik Sense should be modeled

 

Lets look at the code for Employees in more detail:

 

 

The bulk of the work here was adding Employee to all field names, we did this to ensure the fields were more descriptive of what they represent but we go further than that. An employee could have a work address as well as a home address so we add that detail to the field name also so there’s no ambiguity.

The next change is adding a ‘%’ next to two fields. The EmployeeID and a new field we will use to sum up the number of employees (I break down this technique in a previous post) %SumField_Employee.

Before we do anything further lets look at how these fields perform in the UI, firstly we’ll make a couple of selections and check out the results in the selections bar:

 

 

First impressions are the “Employee Home …” field could be named better to fit (highlighted Red). Remember you can’t resize the information displayed in the selections bar in the native app nor can gain any more detail by clicking or hovering over. What you see is what you get! We could rename the field to “Employee Country (Home Address)”? What every you decide make sure its consistent with the other field names!

Note – Like with QlikView you could change the dimension title in the list box (or any visualization), I think this is extremely bad practice as it was with QlikView because the current selection still shows the original field name. If you need to change it do it in the script!!!!

Next lets look at the selections tool (top right highlighted below with red)

 

I’ve searched for field containing the word “country” and we have two results. Users could now also search for “Address” (below) and as the word “Supplier” or “Employee” comes first in the field name the fields are naturally sorted although as you can see below we may need to move things around a little for the Employee fields. The field values always give context and in this view you do get the full field name when you hover over the label, its just something to think about:

Users can also search for field values, here I’ve searched for the value ‘1’ in the Qlik Sense Smart Search:

 

 

Unfortunately we’re now bringing back results from fields we don’t want the user to see. All those prefixed by a “%” are for developer use only so we need to hide them. As with QlikView we have a function for hiding fields which was used in conjunction with the current selection object although the function does more than that in Qlik Sense.

In the script the command Set HidePrefix = ‘%’; removes the field from:

• Search Results
• Current Selections Bar
• Selections Tool
• Field list in Edit Sheet Mode

The final point also ties into the work we did earlier ensuring the field names were written in a descriptive way. In Qlik Sense we often expect users would create their own visualizations by the way of “Edit” sheet mode (for the purpose of this post I’m not going to worry about the added benefit of using Mater Items – But please remember them when you’re developing)

Users should be able to easily drag and drop fields into their new sheets and as developers we should support this by ensuring our field names are descriptive and our system fields are hidden from view.

My final thought is that developers should see field names much more in the context of the user experience (UX)!

Not as they were previously in QlikView; In QlikView only the developer needed to know what each field represented, in Qlik Sense we have to ensure any ambiguity is removed by way of a descriptive field name, writing them in natural language and removing technical attributes for all fields not hidden.

Love your field names!