Consider introducing _repr_html_ for all objects.

[haesleinhuepf]

Hi all,

I'm proposing a user convenience thing and if it's not too complicated to implement, I would support you folks in doing it.

Starting point is this example notebook

Current state

At the beginning, we read a Submission object:

Further down in the code, we visualize some properties of this object like this:

This code is quite complicated and might be detterend for Python beginners who aim at exploring the bioimage archive.

Proposed state

If this html code lived in a __repr_html__ function, future users could just write a submission object by the end of a Jupyter notebook cell and see what's in immediately:

Example code

I'll send a pull-request draft with prototype code to reproduce the screenshot above.

Let me know what you think!

Best, Robert

[liviuba]

Hi @haesleinhuepf ,

Thanks for suggesting this, and for your your PR!

We added _repr_html_ to all models as part of a bigger change to use our new API. This is still an ongoing PR, but you can find some example uses of the new explorer here/here/here.

Any feedback for how to make the package more usable would be very welcome!

Kind regards, Liviu

[haesleinhuepf]

Hi @liviuba ,

awesome, thanks for spending time on this! I'm just curious, do you think it's a good idea to show everything in _repr_html_ per default? The example notebooks linked above are quite long and it seems they become harder to read if "everything" is the default level of detail. Might it be possible to show only major information in _repr_html_ such as a small thumbnail image, title of the study and authors + license? Or something similar to the entries in the BIA gallery:

Users could call study.details or study,metadata to retrieve another object with complete details?

I'm just aiming at maximum user-friendlyness. Looking forward to hear what you think!

[liviuba]

Hi @haesleinhuepf

Thank you very much for taking the time to look at the changes & the feedback!

I agree that displaying everything was a bit overwhelming. I updated _repr_html_ to filter out most attributes, but am reluctant to format the output of that function too much (as in the gallery example above, which does look nice), mostly because a table-like structure would also double as "model documentation" and can inform a programmatic user of the attributes they have available.

A compact and user-friendly card would definitely be useful as an alternative representation though, so we also added a ticket to implement something similar to an as_card() method when we revisit the explorer developer experience.

I updated the notebooks (here) to only display the filtered attributes, please let me know what you think!

Kind regards, Liviu