unity-design team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxx>]

On 19/03/10 11:38, Jim Rorie wrote:
>
> On Fri, 2010-03-19 at 08:31 +0000, Mark Shuttleworth wrote:
>   
>> On 15/03/10 18:01, Jim Rorie wrote:
>>     
>   
>>  - ethereal notifications for things you can afford to miss
>>  - indicators for things that should persist (even across a reboot)
>>     
>
>   
>>  - we'll try to create indicators which serve a general purpose and can
>> be used by multiple related apps
>>
>>     
>
> This is the problem I'm pointing out.  I don't see any flaw with what
> you've implemented. It's what you haven't YET that is causing problems.
>
> Applications need a general purpose spec blessed by Ayatana to resolve
> the interactivity problem NOW, or they will create their own solutions.
> The resulting workarounds will all differ in look and feel, much like
> the panel icon context menu that you are trying to fix with the IA.  You
> will spend time trying to fix this problem and likely annoy developers.
> And it could have been avoided.
>
> Before you pulled the functionality of the old notifier, you should have
> had AT LEAST A SPEC in place for the handling of new interactive
> notifications.  Work something out fully now and silence the criticism.
>   

That's fair, but we've taken a different line. If you take a look at
MPT's work you'll see very extensive specifications for elements on the
panel. It's not yet complete, but it's very substantial. It will get to
complete, and it will get implemented. But trying to define everything
in advance is a recipe for thankless years and no code. So, we're making
a start where we can.

It's also true that we don't know exactly how it will work out. Elements
of the panel, like the session menu, me menu, and the messaging menu,
share subtle but interlinked relationships. Are you online? That's in
the me menu. Has someone sent you a message because you're online?
That's in the messaging menu. I can't pretend we are totally sure we
know how the pieces will fit best, so we have to iterate and experiment.
Perhaps someone knows where the tablets are that define the perfect
solution, but I don't, so we are making a start, and evaluating as we go.

The API's concerned have to stay fluid, to enable us to iterate. In due
course, things will settle down, we can commit to the API's for extended
periods in the way that GNOME requires, we will also hopefully have KDE
on board so that KDE apps work well on desktops that use this framework,
and we can move on to other work.

Expect bumps on the road, but frankly, the panel was such a disaster of
unusability that those bumps are worthwhile.

Mark

Attachment: signature.asc
Description: OpenPGP digital signature