Re: [Ayatana] Message Indicator: Listing apps in menu even if they are not on

[Celeste Lyn Paul <celeste@xxxxxxx>]

On Fri, Sep 4, 2009 at 2:39 PM, Mark
Shuttleworth<mark.shuttleworth@xxxxxxxxxxxxx> wrote:
> Stuart Langridge wrote:
>
> Am I missing something here? If Pidgin's not running then by definition
> I can't have any messages in it. Is the messaging menu just another
> applications menu but only containing apps which are capable of
> generating messages? That seems not all that useful to me, unless I've
> completely misunderstood the purpose of it.
>
>
> I'll go out on a limb and say that's because y ou are one of the special and
> wonderful breed of people who know what's running on your computer. You may
> even, like me, have your favourite ps incantation to reassure you on the
> subject.
>
> The idea the messaging-menu-launching capability is built on is that users
> tend to go there to see if they have messages first, and if they don't see
> anything, they don't know if it's because "the thing is not running".
> Switching and launching are a blurred experience for many people.

So this is all very confusing because I don't think anyone has
responded about the future purpose of the message indicator.

Currently this how I would expect it to work: The message indicator
will indicate if there is a message there. If there are no messages,
there is no indication. No reason to go to the message indicator. No
reason to go there to launch an application. If there is a message
there, then you go to the message indicator and it tells you what
messages you missed. If you missed a message, want to see more about
it, you click on the message item and it takes you to where you need
to be. If the application is running, then you go to the app or
whatever. If there is a message for an application *not* running,
clicking on the message item will launch the application and load the
message. The latter is an acceptable shortcut to an application
because it is simply supporting the primary activity of the message
indicator: helping users view missed messages, regardless if the
application/service is running.

If an application has *no* messages, there should be no reference to
that application anywhere in the message indicator, regardless if it
is running or not. This includes shortcuts to launch applications. But
the v2 plans for the message indicator wants to provide a shortcut to
applications, regardless if they are running and if they have
messages. Why do users need this? All the message indicator should do
is support messages.

This goes back to my original question of if the message indicator is
turning into something more than an indicator, such as a message
center/dashboard. If not, then there shouldn't be shortcuts to launch
applications, all it does is confuse the purpose of the message
indicator. If it is, then the entire interface will need to be
reevaluated for this repurposing.

> So, while I well agree with the risks of having multiple places to achieve
> something ("launch Quassel") I think this is worth exploring. We need to
> look closely at the phrasing of "launch Quassel" in the menu, to get to the
> heart of the matter ("Get onto IRC"), especially with the *other* work
> ongoing to bring online services under a common experiential umbrella. But
> it's worth trying this, cautiously and tastefully, now.
>
> PS. I think this, on re-reading, might be just my restating of Celeste's
> issue :-)
>
>
> No, I interpreted Celeste's concern to be about the "forced and unbending"
> nature of the exposure in the menu, which I believe should be addressed.

Philosophically, I believe that users ought to have some control over
minor options because we as designers can only strive to get it right
in all cases for all users 80% of the time.

However, in this case I do not believe listing application shortcuts
should be configurable because they shouldnt be there at all*

* If infact the message indicator is indeed an indicator and not
turning into a dashboard, which no one has been able to answer.

-- 
Celeste Lyn Paul
KDE Usability Project
KDE e.V. Board of Directors
www.kde.org