It was in bug 102523 that the window icon was made the favicon.

Hm. Well, I'd prefere an application icon, but I guess some usability
tests with other users would be a good idea.

Things did get a bit confusing when I had Rhythmbox and Epiphany open,
with Epiphany pointing to <http://web.rhythmbox.org/> . . .

notabug. This is intentional. In the common case users search the
window list for the window with cnn.com, or espn.com. Using different
icons allows these users to easierly differentiate these windows. The
rhythmbox case you mentioned is an interesting edge case, but it is
just that an edge case. As for tab browsing, its not the default
method of using ephy and for the most part its harder to use than
regular single window browsers (its useful for advance users no doubt,
but they are of course advance).

As I mentioned before, this behavior can be quite irritating. Both, my
sister and my girlfriend got really confused when they used Epiphany
because of this issue. (Well. Me too, the first time)

Again I'd suggest to revert this behavior, for it is quite epiphany
specific. The only other application I know that uses that method is
the Gimp and Gimp only applies a document icon as window icon for the
actual document window. So there my be some logic. (Is has to be
mentioned that the Gimp is not a part of GD&D)

But I think that Epiphany is another case. Epiphany doesn't uses a
multi window interface as the Gimp does. And the users can still
distinguish between cnn.com and espn.com through the window title.

Epiphany is the only application in the GNOME Desktop which uses the
window icon to display a document icon.

Gedit, for example, also has the ability to open several documents in
one window and displays their mime-type icon in the tabs. But Gedit's
application icon is not changed to the mimetype-icon of the currently
open file.

This results in inconsistency between the behavior of the different
GNOME applications. 

Should I file a bug report against the behaviour of Gedit?

I suggest asking the developers of the window list/window menu whether
it would be possible to detect when two different binaries are using
the same icon. If that is detected, a generic app-icon could be used
instead.

Comparing with gedit doesnt really make sense, being gedit an MDI app.

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

This is definitely an interface bug. The task manager misrepresents the task.

  First point: Good design means things look like what they are. They are easily
understandable, and they function the way they appear to. I'm an architect, and
basic way-finding is always based on this premise. However in this case, the
application manager icon in no way represents the application. Not even the task....

  Second point: A web site viewed in a web browser is not a task. It's a
document. Content. We wouldn't expect a File Manager to represent every document
with it's own icon. Imagine the Nautilus application's icon changing based on
whether it is viewing a folder, desktop, home, a network reference, or viewing a
document or thumbnail.

  Third point: Is there any proposal to resolve the conflict when the browser
has more than one tab open? Could the task manager represent each icon in a
single button? It is a cop out to avoid dealing with this under the excuse "tabs
are not the default behavior." (If tabbed behavior isn't important, why not
eliminate them? :)

  Fourth point: I know from experience that this isn't right. I fight this every
time I use Epiphany and so does my wife.

  Fifth point: I can't recall any other application (particularly among web
browsers) that behaves this way.

I can think of only one solution to fix this without reverting back to the
original behavior: Have the icon more accurately express the behavior. 

Imagine Epiphany's icon faintly behind that of the site's favicon, visually
holding it. Or perhaps the Foot-E is primary with a string of favicons beside
it, something like E: 1 2 3 4. At the very least, why couldn't the favicons be
overlayed on a blank document image, like many document MIME types?

This was a good experiment, I certainly appreciate trying it and thinking about
it. But it doesn't work as is. I can't code, but have done plenty of graphics
and icons for other projects if it would help here.

The core of the problem to me seem if the task list should represent the
document or the task. Right now GNOME seem in a mixed mode. Most applications
put clues about the document in the title but use the application icon.
Evolution though use the icon of the active folder.
In general epiphany design is following a document oriented mode (for how much
it's possible in a web browser), that's the reason this behavior was choosen in
first place.

Steve, about fifth point, the problem is that there are people whose experience
is different. I guess a more concrete explanation of when this is a problem
would be helpful (apart applications websites that seem totally a corner case to
me).

seth, clarkbw do you have an opinion about this ?

Marco, you're right on... this really isn't an Epiphany problem, but a task list
one.

I'm taking this to the usability list and will report back.

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

Steve: has this been discussed on the usability list? What was the conclusion ?

Sorry, I dropped this. Making the tasklist/selector components somehow indicate
the content of all open tabs is beyond epiphany's scope. (And might be quite a
battle to implement as I read the usability lists. :) 

So I'd say the original bug is valid: E should indicate it's own icon, not those
of it's content. Displaying the content title is ok, but IMO, the icon shouldn't
ever change.

Implementing the tabbed task list is somewhat difficult, but I think moving in
that direction has more benefits than having epiphany become less document
centric or changing it's icon based on having tabs which might look somewhat
random from the users POV.

There are some problems I see with this argument.  
> Users identificate the applications in the window-list-applet mainly 
> through the application icon. 

Users don't actually identify application icons with the actual application. 
There exists a major disconnect between applications and their representing
icons.  Since icons are generally small and not all that descriptive they cannot
acurately represent what an application is.  This has a lot of factors like,
icons mean different things to many different people so an icon cannot be
expected to represent an application to someone looking at just the icon.  In
Coopers About Face book he calls this recall vs. recognition, the app icon is
used for recall of what the application is after someone has read the launcher
name but not for recognition of what the app might be.  

> They expect application icons, not document-icons, so they get confused.

This is tough to say what are the users expecting to see.  If they load up
slashdot and see the /. icon in their task view they can probably easily relate
that and find the page containing slashdot again.  With the titles only they are
left to hunt for the page by name in a list of generic icons.

Hope this all sounds reasonable.

Anyway, I've done some work on the tabbed view in the task list; starting at the
alt-tab level.  Marco could work on this if he's inclined ;-)  Although I'm sure
window managers are a little out of the norm for him.

http://www.gnome.org/~clarkbw/designs/alt-tab-tab/v2/explanation.html

Indeed; what does the user expect to see in the window-list-applet? Do they
expect applications or do they expect documents?

Maybe this is just one symptom of a desktop wide illness; GNOME does enforce
neither application centric nor document centric approaches.

If GNOME requests the applications to be document centric, then the current
approach is the right one. At the same time the tabbed interface should be
removed from Epiphany.

If application centric applications are the default the icon should always be
Epiphany's.

I reckon this requires more discussion in the gdd and usability mailing lists. 

The tabs in Epiphany are there not because of document-centricness, but because
there's currently no other sane way to have grouping of web page windows.

Regarding the question 'what does the user expect to see in the
window-list-applet?', I'd say 'windows, of course'. To illustrate: try as you
might, gcalctool you will never succeed in making gcalctool document centric,
yet it should still be shown in the window list.

Target Milestone: 1.6 -> 1.8

Is there a quick hack to always use the application icon on the GNOME task list?

Fixed since version 1.9.x.

I'm not sure this has been done in a consistant fashion...

The name of the window reflects the web page in question. Shouldn't then all windows be labeled "Epiphany"? Why is a name different from an icon?

This should definitely be reconsidered, for reasons of desktop-wide consistency.

> Imagine the Nautilus application's icon changing based on
> whether it is viewing a folder, desktop, home, a network reference, or viewing a
> document or thumbnail.

Nautilus in GNOME's default Spatial mode DOES change its icon depending on what folder is currently being viewed. This allows users with lots of Nautilus windows to easily differentiate between them.

Eye of Gnome also changes its icon to a thumbnail of the current image being viewed.

Gaim, while not an offical part of the GNOME desktop, also uses buddy icons as window icons.

The GIMP, while also not an official part of the GNOME desktop, also thumbnails the current document and uses that as the window icon.


Perhaps Epiphany should use favicons for window icons unless tabs are being used (or maybe if all tabs in a window use the same favicon, Epiphany could use that favicon), in which case it would use the current Epiphany icon - this would make it similar to Nautilus' current behaviour (Spatial vs. Browser modes).