Brand and layout approach

[fcoveram]

Hey there folks 👋

I have been following Mathesar from time to time as it is an exciting project for what it aims for. It is truly appealing to build an open source project for non-technical users that care about data and their uses. It is challenging pulling in people that barely know about code.

As a product designer, I have some design comments I would like to share. High-level observations on the approach used for the brand and the layouts. I clustered my notes in two areas.

Brand

Colors

I like the Red 500 color as a brand color. The warmth and accent tone reaches a good balance with the cold shades of slate. Due to the prior, I do not see the need for having the sand variants.

When seeing the mockups, I think you can get rid of sand and instead use a slate version or plain white. You might need a secondary color to complement layouts and other actions, but the sand tone looks muted and opaque next to the red. It reminds me old times of Windows apps, especially in the table inspector panel.

Symbol

The elephant symbol has details that can be simplified. It has corners and angles that disappear in smaller sizes, making it difficult to use in other cases. A filled version would suit better over dark backgrounds.

Typography

Using the system font is a great choice for treating Mathesar as a product, but I wonder, and since the product lies heavily on back-end uses, if you might need a mono version. Code texts placed next to non-code texts look very different and might confuse users when looking similar. See how “Il1” and “0Ol” look like Il1 and 0Ol in monospaced version.

Layout

Onboarding flow

My first reaction when opening the Figma file was looking for onboarding mockups introducing the tool to see what Mathesar is about. I had to figure out the value proposition by reading toast messages and following the action labels instead of reaching layouts explaining themselves. Up to now, I am still not clear about the difference between Database and Schema and how they relate to each other.

Both pages are heavily text content and do not guide the eye through a clear goal. It is not evident to me what should I do and from where. Looking at challenging first-use cases, I went to GarageBand to see how they introduce the tool as music creators interact with many controllers. Here is what I found.

New from empty	New from a template	First view from empty

Thinking of non-expert users, I also like how Mailchimp treats the first-use context with a simple design. Their brand has a modern serif font that brings some warmth and elegance. Even when this product is different from Mathesar, the features for creating user databases have accurately designed layouts.

Since these concepts are difficult to get, I wonder if a layout that highlights the relationship between these terms might alleviate users’ understanding and look more appealing. A drag-and-drop interaction connecting storage boxes sounds interesting, although a11y challenging. Here is an example from a game creator app.

CleanShot.2022-10-11.at.11.11.22.mp4

In that same vein, it might be a good idea to have pre-filled or dummy databases and schemas to make the first use smoother by showing real-life examples. That will reduce the number of explanations like “…For example, you might have a schema for your personal finances, and another for your movie collection…” since the layout explains itself.

Spacing

Regarding spacings and the use of white, there is room for improvement in the pages and components. The empty space in sidebar and below the message is distributed unevenly, the information is condensed in some parts of the screen whereas the main action lies unnoted between the paragraphs.

Other areas look condensed and overloaded with information. More space between them and softer borders will make them easy to recognize and navigate.

Schema page	Table page

---

I hope this feedback sparkles some new ideas and conversations. I am happy to contribute and dedicate some hours to design and help with ongoing tasks.

✨

[kgodey]

Thanks @panchovm, this is all really helpful feedback.

When seeing the mockups, I think you can get rid of sand and instead use a slate version or plain white.

You might need a secondary color to complement layouts and other actions, but the sand tone looks muted and opaque next to the red.

We actually tried this earlier, but it made the table inspector much more difficult to scan and the page lost a lot of its warmth. Since the table page is so information-dense and the inspector has so many different options, we are relying on the additional color to make the options easily scannable, and we wanted it somewhat muted so that it doesn't distract the eye.

If you have other color suggestions, let us know!

I don't have anything to add to any of the other feedback, we will incorporate it in the current design work.

[fcoveram]

we are relying on the additional color to make the options easily scannable, and we wanted it somewhat muted so that it doesn't distract the eye.

I got your point. But in this case, adding colors to distinguish areas and making them scannable ends up being overloaded with shades. The sections are clear, but the shades make it hard to read.

I was exploring shifting the sand shades from backgrounds to borders while keeping the background white in the table editor. Here is a first outcome. Some content might be placed incorrectly, but my main goal was to reduce colors.

[kgodey]

@panchovm Your new design is close to what we had initially. Because there are so many options, it's difficult to identify text that is part of section headers vs. text that's part of a specific option. In addition, the table inspector is part of the table page, which is already white and also has a whole bunch of textual data – we want it to have a clear contrast.

We expect users to spend a bunch of time in the Mathesar table page looking at and performing actions on data. When it all looks visually similar, it's easy to get disoriented after a while.

[fcoveram]

I see your point, and I agree that the interface should ease its interaction by making each section straightforward. But the current design does not address that simplicity you indicate. The background levels and the text grid have multiple styles, and next to the central area of the table editor, it would have even more variations.

You are right that this sidebar should not compete with the page's central area as both look white, but the transitions enacted by interacting with the interface give users the context about where this area belongs to.

On the other hand, and for recurrent users, keeping actions reachable timely has more impact than making areas visually dissimilar; from the UX perspective. In that vein, guiding users through the interface to avoid disorientation and anticipate features is part of the onboarding stage.

Here is an example of how Notion designed the layout by showing and hiding actions and areas.

CleanShot.2022-10-17.at.17.38.01.mp4

The page is mostly white, but the visual relationships rely on the component states and transitions.

Google spreadsheet and Pages have a similar approach. Google adds a drop shadow, whereas Pages mirrors the app header's background color. I do not have Microsoft Excel to see how it works.

Google spreadsheet	Pages

In other products, some actions distinguish a feature by reinforcing it with icons and layout distribution. Here are some examples.

Google slides	Figma	InDesign

[kgodey]

@panchovm Some thoughts in no particular order:

• Your points about using component states and interactions more than purely visual cues makes sense.
• We're trying to get through one round of styling for all pages before we go back and make improvements. We are working with a very short timeline so we need to make some calls about what's "good enough". Since we've already created several pages using the components we have, I don't think it would be good to change those components until we are done with the first round of applying them to all pages.
  • If we do have time to do a second round of changes, then I think we can spend more time on the things you're suggesting.
• I've used some other tools like Google Sheets, Balsamiq, etc. which have a lot of controls and it's difficult to find what you're looking for unless there is some visual distinction.
  • As you pointed out, this doesn't have to be colors – it can be icons or arrangement of controls or whatever.
  • Numbers does a great job at this without too much color, Google Sheets does a bad job, I always have to read through a bunch of controls to find what I'm looking for, Balsamiq is somewhere in the middle.
  • However, for our goal of publishing a demo and first release of Mathesar, we don't have any user data on what features people will use more or less.
    • We are trying to make all our features really easily discoverable, even if it's "in your face"
    • We think we'll have more subtlety over time once we see how people use the product.

My main point is that although you're making very good points, I don't think our product is at the stage to be very subtle yet. I think we can use this kind of feedback better once we launch or we do a second round of styling (especially because we don't have the time to redo our components right now).

I hope this makes sense – I don't want to discourage feedback!