Design guidelines - Feedback

[Mohammer5]

@joeDHIS has sent me the current draft of the Design guidelines.
This issue is to dicuss the guidelines and give feedback.

Update:

Updated Guidelines

[Mohammer5]

Thank you @joeDHIS for writing the guidelines! It looks very good already and I like the examples given! It's def. the right step for having consistent styled across our apps. Hope we find a way to communicate this properly to everyone who's involved in FE dev. Here are some things that I'd like to add, but nothing major:

General

The guidelines sound like they're a description of what's possible, I'm missing a stronger, yet friendly tone, hinting (not explicitly stating) that the guidelines must be followed / scales must be used except when there are good reasons not to do so. Right now it sound a bit like "Btw, you can choose to use these guidelines if you want to" rather than "These are our DHIS2 guidelines that we're using to create consistency across our apps"

Typography

Hierarchy

I think it's important to add that - when using font sizes to indicate different hierarchy levels - the difference needs to be at least 4 pixels in continuous text, like paragraph headlines and paragraphs,
form headlines and form text descriptions, otherwise the difference will be too subtle.

Line height

The values proposed are very vague and will very likely be different for literally every text. I think we can be more strict here, i. e. we can use a line height of 1.625 for text smaller than 24 pixels and 1.3 for text with font size 24px or more. That would result in a line height of 26px for font size 16px, looks quite nice!
Here's an example of how that'd look like.

Spacing

Using spacing

The text says the example uses 16px and 32px, but the picture shows 8px and 32px.
I think if you added a second example that actually used 16px, it'd look nicer as 8px is very dense. Might be good to increase the font size of the headlines as well, will make it more readable, but I guess you chose the same font size to emphasize the spacing

Writing style

Although it's not technically part of the "Writing style" section, I think it's important to make sure the user is always aware of 1. whats happening and 2. will be given explanations in edge/special cases.

Knowing what's happening
By this I mean that the user should always know if there's some data being loaded so he won't press buttons multiple times or thinks that the app broke, i. e. by showing a loading spinner that prevents the user from interacting with the app.

Edge/special cases
On the data set report page of the reports app, when selecting a data set, the app will check if there are any dimensions connected to the data set. If yes, a select dropdown will be rendered so the user can choose to filter the report by dimensions. But many data sets don't have any connected dimensions, so IMO it's important to let the user know that 1. dimensions are being loaded when choosing a data set and 2. that there are no connected dimensions and it's not a bug when none have been found.

Typos

However, sometimes a more subtle contrast is required than the different between 20px and 24px.

should be difference

[ismay]

I like it, clear and well written! Two things that I was wondering:

1. I've mentioned this earlier on slack, but would it be possible for us to use a websafe font? As in, a font that can reasonably be expected to be present on most computers? In my opinion it has several advantages:
   1. Size: gzipped Roboto regular, italic, bold and bold italic are 370 kB, that's quite a lot for a device with a poor network connection. Especially for an asset that is not that crucial for the functioning of the application
   2. No bundling required, which simplifies app distribution for us
   3. No flash of unstyled text, or worse, flash of invisible text while the font is loading, which means there is no shifting layout or even unreadable content while the font is loading
2. The typographic scale and the spacing scale are sized in pixels. I've always found it useful to define those sizes relatively (with em or rem). For users with poor eyesight, who might have a different base-font size in their browser, our interface will then still look as intended. When using pixels for sizing it might break. This is a subject that has been discussed a lot over the last decade, but regardless of whether browsers handle this scenario properly or not, using these units fits better with what we're trying to do I think (scaling our interface elements relative to eachother).

[Mohammer5]

The typographic scale and the spacing scale are sized in pixels. I've always found it useful to define those sizes relatively (with em or rem).

I have very positive experiences with rem (and quite the opposite with em), it's one of the easiest methods to offer scaling font sizes by the user (like + and - buttons)

[ismay]

I have very positive experiences with rem (and quite the opposite with em)

Yeah, since em cascades it's mostly useful if you want to size something relative to the font-size of the parent. So a border for example, or padding, etc. In that case it can be very useful.

For a more direct replacement of how you'd use px, rem fits very well.

it's one of the easiest methods to offer scaling font sizes by the user (like + and - buttons)

Yeah exactly. Plus, if you base your media queries on em and not px, your layout won't break if the user has a non-standard font-size. So all in all a bit more flexible.

[cooper-joe]

I agree that using rem would be beneficial. The typographic scale is defined in pixels as that is how we are forced to work in design tools right now (annoyingly), but I would be fine with defining the scale as rem in the frontend library. In the final version of the guidelines we can include both px for screen design and rem for implementation.

[cooper-joe]

I've mentioned this earlier on slack, but would it be possible for us to use a websafe font? As in, a font that can reasonably be expected to be present on most computers?

Indeed, I have been running this thought over in my mind. I think potentially the solution could be to use the users system font. This has other advatages of DHIS2 looking like a 'native' application to them. This is potential positive for user experience and a potential negative for branding/identity. User experience is far more important, so I think this is worth discussing seriously. The use of Roboto came mostly from the implementation of Material UI (I think, I wasn't here then), although Roboto is a very well designed screen font. I don't think we have a ton of multi-platform users, so I don't think inconsistency between OS's would be a real issue.

In fact, Github is using the system font-stack, so we can test how it works right here, heh.

[cooper-joe]

And I wanted to make sure to say: thank you for the feedback on all points of the linked document, keep it coming if there's more! I may not respond to each individual point here, but on updating the document I will touch on each point raised. Thanks, much appreciated.

[ismay]

I agree that using rem would be beneficial. The typographic scale is defined in pixels as that is how we are forced to work in design tools right now (annoyingly), but I would be fine with defining the scale as rem in the frontend library. In the final version of the guidelines we can include both px for screen design and rem for implementation.

Nice 😊, sounds good!

Indeed, I have been running this thought over in my mind. I think potentially the solution could be to use the users system font. This has other advatages of DHIS2 looking like a 'native' application to them. This is potential positive for user experience and a potential negative for branding/identity. User experience is far more important, so I think this is worth discussing seriously. The use of Roboto came mostly from the implementation of Material UI (I think, I wasn't here then), although Roboto is a very well designed screen font. I don't think we have a ton of multi-platform users, so I don't think inconsistency between OS's would be a real issue.

Yes, I also suspect it's material ui that led us to roboto, and I agree, it looks nice. As you say, you do relinquish some control over the UI when relying on system fonts (or websafe fonts). I think that a proper font-stack could be quite consistent though, there are fonts that are present on almost all systems. It's just that you don't have as much choice, so I'd be interested in whether we could make this work with our designs.

Thanks for sharing your thoughts on this, nice to talk about these things! 👍

[cooper-joe]

Update

I've made some changes based on the feedback received. Here are the main changes:

The guidelines sound like they're a description of what's possible,
I'm missing a stronger, yet friendly tone, hinting (not explicitly
stating) that the guidelines must be followed / scales must be used
except when there are good reasons not to do so. Right now it sound a
bit like "Btw, you can choose to use these guidelines if you want to"
rather than "These are our DHIS2 guidelines that we're using to create
consistency across our apps"

I agree that the tone was too passive. I've changed wordings to some points, replacing 'Try to avoid...' with simply 'Avoid...'. I think this will help. I've also added a 'Using these guidelines' section which reiterates why using these docs is important.

I think it's important to add that - when using font sizes to
indicate different hierarchy levels - the difference needs to be at
least 4 pixels in continuous text, like paragraph headlines and
paragraphs,
form headlines and form text descriptions, otherwise the difference will be too subtle.

Agreed, this is important. The following has been added to the hierarchy section, and includes a visual example:

"Ensure that size differences in continuous text are clear enough if you are relying on size difference as the only way of communicating a relationship. (For example, the image above uses size, color, weight and position) 16px and 18px next to one another will not clearly communicate a relationship, so use a size on the scale that is at least 4px difference when the sizes are in close proximity and must communicate hierarchy."

Line height

The values proposed are very vague and will very likely be different
for literally every text. I think we can be more strict here, i. e. we
can use a line height of 1.625 for text smaller than 24 pixels and 1.3
for text with font size 24px or more. That would result in a line height of 26px for font size 16px, looks quite nice

Nice example! I am wary of setting strict rules, but I take your point that the guidelines are vague. Line-height is something that does usually need some manually tweaking to get it right, but perhaps I was too conservative. At least the suggestions you made are better than the defaults, so I think it would be worth going for that system.

I guess the situation I'm trying to avoid is where we must stick to the guidelines, even when they don't work. If I add some feedback to a project that says "I think we should change the line height to 1.4 here", I don't want there to be a uneasy conflict there with "...that's not what the docs say". But I think that can be avoided by still referring to them as defaults/guidelines, but that they can and perhaps should be checked by the ux/design responsible person.

Adding default rules here is on my to-do list.

Using spacing

The text says the example uses 16px and 32px, but the picture shows 8px and 32px.
I think if you added a second example that actually used 16px, it'd look nicer as 8px is very dense. Might be good to increase the font size of
the headlines as well, will make it more readable, but I guess you chose the same font size to emphasize the spacing'

Yeah I kept the font sizes the same to emphasize the role that spacing can play. I think there could possibly be a more appropriate example to show here that has more UI elements, so I'm going to keep this in mind. Also fixed the error in sizes, thanks.

Writing style

Although it's not technically part of the "Writing style" section, I
think it's important to make sure the user is always aware of 1. whats
happening and 2. will be given explanations in edge/special cases.

Knowing what's happening
By this I mean that the user should always know if there's some data
being loaded so he won't press buttons multiple times or thinks that the app broke, i. e. by showing a loading spinner that prevents the user
from interacting with the app.

Edge/special cases
On the data set report page of the reports app, when selecting a data
set, the app will check if there are any dimensions connected to the
data set. If yes, a select dropdown will be rendered so the user can
choose to filter the report by dimensions. But many data sets don't have any connected dimensions, so IMO it's important to let the user know
that 1. dimensions are being loaded when choosing a data set and 2. that there are no connected dimensions and it's not a bug when none have
been found.

Great suggestions.

Changed 'Writing style' to 'Communicating to the user'.

I've added a new 'Keeping the user informed' section here that covers these points and adds a visual example.

The typographic scale and the spacing scale are sized in pixels. I've always found it useful to define those sizes relatively (with em or rem). For users with poor eyesight, who might have a different base-font size in their browser, our interface will then still look as intended. When using pixels for sizing it might break. This is a subject that has been discussed a lot over the last decade, but regardless of whether browsers handle this scenario properly or not, using these units fits better with what we're trying to do I think (scaling our interface elements relative to eachother).

Added a note to say that the typographic scale should be implemented in rem , this can be taken further and set in the ui library itself.

The updated content can be found at the same link: https://www.notion.so/Design-Guidelines-ab78e28db1eb43ce84df31b4182dc7b6

[cooper-joe]

Hi all, I've started adding this content to my work in progress design-guide, which gives guideance on the general application design and individual components too. Has its own repo here: https://github.com/dhis2/design-system
Feedback very welcome!

[Mohammer5]

Very nice! You could think about adding the sketch files there as well.
https://sketchapphub.com/resource/git-sketch-plugin/

[varl]

I think this issue can be closed, there are no discussions to settle from what I can see. 👍