Dashboard-specific visualization title

[ohTHATaaronbrown]

Visualizations are sorely lacking in the customization department.

• I'd like to be able to set a title on a visualization in a dashboard, rather than always using the name of the visualization
• I'd like the ability to add titles to slices of pie charts (Part of Configurable filter/range legend values #2245)
• I'd like the ability to set font sizes for elements like title, and legend (Duplicate of Configurable font size #2207)
• I'd like some control over color palettes. v3 used to let me set a color per query, then it'd use a graduated palette based on that color. v4 gives me precisely zero control over a crayola-crayon-based palette. Duplicate of (Color palette selection #1362)

[rashidkpc]

3 of the 4 points here have tickets already, so I've changed the title of this ticket to just reflect the desire to customize the panel title independent of the visualization name

[ohTHATaaronbrown]

👍

[radiumx3]

👍 +1000

[carlosvega]

👍 yes please, it's a real hassle when you need to change the name of the panel because it creates a different visualization and then you need to upgrade all your dashboards :(

[hijoshi]

+1

[hesstruck76]

+1

[acs]

Working on it ... I hope to have a PR next week.

[pemontto]

👍

[smjgithub]

+1

[carlosvega]

Any news on this?
And what is the description field for? Would it be cool to add a tooltip or an info button on the panels in order to show the description.

[brooksandrew]

+1

[vram001]

👍
Any idea when this may be available?

[tbragin]

We already have a 'title' attribute in each saved object, including visualizations. Should we be using that?

[Prazzy]

@tbragin yes we added this option (ability to change the title) to visualization..

[tbragin]

@ohTHATaaronbrown @carlosvega and others... do you feel ability to set title independent of vis name is still important now that we decoupled title from object ID in this PR? #9333

[Dom-nik]

@tbragin
Which version of Kibana was it included in?

Correct me if I'm misunderstaning anything, but it's still very useful to have a separate visualisation name independent of the title, as you may want to use the same vis in various contexts, hence with different names on different dashboards. You also may want to have various visualisations with the same title but based on different saved searches underneath for different dashboards.

[tbragin]

@Dom-nik That change is coming in 5.2 (#9087)

For cases when the same visualization is re-used in completely different context, I can still see a case for a dashboard-specific title for that visualization, but I wonder how common that is. I was wondering what the motivation was originally for users that filed this request a while back, and whether it will be as as important if the ID and title are decoupled. It seems at least from some comments (e.g. this one #3393 (comment), that tight coupling between ID and title was the problem.

[jgbarah]

@tbragin commented:

For cases when the same visualization is re-used in completely different context, I can still see a case for a dashboard-specific title for that visualization, but I wonder how common that is. I was wondering what the motivation was originally for users that filed this request a while back, and whether it will be as as important if the ID and title are decoupled. It seems at least from some comments (e.g. this one #3393 (comment), that tight coupling between ID and title was the problem.

We have several use cases for having different titles for the same visualization in different contexts. In short, all of them come to the fact that the name of the visualization is always in the context of a certain dashboard. That dashboard sort of define a "context name". Even when the same visualization makes sense in two dashboards, its name may be very different.

For example, consider this Overview dashboard for the Rust development project:

You may notice that top left "Git" visualization. In this context (a summary of the project), it makes sense it to be tittled "Git", because it is just a summary of metrics related to Git.

Now, consider the Git dashboard for the same project.

Again top left, the same visualization (different arrangement, different filters, but it is the same underlying visualization). In this case, the whole dashboard is titled "Git". So it doesn't make sense to have a visualization with that title. On the contrary, given that the context is already "Git", this visualization could better be "Summary", or something like that.

In summary, I find both decouplings pretty useful. On the one hand, having titles different from the visualization id. On the other, having different tittles for the same visualization in different dashboards. Of course, each visualization could have a "default" title (the one defined when producing it), that would be shown by default in all dashboards, except that it is edited in one (or all) of the dashboards.

Please, let me know if you need clarifications or more use cases.

[Dom-nik]

@tbragin Thanks for your answers!

I will change the route a bit and describe what is our original problem, it's not actually a visualisation reusing case, like @jgbarah, but I believe the solution could be the same.

We have a set of 8 dashboards (and another 8 planned), each based on a separate filtered alias, which require common visualisations (but based on their respective aliases). We would like to have simple names, but right now if we want to keep consistent naming, we end up with 8 visualisations of each kind having the same title, which are very hard to distinguish while we are developing stuff - they all appear with the same name in the 'Management' panel, etc.

That's why I thought that having the possibility of renaming visualisations on dashboard level (basically giving them visible labels) would be very useful (and quite easy to implement I guess, expanding each element in the panelsJSON array with a "label" element that would be displayed above the actual visualisation). This way we can give each vis a distinguishing name in the backend (containing an identifier of the dashboard it belongs to or something), but keep it's displayed name short on the dashboard itself.

No offence, but that's exactly what Splunk offers - you can change each viusalisation's label straight on the dashboard and manage the final dashboard's look from the dashboard edition panel. It's very useful.

[tbragin]

@Dom-nik @jgbarah Thanks so much for additional detail! This make sense.

cc: @kobelb @stacey-gammon

For posterity, an attempt to implement this was in these two PRs:
#7336
#5607

[stacey-gammon]

@Dom-nik It sounds like your situation could be resolved if we made it easier to distinguish between visualizations of the same title. Is that accurate? This is something that is on our radar. We are thinking of adding creation date/last modified to the table to do so, but perhaps even better would be an optional description field ?

[jgbarah]

We are thinking of adding creation date/last modified to the table to do so, but perhaps even better would be an optional description field ?

@stacey-gammon if you mean adding an optional "Description" field to the entry corresponding to each visualization in a dashboard, that could very likely solve our scenarios as well if it included a tick to make it the title of the visualization in that table (but maybe that's too similar to having an optional title field, that if present would just substitute the title for the visualization, and would be editable in the dashboard).

[Dom-nik]

@stacey-gammon It would be a good start, for sure, I also remember there was an idea to add tags to saved objects and that's also a good idea, but these are still quite simplistic.
In general I think that:

1. The entire Management panel is in my opinion quite uncomfortable to use and an important factor to this is that visualisations cannot be organized/searched based on the dashboard they belong to, owner, tags or any other important parameters. I really count on the implementation of the changes described in Improve landing pages for Dashboard and Visualize Apps #7900
2. Possibility of having a title (or description) for each visualisation on the dashboard and changing it straight on the dashboard would really make sense. I also think that Markdown widgets could be embedded in the dashboard, it seems to me that they are rarely reused and easy to write on the spot anyway.

Sum-up: in my opinion Kibana could be a bit more dashboard-centric or at least each dashboard should have visualisation naming and general comments/descriptions of it's own.

[tbragin]

via @derickson

Speaking from personal experience: I find that I have to name my visualizations and dashboards for organizational purposes when I have dozens or hundreds of visualizations to manage, mostly because of the search interface to find things rather than a folder structure. This adds to a lot of clutter and extra markdown widgets to explain things. Having a "pretty display" title for a visualization that is separate from the unique organizational name would be very useful.

[janreges]

+1

I have a lot of dashboards with many visualizations.

The meaning of all visualizations in context of particular dashboards may be different.

It would be better to name the visualization in each dashboard differently. The default name would remain from the visualization definition, of course :-)

[GrahamHannington]

+1

Currently (Elastic 5.5), the visualization titles in my dashboards are too verbose, because my visualization titles begin with phrases that duplicate the context provided by the dashboard title.

For example, here's a list of some of my visualization titles:

CICS transaction average DB2 elapsed time
CICS transaction average dispatch time
CICS transaction average file and journal wait time
CICS transaction average response time
CICS transaction average suspend time
CICS transaction average syncpoint processing time
CICS transaction maximum virtual storage high water mark
CICS transaction metrics
CICS transaction rate
CICS transaction top 10 abend codes
CICS transaction top 20 applids
CICS transaction top 20 originating tran codes
CICS transaction top 20 tran codes
CICS transaction total CPU time
CICS-DB2 data from CICS
CICS-DB2 data from DB2
CICS-DB2 transaction accumulated wait times (stacked, from DB2)
CICS-DB2 transaction average response and suspend time (from CICS)
CICS-DB2 transaction QR and L8 CPU time (from CICS)
CICS-DB2 transaction rate
CICS-DB2 transaction top 20 applids
CICS-DB2 transaction top 20 originating tran codes
CICS-DB2 transaction: class 1 (application) and 2 (in-DB2) CPU time (from DB2)
CICS-DB2 transaction: class 2 elapsed time and class 3 suspend time (from DB2)
DB2 accounting accumulated wait times (stacked)
DB2 accounting class 1 (application) and 2 (in-DB2) CPU time
DB2 accounting class 2 elapsed time and class 3 suspend time
DB2 accounting metrics
DB2 accounting record rate
DB2 accounting top 10 connection name (such as CICS applid or IMS ID)
DB2 accounting top 10 DB2 subsystems
DB2 accounting total accumulated wait times
IMS transaction abend rate
IMS transaction average CPU time
IMS transaction average response time
...

I deliberately begin each visualization title with a phrase that, when the titles are listed alphabetically, groups "related" visualizations (I can describe what I mean by "related" here, if asked) together. This has a number of advantages, including making it easier for me to develop a bunch of visualizations for a new dashboard, and then quickly add them to the dashboard, by filtering the list of visualizations by that common phrase.

However, in the dashboard, those initial phrases on the visualization titles are redundant. The dashboard title begins with a similar phrase, such as "CICS transaction...", so I don't want each viz title to also begin "CICS transaction...".

[guy-bouchard]

+1

[rgheleribefore]

+1

[stacey-gammon]

cc @snide @cjcenizal -- this is the mockup I have so far:

Though KuiContextMenu throws a warning bc I am using a button inside it. Not sure how best to address this... The icon is to "reset" the title back to sync with the saved visualization title. Maybe KuiContextMenu shouldn't use a button if no onClick functionality is provided to it.

[cjcenizal]

@stacey-gammon How about we add a menu-item called "Edit panel >" and when you click it another panel opens up which contains a form with a field for the title and a save button? There's an example in the UI Framework docs that's like this.

[stacey-gammon]

Fixed by #14831