Colour consistency is a great feature, ensuring that within a single dashboard all visualisations will show a member with the same colour. But what about if you have a suite of dashboards? What about if you have reports? A user would want the same member to have the same colours across all content.
Also, there is no way within the dashboard GUI of setting a preferred colour for a member. For example I want "Outdoor Products" to be green. I can do this with careful creation of the dashboard, or editing the dashboard XML. But If I change my mind and want "Outdoor Products" to now be yellow I would have to update all dashboards and reports individually.
The obvious place to define and set colour consistency is within the Data Module.
In the data module tree, when you expand a query level and see the members I should be able to set a colour as a property of that member. For example I could expand the Product Type level, click on "Outdoor Products" and set properties of that member. One of the properties should be colour.
Defining colour consistency within the data module has the advantages of:
All content authored against the DM, report or dashboards, can use the colours defined within the DM.
If we want to change the color for a member we only have to do it once within the DM and all content would now show the updated colour.
It is often the case that for some members we want to define specific colours, for example product types, but when we have hundred of members - such as products we are happy with the product defining its own colour. If the colour property of a member is not defined within the DM then the tools should pick any colour that is not already in use by other members. For example, we have set "Outdoor Products" to be Green. If the dashboard now displays products where no colours have been defined, they cannot use Green. It may be the case that there are a handful of products that I want to define a colour for, maybe they are new products that I want to ensure are coloured Red. In this case I would find those prodcuts and set there colour property to Red. It may be that some members of a level have a colour defined, and others don't.
It would be up to the modeller on which members they set specific colours. If they want to set it on 10 or 1000 then so be it. I think the important bit is that they can set the colour attribute on any member on any data item. That data item could represent a small number of members. For example I could set the colour on members in the Year data item (small number of years), or I could set the colours on members in the days data item. Users could decide to set a colour, or leave unassigned. You shouldn’t have to set the colours for all the years.
Taking this idea to the next level...
The colour attribute could also exist on a query level, if set then all members of that level would be shown in that colour.
For example I could set the Calendar.Year data item to be Blue, and the Calendar.Month data item to be red.
Then when a user sees a bubble chart showing blue bubbles, they know the bubbles are years. If the bubbles are red (such as after a drill down) they now know they are Month bubbles.
Precedence would be given colours defined on individual members, for example whilst Calendar.Year is blue Calendar.Year.2025 could be Green. In a bubble chart of years all would be blue except 2025 which would be green
This sets up the idea of having attributes on members within a level.
Some properties that are set on levels, could also be set on members. For example In a currency dimension I could define the format of the GBP entry as £##.##, I could define the USD entry as $##.##. Ensuring that each is shown with its correct currency symbol.
To set the colour for a member I should be able to use a colour wheel or a hex code.
For advanced modellers I should be able to define a macro to set the hex code.
For example a macro similar to : #queryvalue( “member_colours.colour_hexcode”, “member_colours.key = “ + sq( $thismemberid) )#
I would be able to have a table that has the member is, with a hex code. The macro looks up that hex code.
Then I could just update the colours by updating a table across ALL data modules.
There are more advantages of doing this in the data module interface as well:
We can set data item formats, such as number, currency in a data module.
Surely colour is just another format of a data item.
Thinking of individual dashboards, I know that people want to specify the colours of members in a dashboard.
By putting this functionality into the data module then this gives us an interface that can also be used in a dashboards local data data module as well.
It keeps the same paradigm. For example if a user wants to add a calculation in a dashboard, they use the local dashboard data module and add the calc using the DM interface.
If users want to specify colours in the dashboard, we could reuse the data module colour interface.
Rather than introduce a new colour picker interface tool. Do more with the existing tools, don’t introduce a new thing.
