plotly.js
plotly.js copied to clipboard
plotly
Feature request: rounded corners for trace bars
This is a request to pass attributes to trace bar component to adjust bar corner roundness. That way bar visual variety would be extended. Each bar corners roundness could individually adjusted with percentage value from 0 to 1 where 1 is full circle arc.
Attribute could be passed like this:
"cornerroundness": { "bottomleft": 0.3, "bottomright": 0, "topleft": 0.3, "topright": 0 }
Maximum arc radius could be set to least wide bar edge width divided by two otherwise there could arise visual problems with bar.
Visually that would result that bars would be able to look like this:
The dataviz purist in me is a little squeamish - the area of the bar, the most important component of its visual weight, loses proportionality with the data value, and lacking a straight line at the end it's hard to compare two similar bars and tell which is bigger. But you're right that it's a pleasant effect, we'd entertain a PR about this.
@etpinard the stacking part is a problem. Basically, one way is to manually handle it when passing data object by ensuring appropriate round corners are only on data bars that are on top or on the bottom of the stack. Of course, this isn't ideal since bar can be in different positions in different stacks. Which limits the use of round corners on stacked bars. Another solution would be automatically omit roundness of the bar depending on its position in bar stack. But as I understand it's not quite possible at the moment to know whether there will be a bar on top or on the bottom at the moment of drawing individual bar. Also, it would require to pass bar roundness attribute to all potential data bars that could end up on stack top or the bottom.
I checked out how currently bar stacking is working and based on that added stack position calculation logic which, then is used to check whether corners need to be rounded. Which results in something like seen in the picture below.
Also experimenting with corner roundness I found out that it's is best to use the smallest edge of all the bars, to calculate max corner radius so all the bars look similar and there aren't any cases where taller bars look more round than very small bars. Now bars would look like this instead of the one like you can see in the top comment
+1. I need this as well. Much more subtle but there is a need to fit charts into a brand.
I would say rounded corners are essential for professional graphs. As Steve Jobs would have said: "Even something as basic as a traffic sign has rounded corners".
For now I'll use shapes with plotly.py: https://plot.ly/~empet/14945/shapes-that-are-filled-rectangle/#/
FWIW the shape solution doesn't need two overlaid shapes - just take out the extra M steps between the Q and L portions. See for example https://codepen.io/alexcjohnson/pen/dErOaK?editors=0010
@alexcjohnson Thanks for this simple solution to round the corners.
@Jonathan-MW I updated this notebook https://plot.ly/~empet/14945 defining the path like in the above pen.
Any updates? This an important feature and not optional if you want to fit your chart to a design system brand.
Any update, 7mo later? Though it is a very niche demand, I would love to see this feature come alive. Just noticed, even the latest Plotly logo uses rounded bars.
We'd be happy to work with someone who wants to implement this and get it merged in but it's not on our roadmap at the moment :)
@nicolaskruchten, what would be the ideal approach to implementing this change?
Hi @BrianRuizy !
The first step would be to propose one or more new attributes in the Plotly.js schema to control this new behaviour. Something like "a new attribute cornerradius under bar.marker which accepts integers and defaults to 0" or similar. Usually this results in a bit of discussion around a spec, like "what about stacks? what about groups? what about histogram traces or waterfall traces?" etc.
Once we can agree to a 'spec' like this, it's usually a question of figuring out a test plan and then writing the code. The test plan will involve some static image tests that prove the new attribute works and some Jasmine tests to prove that it can work when turned on and off via react() and restyle and that it behaves correctly under various corner-case situations (i.e. bars that go negative etc).
This issue has been tagged with NEEDS SPON$OR
A community PR for this feature would certainly be welcome, but our experience is deeper features like this are difficult to complete without the Plotly maintainers leading the effort.
What Sponsorship includes:
- Completion of this feature to the Sponsor's satisfaction, in a manner coherent with the rest of the Plotly.js library and API
- Tests for this feature
- Long-term support (continued support of this feature in the latest version of Plotly.js)
- Documentation at plotly.com/javascript
- Possibility of integrating this feature with Plotly Graphing Libraries (Python, R, F#, Julia, MATLAB, etc)
- Possibility of integrating this feature with Dash
- Feature announcement on community.plotly.com with shout out to Sponsor (or can remain anonymous)
- Gratification of advancing the world's most downloaded, interactive scientific graphing libraries (>50M downloads across supported languages)
Please include the link to this issue when contacting us to discuss.
I'm using Plotly along with Dash at my company. While Plotly is great, it pales in comparison to the overall visual pleasantness provided by Tableau. My dashboard is really heavy on Bar Charts and this feature would be most welcome. I don't know if this is very hard to implement or just not a priority. But if the kind developers out there entertain this feature request, I'd be very grateful. Judging from this thread, clearly so many people are interested in it.
One workaround is to programmatically insert a half circle on the top of your bar charts. While we are in the plotly.js repo, this is a demo with Python.
This approach relies on knowing the width of each of the bars, which you can set. If you know the widths, you can programmatically run through all the data points (x,y) in the figure, create an SVG path that starts at (x-1/2*bar_width, y), and then draw a cubic Bézier curve over to the right corner of the bar, at (x+1/2*bar_width, y).
The chart on the left is without the rounded corners, the chart of the right is with the rounded corners.
This is what app.py looks like:
import random
import dash
import plotly
import plotly.graph_objs as go
import dash_core_components as dcc
import dash_html_components as html
X_ARRAY = [1, 2, 3, 4, 5, 6, 7, 8, 9]
Y_ARRAY = [10, 4, 7, 11, 12, 8, 3, 6, 6]
GRAPH_STYLE = {
"width": "50%",
"display": "inline-block",
}
app = dash.Dash(
__name__,
suppress_callback_exceptions=True,
meta_tags=[
{"name": "viewport", "content": "width=device-width, initial-scale=1.0"}
],
)
server = app.server
def bar_graph(x_array, y_array, marker_color=None):
if not marker_color:
marker_color = "DodgerBlue"
fig = go.Figure(
data=go.Bar(x=x_array, y=y_array, marker=dict(color=marker_color)),
layout=go.Layout(
height=300, margin=dict(l=0, r=0, t=0, b=0,), yaxis=dict(range=[0, 15])
),
)
return fig
def rounded_bar_graph(x_array, y_array, marker_color=None):
if not marker_color:
marker_color = "DodgerBlue"
fig = bar_graph(x_array, y_array)
bw = 0.4 # half of the bar width
curve_height = 2.7
no_color = "rgba(0,0,0,0)"
shapes = []
for x, y in zip(fig["data"][0]["x"], fig["data"][0]["y"]):
path = f"""
M {x-bw},{y}
C {x-bw} {y+curve_height}, {x+bw} {y+curve_height}, {x+bw} {y}
V 0
H {x-bw}
Z
"""
shapes.append(
dict(type="path", path=path, line_color=no_color, fillcolor=marker_color,)
)
fig.update_layout(shapes=shapes,)
return fig
layout = html.Div(
children=[
dcc.Graph(
id="bar-graph-2", style=GRAPH_STYLE, figure=bar_graph(X_ARRAY, Y_ARRAY)
),
dcc.Graph(
id="bar-graph",
style=GRAPH_STYLE,
figure=rounded_bar_graph(X_ARRAY, Y_ARRAY),
),
]
)
app.layout = layout
while __name__ == "__main__":
app.run_server(debug=True)
CC @tanmay-kulkarni @prykon @mdriesch
One thing to note about rounded corners is that they're (potentially, I haven't dug up any studies!) problematic for visualization in two ways:
- The height of the bar becomes ambiguous: is it the top of the rounded bit? The part where the rounding starts? (As in @kully's solution... possibly misleading!) The average of the two?
- Beyond length-encoding problems it breaks the area-encoding of equal-width bars: short bars lose proportionally more area (if the corners are "trimmed off", or gain it if it's an added shape) than long bars, making comparisons potentially more error-prone.
- The height of the bar becomes ambiguous: is it the top of the rounded bit? The part where the rounding starts? (As in @Kully's solution... possibly misleading!) The average of the two?
For a full half circle, I can see how this is a problem for sure. However, with only a slight border-radius to the tops of the bars, I don't think the height becomes as ambiguous.
- Beyond length-encoding problems it breaks the area-encoding of equal-width bars: short bars lose proportionally more area (if the corners are "trimmed off", or gain it if it's an added shape) than long bars, making comparisons potentially more error-prone.
This is a really good point as well. If the point of the visualization is to compare areas, having rounded corners could absolutely mislead.
If the point of the visualization is to compare areas
One challenge with visualization is that we have little control over how people actually perceive what we produce, so even if comparing areas isn't "the point" of the visualization author, people who read it most likely will take areas into account when comparing at a glance. But yes, this is minimized when using small corner-radii compared to the bar widths.
One challenge with visualization is that we have little control over how people actually perceive what we produce
This is very true. And it tessellates so neatly with questions such as:
- What is the most ethical/morale way or representing the data? and
- How will a specific person actually perceive this?
@nicolaskruchten Are there any resources/books you know of that talk about these kinds of viz choices and their affect (conscious or not) on the end user/viewer?
Yes, there is lots of research about perception. A good starting point, if dated, is Colin Ware's Information Visualization: Perception for Design.
Side note: these issues also pertain in a long-dormant problem with dash-daq thermometers https://github.com/plotly/dash-daq/pull/68
Side note: these issues also pertain in a long-dormant problem with dash-daq thermometers plotly/dash-daq#68
Ahh I didn't know that, thank you for the heads up.