Created attachment 10353 [details]
screenshot with proposed arrangement of picture tags

Well, looking at it closer, joern and I do have some problems with your mockup:
- time should be included, but can not included, because there is no space
- time on the picture: not for my pictures ;-)
- different size pictures will ruin your layout, the portrait has to contain the same info, which should be on the same line in the whole row.
- i miss the dimensions of the image already.
- i don't think it would scale good for all different size images.

Seeing this list, i am tempted to mark it as wontfix for now.

Hi,

the text _on_ the picture will only be for the thumbnails (of course), not the original behind it.
I just left the time out of the date/time display to make my example easier to comprehend. I guess it's no big deal to add it where the date text is.

I didn't put the dimensions of the image there just because they could just be added as a new line. The text arrangement below the thumbnail was supposed to be dynamic. Perhaps file size + dimensions would always fit side by side underneath the image.

Regarding layout:
The question is if you want to stick to the fixed grid-based layout of the icon view, or if you want to be able to conserve more space and "flow" the thumbnails into the canvas, so that you can have eg. 5 landscape pics in a row, but 7 portrait pics in the next row.

Maybe I overdid it a bit, though. I had too many ideas at once :-)
Would removing the thumbnail/text borders and removing any empty lines below the pictures be acceptable as a first step?

I'll rethink the layout a bit, maybe I'll come up with more ideas.

Thanks for listening, though :-)

Jens

>
> as discussed on IRC today with jokele, toma etc: the current way of
> displaying information about images below their thumbnails wastes a lot
> of space if you don't *want* (all of) the information.


You can reduce number of info in options.
>
> I would like Digikam to
>
> - remove the border around the thumbnails, which will make the area
> *outside an image* larger, and thus make it easier to draw the rubber
> band (mouse) around images to select multiple ones


This border makes easily recognizable where belongs information. With
many images (and info) this will be not so obvious in your example.
>
> - dynamically size the height of each thumbnail row according to whether
> date / comment / tags / etc. actually exist and are displayed, reducing
> the empty space below images; and according to the maximum thumbnail
> height (eg. smaller row height if it only has landscape pics)


No. No. No. This will made constant moving of rows when changing
orientation of images. Also it will be impossible to rely on number of
images in one view.
>
> - optionally, display short strings like size and date directly below
> the image, side by side, 


Good idea.

> *or* embed them _in_ the thumbnail, as some
> film cameras do. (see mockup screenshot) This would require either


Very bad idea. Thumbnails are already cropped. Covering them with
additional info... ugh.

Hello, and thanks for your reply!


Am Samstag, 26. März 2005 01:32 schrieb Mikolaj Machowski:

> You can reduce number of info in options.


Yes, but still, sometimes there are empty lines between the thumbnail and 
the text.

> > I would like Digikam to
> >
> > - remove the border around the thumbnails, which will make the area
> > *outside an image* larger, and thus make it easier to draw the rubber
> > band (mouse) around images to select multiple ones
>
> This border makes easily recognizable where belongs information. With
> many images (and info) this will be not so obvious in your example.


Yes, because there is so much space between the thumbnail and the text, see 
above :-)
If you put all info below the pictures, there would not be a 
misunderstanding. See second mockup :-)

Also, the border makes it extra hard to use the "rubber band" to select 
multiple images, see Bug #99416. Also, I think empty space of the same 
size between images will actually help keeping an overview over the album.

How about only showing a border for _selected_ images, and not making the 
border *wider* than absolutely necessary (maybe + 1 pixel)?
That would already help. (See second mockup)

> > - dynamically size the height of each thumbnail row according to
> > whether date / comment / tags / etc. actually exist and are displayed,
> > reducing the empty space below images; and according to the maximum
> > thumbnail height (eg. smaller row height if it only has landscape
> > pics)
> No. No. No. This will made constant moving of rows when changing
> orientation of images. Also it will be impossible to rely on number of
> images in one view.


I thought so. :-) well, that is what many other apps can do (iPhoto 
included), but I guess it is controversial and probably not easy to 
implement.
btw, why is it important to rely on the number of images in one view?

> > - optionally, display short strings like size and date directly below
> > the image, side by side,
> Good idea.


Thanks :)

> > *or* embed them _in_ the thumbnail, as some
> > film cameras do. (see mockup screenshot) This would require either
>
> Very bad idea. Thumbnails are already cropped. Covering them with
> additional info... ugh.


OK. Forget about that. <g>


Created an attachment (id=10355)
digikam-whole-2.png

> Am Samstag, 26. März 2005 01:32 schrieb Mikolaj Machowski:
> > You can reduce number of info in options.
>
> Yes, but still, sometimes there are empty lines between the thumbnail
> and the text.


This margins could be smaller but it is creating impression of each
photo in its own passe-partout. IMO nice effect.

> If you put all info below the pictures, there would not be a
> misunderstanding. See second mockup :-)


Better.
>
> Also, the border makes it extra hard to use the "rubber band" to select
> multiple images, see Bug #99416. 


Never had problems with that.

> Also, I think empty space of the same
> size between images will actually help keeping an overview over the
> album.


I am not sure. Border helps to attach info to particular image.

> How about only showing a border for _selected_ images, and not making
> the border *wider* than absolutely necessary (maybe + 1 pixel)?


One pixel is very tight.
You can try how to feel real use without borders by modifying themes:

thumbnail.regular.color:             rgb:FF/FF/FF
thumbnail.regular.colorTo:           rgb:FF/FF/FF
thumbnail.regular.bevel:	     FLAT
thumbnail.regular.gradient:          false
thumbnail.regular.border:            false
thumbnail.regular.borderColor:       rgb:FF/FF/FF

IMO when you make margins smaller it will make assigning of info to
image harder.

> btw, why is it important to rely on the number of images in one view?


Predictability when scrolling. Important when you are doing team-work.

Hi!


Am Samstag, 26. März 2005 17:49 schrieb Mikolaj Machowski:

> This margins could be smaller but it is creating impression of each
> photo in its own passe-partout. IMO nice effect.


It's a matter of taste, I guess. I prefer them "free floating".
Would you accept a modified theme (maybe called "Flat") for Digikam that 
used no borders for non-selected images?

I see some of my wishes are already possible now :-)

> > If you put all info below the pictures, there would not be a
> > misunderstanding. See second mockup :-)
> Better.


Thanks :-)

> > Also, the border makes it extra hard to use the "rubber band" to
> > select multiple images, see Bug #99416.
>
> Never had problems with that.


Well, it requires very exact mouse positioning, which can be hard 
especially on laptop screens.

> > Also, I think empty space of the same size between images 
> > will actually help keeping an overview over the album.
>
> I am not sure. Border helps to attach info to particular image.


Yes, but moving the info closer to the image will do the same thing, and 
the canvas will look less crowded. Just IMHO.

> > How about only showing a border for _selected_ images, and not making
> > the border *wider* than absolutely necessary (maybe + 1 pixel)?
>
> One pixel is very tight.
> You can try how to feel real use without borders by modifying themes:


I like it. I didn't know it was part of a theme. Thanks!

> IMO when you make margins smaller it will make assigning of info to
> image harder.


Just the space between the image and the info should be smaller, IMHO. The 
rest is OK.

I would suggest the following: According to what the user wants to see, put 
the info that _always_ exists - like date, size, filename, etc - first. 
Below that, put comments etc. if they exist. Then the text will always 
_look_ being close to the image because it starts right below it.

Currently, the order seems to be 

	Filename
	Comment(s)
	Date, Time
	Dimensions
	File Size
	Tag(s)

I would propose

	Filename
	Date, Time   Size      (on one line if thumbnail >= 160x160)
	Dimensions (perhaps without "Pixel")
	Comments
	Tag(s)

Date/Time + Size should be extruded (aligned left and right to the image 
borders), if possible.

> > btw, why is it important to rely on the number of images in one view?
>
> Predictability when scrolling. Important when you are doing team-work.


During digikam development, or digikam use?

>Would you accept a modified theme (maybe called "Flat") for Digikam that
>used no borders for non-selected images? 

Sure, send your theme to the devel list.
http://digikam.sourceforge.net/themeguide.html

> Am Samstag, 26. März 2005 17:49 schrieb Mikolaj Machowski:
> > This margins could be smaller but it is creating impression of each
> > photo in its own passe-partout. IMO nice effect.
>
> It's a matter of taste, I guess. I prefer them "free floating".
> Would you accept a modified theme (maybe called "Flat") for Digikam that
> used no borders for non-selected images?


As a default? Tentatively. Maybe poll on the list, digiKam page or
kde-look?

> > > Also, the border makes it extra hard to use the "rubber band" to
> > > select multiple images, see Bug #99416.
> >
> > Never had problems with that.
>
> Well, it requires very exact mouse positioning, which can be hard
> especially on laptop screens.


When I cannot use margin of display to start rectangle 'drawing' it is
easier to click individually photos with Ctrl pressed.

> > > Also, I think empty space of the same size between images
> > > will actually help keeping an overview over the album.
> >
> > I am not sure. Border helps to attach info to particular image.
>
> Yes, but moving the info closer to the image will do the same thing, and
> the canvas will look less crowded. Just IMHO.


What would be the best solution is advanced theme mechanism where you
could use HTML/CSS tags to present information. In this way each user
could ultimately customize display for his/her needs.

Personally I would welcome theme with one big thumbnail in a row with
all info on its right side. In this way I could probably view all info
from tooltip with tooltip disabled (it can be disturbing).

With upcoming (in 0.8 I believe) possibility
to custom ordering of images in album it would be ideal for manual
placing of images.

But I am not sure if this is possible.

User point of view:

Present thumbnail as a base div - plate:
<plate style="display: inline; padding : 3px">
<thumbnail style="margin : auto; border : 1px solid #fff" />
<title style="text-color : ... >
<comments />
<dimensions />
<tags />
...
</plate>

With full KHTML use you could enclose date and size in divs with float
: left or right to put them in one row.

> > > btw, why is it important to rely on the number of images in one
> > > view?
> >
> > Predictability when scrolling. Important when you are doing team-work.
>
> During digikam development, or digikam use?
>

digiKam use.

Am Sonntag, 27. März 2005 12:40 schrieb Mikolaj Machowski:

> > Would you accept a modified theme (maybe called "Flat") for Digikam
> > that used no borders for non-selected images?
> As a default? Tentatively. Maybe poll on the list, digiKam page or
> kde-look?


Or a dialog with a choice (select theme with preview) on first startup?
I didn't even think about "themes" when I wanted the thumbs without 
borders, I didn't know that digikam was themeable. :-)

> > > > Also, the border makes it extra hard to use the "rubber band" to
> > > > select multiple images, see Bug #99416.
> > Well, it requires very exact mouse positioning, which can be hard
> > especially on laptop screens.
>
> When I cannot use margin of display to start rectangle 'drawing' it is
> easier to click individually photos with Ctrl pressed.


IMHO it would be nice to enable people to use both methods easily. Just 
making the additional margin around the thumbnail a little smaller will 
have the desired effect and I don't really see any disadvantages.

> > > I am not sure. Border helps to attach info to particular image.
> > Yes, but moving the info closer to the image will do the same thing,
> > and the canvas will look less crowded. Just IMHO.
> What would be the best solution is advanced theme mechanism where you
> could use HTML/CSS tags to present information. In this way each user
> could ultimately customize display for his/her needs.


That's right, but I doubt many users will actually need this. I've used a 
couple photo management tools in the past and from all, iPhoto from Apple 
made the best impression reagarding thumbnail display. (It has other 
shotcomings though. :-)

But liked the thumbnail display, *and* I expect Apple's UI engineers to 
have put a lot of thought into how to present these images, and therefore 
I think I'm not the only one who likes it that way. :-)

> Personally I would welcome theme with one big thumbnail in a row with
> all info on its right side. In this way I could probably view all info
> from tooltip with tooltip disabled (it can be disturbing).


Also not bad, though i think it would waste a lot of space.

> With full KHTML use you could enclose date and size in divs with float


But then you'll need to take care of a bit of security, otherwise people 
start embedding Javascript or similar into JPEG EXIF comments, and digiKam 
will pass them on to KHTML :-)

> > > > btw, why is it important to rely on the number of images in one
> > > > view?
> > > Predictability when scrolling. Important when you are doing
> > > team-work.
> > During digikam development, or digikam use?
> digiKam use.


I don't get it :-)

> > > Would you accept a modified theme (maybe called "Flat") for Digikam
> > > that used no borders for non-selected images?
> >
> > As a default? Tentatively. Maybe poll on the list, digiKam page or
> > kde-look?
>
> Or a dialog with a choice (select theme with preview) on first startup?


First time wizard with options setting. Good idea. It could also make
a presentation of some digiKam features (as themes ;).

> IMHO it would be nice to enable people to use both methods easily. Just
> making the additional margin around the thumbnail a little smaller will
> have the desired effect and I don't really see any disadvantages.


I am not sure, people more often select single images.
> >
> > What would be the best solution is advanced theme mechanism where you
> > could use HTML/CSS tags to present information. In this way each user
> > could ultimately customize display for his/her needs.
>
> That's right, but I doubt many users will actually need this. 


Creating personal themes would be of course only for handful of people,
but if they could use them...

> > Personally I would welcome theme with one big thumbnail in a row with
> > all info on its right side. In this way I could probably view all info
> > from tooltip with tooltip disabled (it can be disturbing).
>
> Also not bad, though i think it would waste a lot of space.
>

Not waste - just different use.

> > With full KHTML use you could enclose date and size in divs with float
>
> But then you'll need to take care of a bit of security, otherwise people
> start embedding Javascript or similar into JPEG EXIF comments, and
> digiKam will pass them on to KHTML :-)
>

I think you can use separately KHTML and KJS.

> > > During digikam development, or digikam use?
> >
> > digiKam use.
>
> I don't get it :-)


When you are processing - tagging, renaming, etc - images in big numbers
(eg. 400) with two people it is important to keep rhytm of work without
thinking about too many details.

Each image is surrounded by:
(1) a thin border;
(2) padding; and
(3) another thin border (which also includes any thumbnail information.
Then there is
(4) more padding between each thumbnail and the edge of the thumbnail pane.

This is really wasteful.  I don't think we need *any* of these.  On the other hand, one might want a little bit of air between each thumbnail.

One idea: If there is any extra horizontal space, divide it evenly between each thumbnail.  Suppose the thumbnail image size is T and then pane width is W.
Then N=floor(W/T) images will fit in a row.  The extra space is W-T*N.  Divide that by (N+1), and use that as the space between each thumbnail, as well as before the first thumbnail and after the last one.  In addition use the same spacing ((W-T*N)/(N+1)) for the spacing between rows, as well as the space before the first row and after the last row.

Thus those who want to cram as many thumbnail on the page as possible can easily do that, and those that want some space between them can do that.  Furthermore, it's a very easy and intuitive user interface, and easy to adjust on-the-fly.

f-spot does divide extra space between each thumbnail, but it doesn't allow squeezing things together as much as I'd like to be able to, and they don't change the vertical spacing.

Furthermore, the album item tooltip should be displayed when the cursor is anywhere in the thumnbnail area, including the information area.  That makes it more useful to reduce the amount of Thumbnail information shown below each image, since if one wants more, just look at the tooltip.

Arnd, 

This is a very old entry here. With KDE4, the IconView will be re-implemented by Marcel using new API from KDELibs. So what we can do with it ?

Gilles Caulier

Personally I think thumbnail "plates" are quite good. There are some
improvements with this view like: hover menus like in Gwenview or
Lightroom, color coding but size is OK.

I think the bug report was before the change that only a click on the thumbnail fired up the editor.  At this time is was really hard to
select images as only the small aere between the boxes could be used.

since 0.7.2 lots has changed to IMHO close the bug as implemented:
all information below the thumb can be turned of and all info is
available in 'captins tags' 

Achim

Well, I think that part of original report and many of the comments here
still apply: In particular too much space is wasted and a
more compact display (eg. like in a camera etc.) would be helpful.

However, it does not make sense to tackle this for 0.9.x as everything
would have to be redone for 0.10.

So in my opinion, out of all the comments above, a summary and concrete
proposal should be extracted...

Possible options:
Would it make sense for some of this data to be shown on mouse over? 
How about a "Info thumbnail:  One thumbnail slot that has the info for the pic that is under the mouse.  

A toggle between Open and Compact display.  

Some data that can appear on the wide border regardless of orientation.
Stars, date and size.  E.g.

For a portait format pic.
   PPPPPP 1524
 * PPPPPP x3096
 * PPPPPP 12 Dec
 * PPPPPP 2008
 - PPPPPP 8:15
 - PPPPPP

Reading some of the comments, "I miss the size already" could be implemented
with more comprehensive filtering.
Or filters that can apply a mark.  
Mark (photo size > 6 MP) (Full bucket icon, upper left)
     (photo size 3-6 MP)  ( half bucket icon, upper left)
     (photo size 1-3 MP)  (quarter bucket icon, upper left)

Mark (Pics < 1 year old)  (Full sun)
     (Pics 1-3 years old (sunset, half sun)
     (pics > 3 years old) (wisp of sun)

*** This bug has been confirmed by popular vote. ***

I created a new bug wish
https://bugs.kde.org/show_bug.cgi?id=225471

that basically just links to my mockup on kde-look.org
http://www.kde-look.org/content/show.php/Digikam+Usability+Improvements+Mockup?content=119622

The mockup addresses the problem with the boxes around thumbnails, and moves the information from below the image and into the right sidebar. As well as some other usability changes.

I have done some work to modularize the drawing in the icon views. This can lead to easier configurability.

The problem that arises is how to make a good interface to configure the visual appearance.

Marcel,

Since icon-view have been ported to qt4 model/view, this entry can be considerate as valid ?

Gilles Caulier

I have only read the initial bug report and skipped the long discussion. I would say that this is still a feature which can be implemented (by writing an alternative delegate) if there is time and interest by a developer

*** Bug 195090 has been marked as a duplicate of this bug. ***

What's about this file using digiKam AppImage bundle 5.4.0 pre release given at
this url :

https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM

Gilles Caulier

I consider the "no border around images" part of the bug (which I filed eleven years ago ;) ) as solved, Digikam 5.4.0 as below doesn't show a border any more. Also, overlay icons are shown inside images for portrait which saves some vertical space, very precious for today's 16:9 display world.

The same might be possible for the rating stars - they would still be readably as overlay icons. Any chance?

About the other ideas mentioned in this bug report, I don't see them as solved yet but most of them are gimmicks, not really providing a lot of advantage.

>The same might be possible for the rating stars - they would still be readably >as overlay icons. Any chance?

Well, this is not a priority. For the moment there are a lots of fixes to do everywhere about more important problems.

Moving rating and pick labels over the thumbnail will certainly hide the thumb as well, especially when size is small. of course, in case of large size, this is different. But we must stay the most versatile in all cases. It's a complex deal.

So the current situation some fine for the moment and for a while.

Gilles Caulier