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

[Celeste Lyn Paul <celeste@xxxxxxx>]

On Sat, Sep 5, 2009 at 3:28 AM, mac_v<drkvi-a@xxxxxxxxx> wrote:
> On Fri, 2009-09-04 at 16:45 -0400, Celeste Lyn Paul wrote:
>> 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.
>>
>
> The real question is "Why not?" why shouldn't it behave as a launcher
> too!
>
> They've already accepted that
> it will be allowed to blacklist/remove apps from the menu ,
> and if no app is using the menu , the icon wont be shown.
> also that the menu would only have limited number of entries and not be
> a comprehensive status dashboard.
> So, now it doesnt hurt anyone who doesnt want to use it and wouldnt spam
> the menu!
>
> I dont see any reason to prevent this new function just because it wasnt
> the "initial goal" !
> So are apps never supposed to add new functions which were not the
> initial goal?
>
> Anyone subscribed to the wiki page would realize that the messaging menu
> specs are changed almost every other day[in the past couple of weeks].
> They seem to be testing it and trying to find a proper solution! I think
> if we are a *little patient* the plans would become clear,eventually.
>
> I *really* [cant stress this enough] like the idea of messaging-menu +
> launching capability , this is a nice idea and hope they dont backtrack
> because of a few questions of this not being the "initial goal" .

If it turns into a dashboard, fine. Just update your documentation so
the rest of us realize this :)


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