search

borgbase / vorta

Desktop Backup Client for Borg Backup
https://vorta.borgbase.com
GNU General Public License v3.0
1.98k stars 132 forks source link

Follow an official Human Interface Guideline HIG #1050

Open bastiencyr opened 3 years ago

bastiencyr commented 3 years ago

EDIT: After some discussions (see bellow), this is a non complete list of tasks to do. It is inspired from official design guidelines. There is a short design guideline below for vorta. It is also inspired from Gnome, Apple and KDE design guidelines: https://develop.kde.org/hig/introduction/ https://developer.gnome.org/hig/stable/principles.html https://developer.apple.com/design/human-interface-guidelines/macos/app-architecture/onboarding/

You can read one of them (or all), Gnome guideline is very well done.

Feel free to do one of these tasks :

This is some rules to follow from official guidelines of Aqua (Apple), Gnome and KDE.

Philosophy

Gnome, Aqua and KDE are probably the most famous desktop environments in the Unix World.

The guidelines from Gnome, Apple and KDE have different philosophies. Gnome philosophy is to keep the UI as simple as possible : "Resist the pull to try and make an app that suits all people in all situations. Focus on one situation, one type of experience.[...] Respect people’s time and attention. Don’t interrupt or distract them unnecessarily." . I like this philosophy to not distract the user for example with useless and slow animations like in the well-known Material Design. And I do agree with the fact that we can't make our app suits all people in all situations. That's why Vorta will never be as flexible as Borg.

But, simplicity is not always a good way. The KDE UI design slogan is "Simple by default, powerful when needed." For KDE, it's important to "Provide sensible defaults but consider optional functionality and customization options that don't interfere with the primary task.". We want to keep Vorta simple for 90% of users but powerful for the 10% advanced users. Hiding the advanced settings is a good way to achieve this.

Writing Text

A text (label, help...) must be as short as possible. Think that some translations will expand your text by 30-50%. You should be short but clear. If you cannot be clear in a label, find another solution (a help button for example). Do not use contraction like "Don't" or "Can't". One reason is that contraction really optimize the length of a text in english. But in other language it is not possible to do this optimization ("Can't delete..." -> "Impossible de supprimer...").

Sentences should not be constructed from text in several controls. Sentences that run from one control to another will often not make sense when translated into other languages. For example, "No matter what, keep all archives of the last 10 hours" should be translate by "Quoi qu'il arrive, garder les archives des 10 dernières heures" but it is impossible since "10" is in control fix widget.

Sentence and header capitalization rules

Sentence and header capitalization rule must be consider each time you write some text. Sentence capitalization rule : Cannot add this profile, Open main window on startup... Header capitalization rule : Remove Profile , Add a File, Allowed Networks... Don't add a dot at the end.

You must use header capitalization rule for short text (less than 4 words). You must use sentence capitalization rule for sentence (only one sentence, less than 10 words).

In Label

Text in tooltip must be short (not more than 5 or 6 words for tooltips and 3 words for label). Follow the header capitalization rule. For example, "Remove a File" and not "Remove a file."
Never put a sentence in a label.

In Tooltip

Follow the header capitalization rule if the tooltip contains less than 4 words and sentence capitalization rule either. A tooltip must be short and contains at most one sentence.

In checkbox

//Not sure about this.// For sentences, follow the sentence capitalization rule. For example : "Automatically start Vorta at login" . We don't add a dot at the end. Only add a dot for "real text".

Typography

Apple typo is not the same that KDE. Keep the default one in qt designer : https://develop.kde.org/hig/style/typography/ Body : 10 Header 4: 11px Header 3: 12px Header 2: 13px

Unless you have a good reason, you don't need header 2.

Colon

KDE and Apple use colon both. A colon must be stuck to the previous word. "Label: " and not "Label : " Use colon before a control widget. "Profile Name: [QLineEdit]".

If a tab contains a lot of checkboxes, you can add a label. For example : System:

Backup:

Note : On Apple, it's not the real way to aggregate checkboxes. I did a mix between Gnome and Apple design. Notice that font Label is ten too. 'Backup' and 'System' are in Bold.

Three dot vs ellipsis

To quote the HIG of KDE :

Ellipses are used to indicate that a button or menu item will perform an action that always requires additional user input before completing. Use the ellipsis Unicode character, not three dot characters, to let screen readers describe it appropriately.

In python this is how you can use ellipsis:

s_bad = "Find..." # Don't do this
s_good = "Find\u2026" # Do this

Look and Feel

Edit a view

To add an item to a view, use a gradient button : Gradient buttons . Since qt doesn't have built-in gradient button (AFAIK), it's difficult to do so. I will try to implement this and document here.

Icons

For Icons, we use Fontawaesome. Notice that icons are simple and flat. When use an icon ? For Control widget (buttons, tabs...). But don't use icons for difficult notions such as Archives. Some icons are familiar to the user (folder, file, paste, copy...). Don't use icon and text in the same control widget but there are some exceptions (sidebar, tab views...).

Spatial organization

According your need, you can use space or sub-space : Spaces : 12 Sub-spaces : 9

For example, you must use a space (12) between the left side tabs (Repository, Source, Schedule, Archives) and what they contain (on the right).

Widgets

Tabs

Tab is used to navigate between views. The title of a tab must be short and clear and follow the header capitalization rule. Write "Clock" and do not write "clock". Write "Prunes" and do not write "Prunes and Archive Name". It's too long.

A tab view contains between 2 and 6 tabs. If you want to add more tabs, find another solutions.

Text

If label or tooltips are not enough, you can use a full text area. But you must also be clear and brief. If you want to add more informations, you can add link to Vorta or Borg site. Don't abuse link since a link can be dead.

Hello,

I started to read some guidelines and docs from official design guidelines 💪 . In my opinion, vorta UI lacked consistency and didn't look modern but I couldn't say why. So after some researches, I discovered Flat and Material design. Flat design is everywhere but I didn't realize and because I have always seen this theme (I'm rather 'young' 😅 ), vorta UI interface seems really old to me.

Consistency is another notion and design guidelines are very helpful for that. If we want to make an interface that looks native, user should find the elements in the same place and in the same way. For example, vorta doesnt follow everytime the header capitalization ( Gnome , Apple ). "One folder or file per line" should be "One Folder or File per Line" or "Can't delete the last profile." should be "Can't Delete the Last Profile".

Since vorta users come from Apple, Gnome or KDE, it's more complicated. But lets be honest, all UI interfaces and guidelines converge towards the same ideas 😝 and looks the same !

So, my proposition is to follow KDE, Gnome and/or Apple guidelines as guide and to follow flat design. Note that Apple, Gnome and KDE have officially chosen the flat design ( see Whats new in macOS11 and compare macOS10 and 11 to be convinced) .

This is the three guidelines ❤️ : https://develop.kde.org/hig/introduction/ https://developer.gnome.org/hig/stable/principles.html https://developer.apple.com/design/human-interface-guidelines/macos/app-architecture/onboarding/

There are many common points between these guidelines.

Thanks for reading 🥰

m3nu commented 3 years ago

Do you have some concrete examples that could be changed to follow such guidelines?

bastiencyr commented 3 years ago

Do you have some concrete examples that could be changed to follow such guidelines?

I don't read the whole guidelines but this is some changes : For text :

Visual changes :

All this exemples are inspiring from Gnome and Apple guidelines. For a Flat look, you can see my last PR in #1008 .

All this changes has interests for users. Its not just stupid rules and Vorta will look like native app.

m3nu commented 3 years ago

Those are all good points and even without reading the guidelines I see how they are good for consistency.

How about starting small and going larger over time:

  1. You share a high level list of changes required. E.g. "Capitalize headers" here as checklist
  2. Then you, me and others wanting to contribute can do small PRs to fix one item at a time. This will be better than one large PR.
  3. When all the small items are cleaned up, we proceed to #1008, which has the biggest changes.

I prefer smaller changes because they are easy to review, revert and smaller tasks can be done by new contributors as well. We also have many translations attached to our text strings. If you change one, they all need to review their translations.

bastiencyr commented 3 years ago

If you change one, they all need to review their translations.

I do agree. We cant do that in just one PR, it will break every translation.

Then you, me and others wanting to contribute can do small PRs to fix one item at a time

I can do small changes but I cannot reformulate too long sentences since I'm not english native :( . But I speek fluent the DeepL translate hhh

When all the small items are cleaned up, we proceed to UI Improvements #1008, which has the biggest changes.

Why ? #1008 just changes the interface, not the text.

m3nu commented 3 years ago

Why ? #1008 just changes the interface, not the text.

True. Then just add it to the list as part of the interface work, so it's in context. No need to wait for text changes.

bastiencyr commented 3 years ago

Fine, I added a list in my first comment. I think we can add the label "Good first issue". I will try to complete this list and quote a design guideline for each item.

bastiencyr commented 3 years ago

I also started a documentation about design UI vorta. It's just a compilation of non obvious ideas from several guidelines. Sometimes, I take some liberties but you can give your opinion if you don't agree. If a commit change the UI, it's good to check this.

real-yfprojects commented 2 years ago

Put font 10 in profile add window.

I think this can be ticked since the text uses the html body tag which will automatically assign the right size (defined by the user/desktop environment).

real-yfprojects commented 2 years ago

In source tab, add gradients bottoms '+/-' at bottom of the view.

This is how KDE implements gradient buttons in Qt: https://develop.kde.org/hig/components/editing/list/#picker-1

In the example with the language list view they use an Add Language button that is the equivalent to vorta's Add File or Add Folder buttons.

real-yfprojects commented 2 years ago

The KDE HIG states regarding checkbox labels:

use affirmative phrases rather than use negative phrases

This is not the case here (for example): https://github.com/borgbase/vorta/blob/23c47673c009bdef8baebb0b9cdf5e78c07fe373/src/vorta/assets/UI/scheduletab.ui#L364

real-yfprojects commented 2 years ago

KDE HIG:

A placeholder with an example is not a replacement for a label, but should give the user only an additional hint about what kind of data is expected.

This is not the case in Scheduletab>shell commands.

torwag commented 2 years ago

May I ask/add why there is no (as common) context menu for the "Source" and the "Archives" tables? Source has buttons on the right, which is still easy to understand. However, in archives, you get some buttons below, and even this is split in a drop-down menu "Selected Archive" and three separate buttons.

This is particular difficult to get if you use displays in portrait orientation and a tiling window manager, as those buttons are really down at the bottom of an otherwise almost empty list. ;)

I also believe that the sub-menus are easier to get, if they would be located in a left-side window-pane as tree-view, as it can be found in many programs when it comes to configuration and settings.

real-yfprojects commented 2 years ago

The KDE HIG states:

Don’t use context menus as the only way to access functionality. Every item in a context menu must be available via a method that is somehow visible by default

Provide a context menu for any item with actions that can be performed on it.

So context menus should definitely be added to vorta's item views.

MarjaE2 commented 1 year ago

Are there accessible versions of any of the linked guidelines pages? All 3 have very wide non-scrolling sidebars, so all 3 trigger migraines.

real-yfprojects commented 1 year ago

Are there accessible versions of any of the linked guidelines pages? All 3 have very wide non-scrolling sidebars, so all 3 trigger migraines.

I guess not.