Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Listing Views Spec #16

Merged
merged 19 commits into from
Jan 11, 2022
Merged

Listing Views Spec #16

merged 19 commits into from
Jan 11, 2022

Conversation

ghislaineguerin
Copy link
Contributor

@ghislaineguerin ghislaineguerin commented Dec 20, 2021

Specs to implement the design for Support for listing database views

@ghislaineguerin ghislaineguerin marked this pull request as ready for review December 20, 2021 19:29
@ghislaineguerin ghislaineguerin requested a review from a team as a code owner December 20, 2021 19:29
@github-actions github-actions bot requested review from eito-fis, kgodey, mathemancer, pavish, seancolsen and silentninja and removed request for a team December 20, 2021 19:30
Copy link
Contributor

@seancolsen seancolsen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good. I have a few questions about Scenario 1 -- "Schema detail view"

  • What is the purpose of the "Schema detail view" page? Why do we need it?
  • How does the user navigate to this page?
  • What should the URL look like for this page?
  • What does "Last access" mean? The time I viewed it? The time anyone viewed it? The time someone modified it?

@seancolsen seancolsen removed their assignment Dec 21, 2021
@ghislaineguerin
Copy link
Contributor Author

@seancolsen thanks for the feedback.

What is the purpose of the "Schema detail view" page? Why do we need it?

At some point, as we've discussed in the issue for 'Listing Views' we'll have limits on how many views or tables we can show, and having an overview of the schema might be helpful for this.

How does the user navigate to this page?

The user can navigate to it by clicking on the top nav's schema name.

What should the URL look like for this page?

I'm assuming just database/schema without the selected object at the end. But now I'm wondering if the 'explorer' view allows a 'nothing selected' state and if that's a state that needs to be designed as well. I'll think about this and update.

What does "Last access" mean? The time I viewed it? The time anyone viewed it? The time someone modified it?

Last accessed was added in replacement for 'last updated' as we have no way of knowing that. Accessed would mean the object was opened in the explorer view.

@seancolsen
Copy link
Contributor

@ghislaineguerin Here are some thoughts based on your above clarifications:

  • I don't think we need the "Schema detail view" page. Can we wait to add that page until the need for it becomes stronger? Broadly speaking, I can see the usefulness of the "last accessed" field as a way to quickly find the objects I've been working with recently. But I think we could safely defer this feature until after Alpha. Would you agree?
  • If we do add that page, then:
    • You said:

      The user can navigate to it by clicking on the top nav's schema name.

      Currently clicking on the schema name will select the schema. So with your proposed functionality, the user would have no way to toggle between viewing separate schemas without first clicking through the "Schema detail view", correct? That seems like a (very minor) UX regression. Would the user have some other way to select a schema without navigating to the "Schema detail view" page?

    • You said:

      Accessed would mean the object was opened in the explorer view.

      I have more questions:

      • Is it the time that the current user last opened the object in the explorer view? Or the time that any user last opened the object in the explorer view?
      • @kgodey do we already have support for this "last accessed" functionality at the API level? I'm curious what events we're using (or would plan to use) at the API level to qualify as as "accessing" the object for this purpose. Maybe we would rely on a GET request to the records API? Or would the be a different mechanism? Perhaps a dedicated endpoint? I'm sure we'll have a more detailed conversation at implementation time, but for now I'm just trying to understand the meaning behind "last accessed", for the purpose of UX.

@ghislaineguerin
Copy link
Contributor Author

@seancolsen I've introduced the 'last accessed functionality based on this comment. The requirements specified 'last updated' which we couldn't determine.

Copy link
Contributor

@kgodey kgodey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ghislaineguerin Looks good! Please assign me again when it's ready for re-review.


- User opens a schema and sees the [schema explorer sidebar](#schema-explorer-sidebar).
- User sees a list of all tables and views for the current schema.
- The list shows both object types by default but can be filtered to only show tables or views using the [filter bar](#sidebar-filters) at the top of the sidebar.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if we might want to reuse the filter component (from tables/views) here rather than having tabs. That way, the user has the same experience for all filtering actions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think maybe the name filter is misleading. I'll update that to tabs instead. I'd be concerned about having multiple instances of filter and confusing users.

No differentiation has been introduced for materialized views, as we concluded that the functionality would be similar. A different icon was proposed, which can be added to the UI improvements design work.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mathemancer The product goals for the alpha release are to ensure that materialized views that are already present in a database are shown as such to the user. We will not have any other functionality for creating or working with materialized views from the UI.

I don't think it is worth spending much design effort into materialized views until we have better support for them in the product.

@kgodey kgodey removed their assignment Jan 4, 2022
Copy link
Contributor

@kgodey kgodey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ghislaineguerin Looks good, some minor changes requested.


### Schema Details Page

The schema details page will be shown when a schema is open and notables are selected. It will contain the schema's name, the total number of tables and views, and additional sections that we can use to present the user with relevant information or links. Examples of content that could go into this section are:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean "no tables" instead of "notables"? I was trying to figure out what a "notable" was. :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, that was it, I'll fix it. Thanks


The schema details page will be shown when a schema is open and notables are selected. It will contain the schema's name, the total number of tables and views, and additional sections that we can use to present the user with relevant information or links. Examples of content that could go into this section are:

- Recently opened views or tables
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a note here that these are examples and not meant to be part of the implementation of this spec.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If any of these are not examples and should be implemented (maybe recently opened?), please indicate those.


### Regular vs. Materialized Views

Regular views need to be differentiated from materialized views as the use cases might differ. However, we don't want to create a rigid distinction between both as it could confuse users being introduced to the concept of views. For this purpose, an indicator, such as the letter 'M' can be added next to the view icon to show that it is of the type 'Materialized'.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does "can be added" mean here? Should it be added or not?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kgodey I did add an indicator to the design. I believe it should be added, I will update the spec to remove the ambiguity.

@kgodey kgodey removed their assignment Jan 11, 2022
@kgodey kgodey added status: waiting A PR that needs follow-up work from its author after review and removed status: review In review labels Jan 11, 2022
Copy link
Contributor

@kgodey kgodey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good @ghislaineguerin!

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
status: waiting A PR that needs follow-up work from its author after review
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

7 participants