HeaderBar design and impelmentation

[Suzie97]

A headerbar is an important part of elementary OS apps. elementary OS doesn't recommend using menu bars which are used by most of the other photo editing applications.

Being limited to use a headerbar only, it gives us an advantage as well as a disadvantage at the same time.

Menu Bar Analysis

Menu bars can contain a lot of options which prove to be pretty helpful once the user has used the app enough and knows where each option is hidden. But this is also the problem with menu bars in my opinion. The poor discoverability. There is not much distinction between the options and the user has to rely on reading text for finding what he/she needs. This can be very tedious and unintuitive, when the user is just starting.

HeaderBar Design

Right now, I'm thinking about putting controls to hide and view the sidebars, like GNOME Builder, and the tools panel.

Also, I want the headerbar to display information about the document, provide controls to switch personas, control the zoom level, and provide a options to open a file, export and other similar things.

Prior Art

Affinity Photo

Pixelmator Pro

Adobe Photoshop

Akira

[Suzie97]

@abdallah-moh, @syfds, what are your thoughts?

Pixelmator Pro Merged with Akira

[syfds]

@Suzie97, I like the design you created in figma: minimal and clear. I'm personally not a fan of a header bar full of icons/shortcuts like implemented in Akira. For example I would move zoom widget to the bottom like in Photos. I find the approach in Inkscape with this left oriented toolbar quite intuitive:

@syfds I think having a bottom bar will take more space from the window I saved space in the design for the user to view the image freely
without having a small canvas to edit the Image

[Suzie97]

@Suzie97, I like the design you created in figma: minimal and clear. I'm personally not a fan of a header bar full of icons/shortcuts like implemented in Akira. For example I would move zoom widget to the bottom like in Photos. I find the approach in Inkscape with this left oriented toolbar quite intuitive:

We will also implement a left oriented toolbar, and as for the zoom button, I think having it in the headerbar makes more sense because the main goal is to give the content (image) full attention and make the interface almost invisible. So the less UI visible, the better. And for the other options that can be potentially included in a bottom bar, we will try to incorporate them in the sidebars.

And personally, I also like a nice and clean headerbar, but it is tempting to put more options at the headerbar like moving the layer to the top, smart search features etc.

I'll research and do some more revisions.

[Suzie97]

Sketch lets the user customize the toolbar, i.e. he/she can put whateever buttons he wants on it, other apps like affinity provide personas. Each persona adds and removes different buttons from the toolbar based on the workflow.

As @syfds said, some users might like a minimal headerbar with less buttons, while others might want all the shortcuts they can get on it. We can discuss on making the toolbar intuitively customizable.

I agree with this

[Suzie97]

@abdallah-moh do you have somewhat of an idea on how hard or easy the implementation of a customizable toolbar will be? Ideally, we would want to provide the functionality to just drag the buttons from a window to the headerbar like macOS apps and firefox.

First if the user removes something from the headerbar where will it appear

[Suzie97]

First if the user removes something from the headerbar where will it appear

see a video on customizing the toolbar on mac OS apps, we can do something like that

[Suzie97]

Sharing some videos on how to implement the customization of the headerbarThis is how the toolbar can be customized in macOS apps.

Pixelmator Pro

CustomizeTools.mp4

Prior Art in elementary OS

We can drag and drop apps from the applications menu to the dock, and drag an app icon out of the dock to remove it.

[hanaral]

The poor discoverability and 'takes up too much space' issue, imo, is completely ignoring the fact that all good implementations actually utilise modern paradigms like context based switching of context bound actions. Akira recently added this as an aim (by disabling/hiding out-of-use widgets), since it is necessary if we want an accessible and also visually appealing future. I think that the design and user experience from every level needs to be used to assess how a headerbar is used since at the end of the day, the app isn't just used from the headerbar, and it shouldn't be anyway.
Take a look at how Sketch on macOS has a limited number of buttons available based on what's selected:

Or Affinity Photo controls for live retouching

Versus selection refining