Image preview improvements

[dyskette]

After seeing issue #972, I remembered a mockup for the image viewer I did a few months ago but never shared.

Here it is.

• Navigation buttons (previous image, next image) are intuitive and more prominent.
• All save actions are separated from navigation, and placed together.
• Removed "... and close" buttons, eliminating redundancy. We already have a close button in the window, also fix bug of 2 "close" buttons inside the window when image is already saved.
• Details are ready in the window.
• Links are less cluttered.

Also, maybe we could use the word "Dimension", "Resolution" or just "Width x Height" instead of "Size" in the details, but I'm not sure.

As for the main UI, is more complicated, but I think there are so many little things that could be improved. E.g. The navigation buttons don't show intention of navigation by their location in the window and by being so far apart. Or the download list selection of cells instead of rows, lack of drag and drop to reorganize the list, to remove "Move down" and "Move up" buttons. Etcetera.

[Bionus]

Indeed, it definitely looks good! I will definitely use it as inspiration for changing the image viewer window. 👍

Just two remarks:

• Isn't a big part of the good looking result the flat button design and the font? Two things I'm not really willing to do in the program to stay coherent with both the OS and the rest of the UI.
• Isn't it harder to read tags when put horizontally? (instead of the current booru-like vertical way) Maybe both could be mixed with a 3-column design? (image, details, vertical tags)

[dyskette]

I was following closely how KDE's Dolphin (file manager) looks. Buttons without relief, "Breeze" theme and icons. Fonts were Roboto and Cantarell, but those should be irrelevant. The image was all about the organization of the window.

Tags: I think so too, horizontally is not optimal for reading something which is supposed to be a list.

Here is a more conservative approach:

• Buttons with relief.
• Tags vertically on the left, resembling an imageboard post. If there are more tags, it should scroll.
• Do not show details, just a button. The titlebar already provides some basic info like size.

P.S. Other mockups: Search, Favorites and Downloads.

[Bionus]

I was following closely how KDE's Dolphin (file manager) looks. Buttons without relief, "Breeze" theme and icons. Fonts were Roboto and Cantarell, but those should be irrelevant. The image was all about the organization of the window.

Yes it wasn't a reproach or anything it's just a risk when changing multiple things at the same time ^^

Tags: I think so too, horizontally is not optimal for reading something which is supposed to be a list.

Here is a more conservative approach:

Still looks quite good. I even think that the details button doesn't even need to open a new window and could open a pane like in the first mockup.

P.S. Other mockups: Search, Favorites and Downloads.

Those look good too!

Just a few remarks:

• Is there any difference between the normal search tabs and the favorites tabs with this design?
• Some users will be very against moving the "Merge" button to the "+" area
• In the download tab, I believe the disappearance of the "Move" buttons means it's drag and drop? I'm not sure rows can be drag and drop with cells still being editable, so I'll take a look.

I have felt that the single image view has needed a UI overhaul so I really appreciate your designs on this, regardless of whether Bionus sees fit to implement. I really like that new one as well! If I knew the QT classes, I would attempt to create a style for it.

Since you already have Qt installed you must have Qt Designer too. It's totally WYSIWYG if you want to give it a try :smile:

As for the styles themselves, you can't move items around using Qt CSS, but all classes are in Qt doc for other types of customization. And if you want to style a widget in particular, you can identify it with their CSS ID which is the same as their "objectName" in Qt Designer.

[dyskette]

Yes it wasn't a reproach or anything it's just a risk when changing multiple things at the same time ^^

I understand really, it was just a clarification. Maybe I should use some emoticons too. 😄

Is there any difference between the normal search tabs and the favorites tabs with this design?

Search would behave just like it does now.

Favorites would resemble search, but still behaves very similar to what it does now. This is what I was thinking:

a) Showing a sidebar in the same place as search would use the familiarity with the search tab and try to not introduce so many different behaviours. b) The searchbar (or tagbar?) and "Plus" button would be disabled, but the searchbar would still show what tags is following the selected favorite. c) There is a button to add a favorite, which would bring a window dialog. d) Editing a favorite would bring the same dialog but populated. e) When adding a new favorite it would show not viewed for a week prior. This would eliminate the need to edit the favorite just after adding it.

Some users will be very against moving the "Merge" button to the "+" area

Mmmh, well, that could be an issue. As I see it, "merging" is in the same context as configuring post-filtering. Both still need to press "OK" after changing them as well. And the mockup tries to group them together because those are "connected" actions, one after the other. This way it should be telling the user "Hey, you still need to press OK", and OK is the last action performed all the time in there. That's why "Sources" is also up there.

If it were an immediate action, i.e. at the moment the checkbox is active the view content changes. I would've put it together with pagination at the bottom, because pagination is immediate, it doesn't require confirmation.

In the download tab, I believe the disappearance of the "Move" buttons means it's drag and drop? I'm not sure rows can be drag and drop with cells still being editable, so I'll take a look.

Here, I'm still not sure either about what should be. (°-°;)?

I was thinking that a context menu with "Edit" and "Delete" items maybe would be more fitting. If more than 1 row were selected, the context menu would show the "Edit" item in a disabled state. The "Edit" item would bring up the same dialog as "Add (group or image)" but populated.

[MasterPetrik]

I missed a few days and you guys already gonna change whole interface,O_o

First of all, I'm standing mostly on the side of old interface, but some suggestions looks interesting. And of course I have some arguments.

Main thing: bad place for Buttons bar area

Buttons bar shouldn't be placed at the top of the preview window, it's VERY bad idea. Buttons bar at the top of the window is normal for the file managers and for almost all windows which works with grid of files, BUT! It's a very bad idea in preview window. In Preview windows all buttons should be placed at the bottom of the window. As example you can look at almost all image viewers preview windows and to all media players. Actions and navigations button alvays placed at the bottom.

And I tell you why. User reads window from top left corner to right bottom corner, and it's very unconvinient for all users to break this habit. Users ALWAYS reads pages from top to bottom, and from left to right. That's how all people reads books, sites and all kind of pages and windows. And that's why most common alignment of all areas on the sites and windows is left alignment, because it's easy to use(it's about first suggested bad position of tags area) That's why in preview windows buttons placed at the bottom:

1. user opens preview window and starts watch it from top to bottom
2. he moves his sight down from top to the image\video, watch it and make a decision for action\navigation
3. after that he again moves his sight down and press on already decided button in the buttons bar. Easy and convenient. That's works because user needs all these buttons only after watching at the image, so placing its before image is pointless.

It looks kind of this(arrows shows moves of the user's sight)

[MasterPetrik]

About preview window interface suggestion

Buttons size and positions

Navigation buttons (previous image, next image) are intuitive...

Maybe they are more intuitive on mac/linux, but how it will looks like on windows? Pleas show me if you can.

...and more prominent.

Absolutely not! they became smaller, shorter, and a bunch of unused blank space appears on the buttons bar, which becames even more not prominent if you open window in fullscreen, as it does almost all users, these little buttons will be still small, but blank space will be greatly increased. Moreover, in other languages same titles will take different width(shorter for asian languages, longer for russian), which means different size of these buttons in different language versions, that's not good.

Now look at the current buttons bar, it's multi sized, because all buttons fills whole space and well wisible with any size of the window, moreover, it fills all bar and there is no unused blank space at all. And all buttons have one size, it looks very beatiful compare with your suggested buttons bar where all buttons have different sizes only because of text on it.

Navigation buttons

Your suggestion to place both "previous" and "next" buttons alongside. I think it's a bad idea. Again think about user logic: "I want to go to the right image, I expect that button that moves me to the right next image will be at the right side of the window and if I want to go to the left image, I expect that button that moves me to the previous image will be at the left side of the window "

current navigation logic

suggested navigation logic

So it's very unclear to place "next" button in the left corner. Moreover when completely different but visually similar buttons placed so closely to each other there are big probability of misclick.

Moving "save as..." button

All save actions are separated from navigation, and placed together.

"Save as..." button placed at the end because it's not often used function, it's for special lmages mostly. Destination folder is not widely used function too(but very useful anyway), so placing all save actions together sounds logical. Kind of this:

Favourite folder functions

Many users not uses Favourites folder function(I'm too), and for them these buttons will be only dead weight, in current interface users who use this function just one time press "+" button and can use all wide functional of the favourite folder menu all time. So it's convinient for all. Moreover in the future in the "+" bar can be added new buttons, so "+" button is useful anyway. So I don't think that users would be happy if you deside to remove functions they use like destination of favourites folder and save to fav and close function. So this is obviously a bad idea.

"Save and close" actions

Removed "... and close" buttons, eliminating redundancy. We already have a close button in the window, also fix bug of 2 "close" buttons inside the window when image is already saved.

Oh you! I love Grabber because of "save and close" function, and not only me. This button saves many time for user because makes two main actions in one time, so you don't need to move mouse through whole screen and press two buttons(first "save" an then "X" in the corner)instead of one: moreover many users use it almost as frequently as normal "save" button. So hands off from this function >_< If YOU personally don't use it, don't means that you can just remove it for all. Also, redundancy exist in any interface and it's OK.

[MasterPetrik]

@BarryMode Thanks for you feedback, I'm really appreciate it. Btw, I can identify you only by avatar now but as I remember, you are Barry Anders

I have to say that I like the suggested design(s) above more than the current interface. Especially the buttons. I like that there is so much blank space. It feels cleaner to me. It's very browser-like having the forward/back buttons side by side, which I think everyone is used to.

But it's about browser similarity. And browser-like interface (buttons bar at the top, "<" and ">" alongside) is typical for search windows(llike tabs in grabber, it's very browser-like), windows with grid(file managers and results window in grabber) and other same pages(like downloads page in Grabber) but Browser's interface isn't supposted to be image viewer at all, So this interface in preview shouldn't looks like browser interface. In browser "<" and ">" buttons NOT means previous/next item, they means undo/redo your actions in the window, and then it's fully logical to place them alongside. In all programms these buttons placed nearby, snd that's good. But look at the "<" and ">" buttons in preview window, they moves you to the previous\next image in the grid, so this is completely same functions, that do "<" and ">" buttons in all media players, music players and most imageviewers preview windows, so in Preview windows it's pretty native. And in all these programms buttons bar placed at the bottom and center-aligned and buttons mostly stay in order like [previous item] - [some actions with this item] - [next item] In all these probramms "<" and ">" buttons are separated, and for preview it's ligical, I guess. For example here is the preview window of default Windows image viewer: So try to think about this window not like about browser window, but like media player window, considering that Grabber shows video too. Than I think you may better understand my position.

think some of your points are valid, and some are either an opinion or may be dependent on what your OS is.

True. As @dyskette use Linux, I don't know which suggested changes are linux-only and which are global, so I only can imagine how suggested interface will looks on Windows, and I can only tell about windows interface. I think it's wrong to base global GUI changes on linux GUI changes since most of the users use windows version and some users also use MAC, so first of all it's need to see how it can look in another OS too. Maybe things that looks good in Linux will be look bad in Windows etc. So I don't think that it's a good idea to bring GUI examples from other linux programms.