Window titles

[Andrew Cowie]

What is the current correct behaviour for window titles?

I'm working in something right now that manipulates documents; I could
do:

blah.xml
blah.xml - Program
Chapter Title
Chapter Title - Program

When I researched the HIG on this (some years ago, admittedly), the
advice boiled down to what I wrote in our API documentation for Window's
setTitle(),
http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/Window.html#setTitle(java.lang.String)

However,

Judging by this screenshot I took of the window selector applet's popup
list, we're all over the map at the moment (which is to say people are
still doing their own thing, and whatever GNOME's policy is, it's not
being enforced very well),
http://research.operationaldynamics.com/files/andrew/WindowTitles_Screenshot.png

It's also obvious that we're still getting dealing with the hangover
from when someone thought it would be cool to have programs called "Web
Browser" instead of Epiphany, etc — so we see some programs calling
themselves "Sound Reorder", some saying a document title / email subject
(only), some saying  "path/to/filename.ext - Application", "Inbox (1849
total) - Evolution", and permutations thereon.

I must admit I'm worryingly tempted to do "Document Title -
Application". But I also know there was once a push to have only the
shorter form along with the icons to identify application. But given the
kill-the-icons meme that's suddenly turned up around here, it no longer
seems a good idea to be de-emphasizing one's application's name.

So anyone care to put a stake in the ground about what is correct?

[be that "now" or in the "post 3.0 world", but in either case feel free
to speculate about what we're going to do to make the Entire Desktop
Experience actually consistent in this regard, because if we don't, then
what's the point of having a policy?]

Cheers,

AfC
Sydney


--
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.

http://www.operationaldynamics.com/


_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Patryk Zawadzki]

On Sat, Nov 14, 2009 at 10:58 AM, Andrew Cowie
<andrew@...> wrote:

> What is the current correct behaviour for window titles?
>
> I'm working in something right now that manipulates documents; I could
> do:
>
> blah.xml
> blah.xml - Program
> Chapter Title
> Chapter Title - Program
>
> When I researched the HIG on this (some years ago, admittedly), the
> advice boiled down to what I wrote in our API documentation for Window's
> setTitle(),
> http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/Window.html#setTitle(java.lang.String)
>
> However,
>
> Judging by this screenshot I took of the window selector applet's popup
> list, we're all over the map at the moment (which is to say people are
> still doing their own thing, and whatever GNOME's policy is, it's not
> being enforced very well),
> http://research.operationaldynamics.com/files/andrew/WindowTitles_Screenshot.png

It's never really been standardized, even the API docs above seem more
like a hint than a requirement.

> It's also obvious that we're still getting dealing with the hangover
> from when someone thought it would be cool to have programs called "Web
> Browser" instead of Epiphany, etc — so we see some programs calling
> themselves "Sound Reorder", some saying a document title / email subject
> (only), some saying  "path/to/filename.ext - Application", "Inbox (1849
> total) - Evolution", and permutations thereon.

I think it makes most sense if document-driven apps (abiword,
gnumeric, file-roller etc.) just show the document name while
task-centric apps (evolution, transmission) show their purpose
followed by a short summary ("e-mail - 25 unread").

Evolution's current behavior makes it a moving target. The window
constantly renames itself each time you switch folders. IMHO it should
only change the first part of the title when you switch from e-mail to
calendar or address book.

> I must admit I'm worryingly tempted to do "Document Title -
> Application". But I also know there was once a push to have only the
> shorter form along with the icons to identify application. But given the
> kill-the-icons meme that's suddenly turned up around here, it no longer
> seems a good idea to be de-emphasizing one's application's name.

Only purely decorative icons were dropped, app icons and document
icons are here to stay.

--
Patryk Zawadzki
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Calum Benson]

On 14 Nov 2009, at 09:58, Andrew Cowie wrote:

> So anyone care to put a stake in the ground about what is correct?

Well, the HIG advice hasn't really changed over the years:
<http://library.gnome.org/devel/hig-book/stable/windows-primary.html.en#primary-window-titles>

However, just when it's all looking fairly straightforward, it wimps out at the end by saying "If you plan to include your application's name in the title of a primary window...", without saying when/why that might be an acceptable practice.  This, IIRC, was one of the concessions we made to some maintainers who weren't happy that their pet project name might not be appearing on the screen any more, whether or not it was of any use to anyone.

Like most things in the HIG, all of this will most likely be up for review once we start to properly shape the user experience for 3.0.

Cheeri,
Calum.

--
CALUM BENSON, Interaction Designer     Sun Microsystems Ireland
mailto:calum.benson@...            OpenSolaris Desktop Team
http://blogs.sun.com/calum             [phone]

Any opinions are personal and not necessarily those of Sun Microsystems

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[William Jon McCann-3]

Hi Calum,

On Tue, Nov 17, 2009 at 1:27 PM, Calum Benson <Calum.Benson@...> wrote:
>
> On 14 Nov 2009, at 09:58, Andrew Cowie wrote:
>
>> So anyone care to put a stake in the ground about what is correct?
>
> Well, the HIG advice hasn't really changed over the years:
> <http://library.gnome.org/devel/hig-book/stable/windows-primary.html.en#primary-window-titles>
>
> However, just when it's all looking fairly straightforward, it wimps out at the end by saying "If you plan to include your application's name in the title of a primary window...", without saying when/why that might be an acceptable practice.  This, IIRC, was one of the concessions we made to some maintainers who weren't happy that their pet project name might not be appearing on the screen any more, whether or not it was of any use to anyone.


In my view it seems like the only part of those recommendations that
should change for the shell is to remove this:
"While document names are most pertinent to users, we understand that
application developers may want to increase recognition of their
application. If you plan to include your application's name in the
title of a primary window, use the following format: Document Name -
Application Name. This will ensure that the document name appears in
limited space situations such as the system window list."

We will have an application menu at the top of the screen that will
serve the purpose of identifying the application.

> Like most things in the HIG, all of this will most likely be up for review once we start to properly shape the user experience for 3.0.

Well, really now is the time.  We are in the process of shaping the
user experience for 3.0.  I encourage designers from Sun, Novell,
Canonical etc to get involved now - while there is still time.  I've
literally been begging for involvement from these companies for a year
now.  And unfortunately, we haven't gotten much if any help yet.  I
don't know why.

Thanks,
Jon
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Andrew Cowie]

On Tue, 2009-11-17 at 18:27 +0000, Calum Benson quotes from HIG:
> "If you plan to include your application's name in the title of a
> primary window..."

Since I wrote my first message, I've come to realize that the *only*
windows on the desktop that _don't_ have applications in the title are
_some_ "GNOME" ones. But in day to day usage, we see

        Document - Inkscape
        Document - Mozilla Firefox
        Document - Open Office
        Inbox - Evolution
        source - Eclipse

Indeed, in regular use,

        Document

from Epiphany [which is what I actually use] is essentially the only
major app not following this practise.

Obviously there are lots of !GNOME apps in that list. But the point
remains that unless something strong [social? technical?] is acting to
constrain it, the in practice default out there is Application names in
titles, and we are the ones rocking the boat and being inconsistent.

[I also borrowed a Microsoft Windows computer for 30 minutes, and noted
that essentially *every* app on this admittedly small sample  identifies
itself this way. I used to think that the GNOME idea of not doing this
and strongly associating windows with application icons was so cool. But
nothing on my in-use GNOME Desktop apart from a few utility programs
actually does this. There's a big gap between premise and practise]

Anyway, looking at that list, it was obvious to me that the consistent
thing to do was to do what the HIG allows and put my application's name
in the title bar. I'm not happy about that (though it did have one
beneficial effect¹) but at least its consistent with the rest of the
desktop.

:(

On Tue, 2009-11-17 at 14:16 -0500, William Jon McCann writes:

> We will have an application menu at the top of the screen that will
> serve the purpose of identifying the application.

Huh.

A what?

Is this like the Global Menu (that works great, incidentally) that was
just rejected by release-team GNOME since it wasn't compatible with
GNOME Shell? [ok, I get that globalemenu is an applet presently, but I
was of the impression that the idea itself had been torpedoed, which I
thought a shame].

>
> Well, really now is the time.  We are in the process of shaping the
> user experience for 3.0.
>
Indeed.

The debacle about removing menu & button icons from everywhere by
default without investing a huge effort to get applications to port
their code so that important icons are actually so marked indicates that
we're really lacking something in GNOME. The release-team new modules
inclusion process is fairly visible. The API and ABI stability
requirements are well established. But there's no stability in user
experience.

I would suggest that the HIG (or a replacement thereof) is the place to
get this right. The user experience of Shell — and that of applications
that are intended to be compatible with it — really needs to be
*defined* there. And then enforced. And then changes to that standard
need to be vetted and fought against just like changes to anything else
in GNOME.

Enforced?

Tricky.

AfC
Sydney


¹ So the unexpected thing was that having "Application" always present
in the title bar meant that when you first type the characters of the
field that is driving the . Try it composing a message in Evolution;
when you type the first letter 'H' of the Subject, you snap from

        Compose Message

in the title bar to

        H
        He
        Hel
        ...

which looks sort of ok once it gets going, but bloody awful and jarring
when it snaps from "Compose Message" to "H".

Going from

        Application

to

        H - Application
        He - Application
        Hel - Application
        ...

and so on actually looks really smooth (ooooh, animation :)) I'd go back
to document title only if I could just figure out an elegant way for the
experience of actually entering the title not to be jarring.



_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Jud Craft]

>> We will have an application menu at the top of the screen that will
>> serve the purpose of identifying the application.
>
> Huh.
>
> A what?
>
> Is this like the Global Menu (that works great, incidentally) that was
> just rejected by release-team GNOME since it wasn't compatible with
> GNOME Shell?

Minor side-note:  the "Application menu" in Shell is similar to
the...well, to the Application menu that is part of gnome-global-menu.
 It shows the current application.

I like Global-Menu -- it's like the most functional GTK menu hack out
there -- but it -should- be torpedoed.

The reason is because their method (retrieving the GTK menus over
D-Bus) is inherently limited.  It only supports basic menu options.
Try using Banshee for example -- the cool formatting in menus (bold,
italic) and the extra widgets (like the rating menu option) are
broken, because it doesn't fit the "icon + label" menu choice paradigm
that they use.

So it's a cool toy, but a -true- global menu needs to be just as
flexible as real GTK menus.  They really need to reform Global Menu to
be a specification that can be used by a program (Similar to how GTK
on Mac OSX specifies one line of code needed to integrate with the OS
X global menu, that Banshee and MonoDevelop use -- this API should be
supported with Global Menu instead of a dumb but cool hack).

In addition, although the whole "applets don't fit into Shell" thing
is a problem, the fact is that the GNOME Panel experience with applets
deserves to be torpedoed and replaced with a better system (although I
don't think Shell's Javascript is it).

Personally, since Shell intentionally aims for a "document-centered
UI", I wish they had purposefully created their own global menu
implementation (maybe based on the GTK-OS X API mentioned, for
consistency) and supported it intimately from the start.

Since the GNOME 3.0 platform is approaching, it would be an excellent
time to actually introduce new GTK UI API, rather than just letting
the toolkit stay stagnant while the main shell changes.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Frederic Peters-5]

Hi Jon,

> > Like most things in the HIG, all of this will most likely be up
> > for review once we start to properly shape the user experience for
> > 3.0.
>
> Well, really now is the time.  We are in the process of shaping the
> user experience for 3.0.  I encourage designers from Sun, Novell,
> Canonical etc to get involved now - while there is still time.  I've
> literally been begging for involvement from these companies for a year
> now.  And unfortunately, we haven't gotten much if any help yet.  I
> don't know why.

Perhaps the usability list has been seen as a bikeshedding list, far
from useful, certainly it has been less active in recent years, but it
would have been a perfect place to request for involvement (to answer
your "why").  Prhaps it could be refocused to be about "user
experience", and getting together usability people, designers and
artists.

With both you and Jeremy Perry who are working hard on the shell
design, with Andreas Nilsson and friends¹, with the experienced people
from Sun, with designers from OpenSUSE and Ubuntu, in an open but
focused channel, we could assert we have a trusted team in charge, and
avoid accusations of changes being made by lone runners.


Cheers,

        Frederic

¹ 4AF9E957.6000404@..., "The people in the room was me, Hylke
Bons, Vinicius Depizzol, Jakub Steiner, Garrett Lesarge, Benjamin Berg
and Kalle Persson."
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Calum Benson]

On 17 Nov 2009, at 19:16, William Jon McCann wrote:

> Well, really now is the time.  We are in the process of shaping the
> user experience for 3.0.  I encourage designers from Sun, Novell,
> Canonical etc to get involved now - while there is still time.

Absolutely agree, and as you'll hopefully have seen on the usability list and elsewhere recently, there's certainly some efforts to rejuvenate some kind of semi-formal usability group to get stuck right into it.  I think we have some good ideas about how we want the HIG to evolve, just need to get started on that, and on some of the other usability activities we'd like to be doing, too.

> I've literally been begging for involvement from these companies for a year
> now.  And unfortunately, we haven't gotten much if any help yet.  I
> don't know why.

Can't speak for the others, but on my front it's simply been lack of availability :/ I've been tied up  with other Sun projects, and in non-work hours with moving house, amongst other things.

All that means I've barely even had a chance to look at gnome-shell yet, either, let alone make any meaningful contribution to any discussions about it, which is rather frustrating.  (It doesn't help that it's a bit of a pain to build and run on OpenSolaris at the moment, and that it doesn't work all that nicely on other distros running in VirtualBox, where it would be theoretically easier to play with).

Cheeri,
Calum.

--
CALUM BENSON, Interaction Designer     Sun Microsystems Ireland
mailto:calum.benson@...            OpenSolaris Desktop Team
http://blogs.sun.com/calum             [phone]

Any opinions are personal and not necessarily those of Sun Microsystems

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list