[Fwd: [kde-artists] Icons for: FitToPage, FitToWidth, & FitToHeight revisited]

[James Richard Tyrer]

Sorry to cross post, but there doesn't seem to be anybody home at
KDE-Usability-Devel.

--
JRT

At the suggestion of Olivier Goffart, I am forwarding this question to
the usability developers for comments and possible resolution.

--
JRT


-------- Original Message --------
Subject: [kde-artists] Icons for: FitToPage, FitToWidth, & FitToHeight
revisited
Date: Wed, 28 May 2008 15:10:13 -0700
From: James Richard Tyrer <tyrerj@...>
To: kde-artists@...

We have the 3 KDE Standard Actions:

        FitToPage
        FitToWidth
        FitToHeight

for which I made KDE3 icons for CrystalSVG & HiColor (HiColor is
installed as KDEClassic).  In KDE3 they are named:

        view_fit_window
        view_fit_width
        view_fit_height

See attached KDEClassic.

I was originally going to rename these (KDE4 names):

        view-fit-window
        view-fit-width
        view-fit-height

But was persuaded that they should be called:

        zoom-fit-best
        zoom-fit-width
        zoom-fit-height

This appears to have been an error and we should rethink it.

We also had the KDE3 icons:

        viewmag+
        viewmag-
        viewmag

See attached KDEClassic

The first two were renamed:

        zoom-in
        zoom-out

and, therefore, the third should logically be named:

        zoom

This results in a (possibly) valid issue that if an icon: "zoom-fit-*"
is not available that the icon loader will fall back to "zoom".

One proposed solution for this is to rename "viewmag" to "page-zoom".
This appears to be a poor choice since:

1. It leaves us without a "zoom" icon for fallback.

2. It is a singular icon.  There are no other: "page-*"

3. It is inconsistent with the naming spec.

We also have the "view-*" set of icon (or tree if you prefer that math
metaphor).  I think that it has been agreed that the: "view_remove"
(KDE4: "view-close") icons are not satisfactory and that they have been
misused by various apps.  The proposed solution is that we have a "view"
icon [Oxygen attached] and a "view_remove" ("view-close") icon with a
red "X" [Oxygen attached].

So, if we have icon names: "view" & "zoom" this focuses the question of
the names for the icons for the above 3 KDE Standard Action (FitTo*).
The question is whether they should be members of the "view*" set or the
"zoom" set.

Note that I am presuming that the name "page-zoom" is a mistake that
needs to be promptly corrected (to "zoom").

I think that my original thoughts were correct and the three icons
should be members of the "view-*" set (or tree).

Note that this is not really that important as far as the use by people
is concerned.  However, for the icon loader to act as people expect, it
is important to have logical names for icons.

--
JRT





       













______________________________________________________________________________
kde-artists@... |  https://mail.kde.org/mailman/listinfo/kde-artists


_______________________________________________
Kde-usability-devel mailing list
Kde-usability-devel@...
https://mail.kde.org/mailman/listinfo/kde-usability-devel


_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

On Thursday 29 May 2008, James Richard Tyrer wrote:
> and, therefore, the third should logically be named:
>
> zoom
>
> This results in a (possibly) valid issue that if an icon: "zoom-fit-*"
> is not available that the icon loader will fall back to "zoom".

which is why themes must simply provide a zoom-fit at minimum. the fallbacks
are not there to replace proper themes, otherwise it would be possible to
create a usable theme with a dozen or so icons ;)

the fallbacks are there for where it makes sense and the mechanism is defined
in a generic way (as opposed to explicit per-use-case fallback paths) so that
the solution can be used wherever it may make sense now and in the future.

so i don't think it matters much to try and prevent zoom-fit-* missing from
falling back to zoom: that's exactly what ought to happen, though icon themes
that let that happen can only be described as incomplete.

> One proposed solution for this is to rename "viewmag" to "page-zoom".
> This appears to be a poor choice since:

i would agree.

> We also have the "view-*" set of icon (or tree if you prefer that math
> metaphor).  I think that it has been agreed that the: "view_remove"
> (KDE4: "view-close") icons are not satisfactory and that they have been
> misused by various apps.

can you give some examples of the misuse?

--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech



_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

On Saturday 31 May 2008, Aaron J. Seigo wrote:
> On Thursday 29 May 2008, James Richard Tyrer wrote:
> > and, therefore, the third should logically be named:
> >
> > zoom
> >
> > This results in a (possibly) valid issue that if an icon: "zoom-fit-*"
> > is not available that the icon loader will fall back to "zoom".
>
> which is why themes must simply provide a zoom-fit at minimum. the

never mind.

i just caught up with kde-core-devel mail finally and read about this issue
there where there was a pointer to this discussion:

        http://lists.kde.org/?l=kde-artists&m=121062526701465&w=2

in the second mail, Jakob says:

"That's what my original idea (and even proposal for the ArtLibreSet) was as
well, but when thinking about this once more, it appears better to have an
icon that is not in the current theme but has an accurate metaphor, as opposed
to have a row of plain magnifier glasses that all look the same."

he then gives some pretty compelling reasons for that position, namely
that the zoom-* set of icons do not behave like many other such sets where
there is no generic concept that works for any of the given leaf-node icons.

James, if you would in future provide links to previous discussion on a matter
that would be awesome. =)

> > One proposed solution for this is to rename "viewmag" to "page-zoom".
> > This appears to be a poor choice since:
>
> i would agree.

to expand on this a bit: would it instead be possible to provide a
zoom-generic or zoom-glass or some other named icon? to at least keep it in
the generic zoom-* space?

--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech



_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[Jakob Petsovits]

On Sunday, 1. June 2008, Aaron J. Seigo wrote:
> On Saturday 31 May 2008, Aaron J. Seigo wrote:
> > On Thursday 29 May 2008, James Richard Tyrer wrote:
> > > One proposed solution for this is to rename "viewmag" to "page-zoom".
> > > This appears to be a poor choice since:
> >
> > i would agree.

It's the general feeling that "page-zoom" is not an ideal name, and after
having seen some more examples of how applications use a generic "zoom" icon,
I do agree with that.

I also talked with dobey (naming spec maintainer) about this issue, and one of
the conclusions for me is that the root problem here is the usage of a single
icon for two different use cases:

a) as a "zoom tool", like in drawing applications such as Krita or Inkscape.
b) as icon for the "Zoom" menu which does not do anything by itself but
   just contains a set of concrete zoom actions ("Zoom in", "Zoom out",
   "Zoom to original size", etc.).

In order to make sane icon naming possible here, we need to distinguish
between those different concepts and look at them separately.

The "zoom tool" use case is relatively easy from a naming point of view, and
after talking to dobey there is little doubt that "tool-zoom" should be the
right name for such an icon (next to other drawing tools that will also be
prefixed with "tool-*").

The menu use case is the one that causes all the confusion. It would be worth
a though to consider dropping this icon, as it does not represent an actual
action. Nice to be on the usability list now, so my question goes:

Could the "View" menu also do without the "zoom" icon for that submenu
(and just contain icons for the concrete zoom actions?). That would simplify
this task quite considerably.

If this icon can't be missed then we might take it as a hint that it's just an
icon for use in a specific menu, and call it "view-zoom" - for the "Zoom"
submenu in the "View" menu. Both dobey and I would rather prefer not to have
an icon for this use case at all, though.

Thoughts? Wishes,
  Jakob
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[James Richard Tyrer]

Aaron J. Seigo wrote:

> On Thursday 29 May 2008, James Richard Tyrer wrote:
>> and, therefore, the third should logically be named:
>>
>> zoom
>>
>> This results in a (possibly) valid issue that if an icon:
>> "zoom-fit-*" is not available that the icon loader will fall back
>> to "zoom".
>
> which is why themes must simply provide a zoom-fit at minimum.

An interesting suggestion.  The problem is that there is no icon name
"zoom-fit"

> the fallbacks are not there to replace proper themes, otherwise it
> would be possible to create a usable theme with a dozen or so icons
> ;)

I see a need for fallback icons where KDE has added icons that are not
in the name spec.  This is the case with "view".  Whether or not that is
relevant with the question of the "zoom" icon depends on what the icons
for FitToPage, etc. are named.  If they are named, "view-fit-*" then it
is not relevant.  However, IAC, the icon named "viewmag" in KDE3 is
needed and the simplest and most logical name for it is simpy "zoom".

> the fallbacks are there for where it makes sense and the mechanism is
>  defined in a generic way (as opposed to explicit per-use-case
> fallback paths) so that the solution can be used wherever it may make
>  sense now and in the future.

Yes, I agree.  For the fallback code to work and for it to be simple,
the icon names must be logically structured according to set theory or a
tree diagram (they accomplish the same thing, pick your poison).

> so i don't think it matters much to try and prevent zoom-fit-*
> missing from falling back to zoom: that's exactly what ought to
> happen, though icon themes that let that happen can only be described
>  as incomplete.

I agree that there is nothing wrong with that (it is starting to look
like "bikeshedding") but if this is a problem, then it can be solved by
using "view-fit-*" based names for the actions FitToPage, etc..

>> One proposed solution for this is to rename "viewmag" to
>> "page-zoom". This appears to be a poor choice since:
>
> i would agree.
>
>> We also have the "view-*" set of icon (or tree if you prefer that
>> math metaphor).  I think that it has been agreed that the:
>> "view_remove" (KDE4: "view-close") icons are not satisfactory and
>> that they have been misused by various apps.
>
> can you give some examples of the misuse?
>

Jakob brought this up.  I wouldn't really call it misuse, but any use
that isn't closing or removing something isn't going to work with a
proper "view-close" icon that incorporates a red "X" like other such icons.

--
JRT
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability

[James Richard Tyrer]

Aaron J. Seigo wrote:

> On Saturday 31 May 2008, Aaron J. Seigo wrote:
>> On Thursday 29 May 2008, James Richard Tyrer wrote:
>>> and, therefore, the third should logically be named:
>>>
>>> zoom
>>>
>>> This results in a (possibly) valid issue that if an icon: "zoom-fit-*"
>>> is not available that the icon loader will fall back to "zoom".
>> which is why themes must simply provide a zoom-fit at minimum. the
>
> never mind.
>
> i just caught up with kde-core-devel mail finally and read about this issue
> there where there was a pointer to this discussion:
>
> http://lists.kde.org/?l=kde-artists&m=121062526701465&w=2
>
> in the second mail, Jakob says:
>
> "That's what my original idea (and even proposal for the ArtLibreSet) was as
> well, but when thinking about this once more, it appears better to have an
> icon that is not in the current theme but has an accurate metaphor, as opposed
> to have a row of plain magnifier glasses that all look the same."

While this probably wouldn't actually occur, we are using it as an
example.  Having multiple magnifier glasses would be preferred over
having multiple "?" icons.

> he then gives some pretty compelling reasons for that position, namely
> that the zoom-* set of icons do not behave like many other such sets where
> there is no generic concept that works for any of the given leaf-node icons.

Might want to reread what he said about this point again since I think
he meant the opposite.  I didn't find his reasons compelling which IIUC
are that he wanted to avoid "zoom-*" leaves falling back to the root
'zoom' icon.  Duh! Isn't that how it is supposed to work?

His premise is that it would be better to fallback to a different theme
than a different icon.  We had bugs in KDE3 where users of themes other
than CrystalSVG would get CrystalSVG icons and this wasn't a good thing.

> James, if you would in future provide links to previous discussion on a matter
> that would be awesome. =)

This was a summary that I wrote for the specific purpose of submitting
to Usability since the discussion was a bit long and unclear.  Sorry if
the engineering method is too ingrained -- I was sending it to another
department so I wrote a summary.

>>> One proposed solution for this is to rename "viewmag" to "page-zoom".
>>> This appears to be a poor choice since:
>> i would agree.
>
> to expand on this a bit: would it instead be possible to provide a
> zoom-generic or zoom-glass or some other named icon? to at least keep it in
> the generic zoom-* space?
>
When choosing a name, it is important to consider fallback.  So, it
doesn't do any good to have a generic icon if it doesn't have a generic
name (i.e. a name that missing KDE icon names could fall back to).  So,
your suggestions would not help since there are no subset icons to fall
back to "zoom-glass" (also you have to consider set theory for a proper
name: Is 'glass' a proper subdivision of 'zoom'?  Only, "zoom" and
"zoom-fit" can act as fallbacks with the existing set of names in the
'zoom' set.  This might be a moot point if "view-fit-* names are used as
stated in other posts.  However, good design requires that we always
consider future possibilities, and it is possible that in the future
that additional "zoom-*" icon names will be added.

--
JRT
_______________________________________________
kde-usability mailing list
kde-usability@...
https://mail.kde.org/mailman/listinfo/kde-usability