Bokeh is an interactive visualization library for modern web browsers. It provides elegant, concise construction of versatile graphics and affords high-performance interactivity across large or streaming datasets. Bokeh can help anyone who wants to create interactive plots, dashboards, and data applications quickly and easily.
The development pace of Bokeh is contingent on external funding opportunities, so this roadmap does not mean to imply any specific dates or deadlines. Listed below are the major areas of work the Core Team considers important. These are tasks and projects that we would like to do ourselves, when time and resources permit, or that we would be happy to have done by new contributors.
Bokeh currently can use WebGL to accelerate plotting for larger datasets in some limited situations. In addition to not fully supporting some use-cases, the internal cost is having to maintain two separate code paths. It would be desirable to convert Bokeh’s rendering to always use WebGL whenever possible, so that better performance for larger data sets is always available, and to streamline maintenance for the future.
By and large none of the core contributors have been JS or front-end experts, and for some time the client side BokehJS library was an implementation detail. There is more interest to use BokehJS directly, and with attention from experienced front-end JS developers, BokehJS could integrate better with existing common web frameworks and tools than it currently does. This includes making much more accessible documentation for BokehJS itself. These improvements would also help increase the potential pool of core developers interested in maintaining BokehJS over the long run.
We need to better serve users and contributors with cognitive, developmental, intellectual, mental, physical, and/or sensory disabilities and better accommodate assistive technologies. Working towards this goal includes updates to Bokeh’s codebase as well as to Bokeh’s documentation and other web assets.
Bokeh currently has some minimal theming ability, that can specify properties for types. It would be useful to have more targets and sophisticated ways to theme individual objects, or collections of objects. Additionally some work is needed to improve or create visual assets that work with different themes, and to make DOM elements easily themeable as well.
Bokeh has never had the benefit of any dedicated web or visual designers, and this is one area where it suffers compared to some other projects. Visually, it looks much less “designed by engineers” than it used to, there is still much room for improvement. Another idea, if Better Theming Support is accomplished is to have visual designers help create a set of attractive themes that can be immediately available to users.
Open Geospatial Consortium (OGC) standards, such as GeoJSON and TopoJSON, play an important role in sharing and exchanging geo data. Improving Bokeh’s support for those open standards would significantly increase the usability and usefulness of Bokeh’s geo-related features.
Bokeh has good basic support for any type of data, but does not include any special optimizations for the common case of scalar, linear, or image data sampled on a regular timebase. Gridded 0D/1D/2D timeseries data of this type arises often in scientific or engineering data-acquisition and analysis contexts involving point, line, or image sensors, such as microphones or temperature probes, electrode arrays, camera or microscope images, and so on. Bokeh’s performance, ease of use, and ease of application can be greatly improved to cover these cases well, building on the existing efficient binary transport mechanisms while improving performance, adding user interface elements to work with streaming data, and showing examples for researchers to follow.
Some users have expressed interest in the ability to make different views of a plot transform smoothly from one state to another. (Compare to “tween” animations in GGplot). This would afford the ability to create visually attractive “data stories” by scripting smooth transitions that connect one view of data to another.
Bokeh currently allows for users to execute JavaScript code or Python code in response to data changes or various UI events. Some users have requests a more direct “simple remote procedure” capability that would enable them to e.g. execute a JavaScript function directly from Python in a Bokeh server application or vice versa.
The Bokeh documentation has grown quite large and has much information, but it seems to be the case that many users still have difficulty finding the appropriate documentation or examples, even when they exist. The project would benefit greatly from experienced help to organize the information architecture of the docs, point out missing areas, etc.
Bokeh can display mathematical symbols and formulas by creating and using custom extensions. Users have expressed a desire for this capability to be more directly integrated, e.g to draw math text for axis or tick labels, without needing to resort to a custom extension.
Bokeh supports various sorts of hit testing for selection and hover on a per-glyph basis. It would be good to make support more uniform by adding the requisite hit testing wherever it is currently missing. Additionally Bokeh needs a policy-based mechanism for dealing with “multiple hits” i.e. if the mouse hovers over 50 points, a way to show just one, or just the top N, or even some aggregation or summary as the hover.
We have repeatedly experienced that diversity, resulting from an inclusive culture, is intrinsically good for the project and a crucial factor in making Bokeh a better tool. We are determined to make Bokeh welcoming and supportive to users and contributors, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. We are aware that working towards this goal is a continual process of learning and improvement.