[Discuss] Graph icons and colors redesign

flash1293 commented 5 years ago

In Graph it's possible to choose from a limited variety of icons to make nodes of various types easier to differentiate.

As a part of the current Graph rewrite (see https://github.com/elastic/kibana/issues/44225) it might make sense to overhaul how icons work in Graph.

This issue is intended to collect various ideas.

Constraints

As there are already saved workspaces it should be possible to migrate from the current icon set to a new one - the icons don't have to stay exactly the same, but there should be an equivalent for all current icons

Ideas

Use EUI palette as default colors
The easy way: Just keep the current icons
Make icons optional and default to just colors (con: isn't really accessible)
Allow EUI icons (con: most of these don't really make sense for graphs and the old icons still have to stay around for BWC)
Pull in another icon set and allow more icons (Which icon set? What icons should be allowed?)
Provide a way to define svg icons in the UI (con: Cumbersome for the user)
Default to simple shapes instead of trying to infer a matching icon from the field name (triangle, square, circle, ...)

cc @cchaos @shaunmcgough

elasticmachine commented 5 years ago

Pinging @elastic/kibana-app

shaunmcgough commented 5 years ago

We could use an existing open set (previewed here)?

cchaos commented 5 years ago

Some ideas on your ideas

Use EUI palette as default colors

Yes, we can certainly default to our color blind safe visualization palette, leaving any existing Graphs using the current colors as "custom" colors. Users should still be able to choose any color they want via the EuiColorPicker.

Make icons optional and default to just colors (con: isn't really accessible)

The accessibility comment is not completely true. It's the same way multiple series are handled in visualizations. If the color palette has been optimized for color blindness then the colors will at least be differentiated from each-other. But Graph always labels each node so there's no instance where its only a colored dot. It's a colored dot with a label <- that is accessible.

The easy way: Just keep the current icons

Allow EUI icons (con: most of these don't really make sense for graphs and the old icons still have to stay around for BWC)

Pull in another icon set and allow more icons (Which icon set? What icons should be allowed?)

Provide a way to define svg icons in the UI (con: Cumbersome for the user)

I think we should brainstorm a simple viable set of icons (could be the same set that there is now) and remake them in SVG form that align with the EUI icon style but are created and live solely in the Graph application. Then (in the future) we also give users the ability to upload their own icons/images similar to Canvas.

I'm worried that presenting the user with hundreds of icon choices will be overwhelming. We'd then need a way to filter and search by name or type of icon and that presents a whole other challenge. It's ok to be limited at the moment, they'll find something that somewhat suits their needs.

Default to simple shapes instead of trying to infer a matching icon from the field name (triangle, square, circle, ...)

I think this is also a viable option but could be in conjunction with icons and not an alternative to. Icons can then also be optional.

cc @miukimiu for her thoughts as well.

flash1293 commented 5 years ago

Thanks for your input @cchaos

I agree with all of your points - I put this on the roadmap for 7.6 for now, but I will keep it in mind as a stretch goal for 7.5

Two little comments to your ideas on my ideas

The accessibility comment is not completely true. It's the same way multiple series are handled in visualizations. If the color palette has been optimized for color blindness then the colors will at least be differentiated from each-other.

You are right, it's probably fine. Other Graph tools are also doing this to my knowledge.

But Graph always labels each node so there's no instance where its only a colored dot. It's a colored dot with a label <- that is accessible.

The label doesn't contain the field of the node, that would only be expressed by the colored dot. In Graph each node is linked to a field and a term, the label is just the term, the field is represented by color and icon.

flash1293 commented 5 years ago

Just to make sure to not lose this thought: If a field name matches an ecs field name, we can pick a suitable icon - in other cases we probably shouldn't try to (or fall back to simple shapes)

markharwood commented 4 years ago

FWIW I always thought iconography choices for fields might also have uses elsewhere in Kibana.

flash1293 commented 4 years ago

We have to make sure that the distinction between these icons and the standard field type icons is made clear.

flash1293 commented 4 years ago

FWIW I always thought iconography choices for fields might also have uses elsewhere in Kibana.

@markharwood Interesting question, I don't know a place in Kibana where something like this done. Do you have something specific in mind? Also there have been discussions around configuring color choices somewhere central, might also be interesting in this context.

markharwood commented 4 years ago

I don't know a place in Kibana where something like this done. Do you have something specific in mind?

I suppose anywhere you want to render multiple types of entity in a space.

Could be a map (lat/lon axes)
Could be a scatterplot (see Scattertext and Republican vs Democrat axes)

flash1293 commented 4 years ago

I also had these in mind, but it seems like in these cases the icon choice is more of an icon for a document or maybe a specific value of field, not a field itself within the document, right?

markharwood commented 4 years ago

I think the iconography choices should relate to a real-world entity type (person, car...). An instance of a person type eg "Fred Smith" might appear in multiple documents and fields - payer and payee. The field names often determine the role an entity plays in an interaction. Entity type is not a concept we have right now.. Even in flat lists of fields, common entity-type iconography might help, for example, to show all the fields that hold "bank account" type entities. Without that knowledge, Kibana doesn't know that values found in one keyword field will have currency when used as queries in other keyword fields.

th0ger commented 4 years ago

Font Awesome is another icon set you could consider. A successful implementation can be found on e.g. Cheatography.

th0ger commented 4 years ago

The icon set should obviously be able to represent real world things.

But since a large part user segment of Elastic focuses on system logs, there should be a more diverse icon set covering technology, transactions & communication. E.g. to support a network graph of infrastructure (servers/services = nodes and transactions/interface = edges).

Here are some rough suggestions (again taken from Cheatography: Font Awsome for illustration).

server {{fa-server}}
database {{fa-database}}
access points {{fa-wifi}}
transaction {{fa-exchange}}
downloads {{fa-download}}
uploads {{fa-upload}}
emails {{fa-envelope}}
images {{fa-image}}
conversations {{fa-comment-o}}
clicks {{fa-mouse-pointer}}
source code {{fa-code}}
reports {{fa-line-chart}}
coffe {{fa-coffee}} (sorry couldn't help it)

elasticmachine commented 3 years ago

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

elasticmachine commented 1 year ago

Pinging @elastic/kibana-visualizations @elastic/kibana-visualizations-external (Team:Visualizations)

timductive commented 5 months ago

Closing this because it's not planned to be resolved in the foreseeable future. It will be tracked in our Icebox and will be re-opened if our priorities change. Feel free to re-open if you think it should be melted sooner.

elastic / kibana