Feedback to improve bokeh.charts

Bryan · July 20, 2016, 1:43am

Hi all,

There has not been any work on bokeh.charts in some time now. I'd like to spend some time improving it before a 1.0 release. There is alot of good in the current charts API, the work that Nick and Fabio did moved things forward a great deal. But more polish is needed before we give this "final blessing". A big issue is that none of the few people working on bokeh core dev right now are people that would actually use bokeh.charts for anything. (I'm not a data scientist doing EDA, e.g.) This makes the problem really: knowing what are the right things to fix or improve in the first place.

Some things are obvious, there are definitely gaps in the user guide. The default palettes and styles need to be improved. There are some bugs and implementation improvements that can be made. There are probably also entire chart types that should be considered for adding.

But the main thing I'd like help understanding: what are the common things a "charts user" would want to do, that are too-hard, or impossible to do right now.

I'd like to collect some thoughts on this email chain, in order to inform some concrete tasks that would be reasonable to schedule.

Thanks,

Bryan

Tina_Wenzel · July 20, 2016, 9:31am

Hi Bryan,

I don’t know whether you count it under charts, but the datatables would benefit from further functionalities and better graphics.

I am thinking of searchability, pagination and design (bootstrap style datatables)

Thanks & Regards,

Tina

···

2016-07-20 3:43 GMT+02:00 Bryan Van de Ven [email protected]:

Hi all,

There has not been any work on bokeh.charts in some time now. I’d like to spend some time improving it before a 1.0 release. There is alot of good in the current charts API, the work that Nick and Fabio did moved things forward a great deal. But more polish is needed before we give this “final blessing”. A big issue is that none of the few people working on bokeh core dev right now are people that would actually use bokeh.charts for anything. (I’m not a data scientist doing EDA, e.g.) This makes the problem really: knowing what are the right things to fix or improve in the first place.

Some things are obvious, there are definitely gaps in the user guide. The default palettes and styles need to be improved. There are some bugs and implementation improvements that can be made. There are probably also entire chart types that should be considered for adding.

But the main thing I’d like help understanding: what are the common things a “charts user” would want to do, that are too-hard, or impossible to do right now.

I’d like to collect some thoughts on this email chain, in order to inform some concrete tasks that would be reasonable to schedule.

Thanks,

Bryan

–

You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/4884309E-F2E8-4645-9C52-DBAF1E23AAC7%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–

Tina Wenzel
23, Shaftesbury Rd

N19 4QW
(+44) 7553775883

Alexandre_Avanian · July 20, 2016, 11:16am

Hi,

one thing that has been frustrating for me using charts is the gap in the api between charts and figures. Charts give a good starting base but often, you will want to customize some aspects of it using the lower level api. In some cases, it’s immediate, in others, less so (keyword arguments not being named the same, or the sub element not being easily accessible) and in other cases, I couldn’t even find a solution that would be quicker than just redo it from scratch what I wanted from the lower level api.

I have now built my own ‘chart’ classes (much more trivial than bokeh charts) to build the few typical plots I often do so I’m less engaged on charts anyway (which I guess is pretty common and maybe a reason not put in too much work in the charts api but more in how-tos/faqs)

Now a few qualifiers:

I’ve mostly retreated from using charts between 0.10 and 0.11 so the situation may have improved
I may have attempted to customize in the wrong manner (eg: I don’t think I fully investigated using select to get chart elements) which may have solved some of my issues
the documentation issue amplifies this experience but I don’t think is the full solution. Being able to seamlessly (or almost) manipulate a chart just like one would do with a figure would be the target imho and enable the charts api to be a stepping stone into making advanced plots instead of a dead-end (that last word might be too strong but I hope you see what I mean)
by the way, my experience relates mostly to TimeSeries, Scatter and Histograms which are also among the easiest charts to do with the lower api I guess (and my hurdles particularly to TimeSeries)
one thing I faced is a by-product of a missing feature is the hover tool (datetime formatting) and can’t really be blamed on charts (just couldn’t find a quick way to implement the fix with charts)

Best,

Alexandre

···

On Wednesday, July 20, 2016 at 9:43:27 AM UTC+8, Bryan Van de ven wrote:

Hi all,

There has not been any work on bokeh.charts in some time now. I’d like to spend some time improving it before a 1.0 release. There is alot of good in the current charts API, the work that Nick and Fabio did moved things forward a great deal. But more polish is needed before we give this “final blessing”. A big issue is that none of the few people working on bokeh core dev right now are people that would actually use bokeh.charts for anything. (I’m not a data scientist doing EDA, e.g.) This makes the problem really: knowing what are the right things to fix or improve in the first place.

Some things are obvious, there are definitely gaps in the user guide. The default palettes and styles need to be improved. There are some bugs and implementation improvements that can be made. There are probably also entire chart types that should be considered for adding.

But the main thing I’d like help understanding: what are the common things a “charts user” would want to do, that are too-hard, or impossible to do right now.

I’d like to collect some thoughts on this email chain, in order to inform some concrete tasks that would be reasonable to schedule.

Thanks,

Bryan

JTampel · July 20, 2016, 1:04pm

I think charts should be delegated to render Vegalight json from Altair, which is specialized and focused on EDA. That would ease burden on Bokeh core and reduce fragmentation in the ecosystem.

···

On Tuesday, July 19, 2016 at 9:43:27 PM UTC-4, Bryan Van de ven wrote:

Hi all,

There has not been any work on bokeh.charts in some time now. I’d like to spend some time improving it before a 1.0 release. There is alot of good in the current charts API, the work that Nick and Fabio did moved things forward a great deal. But more polish is needed before we give this “final blessing”. A big issue is that none of the few people working on bokeh core dev right now are people that would actually use bokeh.charts for anything. (I’m not a data scientist doing EDA, e.g.) This makes the problem really: knowing what are the right things to fix or improve in the first place.

Some things are obvious, there are definitely gaps in the user guide. The default palettes and styles need to be improved. There are some bugs and implementation improvements that can be made. There are probably also entire chart types that should be considered for adding.

But the main thing I’d like help understanding: what are the common things a “charts user” would want to do, that are too-hard, or impossible to do right now.

I’d like to collect some thoughts on this email chain, in order to inform some concrete tasks that would be reasonable to schedule.

Thanks,

Bryan

Bryan · July 20, 2016, 2:51pm

Hi,

one thing that has been frustrating for me using charts is the gap in the api between charts and figures. Charts give a good starting base but often, you will want to customize some aspects of it using the lower level api. In some cases, it's immediate, in others, less so (keyword arguments not being named the same, or the sub element not being easily accessible) and in other cases, I couldn't even find a solution that would be quicker than just redo it from scratch what I wanted from the lower level api.

I think we did not socialize this new feature well enough: as of 0.12 all the glyph methods (circle, etc) now exist on Charts as well, so hopefully that helps.

I have now built my own 'chart' classes (much more trivial than bokeh charts) to build the few typical plots I often do so I'm less engaged on charts anyway (which I guess is pretty common and maybe a reason not put in too much work in the charts api but more in how-tos/faqs)

Now a few qualifiers:
* I've mostly retreated from using charts between 0.10 and 0.11 so the situation may have improved
* I may have attempted to customize in the wrong manner (eg: I don't think I fully investigated using select to get chart elements) which may have solved some of my issues
* the documentation issue amplifies this experience but I don't think is the full solution. Being able to seamlessly (or almost) manipulate a chart just like one would do with a figure would be the target imho and enable the charts api to be a stepping stone into making advanced plots instead of a dead-end (that last word might be too strong but I hope you see what I mean)
* by the way, my experience relates mostly to TimeSeries, Scatter and Histograms which are also among the easiest charts to do with the lower api I guess (and my hurdles particularly to TimeSeries)
* one thing I faced is a by-product of a missing feature is the hover tool (datetime formatting) and can't really be blamed on charts (just couldn't find a quick way to implement the fix with charts)

I definitely think there are non-API-breaking technical improvements to the hover tool implementation that can be made to charts.

Thanks,

Bryan

···

On Jul 20, 2016, at 6:16 AM, Alexandre Avanian <[email protected]> wrote:

Best,
Alexandre

On Wednesday, July 20, 2016 at 9:43:27 AM UTC+8, Bryan Van de ven wrote:
Hi all,

There has not been any work on bokeh.charts in some time now. I'd like to spend some time improving it before a 1.0 release. There is alot of good in the current charts API, the work that Nick and Fabio did moved things forward a great deal. But more polish is needed before we give this "final blessing". A big issue is that none of the few people working on bokeh core dev right now are people that would actually use bokeh.charts for anything. (I'm not a data scientist doing EDA, e.g.) This makes the problem really: knowing what are the right things to fix or improve in the first place.

Some things are obvious, there are definitely gaps in the user guide. The default palettes and styles need to be improved. There are some bugs and implementation improvements that can be made. There are probably also entire chart types that should be considered for adding.

But the main thing I'd like help understanding: what are the common things a "charts user" would want to do, that are too-hard, or impossible to do right now.

I'd like to collect some thoughts on this email chain, in order to inform some concrete tasks that would be reasonable to schedule.

Thanks,

Bryan

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/0c7c6852-e5d2-4c5c-9503-9243f5b532a1%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

Bryan · July 20, 2016, 2:58pm

I think charts should be delegated to render Vegalight json from Altair, which is specialized and focused on EDA. That would ease burden on Bokeh core and reduce fragmentation in the ecosystem.

I think the converse notion (i.e. generating Bokeh plots from Vega-Lite) is a useful one to explore, but there's a number of reasons why what you suggest is not really practical from my perspective:

* bokeh.charts aims to have a wider variety of charts (contour, quiver, chord) than is supported by Vega-Lite
* supporting the full interactive capabilities of Bokeh with only Vega-Lite would be problematic
* no path to integrate with datashader or leverage other pydata tools for larger pre-aggregating data sets (Vega does its own aggregation and just "JSON's all the things" which is not scalable)
* maintaining two backends is not a maintenance improvement over maintaining one

As for "fragmentation" I think more options is a good thing.

Bryan

···

On Jul 20, 2016, at 8:04 AM, Templ <[email protected]> wrote:

On Tuesday, July 19, 2016 at 9:43:27 PM UTC-4, Bryan Van de ven wrote:
Hi all,

There has not been any work on bokeh.charts in some time now. I'd like to spend some time improving it before a 1.0 release. There is alot of good in the current charts API, the work that Nick and Fabio did moved things forward a great deal. But more polish is needed before we give this "final blessing". A big issue is that none of the few people working on bokeh core dev right now are people that would actually use bokeh.charts for anything. (I'm not a data scientist doing EDA, e.g.) This makes the problem really: knowing what are the right things to fix or improve in the first place.

Some things are obvious, there are definitely gaps in the user guide. The default palettes and styles need to be improved. There are some bugs and implementation improvements that can be made. There are probably also entire chart types that should be considered for adding.

But the main thing I'd like help understanding: what are the common things a "charts user" would want to do, that are too-hard, or impossible to do right now.

I'd like to collect some thoughts on this email chain, in order to inform some concrete tasks that would be reasonable to schedule.

Thanks,

Bryan

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/e7a6eb82-107a-477b-b414-733b25448c2e%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

JTampel · July 20, 2016, 4:18pm

generating Bokeh plots from Vega-Lite
Yes that’s what I meant. Altair spits out a Vega-Lite spec and bokeh renders it. Altair is already designed to work with multiple backends and that way bokeh can do additional processing.

The only downside I see is that Bokeh has a wider scope…but perhaps these additional charts can be PRs to altair and marked as bokeh backend only.

Also where do you see holoviews fitting in?

···

On Wednesday, July 20, 2016 at 10:58:52 AM UTC-4, Bryan Van de ven wrote:

On Jul 20, 2016, at 8:04 AM, Templ [email protected] wrote:

I think charts should be delegated to render Vegalight json from Altair, which is specialized and focused on EDA. That would ease burden on Bokeh core and reduce fragmentation in the ecosystem.

I think the converse notion (i.e. generating Bokeh plots from Vega-Lite) is a useful one to explore, but there’s a number of reasons why what you suggest is not really practical from my perspective:

bokeh.charts aims to have a wider variety of charts (contour, quiver, chord) than is supported by Vega-Lite

supporting the full interactive capabilities of Bokeh with only Vega-Lite would be problematic

no path to integrate with datashader or leverage other pydata tools for larger pre-aggregating data sets (Vega does its own aggregation and just “JSON’s all the things” which is not scalable)

maintaining two backends is not a maintenance improvement over maintaining one

As for “fragmentation” I think more options is a good thing.

Bryan

On Tuesday, July 19, 2016 at 9:43:27 PM UTC-4, Bryan Van de ven wrote:

Hi all,

There has not been any work on bokeh.charts in some time now. I’d like to spend some time improving it before a 1.0 release. There is alot of good in the current charts API, the work that Nick and Fabio did moved things forward a great deal. But more polish is needed before we give this “final blessing”. A big issue is that none of the few people working on bokeh core dev right now are people that would actually use bokeh.charts for anything. (I’m not a data scientist doing EDA, e.g.) This makes the problem really: knowing what are the right things to fix or improve in the first place.

Some things are obvious, there are definitely gaps in the user guide. The default palettes and styles need to be improved. There are some bugs and implementation improvements that can be made. There are probably also entire chart types that should be considered for adding.

But the main thing I’d like help understanding: what are the common things a “charts user” would want to do, that are too-hard, or impossible to do right now.

I’d like to collect some thoughts on this email chain, in order to inform some concrete tasks that would be reasonable to schedule.

Thanks,

Bryan

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/e7a6eb82-107a-477b-b414-733b25448c2e%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

birdsarah_continuum · July 20, 2016, 7:00pm

We’ve started thinking about how Bokeh can support Altair. There’s an issue here you can follow :

      As a simple user of

charts alta ir looks awesome to me.
But I know we have charts users who want more than what altair can deliver e.g. we’ve ha d
the chord chart contribution

So I’m very keen to hear further from our charts
power users.

···

https://github.com/bokeh/bokeh/issues/4844
On 7/20/16 11:18 AM, Templ wrote:

      generating
Bokeh plots from Vega-Lite
Yes that’s what I meant. Altair spits out a Vega-Lite spec
and bokeh renders it. Altair is already designed to work with
multiple backends and that way bokeh can do additional
processing.

      The only downside I see is that Bokeh has a wider
scope…but perhaps these additional charts can be PRs to
altair and marked as bokeh backend only.

Also where do you see holoviews fitting in?
      On Wednesday, July 20, 2016 at 10:58:52 AM UTC-4, Bryan Van de
ven wrote:
        > On Jul 20, 2016, at 8:04 AM, Templ <[email protected]            >
wrote:
        >

        > I think charts should be delegated to render Vegalight
json from Altair, which is specialized and focused on EDA.
That would ease burden on Bokeh core and reduce
fragmentation in the ecosystem.
        I think the converse notion (i.e. generating Bokeh plots
from Vega-Lite) is a useful one to explore, but there’s a
number of reasons why what you suggest is not really
practical from my perspective:
        * bokeh.charts aims to have a wider variety of charts
(contour, quiver, chord) than is supported by Vega-Lite
        * supporting the full interactive capabilities of Bokeh with
only Vega-Lite would be problematic
        * no path to integrate with datashader or leverage other
pydata tools for larger pre-aggregating data sets (Vega does
its own aggregation and just “JSON’s all the things” which
is not scalable)
        * maintaining two backends is not a maintenance improvement
over maintaining one
        As for "fragmentation" I think more options is a good thing.




        Bryan



        >

        > On Tuesday, July 19, 2016 at 9:43:27 PM UTC-4, Bryan
Van de ven wrote:
        > Hi all,

        >

        > There has not been any work on bokeh.charts in some
time now. I’d like to spend some time improving it before a
1.0 release. There is alot of good in the current charts
API, the work that Nick and Fabio did moved things forward a
great deal. But more polish is needed before we give this
“final blessing”. A big issue is that none of the few people
working on bokeh core dev right now are people that would
actually use bokeh.charts for anything. (I’m not a data
scientist doing EDA, e.g.) This makes the problem really:
knowing what are the right things to fix or improve in the
first place.
        >

        > Some things are obvious, there are definitely gaps in
the user guide. The default palettes and styles need to be
improved. There are some bugs and implementation
improvements that can be made. There are probably also
entire chart types that should be considered for adding.
        >

        > But the main thing I'd like help understanding: what
are the common things a “charts user” would want to do, that
are too-hard, or impossible to do right now.
        >

        > I'd like to collect some thoughts on this email chain,
in order to inform some concrete tasks that would be
reasonable to schedule.
        >

        > Thanks,

        >

        > Bryan


        >

        > --

        > You received this message because you are subscribed to
the Google Groups “Bokeh Discussion - Public” group.
        > To unsubscribe from this group and stop receiving
emails from it, send an email to [email protected] .
        > To post to this group, send email to [email protected]            .


        > To view this discussion on the web visit [https://groups.google.com/a/continuum.io/d/msgid/bokeh/e7a6eb82-107a-477b-b414-733b25448c2e%40continuum.io](https://groups.google.com/a/continuum.io/d/msgid/bokeh/e7a6eb82-107a-477b-b414-733b25448c2e%40continuum.io)            .


        > For more options, visit [https://groups.google.com/a/continuum.io/d/optout](https://groups.google.com/a/continuum.io/d/optout)            .

–

  You received this message because you are subscribed to the Google

Groups “Bokeh Discussion - Public” group.

  To unsubscribe from this group and stop receiving emails from it,

send an email to [email protected].

  To post to this group, send email to [email protected].

  To view this discussion on the web visit [https://groups.google.com/a/continuum.io/d/msgid/bokeh/9ffd737c-8002-4d4d-8c31-468d92ae12d8%40continuum.io](https://groups.google.com/a/continuum.io/d/msgid/bokeh/9ffd737c-8002-4d4d-8c31-468d92ae12d8%40continuum.io?utm_medium=email&utm_source=footer).

  For more options, visit [https://groups.google.com/a/continuum.io/d/optout](https://groups.google.com/a/continuum.io/d/optout).

–
Sarah Bird
Developer, Bokeh

    [
      ![Continuum Analytics](http://docs.continuum.io/_static/img/ContinuumWordmark.png)
    ](http://continuum.io)

Fabio_Pliger · July 26, 2016, 5:45pm

Sorry for taking so long to chime in on this and thanks Bryan for this. It’s really worth it to start discussing this sooner.

I do agree that we should collect various feedbacks about good things and bad things of the current charts and prepare a target plan (basically “how would a blessed 1.0 charts look like?”). IMO the most important of this process is really getting end users feedback. I can try to collect the charts related open issues to build build a knowledge base and sum up things that are missing (and were part of the final view of the work I and Nick were doing). Honestly the most important thing I can think now is improving documentation clarity and efficiency. I think the docs are not straightforward enough…

Finally, after we have some more knowledge about what we need to do, it may be useful to have a focused (a day or 2?) sprint with other folks (internal and external contributors?) to start tackling specific things. Actually… if there’s interest we could have a call for sprinters (even remoters) to see if external contributors would like to help.

Last thing: ideally we could integrate this work with some support for altair… but we should probably be very careful about including this action when working on the rest to not have too much meat on the grill.

···

On Wed, Jul 20, 2016 at 9:00 PM, Sarah Bird - Continuum [email protected] wrote:

We’ve started thinking about how Bokeh can support Altair. There’s an issue here you can follow :
https://github.com/bokeh/bokeh/issues/4844

      As a simple user of
charts alta ir looks awesome to me.
But I know we have charts users who want more than what altair can deliver e.g. we’ve ha d
the chord chart contribution

So I’m very keen to hear further from our charts
power users.

On 7/20/16 11:18 AM, Templ wrote:

      generating
Bokeh plots from Vega-Lite
Yes that’s what I meant. Altair spits out a Vega-Lite spec
and bokeh renders it. Altair is already designed to work with
multiple backends and that way bokeh can do additional
processing.

      The only downside I see is that Bokeh has a wider
scope…but perhaps these additional charts can be PRs to
altair and marked as bokeh backend only.

Also where do you see holoviews fitting in?
      On Wednesday, July 20, 2016 at 10:58:52 AM UTC-4, Bryan Van de
ven wrote:
        > On Jul 20, 2016, at 8:04 AM, Templ <[email protected]            >
wrote:
        >

        > I think charts should be delegated to render Vegalight
json from Altair, which is specialized and focused on EDA.
That would ease burden on Bokeh core and reduce
fragmentation in the ecosystem.
        I think the converse notion (i.e. generating Bokeh plots
from Vega-Lite) is a useful one to explore, but there’s a
number of reasons why what you suggest is not really
practical from my perspective:
        * bokeh.charts aims to have a wider variety of charts
(contour, quiver, chord) than is supported by Vega-Lite
        * supporting the full interactive capabilities of Bokeh with
only Vega-Lite would be problematic
        * no path to integrate with datashader or leverage other
pydata tools for larger pre-aggregating data sets (Vega does
its own aggregation and just “JSON’s all the things” which
is not scalable)
        * maintaining two backends is not a maintenance improvement
over maintaining one
        As for "fragmentation" I think more options is a good thing.




        Bryan



        >

        > On Tuesday, July 19, 2016 at 9:43:27 PM UTC-4, Bryan
Van de ven wrote:
        > Hi all,

        >

        > There has not been any work on bokeh.charts in some
time now. I’d like to spend some time improving it before a
1.0 release. There is alot of good in the current charts
API, the work that Nick and Fabio did moved things forward a
great deal. But more polish is needed before we give this
“final blessing”. A big issue is that none of the few people
working on bokeh core dev right now are people that would
actually use bokeh.charts for anything. (I’m not a data
scientist doing EDA, e.g.) This makes the problem really:
knowing what are the right things to fix or improve in the
first place.
        >

        > Some things are obvious, there are definitely gaps in
the user guide. The default palettes and styles need to be
improved. There are some bugs and implementation
improvements that can be made. There are probably also
entire chart types that should be considered for adding.
        >

        > But the main thing I'd like help understanding: what
are the common things a “charts user” would want to do, that
are too-hard, or impossible to do right now.
        >

        > I'd like to collect some thoughts on this email chain,
in order to inform some concrete tasks that would be
reasonable to schedule.
        >

        > Thanks,

        >

        > Bryan


        >

        > --

        > You received this message because you are subscribed to
the Google Groups “Bokeh Discussion - Public” group.
        > To unsubscribe from this group and stop receiving
emails from it, send an email to [email protected] .
        > To post to this group, send email to [email protected]            .


        > To view this discussion on the web visit [https://groups.google.com/a/continuum.io/d/msgid/bokeh/e7a6eb82-107a-477b-b414-733b25448c2e%40continuum.io](https://groups.google.com/a/continuum.io/d/msgid/bokeh/e7a6eb82-107a-477b-b414-733b25448c2e%40continuum.io)            .


        > For more options, visit [https://groups.google.com/a/continuum.io/d/optout](https://groups.google.com/a/continuum.io/d/optout)            .

–

  You received this message because you are subscribed to the Google

Groups “Bokeh Discussion - Public” group.

  To unsubscribe from this group and stop receiving emails from it,

send an email to [email protected].

  To post to this group, send email to [email protected].

  To view this discussion on the web visit [https://groups.google.com/a/continuum.io/d/msgid/bokeh/9ffd737c-8002-4d4d-8c31-468d92ae12d8%40continuum.io](https://groups.google.com/a/continuum.io/d/msgid/bokeh/9ffd737c-8002-4d4d-8c31-468d92ae12d8%40continuum.io?utm_medium=email&utm_source=footer).

  For more options, visit [https://groups.google.com/a/continuum.io/d/optout](https://groups.google.com/a/continuum.io/d/optout).

–
Sarah Bird
Developer, Bokeh

    [
      ![Continuum Analytics](http://docs.continuum.io/_static/img/ContinuumWordmark.png)
    ](http://continuum.io)

–

You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/532fea91-c497-8254-e135-c91e28d2d774%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–

Fabio Pliger

Senior Software Engineer, Bokeh

Fabio_Pliger · July 26, 2016, 5:49pm

Thanks Alexandre. That's a very good feedback. I can think of a few things
that you've mentioned that have been already addressed or have been
documented but not all. It'd be helpful if you can open issues with
specific things so we can better track them and include in the discussion.

Cheers

···

On Wed, Jul 20, 2016 at 1:16 PM, Alexandre Avanian < [email protected]> wrote:

Hi,

one thing that has been frustrating for me using charts is the gap in the
api between charts and figures. Charts give a good starting base but often,
you will want to customize some aspects of it using the lower level api. In
some cases, it's immediate, in others, less so (keyword arguments not being
named the same, or the sub element not being easily accessible) and in
other cases, I couldn't even find a solution that would be quicker than
just redo it from scratch what I wanted from the lower level api.
I have now built my own 'chart' classes (much more trivial than bokeh
charts) to build the few typical plots I often do so I'm less engaged on
charts anyway (which I guess is pretty common and maybe a reason not put in
too much work in the charts api but more in how-tos/faqs)

Now a few qualifiers:
* I've mostly retreated from using charts between 0.10 and 0.11 so the
situation may have improved
* I may have attempted to customize in the wrong manner (eg: I don't think
I fully investigated using select to get chart elements) which may have
solved some of my issues
* the documentation issue amplifies this experience but I don't think is
the full solution. Being able to seamlessly (or almost) manipulate a chart
just like one would do with a figure would be the target imho and enable
the charts api to be a stepping stone into making advanced plots instead of
a dead-end (that last word might be too strong but I hope you see what I
mean)
* by the way, my experience relates mostly to TimeSeries, Scatter and
Histograms which are also among the easiest charts to do with the lower api
I guess (and my hurdles particularly to TimeSeries)
* one thing I faced is a by-product of a missing feature is the hover tool
(datetime formatting) and can't really be blamed on charts (just couldn't
find a quick way to implement the fix with charts)

Best,
Alexandre

--
*Fabio Pliger*
*Senior Software Engineer, Bokeh*

Darren_Kondrat · July 26, 2016, 7:12pm

Hi

Thanks for the chance to add my thoughts. I am new to Python and started with Mathplotlib. I was able to create interactive sliders, textbox, multivariable lists from lists easily. I was able to choose variables in one and add it to another. I was trying to select variables to create crossplots quickly and output a table of results if I liked what I saw. I switched to bokeh so that I could select points in one graph and highlight them in the other. I love the look and feel of bokeh but I find the widgets to be very difficult to configure. I would really like to be able to not just view my data but actually make changes to it interactively. My vote would be to make the widgets easier to make callbacks.

oh ya, a file loader would be nice too… ( a button that would call up a open file window)

Thanks for the toolkit!

Darren

···

On Wed, Jul 20, 2016 at 1:16 PM, Alexandre Avanian [email protected] wrote:

Hi,

one thing that has been frustrating for me using charts is the gap in the api between charts and figures. Charts give a good starting base but often, you will want to customize some aspects of it using the lower level api. In some cases, it’s immediate, in others, less so (keyword arguments not being named the same, or the sub element not being easily accessible) and in other cases, I couldn’t even find a solution that would be quicker than just redo it from scratch what I wanted from the lower level api.

I have now built my own ‘chart’ classes (much more trivial than bokeh charts) to build the few typical plots I often do so I’m less engaged on charts anyway (which I guess is pretty common and maybe a reason not put in too much work in the charts api but more in how-tos/faqs)

Now a few qualifiers:

I’ve mostly retreated from using charts between 0.10 and 0.11 so the situation may have improved

I may have attempted to customize in the wrong manner (eg: I don’t think I fully investigated using select to get chart elements) which may have solved some of my issues

the documentation issue amplifies this experience but I don’t think is the full solution. Being able to seamlessly (or almost) manipulate a chart just like one would do with a figure would be the target imho and enable the charts api to be a stepping stone into making advanced plots instead of a dead-end (that last word might be too strong but I hope you see what I mean)

by the way, my experience relates mostly to TimeSeries, Scatter and Histograms which are also among the easiest charts to do with the lower api I guess (and my hurdles particularly to TimeSeries)

one thing I faced is a by-product of a missing feature is the hover tool (datetime formatting) and can’t really be blamed on charts (just couldn’t find a quick way to implement the fix with charts)

Best,

Alexandre

Thanks Alexandre. That’s a very good feedback. I can think of a few things that you’ve mentioned that have been already addressed or have been documented but not all. It’d be helpful if you can open issues with specific things so we can better track them and include in the discussion.

Cheers

–
Fabio Pliger

Senior Software Engineer, Bokeh