## For 0.3.* series of releases - April 2020¶

The napari roadmap captures current development priorities within the project and should serve as a guide for napari core developers, to encourage and inspire contributors, and to provide insights to external developers who are interested in building for the napari ecosystem. For more details on what this document is and is not, see the about this document section.

The mission of napari is to be a foundational multi-dimensional image viewer for Python and provide graphical user interface (GUI) access to image analysis tools from the Scientific Python ecosystem for scientists across domains and levels of coding experience. To work towards this mission, we have set the following three high-level priorities to guide us over the upcoming months:

• Make the data viewing and annotation capabilities bug-free and fast.

• Make accessible documentation, tutorials, and demos.

Once the above goals are met, we will develop napari’s capabilities for image processing and analysis. We are prioritizing the robustness and polish of the core viewer before adding advanced features or support for functional or interactive plugins to ensure that plugin development will happen against a solid foundation, and because we have repeatedly encountered biologists and other scientists who have trouble even looking at their data, and annotating it. We are prioritizing the downloadable application with reader / writer plugin management so that we can start getting feedback from non-coding users to better understand their needs.

## Make the data viewing and annotation capabilities bug-free, fast and easy to use¶

• Better support for viewing big datasets. Currently, napari is fast when viewing on-disk datasets that can be naturally sliced along one axis (e.g. a time series) and where loading one slice is fast. However, when the loading is slow, the napari UI itself becomes slow, sometimes to the point of being unusable. We aim to improve this by making views and interactions non-blocking (#845), and improving caching (#718). We will also ensure that napari can be used headless without the GUI.

• Improving the performance of operations on in-memory data. Even when data is loaded in memory, some operations, such as label and shape painting, slicing along large numbers of points, or adjusting contrast and gamma, can be slow. We will continue developing our benchmark suite and work to integrate it into our development process. See the performance label for a current list of issues related to performance.

• Add a unified world coordinate system. Scientists need to measure data that comes from a real space with physical dimensions. Currently, napari has no concept of the space in which data lives: everything is unitless. Further, it is unclear at various parts in the UI whether a coordinate has been transformed. And finally, some data are acquired with distortions, such as skew in data collected on stage-scanning lightsheet microscopes, and napari should be able to account for those distortions by chaining together transforms - including affine and ultimately deformable transforms. We are tracking progress in this area in the World Coordinates project board.

• Ensure easy installation with a success rate close to 100%. We can still struggle with installation of Qt in some cases, and have had problems with dependency conflicts with other Python packages. We have recently added a conda-forge package and are working towards distributing bundled applications in #496. See the installation label for a current list of issues related to installation.

• Eliminate all known bugs. See the bug label for a current list of known bugs. We also want to make it easier for users to report bugs (#1090). Additionally, when bugs are encountered, we want to examine whether an improved software architecture could have prevented them. For example, we are undertaking a refactor to centralize event handling within napari and avoid circular, out of order, or repeated function calls (#1040). In the process of eliminating bugs we should also ensure that our continuous integration, i.e. automatic testing of each change on cloud infrastructure, is robust, and that we have increased coverage of our tests, including more GUI tests with screenshots. See the tests label for more information about our tests.

• Improve support for annotation of points #858, shapes #177, labels, and images #209 including text rendering #600.

• Add linked multi-canvas support (#760) to allow orthogonal views, or linked views of two datasets, for example to select keypoints for image alignment, or simultaneous 2D slices with 3D rendering.

• Add layer groups #970, which allow operating on many layers simultaneously making the viewer easier to use for multispectral or multimodal data, or, in the context of multiple canvases, where one wants to assign different groups to different canvases.

• Improve the user interface and design of the viewer to make it easier to use. A napari design audit last year dramatically improved the usability of the viewer. We must continue to run through these periodically to ensure the UI is friendly to new users, particularly non-programmers. See the design label for more information.

## Make a downloadable application with basic plugin management and persistent settings¶

• Distribute a bundled application for each major OS #496 to allow scientists to use napari without requiring a Python development environment, which can be difficult to install and maintain. The bundle should contain the necessary machinery to add plugins #1074.

• Support for reader plugins #937 and writer plugins #1068 to allow viewing of domain-specific data and saving of annotations. For more details see the plugins label on our repository.

• Support for persistent settings #834 to allow saving of preferences between launches of the viewer.

## Provide accessible documentation, tutorials, and demos¶

• Improve our website napari.org to provide easy access to all napari related materials, including the four types of documentation: learning-oriented tutorials, goal-oriented how-to-guides or galleries, understanding-oriented explanations (including developer resources), and a comprehensive API reference. See #764 and the documentation label on the napari repository for more details.

• Add a napari human interface guide for plugin developers, akin to Apple’s Human Interface Guidelines. We want such a guide to promote best practices and ensure that plugins provide a consistent user experience.

## Work prioritized for future roadmaps¶

We’re also planning or working on the following more advanced features, which will likely be prioritized in future roadmaps:

• General support for undo / redo functionality #474, a history feature, and macro generation.

• Complete serialization of the viewer #851 to enable sharing the entire viewer state. This feature will be supported after writer plugins have been added.

• Support for generating animations #780. This feature will be supported after we have the ability to serialize the viewer state #851.

• Draggable and resizable layers #299 and #989. This feature will be supported after we have added support for world coordinates project board 10 and rotations to our transform model.

• Linked 1D plots such as histograms, timeseries, or z-profiles #823 and #675.

• Support for using napari with remote computation (i.e. a remote jupyter notebook #495).

• Functional or interactive plugins that allow for analysis of data or add elements to the GUI.

This document is meant to be a snapshot of tasks and features that the napari team is investing resources in during our 0.3 series of releases starting April 2020. This document should be used to guide napari core developers, encourage and inspire contributors, and provide insights to external developers who are interested in building for the napari ecosystem. It is not meant to limit what is being worked on within napari, and in accordance with our values we remain community-driven, responding to feature requests and proposals on our issue tracker and making decisions that are driven by our users’ requirements, not by the whims of the core team.
Another good place to look for information around bigger-picture discussions within napari are our issues tagged with the long-term feature label.