Notes from Iris UX Discussion 2025-05-02
#6852
trexfeathers
started this conversation in
Minutes and notes
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Community
Low User Interaction
Iris has always been a bit difficult to discover, as it covers quite a niche area. We think that with the more popular and general-fit xarray, not only are we hard to discover, but our ideal users might be finding xarray, calling it "good enough", and not putting in the extra effort to find the better fitting packages.
It might also be that Iris' user base is largely Met Office employees, who would rely on support and Viva Engage. We DO NOT think that we should put more focus onto Met Office employees, as that would skew the balance and dissuade further users from joining us.
ACTION: Have a discussion about how much resource we can commit to publicity. This could involve visiting and/or presenting at conferences, having a greater social media presence, etc.
Documentation
Ease of Cross-Package Development
We do currently have the Community tab, which includes valuable documentation for xarray and pandas documentation. This is hard to find however, and misses links for things such as GeoVista and ncdata. We think this should be more immediate, or less buried. We also wonder if we should sell Iris as both a complete product and a toolbox, for using with xarray.
Accessibility and Completeness of Documentation
We need to offer a wider and more balanced approach. Diataxis caters to all learning styles, so would be a good start. We also think that a how-to section, like in ncdata, and more visible tutorials/examples should be added.
Development Process Transparency
We need a clear page on our philosophy, including why we've made certain decisions and how that will affect users. An example is where we stand on CF standards.
We should also offer a public roadmap of our plans around Iris, and more transparency of our approach.
Codebase
Ecosystem Alignment
We've found numerous examples of methods etc. that follow a different pattern than is used across most other popular repos. These should all be aligned, unless it significantly hinders our users, or if the payoff wouldn't be worth the work.
Most cube methods could just be root level. There's pros and cons to this. Most operations require a cube anyway, so one school of thought suggests making them methods is redundant, and many repos have moved away from this. However, it was raised that chaining methods are a useful utility, and that this move might not make much difference to users. We didn't come to a decision on this, but we were leaning against.
We have a number of in-place operations, that really shouldn't be. We have an issue for this, but we think this should definitely be in the next major release.
cube.copy() currently offers the ability to overwrite the data of the cube by adding the new data as a parameter. This is not the same as other packages, and adds unnecessary confusion to dataless cubes. There is an issue existing for this.
Ease of Debugging
We've been bitten a few times by silently failing bugs, either because errors aren't clear enough, or that Iris doesn't raise an error at all when something doesn't work. Any solutions for this seem to be more cultural than an immediate action, as these silent failures aren't noticed
Outdated API
Many of the methods that perform operations on dimensional metadata have useless duplication. For example, adding cell_measures requires a unique method call, even though it shares an API with most other metadata.
The way we approach dask is confusing in places. Our approach to data realisation is based on a legacy understanding. We want to ensure you can't accidentally realise data.
Why is it a method to access the dask array, and a property to realise the data?!
Why do we have cube.data.rechunk, rather than cube.rechunk. Is this just a convenience that will open us up to further troubles?
Culture
ACTION: Ensure when bug workarounds are created, that these are either documented or Iris or that there is a related issue raised.
ACTION: Plan a regular session for discussing the state of the user experience. We discussed making this yearly, although it could be more or less frequent as needed.
ACTION: Create a UX label to tag related issues and PRs.
Further Notes
We currently have a number of ongoing PRs that we think make large strides in including our UX:
Merge Concatenate work
Iris Loading work
Beta Was this translation helpful? Give feedback.
All reactions