unity-design team mailing list archive
-
unity-design team
-
Mailing list archive
-
Message #02381
Re: memenu and appmenu
2010/5/21 Conscious User <conscioususer@xxxxxxx>
>
> The combination thing is more or less my point: changing status is
> common, and responding to messages is common, what I don't think
> it's common is doing *both* as a reaction to a message (the
> "annoying message" scenario you brought up).
>
Annoying messages are only an example.
In the real life, I turn on/off my phone by a switch near the display.
No one use his TV remote control to turn on/off his phone.
This is simply, I think.
>
> > Moreover, all other interfaces similar to Ubuntu indicator (like dock
> > in Mac OS X) work with the behavior that I will.
> > There is a reason, I think. The reason is usability and simplicity.
> > Users expect this, IMHO.
>
> But they do this under a application-oriented intention...
>
Messaging Menu is function-oriented, but each part of it is (partly)
application oriented.
So you can open contacts, see past messages, create a new message, etc.
according to functions of *each application. *
You can *start* to receive messages from applications through it, but
you *cannot
stop*.
> A behavior I don't particularly agree with. I agree with
> receiving broadcasts in the messaging menu, but only if
> they are directed at you (thus, messages).
>
Well, this could be only partly reasonable because pratical reasons, not
design.
I think to know the number of unreaded messages from gwibber or pino should
be useful and consistent.
> And none of them include status changing, which is the core of
> my point. :)
>
My point is usability.
To have memenu and messaging menu nearest could be a partial solution.
But a switch to stop messaging from an application should be the goal. This
doesn't involve the global stautus automatically.
>
> Re-reading my previous email, there was an epic fail in my
> part in not making it clear that I wasn't defending the
> developers' point of view (specially because I am not one),
> but my own. My intention was disagreeing with you flat-out
> saying there's no logical reason, because I see one.
>
Well, I never said there are no reasons at all. But this reasons should be
mixed with usability reasons and with simplicity.
It isn't useful to make GUI more complex.
>
> Sorry for the confusion.
>
>
> That's a very interesting point of view, because a lot of
> people agree that the text field in the Me Menu should be
> for IM custom status. I personally think an experiment
> where it would do *both* would be very interesting.
>
I think this too.
> And, by the way, presenting my view includes disagreeing
> with Mark *and* specifications if necessary. :)
>
Well, it was a misunderstanding.
Gospel says: "The Sabbath was made for man, not man for the Sabbath" (Mark
2:27)
So I think specifications are made for users, not users for the
specifications :)
>
> If you felt offended by any of
> them, I am sorry.
> Let's just have a beer and keep discussing productively. :)
No problem, have a beer for me :)
> (in particular, the very interesting "IMs have broadcast
> functions" point you brought up is something I'd like to
> focus on)
>
Yes, but I think this is a separated topic.
References