hi

the filter and Tag system is tricky. you have right.

a Bad a feature request
when i use a picture APP i habe to had a select system where i select for example the HP pictures Form one folder and than i resize them. it woulb be realy realy cool if i can Tag files with a Tag for example resize web and when i tag a file the file will be resized, moved, ... automatically in the background.

so i can made a script like you know it Dolphin for tags.

Sogatori wrote: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.

I agree. Plasma Active Files uses tabs for the different browsing modes, too, and it works quite well.

I'm going to play the devils' advocate here, but before I do that I need to say the designs look great. So, here I go;

This gallery application is juggling a lot of balls; it's a file browser, and image editor, a photo viewer, and a slideshow. And while it can do it all, perhaps breaking the gallery into two smaller programs will streamline the programs' usage; A simple image viewer / slideshow which does image viewing well, and a basic photo manager which aims to manage photos well.

The viewer app would attempt to have almost no UI - a focus solely on maximising the canvas we have for the image, and it would work under the assumption that all you want is bask in the glory of your gallery. UI elements would rest on the bottom (back, next, pause/play, fullscreen, and popups for transition style / timing, thumbnail "playlist" toggle); It would not offer file browsing features - at most it might have a simple bookmark utility where you could bookmark a folder for presentation later. It would also have a minor behavioural change in how it opens files; opening a single file will have it browse the files' folder, but selecting multiple files and opening the viewer would make a slideshow of just those files. I think adding transition options would be great, allowing the user to choose between sliding, fading, wiping, etc. Overall, it would have more of a focus on being flabbergastingly beautiful.

The manager app would be your current designs, but with minor behavioural differences; fullscreen would just be the app - only fullscreen, not a slideshow mode. The top toolbar would have editor-centric UI controls (save, save all, undo, redo | file browser, full screen, share, menu). This app would behave like a 'casual' version of Digikam.

Edit: mockup of a 'pure' gallery viewers' main view;



(With a new setting where the background can be set to "dynamic" - with the blurred style we've seen from the media mockups)

I really enjoy extremely minimalistic image viewers. As soon as I get set up and comfortable with my development environment I intend to make exactly that kind of viewer.

(I already have a version running on Windows - which I've abandoned 80% through, since I don't intend to use Windows again - which can remove the entire window frame as well.)

While I'm generally all for the "do one thing and do it well" approach, there is one thing I'd like to throw in:
What I like about Gwenview is that I can just associate all image files to open with Gwenview, and in 95% of the cases, it is the application I want. It works well for just browsing through photos, but I can also use it to quickly crop an image for use somewhere else, or I can turn photos which have been shot sideways and have not been turned yet.
If there is an application which is just for showing images, this is what I'd associate with image files, but then whenever I noticed that I wanted to quickly crop or turn an image while browsing through a folder, for example, I'd have to open it with a different application.
For me, Gwenview has just the right amount of extra features for what is actually an application for browsing through and displaying images.

Then we could just include an 'Edit' button or something in the Viewer application, which would open the current image in Gwenview or another, more powerful image viewer and editor.

Often times, all I want to do is to look at an image, perhaps pan or zoom it, and not be distracted by any extra visuals. I never made any screenshots, but the Windows app I made had no UI whatsoever, so when opening an image file, all I got was the image itself, floating on my screen. Granted, that might be a bit too little, and I wouldn't expect random users to know to use 'Esc' to close the app, so I think the window border should be visible by default at least.

veqz wrote:Then we could just include an 'Edit' button or something in the Viewer application, which would open the current image in Gwenview or another, more powerful image viewer and editor.

Often times, all I want to do is to look at an image, perhaps pan or zoom it, and not be distracted by any extra visuals. I never made any screenshots, but the Windows app I made had no UI whatsoever, so when opening an image file, all I got was the image itself, floating on my screen. Granted, that might be a bit too little, and I wouldn't expect random users to know to use 'Esc' to close the app, so I think the window border should be visible by default at least.

Truth be told, I've maybe used Gwenview to edit images on 2 occasions, and it was just rotations. When I'm going to edit an image, I tend to jump into Gimp, Krita, or Kolourpaint - depending on what I'm going to do. I guess my main gripe with Gwen is that I'm constantly fiddling with an interface that wants to be an editor, browser, and viewer all at the same time - all the time - and for some actions things just get weird because you have 3 'apps' in one UI. (For example, with hotkeys the Esc button takes you into the browser - but in a fullscreen slideshow you'd expect Esc to take you out of it)

I like the idea of an edit button which just launches your preferred editor. Or alternatively we could package some basic functions like crop, rotate, and auto-enchance into the main menu or in an "edit" menu. Essentially, keep some basic stuff in there for those quick things, but give quick access to dedicated programs for a more flexible editor.



(Pretend that context menu has the sister manager application)
(Bottom image would be the viewer in 'crop mode')

Maybe you can use the thumbnail bar for the edit function.

Include the /\ Botton for go to the gallery and it work still the same like the music (video) app mockup.

Is there a 'print' function included into the mockup?
Currently it's a mess to print pictures e.g. you want two photos per page. I have to use the print assistant in Gwenview's modules list (not the actual 'print' function) ...
took 1/2h to figure out how to print images for my parents.

I think the gallery application should include an easy to use photo printing function.

PS: Nice mockups so far

Kver wrote:

veqz wrote:Then we could just include an 'Edit' button or something in the Viewer application, which would open the current image in Gwenview or another, more powerful image viewer and editor.

Often times, all I want to do is to look at an image, perhaps pan or zoom it, and not be distracted by any extra visuals. I never made any screenshots, but the Windows app I made had no UI whatsoever, so when opening an image file, all I got was the image itself, floating on my screen. Granted, that might be a bit too little, and I wouldn't expect random users to know to use 'Esc' to close the app, so I think the window border should be visible by default at least.

Truth be told, I've maybe used Gwenview to edit images on 2 occasions, and it was just rotations. When I'm going to edit an image, I tend to jump into Gimp, Krita, or Kolourpaint - depending on what I'm going to do. I guess my main gripe with Gwen is that I'm constantly fiddling with an interface that wants to be an editor, browser, and viewer all at the same time - all the time - and for some actions things just get weird because you have 3 'apps' in one UI. (For example, with hotkeys the Esc button takes you into the browser - but in a fullscreen slideshow you'd expect Esc to take you out of it)

I like the idea of an edit button which just launches your preferred editor. Or alternatively we could package some basic functions like crop, rotate, and auto-enchance into the main menu or in an "edit" menu. Essentially, keep some basic stuff in there for those quick things, but give quick access to dedicated programs for a more flexible editor.



(Pretend that context menu has the sister manager application)
(Bottom image would be the viewer in 'crop mode')

I like your ideas. I'm a bit sceptical about breaking the application into smaller part, however. I really like the very simple actually photo viewer, but if we pack the basic editing functions into it, they way you presented them, then we'd lose some function e.g. different form factors for crop. But I like the visuals, brings it closer to the Andrew's music player!
We could, however, try this: Add an edit icon, and when it's toggled the edit options appear in one of these side panels from my mockup, minus the whole "information" stuff. Maybe that would also increase the continuity with the "tagging" UI. What do you think?

This is a mockup I was doing when Jens mentioned a new image viewer. It isn't finished as there are already some mockups in discussion here, but just wanted to chime in with mine. It follows the same design as the video player in the Made for Plasma thread (I also made that one).

As it's a simple application, only the basics are on the toolbar.

Hey everyone.

So, I started implementing the first mockup. It's still a work in progress, but here are some screenshots -



As you can see, it's clearly a work in progress. Here is what works from a UI point of view -
* Adding/Removing tags
* Tag Filters - Most of the interaction shown in the first post has been implemented. Minus auto-completion for tags.

Currently, I've just hardcoded some 10 images. However, it's very trivial to hook it up to show all my images and make it tag filters actually filter images. Very trivial. Actually, most of the backend code looks pretty simple in my head right now. Alright, so here are my main issues -

1. All of the mockups seem to have been done in this "dark" theme. This dark theme is not the default, and I'm not too sure how to make it work. Could we perhaps have mockups in the default plasma theme? That way it'll be easier for me to make it look exactly like the mockups.

2. Workflows - There seem to be a large number of images, and even some minor workflows about how to pin tags, but overall we still need proper work flows for the entire application and we need user cases, personas and all of that.

3. Animations - We're using QML, and animations are much simpler to add in comparison to C++. We should definitely be using them more. I've currently only added some basic ones for adding/removing tags. We'll need proper guides as to what should be animated and how. This includes how the application should start up, how the images should appear when they are loading, what happens when you click and image, click a button which changes the screen, etc.

4. Home Screen - What should the home screen of the application be like? What images should we be showing by default?

5. Untagged Images - There is an option for showing all untagged images. This seems sensible, but since tagging is not that prevalent, it will result in all the images being shown. This can be a very large number. If you want a rough guess run this command -
$ baloosearch -t "Image" -l 1000000 "" | wc -l

I'm not sure what the best approach is. Should we be showing all the images then? Showing them in pages?

6. Tag Colors - How do we choose colors for tags? Automatically? Show a color picker?

7. Only Tags - So far the mockups seem to have mostly concentrated around Tags. While tags are awesome, we need to cover other parameters as well. The 2 options which I would really like targeted are "time" and "location". We already have the metadata for both of these, and they are options that users clearly understand. It might make sense to expose them.

8. Icon names: When creating mockups if you could give me a list of icon names to use, that would be awesome.

9. Favorite Tags: How does one mark a Tag to be a favorite? Is this a global setting or specific to images? Do we also want the concept of "favorite tags". One could also do stuff like "Most used", "Recently Used", etc.

10. There is an "Add Image" button in the first mockup. What is that supposed to do?

--

The code is in my scratch repo. It has just taken me a couple of days to do this much. I think it would be great if we can get more mockups and experiment more. This seems like the kind of thing which make take a few iterations. So, throw some mockups at me, I'll implement them, and you can play around and see what works and what doesn't.

vHanda wrote:Hey everyone.

So, I started implementing the first mockup. It's still a work in progress, but here are some screenshots -

http://vhanda.in/gallery.png
http://vhanda.in/gallery2.jpg

As you can see, it's clearly a work in progress. Here is what works from a UI point of view -
* Adding/Removing tags
* Tag Filters - Most of the interaction shown in the first post has been implemented. Minus auto-completion for tags.

Wow that looks amazing! Nicely done!

vHanda wrote:1. All of the mockups seem to have been done in this "dark" theme. This dark theme is not the default, and I'm not too sure how to make it work. Could we perhaps have mockups in the default plasma theme? That way it'll be easier for me to make it look exactly like the mockups.

Yes, that's pretty much a non-issue on my side I was just experimenting a bit. Maybe in some distant future we can get applications to use a dark theme by default too!

vHanda wrote:2. Workflows - There seem to be a large number of images, and even some minor workflows about how to pin tags, but overall we still need proper work flows for the entire application and we need user cases, personas and all of that.

Yes that's an issue. I left them out, because I was not entirely sure how to handle this. I think the whole personas stuff etc. should not be too much trouble to write down.
I had some ideas how I can combine Kver's ideas with my mockups, however that will still need some time. With that I (or anyone else, if they want ) will deliver a more complete work flow.

vHanda wrote:3. Animations - We're using QML, and animations are much simpler to add in comparison to C++. We should definitely be using them more. I've currently only added some basic ones for adding/removing tags. We'll need proper guides as to what should be animated and how. This includes how the application should start up, how the images should appear when they are loading, what happens when you click and image, click a button which changes the screen, etc.

I not too sure about this one, but since people are working on animation guidelines, I think I can refer to them XD.

vHanda wrote:4. Home Screen - What should the home screen of the application be like? What images should we be showing by default?

5. Untagged Images - There is an option for showing all untagged images. This seems sensible, but since tagging is not that prevalent, it will result in all the images being shown. This can be a very large number. If you want a rough guess run this command -
$ baloosearch -t "Image" -l 1000000 "" | wc -l

I'm not sure what the best approach is. Should we be showing all the images then? Showing them in pages?

Originally I had thought we could show "all" pictures by default, however the command of yours made me think that this is probably not the best idea. This needs some heavy thinking.

vHanda wrote:6. Tag Colors - How do we choose colors for tags? Automatically? Show a color picker?

I thought about doing it automatically, as it would make the whole process much smoother. We had planned to make an extended colour palette at some point, however, I am not entirely sure if that would suffice for our use case. Would it be possible to create some kind of spectrum from which the automated colour picker is allowed to choose? Like some painting applications allow to create masks to the colour picker, which introduces boundaries which limit the colour one can choose in the colour picker.

vHanda wrote:7. Only Tags - So far the mockups seem to have mostly concentrated around Tags. While tags are awesome, we need to cover other parameters as well. The 2 options which I would really like targeted are "time" and "location". We already have the metadata for both of these, and they are options that users clearly understand. It might make sense to expose them.

Definitely!

vHanda wrote:8. Icon names: When creating mockups if you could give me a list of icon names to use, that would be awesome.

I could do that, first I would have to get some of the icons used into upstream Breeze though. This will take some time for me though.

vHanda wrote:9. Favorite Tags: How does one mark a Tag to be a favorite? Is this a global setting or specific to images? Do we also want the concept of "favorite tags". One could also do stuff like "Most used", "Recently Used", etc.

Originally I had the idea to simply use Filter with only one tag in them, however, as several people have pointed out that is not very easy to understand. I agree. I/We either have to come up with an idea how to convey this information better or we should simply swap them for "Most used", "Recently Used", like you said.

vHanda wrote:10. There is an "Add Image" button in the first mockup. What is that supposed to do?

Orignially it was for an "import" function, because usually when one adds pictures from Cameras, thumb drives etc. do not have tags on them. However, I haven't give this function much thought yet, so we might as well drop it, at least for now.

Sogatori wrote:

vHanda wrote:2. Workflows - There seem to be a large number of images, and even some minor workflows about how to pin tags, but overall we still need proper work flows for the entire application and we need user cases, personas and all of that.

Yes that's an issue. I left them out, because I was not entirely sure how to handle this. I think the whole personas stuff etc. should not be too much trouble to write down.
I had some ideas how I can combine Kver's ideas with my mockups, however that will still need some time. With that I (or anyone else, if they want ) will deliver a more complete work flow.

Checkout the Getting Started section of the updated HIG. It should be help you identify these crucial conceptual elements of designing an application: Project Vision, Personas, Scenarios. Also our usability folks (Bjorn, Heiko and Thomas) have been extremely helpful in getting this kind of stuff nailed down.