UI/UX suggestions

[dhirschfeld]

First, thanks for working on this extension - I think it's incredibly important functionality for JupyterLab and is one of the most requested features from my users!

I'm just starting to try it out and have a couple of suggestions.

• Since space is at a premium the shape column should just show the shape tuple - e.g. (100, 3).
  The datatype (Array/DataFrame) is redundant since it just duplicates the TYPE column
  The rows/columns are redundant since they're implicit in the ordering
• After the type and shape the next most important information for me is the dtype so I'm wondering if there is some way to incorporate that? For the DataFrame seeing the column names (under content) is nice but it woudl be more useful if it were a name: type mapping. I can imagine that might quickly become too much information to display but thought I'd mention it in case anyone has a good solution.
• I'm not sure of the utility of the content view as is since space is often too limited to show enough information. Perhaps displaying the content is best left for a specific content-view triggered on double-click - as is already done.
  Edit: I guess it's very useful to quickly see the value of scalars or e.g. short tuples/lists 🤔

[lckr]

Hey @dhirschfeld,
Thank you for your valuable input.

I agree with you that there is too much redundant information in the type and shape fields at the moment.

Additionally, I like the idea of showing dtypes in the content field. But as you already pointed out, it is not too easy to decide what to show in this field due to space constraints. I'm not very happy with the current state especially w.r.t. the presentation of arrays which I find quite ugly as soon as its string representation needs to be truncated.

My idea is to show values only for scalars, strings and small collections. For larger collections or matrices we could try to display the 'dtypes'. To cope with the limited space we could allow to expand or collapse a row vertically whenever the enumeration of collums would exeed the available space.

What do you think about that?

[dhirschfeld]

Yeah, I think figuring out what/how to display an object is a hard problem!

I like your idea about an expander and had similar thoughts myself. A DataFrame may have come from a database with 20+ columns all with long names so even the dtype repr would have to be truncated. An expander might well be the solution there though.

[dhirschfeld]

There might also be something to learn/use from vscode:

i.e. an expandable json-tree view of Python objects might be nice

This can be done (very roughly) in JuypyterLab:

class Bar:
    def __init__(self, value):
        self.value = value

class Foo(object):
    def __init__(self, foo, bar=3):
        self.foo = foo
        self.bar = Bar(bar)
        self._baz = pd.datetime.now()

code

from IPython.display import display, JSON
from ipykernel.jsonutil import json_clean

def tojson(val):
    try:
        return json_clean(val)
    except ValueError as exc:
        return _repr_json(val)

def _repr_json(val):
    if not hasattr(val, '__dict__'):
        return repr(val)
    public =  {k: tojson(v) for k, v in val.__dict__.items() if k[0] != '_'}
    private = {k: tojson(v) for k, v in val.__dict__.items() if k[0] == '_'}
    if private:
        attrs = {'_': private, **public}
    else:
        attrs = public
    return attrs

def repr_json(val):
    json = _repr_json(val)
    name = f"{val.__class__.__name__}"
    display(JSON(json, metadata={'expanded': False, 'root': name}))

[thesimonho]

I think we'd need a different display method for each object type...

for scalars/strings/lists, I think the current content column is correct as it is useful for quickly seeing those values. Not showing the values for small collections (and instead requiring a double click to see those values) almost defeats the purpose of an inspector designed to show information at a glance

for things like classes or any deeply-nested structure like a dictionary, I like the vscode expandable tree display. In those cases its hard to predict what information someone might find valuable, so displaying as much as possible in an expandable tree allows for flexibility

I think dataframes are a special case. when working with a dataframe, you often dont need to see values at a glance - theres never going to be enough space to show a meaningful amount of actual data anyway, so no point trying.

so I think an expandable tree would be correct, but displaying the amount of information that vscode displays would be too much. specifically, I dont think we should be displaying values in the tree. something simple like single-clicking the dataframe to expand multiple rows, one for each dataframe column, that simply shows "column name: dtype" would be my vote. then double click to show dataframes contents/values in a new window

normally Id opt for a one size fits all approach, but in this case I think that might just end up creating either too much clutter or a frustrating/slow user experience

[nmichaud]

Chrome's debugger has a good UX for lists/arrays. It will chunk up rows of data into bigger groups (say 1000 rows) and let you drill into those individual chunks.

[dhirschfeld]

xref: #92