Viewing Views

[ghislaineguerin]

The design for issue #466 is ready for review. Please follow the Review Guidelines and make sure to review before the set deadline expires.

Document

https://wiki.mathesar.org/en/design/specs/viewing-views-specs

Reviewers

@kgodey @pavish @mathemancer Your review is required.
Feedback from the community is also welcome. Contributors can find more context about Mathesar's design strategy here.

Deadline

The deadline for submitting feedback is set 2 days from now, on Wednesday 8.

[kgodey]

@ghislaineguerin There is no prototype linked.

[ghislaineguerin]

@kgodey Just fixed this, I will add an additional day for the review.

[kgodey]

@ghislaineguerin Looks good! Feedback:

(1) I like the colors for indicating the different tables that a column comes from. :)

(2) I think "referenced entities" may not be very accessible. I think we should try and find a simpler label for that. I do like the functionality.

(3) I'm not sure what "Referenced Column Options" is. Is it an option to completely change the column that's at the position? I'm not sure if it's necessary.

(4) Should we have an option to reorder columns (e.g. using drag and drop)? We can do this for views (but it's not recommended for tables).

(5) I'm wondering if we can consolidate the "Save" and "Save as New" buttons somehow so that they don't take up as much space.

[mathemancer]

(4) Should we have an option to reorder columns (e.g. using drag and drop)? We can do this for views (but it's not recommended for tables).

If we want to do that, it will involve creating a new view at the DB level. This is do-able, but we should figure out whether we want to represent that (i.e., that reordering creates a new view, and both could be saved under different names if desired). Letting the user save those as different views would also make it so that they don't end up repetitively creating the same views over and over if they reorder the columns between a couple of options.

(5) I'm wondering if we can consolidate the "Save" and "Save as New" buttons somehow so that they don't take up as much space.

Seconded.

[ghislaineguerin]

@kgodey Thanks for the feedback

(2) I think "referenced entities" may not be very accessible. I think we should try and find a simpler label for that. I do like the functionality.

Could we call it "Relationships"? I think that word is the one that conveys the most meaning, a lot better than references.

(3) I'm not sure what "Referenced Column Options" is. Is it an option to completely change the column that's at the position? I'm not sure if it's necessary.

They can just remove and add another column then? I was thinking since we don't have column reorder they might use this to replace a column, but reorder might be better. I will remove this.

(4) Should we have an option to reorder columns (e.g. using drag and drop)? We can do this for views (but it's not recommended for tables).

I think this is necessary, yes.

(5) I'm wondering if we can consolidate the "Save" and "Save as New" buttons somehow so that they don't take up as much space.

Save could have a menu icon with another save option. I will try some options.

[kgodey]

Could we call it "Relationships"? I think that word is the one that conveys the most meaning, a lot better than references.

That works.

They can just remove and add another column then? I was thinking since we don't have column reorder they might use this to replace a column, but reorder might be better. I will remove this.

I think reorder would be better. Perhaps we can allow them to drag and drop columns to reorder them (for an easy/intuitive experience)

[ghislaineguerin]

@kgodey Save button, column order, and 'Relationships' dialog have been updated in #653

[kgodey]

@ghislaineguerin Should we mark this discussion as "done" and move feedback there?

[mathemancer]

Overall, I think this looks great.

I think the hierarchical way that you've shown the things referenced by the view in the "referenced entities" UI is quite intuitive. W.r.t. the "referenced entities" terminology, I agree with @kgodey that this might confuse some users. Unfortunately, the "proper" term for the type of entities referenced in a view would be "relations", giving "referenced relations". I don't think that would be much better, but I don't have a better name for the general class of objects that can be referenced by a view. Given the way it's portrayed, you might be able to just use "referenced columns", and portray the type of relation the column resides in via the icon next to that part of the UI (let me know if this isn't clear; I can elaborate).

For "save" vs. "save as new", to reiterate my response to one of @kgodey 's comments, there isn't really a "save" at the DB level; it'll always be "save as new". So, if the user filters, then saves the result, we'd need to replace the current view with a given name with an entirely new one of the same name (and then propagate that simulated "save" through the service models). This is possible, but it makes me wonder if we should try to portray more of what's going on to the user so they aren't surprised somehow. For example, the view will get a new OID each time it's "saved", which may throw off some script they're using that references an OID.

[kgodey]

This is possible, but it makes me wonder if we should try to portray more of what's going on to the user so they aren't surprised somehow. For example, the view will get a new OID each time it's "saved", which may throw off some script they're using that references an OID.

For non-technical users, I think we need to have very simple actions for "replace this view with an updated version" (currently "Save") or "keep this view as it previously was but create a new view with the changes I'm currently looking at" (currently "Save as New"). We need to maintain this simplicity if we change how things work; if we cannot, I think it's fine to keep the "Save" and "Save as New", especially since we do not expose the OID via API or UI. It would be ideal if we could keep things simple and expose more of the underlying internals, of course, but I'd prioritize simplicity.

[pavish]

@kgodey @mathemancer I understand the OID will change when we update a view (i.e replace it), but I assume/expect the id we have in our mathesar tables remains the same. Is this assumption valid?

[mathemancer]

That's correct. With the OID comment, I'm just thinking of users who may access the same DB through clients other than Mathesar. I can't think of any way it would be a problem for users who only use the Mathesar API (including the front end).

[pavish]

@ghislaineguerin This looks pretty good to me! Kriti and Brent have covered the naming terminology factors. I have no further comments. :)

[kgodey]

Based on the new action plan from the 2021-10-15 meeting, we're going to update the design requirements for issues in this milestone, including this one.