[WARNING big pictures]
Hello everyone,

today I want to come forth with what I have been working on for quite some time now (with breaks in between): A new/redesigned gallery application for using all the goodies from KDE technology. Originally this work started out as a redesign of Gwenview, but then evolved into something else, however, Gwenview gives a good glimpse at what we want: A bit more than a simple photo viewer and much less than Ocular.
These applications we're working on are also an exercise for us to find a good design language for KDE software, as such we probably have ideas in our mockups that will not make it into an application, but for that you are here anyway

Browsing

As stated in the layout guidelines we tried to enforce a strict separation between navigation and actions. The left side panel is used to navigate between different views and the right hand side only contains actions that are file dependant. This separation allows us to explore different navigation types while not having to change the overall work flow. This imagines gallery application employs tag based navigation, however, our separation of navigation and action allows us change it back to a file system based navigation type a la Gwenview

The left panel has several interesting options, by default the "Show All" is selected, which shows all pictures available, with or without tag. Then there's the "Not Tagged" option, which shows images which are not yet tagged, so that the user can start to sort them by tagging them.
By clicking on one of the pinned tags the view changes to display only the photos tagged with said tag. However, sometimes the user want to view not only one tag, but several at a time. That's what "filters" are for. They can be created by using the "create filter" option and consist of 2 or more tags. How this is done will be explained later.
A filter then only shows only the photos which are tagged with at least one of the tags the filter is made up of.
When these operations are performed more often the user may wish to have a persistent filter, akin to folders, that's why we allows to make filter operations persistent by pinning them. Instead of having to type the filter query every time it's only way click away.
The same effect could, of course, also be achieved by giving all the photos a new, unique tag, but we thought that we user might want to have this option anyway. Filters, however, are a bit more flexible as tags can always be added or removed which then in- or excludes pictures from the view.
Photos can be tagged by dragging them onto a pinned tag or filter, or using the tag editor on the right panel.
The tag editor show all the tags a photo possesses and allows to easily add and remove them. Currently this only works well visually for a single selected picture, however we want to come up with a good visual representation in future.

Editing filters and tags

This mockup shows the process of how the user creates and pins filters. The tag editor does work in the same way without the pinning. The process should be fairly self explanatory.


This mockup shows are existing filters can be edited.


And this mockup shows how removing one of the tags from the pinned filter affects the view. By removing tag 1 all pictures, that only posses tag 1 and none of the other tags within the filter, are hidden. Pictures that are tagged with tag 1, but also another tag within the filter won't be hidden.

Viewing and editing photos

This is mostly from the Gwenview redesign, though I didn't see a need to change it much. I just tried to clean it up a bit.
One thing I tried to make different is to use sliding in modal dialogues that appear on top of the right panel instead of opening a new, small window. I'm not sure how this will play out, though I liked to play with the idea a bit.

The .svg files can be found here (tar.xz) and here (.zip)

Thanks for your attention.

Thanks for sharing all of this (special thanks for sharing the svg's). I will look into this a bit deeper as soon as I have got more time. One thing I noticed: I would instantly miss the "Crop" and "Resize" actions from Gwenview. I think we should really reuse useful features of gwenview.

EDIT: Oh there seems to be an overlap between "Operations" and "Actions" I overlooked, nevermind.

Great work Sogatori! Lots of goodies in here to take advantage of for solving lots of design problems!

Wow, cool, cool, like it.

The separation between navigation and actions was great, also the tag method was nice. I think the tag method should be in every kde application the same, there is a discussion for tagging files in dolphin (viewtopic.php?f=285&t=122205).

The navigation works at the screen shots only for tagged files. when you look at digikam you have different navigation methods because people have different workflow. So you have a navigation through folders, tags, calendar, map, ... Folders, tags and calendar should be supported for navigation.

Is filters the same than search results? Maybe search would be also usable. Filters/Search results should not be only for tags. Maybe the date or the file extension would also be nice to search.

For the zoom in the status bar there is a thread (viewtopic.php?f=285&t=122662), because in the HIG status bars shouldn't be used.

Again nice mockups.

kdeuserk wrote:Thanks for sharing all of this (special thanks for sharing the svg's). I will look into this a bit deeper as soon as I have got more time. One thing I noticed: I would instantly miss the "Crop" and "Resize" actions from Gwenview. I think we should really reuse useful features of gwenview.

EDIT: Oh there seems to be an overlap between "Operations" and "Actions" I overlooked, nevermind.

It should not be corrected!

andreas_k wrote:Wow, cool, cool, like it.

The separation between navigation and actions was great, also the tag method was nice. I think the tag method should be in every kde application the same, there is a discussion for tagging files in dolphin (viewtopic.php?f=285&t=122205).

Oh yes, I remember that thread. Thanks for reminding me! I remember having drawn some inspiration from this thread. I think I should explain my reasoning there too. The main difference was that I was mostly tackling the problem of a tag based navigation, while the thread was about Dolphin a file manager. I'll be exiting to see if we can incorporate some of my idea into the proposal.

The navigation works at the screen shots only for tagged files. when you look at digikam you have different navigation methods because people have different workflow. So you have a navigation through folders, tags, calendar, map, ... Folders, tags and calendar should be supported for navigation.

Oh yes, absolutely. We discussed this in the VDG, too and settled for focusing on the tag based navigation first. Originally I also wanted to incorporate the calendar navigation/sorting too, but to be honest I realized that I'd have to incorporate another tab which would have required changing the mockups in lots of different places so I basically said "Oh, this can wait" . Sogatori, this beacon of work ethics in the VDG

Is filters the same than search results? Maybe search would be also usable. Filters/Search results should not be only for tags. Maybe the date or the file extension would also be nice to search.

Filter and Search is related, but not the same thing. A filter basically only shows and hides different items of a list, without modifying it. Search, however, well … searched in lots of different directories to create a list with results. But you are right, the search should not be focused on tags. For the search function I'm eyeing the human query parser in baloo.

The tag based navigation gets fed a list of photographs from an external source, in our case probably baloo, once. For the user the photos will all be handled the same, there are no folders or directories to memories. So they will never have to navigate through directories with lots of other files to a certain location to open a picture, but filter the list presented to them. Of course the infamous "Open with" dialogue can hide all file types but a few selected ones, however there'd still be the navigating though directories aspect. They will just be confronted with a list of all the photos baloo could find. This can be an advantage or an disadvantage, that's why it's wise to offer the option to change the navigation method.

For the zoom in the status bar there is a thread (viewtopic.php?f=285&t=122662), because in the HIG status bars shouldn't be used.

Oh, I wasn't even aware of that. I should chime in, I guess.

Thanks for your kind words

Sogatori, one minor thing I noticed so far: Why do you use two different versions of blue? The zoom slider on the bottom appears in a darker blue due to opacity, I would recommend setting it to 100. The selection in the main view, has also a similar dark blue (this time not due to opacity). I would prefer consistent use of the bright blue.

kdeuserk wrote:Sogatori, one minor thing I noticed so far: Why do you use two different versions of blue? The zoom slider on the bottom appears in a darker blue due to opacity, I would recommend setting it to 100. The selection in the main view, has also a similar dark blue (this time not due to opacity). I would prefer consistent use of the bright blue.

Originally I thought that the blue is too bright, so I turned it down a little. But you are right, it should be consistent. I'll revert it tomorrow

Let me add my two cents sogatori. Would you consider using the bottom area of the application for extra controls? Like this

https://www.evernote.com/shard/s10/sh/cf76f32c-180b-4124-b7e9-0188879bdca2/b4fab7e77926d78772de53b774f41b8f/deep/0/c9sAVb6.png

I have come to find a certain elegance in making footer menus that display the controls below. I have seen a few apps on mobile that do this and other applications adopting the method. I have come to like it a lot.

At the first view it looks complex, but at the second tomorrow morning the mockups are mature and well done. great work.

For the navigation I missed a group, view and sort icon. the panel looks confused because the header is Navigation and than there are subheader. maybe when you can reduce to only one header style for every group, it looks more straigt. also this group header should look like the same in every kde application.

A filter bar like you know it from dolphin (Strg+i) would be nice or a search in the filter.

anditosan wrote:Let me add my two cents sogatori. Would you consider using the bottom area of the application for extra controls? Like this

https://www.evernote.com/shard/s10/sh/cf76f32c-180b-4124-b7e9-0188879bdca2/b4fab7e77926d78772de53b774f41b8f/deep/0/c9sAVb6.png

I have come to find a certain elegance in making footer menus that display the controls below. I have seen a few apps on mobile that do this and other applications adopting the method. I have come to like it a lot.

I think that would depend on the controls one would want to put there. Generally I tried to preserve vertical space, but if it makes sense I don't see why we can't put controls there.

andreas_k wrote:For the navigation I missed a group, view and sort icon. the panel looks confused because the header is Navigation and than there are subheader. maybe when you can reduce to only one header style for every group, it looks more straigt. also this group header should look like the same in every kde application

Hmm, for the header I followed the typography guidelines, so I hope I did the right thing here. It this changes I'll change the header.
I agree with you that the subheaders are not ideal. However, I wanted to have a description for what this panel does. I'm not sure I want this any more. Maybe I'll remove the big header but leave the subheaders intact.
I'll talk to Andrew about it, seeing that he wrote the guidelines, but maybe some of the guideline people can enlighten us? Heiko, Colomar?

A filter bar like you know it from dolphin (Strg+i) would be nice or a search in the filter.

That's definitely on the todo list

anditosan wrote:Let me add my two cents sogatori. Would you consider using the bottom area of the application for extra controls? Like this

https://www.evernote.com/shard/s10/sh/cf76f32c-180b-4124-b7e9-0188879bdca2/b4fab7e77926d78772de53b774f41b8f/deep/0/c9sAVb6.png

I have come to find a certain elegance in making footer menus that display the controls below. I have seen a few apps on mobile that do this and other applications adopting the method. I have come to like it a lot.

The problem I see with this is that it muddies the distinction between status bar and toolbar. That is why we have discouraged putting controls in status bars in the HIG If some applications put controls at the bottom but others don't users cannot know where to expect controls and where not to.
If we want secondary toolbars at the bottom, we have to define very clearly where they are used and use them consistently across applications, so users can form expectations about them.

colomar wrote:

anditosan wrote:Let me add my two cents sogatori. Would you consider using the bottom area of the application for extra controls? Like this

https://www.evernote.com/shard/s10/sh/cf76f32c-180b-4124-b7e9-0188879bdca2/b4fab7e77926d78772de53b774f41b8f/deep/0/c9sAVb6.png

I have come to find a certain elegance in making footer menus that display the controls below. I have seen a few apps on mobile that do this and other applications adopting the method. I have come to like it a lot.

The problem I see with this is that it muddies the distinction between status bar and toolbar. That is why we have discouraged putting controls in status bars in the HIG If some applications put controls at the bottom but others don't users cannot know where to expect controls and where not to.
If we want secondary toolbars at the bottom, we have to define very clearly where they are used and use them consistently across applications, so users can form expectations about them.

I tend to agree on this. Let's really try to apply our new layout guidelines and other HIG guidelines as we work on this. Great contributions so far!

I like it very much

EraX wrote:I like it very much

Me to.

I was thinking about the navigation sidebar. For me your system would work well. As you upload the svg files I can make some tests. One thing I don't like at the navigation bar, when you make a new filter, you search for tags and if you don't find the tag you can make a new one. Maybe it would be a nice feature, I don't know, but you write that you want to separate the navigation area from the operation part.

In the above mockup I include the count and for the header I made a edit and + - button. The Idea is, that with + - you can change how many list items are shown (nothing, favorite or all) and with the edit you can edit the section (sorted by count, name, standard view show all tags, ... ) The edit icon is from darktable.

with the + - you can also integrate the folder and date navigation without tabs.

Hey, I just wanted to give you heads up, I'm in the process of moving to another town, so don't worry if it takes some time for me to reply?

andreas_k wrote:I was thinking about the navigation sidebar. For me your system would work well. As you upload the svg files I can make some tests. One thing I don't like at the navigation bar, when you make a new filter, you search for tags and if you don't find the tag you can make a new one. Maybe it would be a nice feature, I don't know, but you write that you want to separate the navigation area from the operation part.

Yes, Colomar had the same concerns. It was just an example by me, but I seriously consider to not allow that The way the tagging UI is working out it should also work with several icons selected.

In the above mockup I include the count and for the header I made a edit and + - button. The Idea is, that with + - you can change how many list items are shown (nothing, favorite or all) and with the edit you can edit the section (sorted by count, name, standard view show all tags, ... ) The edit icon is from darktable.

with the + - you can also integrate the folder and date navigation without tabs.

I like the idea, however, I'd avoid to use the same icons for every entry. Maybe we could add an item on top of the side panel, that toggles an "edit mode". I don't expect users to make fundamental changes to the panels often, so I don't think we do have to show these icons all the time.

Another thing: I see you have duplicated the "Search Tag" button. That shows that there's a problem with my organisation! My idea was that if one composes a filter and only adds one tag to it, then proceeds to tag it it would then only pin it it to "pinned tags" and not "filters". Though I can see that this is not the most transparent process. I guess I have to think of something else.

I'm not sure if we want to mix a file system based navigation approach and a tag based one without tabs, as they are somewhat excluding each other. With a tag base approach folders have little use, because the file system is abstracted away, and in a file system based approach tags are only useful as additional search criteria.