What's Best Practice? straight table vs a container grid

[#1]

I've been working along with someone else to accomplish some analytics dashboards in qlik.  I'm new and just learning.  I dove in, and charged ahead using the project to cut my teeth on, even though we have another pro working on the project as well.

We approached things differently and I was curious as to what's better?

Is there a performance reason he did it his way, and why I shouldn't do it my way.

Is there web rendering issue?

He approached it with a Straight table,

Dimension: Value List( A, B, C)

Expressions: PICK(row(),Expr1,Expr2,Expr3)

I approached it with a container grid object 3 by 2 with text objects filling it. The text objects had the appropriate expression sources. I see the container grid object as kinda a "div" or table in web speak, and I use it to layout my sheets accordingly.  I next containers within containers and what not.

He littered the same expressions throughout the sheet,.

I recognized commonly used expressions and assigned them to variables.  Then I littered the variables throughout the sheet.  I would assume that my method was more sustainable for maintenance and quicker to implement.  I was doing as he had done, but then changed to the variable method and moved much more quickly.

Is this just a "qlik has a lot of ways to accomplish the same thing, and y'all just do thing differently"   or is there a reason I should not approach it as I should?

[jpapador]

Container objects can slow performance.  In a grid it's less noticeable because all objects are shown.  But in a traditional container it will load all objects at once contained with in.  Where as minimized or hidden objects will only load when maximized or shown.

If performance isn't an issue in your app and both ways work, it is likely fine for now.

[ramoncova06]

regarding the variables it does tend to be considered as best practice to create variables for commonly used expressions, that way you change it once and don't have to worry for for missing it on one of the "hidden" tables

[rwunderlich]

I generally prefer straight tables for KPIs as I find them easier to work with and format. I don't follow the need for the ValueList() and Pick() though.

-Rob

[#5]

It's a kpi table that compares current year to previous year, with indicator arrows in between.

Dimension: ValueList('Total Market','Facility','Facility Market Share')

Expression 1: Pick(row(),sum(<year = {x-1}>}total sales),sum(sales),sum(<year = {xx-1}>} sales)/sum({? <year = {x}>} total sales))

Expression 2:Pick(row(),sum(<year = {x}>}total sales),sum(sales),sum(<year = {x}>} sales)/sum({? <year = {x}>} total sales))

As the measures above were used a lot in other portions of the sheet, I had assigned them to variables.

I created a container grid with text objects in each grid cell.  I gave the text objects a source of the variables.

Aesthetically, in my opinion, the container grid looks better than the straight table, and accomplishes the same thing.  My method doesn't require picks and such, and my method would seem easier to maintain as the variables only have to be changed to update the entire sheet.

Which is best though?

[rwunderlich]

As you've identified, there are tradeoffs to both approaches. I would say "best"  in this case is what works best for you.

[#7]

i stongly agreed to Rob wunderlich . what is the best is what best work for you. it's depend on client requirement before you go to made data modeling. 🙂

[#8]

I can't say I'm a big fan of containers.  I've found several workarounds but in some cases the container is unavoidable.   Even tried containers of containers - that can get messy.

1) Setup buttons and variables that drive which table to show

2) If all you're doing is changing columns selections, use a smart table and simply disable the appropriate columns

3) Latest variation is using a listbox against an inline table in place of the buttons for #1

[mikecrengland]

I'd say that if your users are ever going to export it, use the straight table. In my experience, someone will always want to export it...

Mike