Frontend followup work on Database connections UI

[pavish]

As part of the DB Connections spec and #3294, we need the following:

• Modify database page route and bring it under connections:

  • Old: /db/<connection_name>/
  • New: /connections/<connection_id>/

• Use the term Database Connection wherever Database is used.

  • In multiple places in the app, we still use the term Database. Eg., the database page shows the connection nickname with a database icon and the term: Database. We need to look around the app and change this.
  • Note: This is only regarding the UI visible to the user. The terminology in code can be changed later.

• Resolve design items in this HackMD doc and implement the frontend work for them.

• If any of the above work is not strictly needed for 0.1.4, move them into a different backlog issue.

[seancolsen]

@pavish here are my responses to your design critique document:

• 1. Width of the Connections page is not restricted

  Yes, I share you opinion Pavish. I raised this same concern with @ghislaineguerin during design review. I would like the width the be constrained to a maximum page size which is centered within large viewports. Ghislaine wanted it to remain full width. I acquiesced, mostly for the sake of compromise, since I had raised so many other design concerns that Ghislaine had sided with.

  I also think this would be fine to re-evaluate in a later release to give ourselves more time to discuss it.

• 2. Re-evaluate table vs card

  I also had proposed using cards for the Connections page, mainly for the sake of UX consistency, design simplicity, and implementation simplicity (since we could re-use existing components to a greater extent).

  We should try to avoid tables wherever it’s not warranted since our application is table-heavy.

  I actually don't agree with this logic though. Personally, I don't like cards. I'd rather use tables everywhere. But I don't feel too strongly about it. I don't hate the cards — I just find tables easier to parse and scan. But this design aspect is quite subjective I think.

  Overall, I don't feel very strongly about tables vs cards on the Connections page.

• 3. Empty state message pattern is inconsistent

  Your suggestions seem good here, Pavish. These points are quite minor, so I think it would be appropriate to forge ahead with implementing your suggestions, if you haven't already. (I've not yet looked at your PR.)

• 4. Nomenclature is inconsistent

  and

  6. Define what the connections and database icons represent

  Ghislaine and I discussed this a bit too. The latest design (that you're working on implementing) admittedly puts Mathesar into a weird limbo state between the concept of a "Database" and the concept of a "Connection". Sometimes we say "Database". Sometimes we say "Connection". And sometimes we say "Database Connection". And yes, the icons are inconsistent.

  You suggested:

  Use the term ‘Database Connection’ in it’s entirety in all places.

  I don't it's necessarily that simple. For example, you've also proposed that we use "connections" in the URL routing. I think there are a lot of places throughout Mathesar that require small decisions about how to portray a database connection to the user. Our current design does a poor job of following a consentient pattern across all those decisions. Further, there is code that portrays these concepts to developers. It would be nice to eventually make that code consistent too.

  I think it would be nice to have a larger conversation about this on a call, potentially with the entire team.

  However, I'm not sure it's necessary to improve this nomenclature and icons before doing this release. These are things we can improve later I think.

• 5. Account for all access levels

  Your suggestions are good here, Pavish. As in 3., I encourage you to go forth with this implementation.

[pavish]

@seancolsen Your responses seem good to me.

I do think it's important to figure out the table vs card, and page width design issues, but I agree that we could defer them for later.

It looks like we may not require any of this for 0.1.4, so I think we can safely move this issue out of the release for later discussion & implementation. I'll leave that call to you.

[ghislaineguerin]

@pavish

• I agree with limiting the page width. I had some other layout modifications in mind, but I don't think they will work well with the design, as you've mentioned. I have updated the Figma file to reflect the limited width.
• I agree with Sean about preferring tables. My idea was to introduce sorting headers at some point, which is what I appreciate about tables for listing things. I prefer cards when we have additional functionality to sort them. In the future, I'd like to include additional columns, such as 'Last Updated', and arrange them in default order based on that.
• Regarding your other suggestions, I will ensure that the design specs consider all user access levels and will also review the existing nomenclature/messaging throughout the app.

[kgodey]

Meta comment: I discussed this with @pavish in a 1:1, but I think we need some sort of design checklist that outlines the things we need to consider for each design – e.g. what viewports we should be designing against, ensuring that we are considering all design levels, ensuring that we're following the same nomenclature and UI design patterns, etc.

@pavish maybe you could start one? I don't think it needs to be comprehensive, just something based on the issues that came up here, we can add to over time.

[pavish]

@kgodey Yes, it's on my list, I haven't started any work on it. I will send a mail once I have a draft.

[seancolsen]

It seems that the only thing we're stuck on now is the layout for the list of connections — @pavish prefers cards. @ghislaineguerin prefers a table. I don't really care. Do you think you two could hop on a call to try reaching an agreement?

[seancolsen]

We chatted about this briefly at our design call today and agreed that we'll keep the design as-is for v0.1.4 (table layout for connections and /db/<connection_id> for the URL). We'll still discuss these design points for a later release though.

[seancolsen]

I'm closing this in favor of the following more specific issues:

• Resolve confusing terminology and iconography throughout UI for database connections #3363
• Display connection details on database page #3362
• Re-think card display vs table display for several pages #3364
• Constrain the max width of the connections page content #3365
• Make connections page layout respond better to narrow viewports #3366