Re: [Ayatana] Notify OSD: Talk about giving the user preferences

[Luke Benstead]

While I appreciate the work that is being done to determine a position
for the notifications that is suitable for most users, I feel that
really this default should be just that. There should be some way
(through gconf-editor if need be) that the position can be altered
away from the default.

There are several reasons for this, the most obvious one is that not
all people like the notifications in the same location, each user is
different after all. But also, with the entire GNOME desktop being
largely configurable, with panels that can be docked at any side,
window buttons that can be relocated etc. the default position will
not be suitable 100% of the time for 100% of the users, it simply
cannot be - nothing is that simple unfortunately. However, my main
reason for asking (begging?) for some kind of configuration of
position is that some people with problems with their vision need this
kind of configuration. In a bug report (forum post?) I was reading
recently (I can't find it now) there was a user who couldn't see the
notifications in their new location because of his poor peripheral
vision, but he was unable to restore the old location.

I personally would prefer the notifications at the lower right of the
screen so they don't cover the FF search box while I'm typing, others
have been pleased with the new location in the middle and many loved
the old location. Some kind of option for configuring this would
please everyone. Would patches be accepted for this kind of change?

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Notify OSD: Talk about giving the user preferences

[Luke Benstead]

You did used to be able to configure the old ones by going to
System->Preferences->Pop-Up Notifications and those popups were
closable if they were in the way, so it kinda matters more now that
the notifications can only be made translucent rather than disappear
completely.

Luke.

2009/8/29 Toni Ruottu :
> In the old days Ubuntu had those funny comic book bubbles used for
> notification. Afaik there was no way to configure them. If users
> didn't find the default placement awkward then, why would they now.
> What has gone worse?
>
>  --Toni
>
> On Sat, Aug 29, 2009 at 10:45 AM, David
> Bensimon wrote:
>> Reading the entire "[Ayatana] New notification placement" thread, while
>> at the same time testing karmic, got me thinking about notifications. I
>> find that a lot of attention is being given to the positioning and
>> behaviour, but little consideration is being given to a users
>> preference. Notification have many attributes (position, timing,
>> effects) that could be user editable.
>>
>> I have to agree with both Angel and Luke that although a default
>> positioning and behaviour needs to be chosen, ultimately the power of
>> choice should be given to the end user.
>>
>> Where the notification configuration would reside could be a tough
>> choice. My preference from most to least favourite would be:
>> 1) "Appearance" preferences
>> 2) A new "Notifications" preference option (seen in Jaunty Alpha/Beta)
>> 3) gconf database
>>
>> Regards,
>>
>> David
>>
>> ___
>> Mailing list: https://launchpad.net/~ayatana
>> Post to     : ayatana@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~ayatana
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Notify OSD: Talk about giving the user preferences

[Luke Benstead]

> The main problem here, which Mark has hit upon in previous emails, is
> that while more configuration sounds nice and simple in theory, it
> creates buggy and inelegant applications. Each option added creates
> another code path to develop, maintain, and test. Even a simple binary
> checkbox theoretically doubles the the number of possible
> configurations as you have all the possibilities you did before with
> the option unchecked, and now that same number with the new option
> checked. It can really be a drain on new features and overall quality,
> which would be a disservice to users.

I totally agree. However in this particular instance, the inability to
configure the location, conflicts with GNOME's general ability to be
configured (i.e. screen elements can be positioned to a users
preference and the notifications may conflict with that). Also, my
accessibility point stands, some users have better vision in certain
portions of their view and would prefer the notifications where they
can see them. I totally agree that the options should be limited, I
don't think the size, colour, animation style, duration etc. of the
notifications need to be configurable (font-size definitely so for
accessibility, but I believe that's already the case) positioning is
necessary though IMO.

>
> That said, users are different and some basic configuration options
> can be beneficial. It is just a fine line on a slippery slope, and I
> think there is a lot that can be done with good defaults and
> intelligent behavior, instead of working around a lack thereof with
> lots of configuration options.

Yep, sane defaults make sense. But in some circumstances we should be
able to change them. I'll give an example, the Pidgin developers
decision to make the input box non-resizable was a sane change to
make. It didn't really affect anyone, no-one suddenly couldn't see the
box, it didn't interfere with any users daily work, it just may not
have been their preference and I believe it was a good decision, it
didn't take me long to get used to it and now I don't even think about
it.

However, right now on Jaunty, if I'm typing into the Firefox search
box and a notification comes in, it interrupts me. As I've mentioned a
few times, people with poor vision may not even see the notifications
in the chosen position (I believe this is the most serious issue
really). Users who arrange their desktop in a non-default way (e.g.
have desktop widgets in that location, have an app with a sidebar
there etc.) will be disrupted by the notifications. Yes they fade if
you hover them, but that's still an action you must perform, and
something that a slight configurability will remedy.

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Notify OSD: Talk about giving the user preferences

[Luke Benstead]

I've just seen this:

"notify-osd (0.9.20-0ubuntu1) karmic; urgency=low

  * New upstream version:
- added support for integer gconf-key "/apps/notify-osd/gravity"
- supported values are 1 (NorthEast, top-right) and 2 (East,
vertically centered at right of screen)
- switch back default positioning to NorthEast (top-right)"

Just wanted to say thank you to whoever is responsible for providing the choice.

Luke.

P.S A south-east option would be awesome ;)

2009/9/1 Luke Benstead :
>> The main problem here, which Mark has hit upon in previous emails, is
>> that while more configuration sounds nice and simple in theory, it
>> creates buggy and inelegant applications. Each option added creates
>> another code path to develop, maintain, and test. Even a simple binary
>> checkbox theoretically doubles the the number of possible
>> configurations as you have all the possibilities you did before with
>> the option unchecked, and now that same number with the new option
>> checked. It can really be a drain on new features and overall quality,
>> which would be a disservice to users.
>
> I totally agree. However in this particular instance, the inability to
> configure the location, conflicts with GNOME's general ability to be
> configured (i.e. screen elements can be positioned to a users
> preference and the notifications may conflict with that). Also, my
> accessibility point stands, some users have better vision in certain
> portions of their view and would prefer the notifications where they
> can see them. I totally agree that the options should be limited, I
> don't think the size, colour, animation style, duration etc. of the
> notifications need to be configurable (font-size definitely so for
> accessibility, but I believe that's already the case) positioning is
> necessary though IMO.
>
>>
>> That said, users are different and some basic configuration options
>> can be beneficial. It is just a fine line on a slippery slope, and I
>> think there is a lot that can be done with good defaults and
>> intelligent behavior, instead of working around a lack thereof with
>> lots of configuration options.
>
> Yep, sane defaults make sense. But in some circumstances we should be
> able to change them. I'll give an example, the Pidgin developers
> decision to make the input box non-resizable was a sane change to
> make. It didn't really affect anyone, no-one suddenly couldn't see the
> box, it didn't interfere with any users daily work, it just may not
> have been their preference and I believe it was a good decision, it
> didn't take me long to get used to it and now I don't even think about
> it.
>
> However, right now on Jaunty, if I'm typing into the Firefox search
> box and a notification comes in, it interrupts me. As I've mentioned a
> few times, people with poor vision may not even see the notifications
> in the chosen position (I believe this is the most serious issue
> really). Users who arrange their desktop in a non-default way (e.g.
> have desktop widgets in that location, have an app with a sidebar
> there etc.) will be disrupted by the notifications. Yes they fade if
> you hover them, but that's still an action you must perform, and
> something that a slight configurability will remedy.
>
> Luke.
>

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Luke Benstead]

> That's where we settled for 9.10. For 10.04 I would like to revisit the
> midpoint of the right hand side. I would not want to rehash old territory,
> so please factor in the above in proposing new ideas. I'm of the view that
> this decision involves at least one ugly compromise no matter which way it
> goes, and am happy to make the call so far (i.e. happy to be the one with
> the thick skin).
>
> If there is an implementation which avoids the issues and is sane, I'd love
> to include it.
>
> Mark
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>

Is having async notifications grow upwards really a problem? I think
that would actually look pretty good with sync notifications at the
bottom, and async slightly above showing a kind of scrolling effect as
more text comes in.  As there would be nothing above the async bubbles
they won't be moving any other screen decoration. If that was the
case, then there isn't much along the bottom of the screen in most
applications that could be disrupted. People read down the page so if
the bubbles were bottom-centre I don't think they'd get in the way so
much, they could also then be wider and shorter.

I still think the most awesome solution would be to allow the
notifications to be dragged around the screen to where the use prefers
though. ;)

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Luke Benstead]

> In general, no. If the ideas they express are better, but the metrics we can
> bring to bear (including the view of the people to whom the design
> leadership has been given) then those patches can be included without
> options, the default behaviour will be improved for all. If they just create
> options for options sake, no. That creates complexity and cruft in code. Go
> and look at the consequences of that, it's all around you. Poor testing,
> poor quality, poor consistency.

I think the reason that notify-osd's positioning is a particular
sticking point with many people is that it is something where no
default location will suit the majority of people. Users with visual
problems, non-default layouts, applications that have elements right
where the notification pops up all would like, perhaps need, some way
to move them out of the way. And the real reason that it causes such
an issue with people is it's a bloody good idea and they want to be
able to use it.

I understand fully what you are saying about both sensible defaults,
and how too much configuration is a bad thing, (I'm a programmer, I
know how much more work it adds to make something configurable) but
sometimes you need to allow some kind of override switch.

Look at it this way, every decision you make when designing software,
you weigh up the pros and cons of all the options before you make it.
When neither option has any concrete benefit over the other, that's
when it's down to personal preference and that (I would argue) is when
you make it configurable and then, only then when it's worth the extra
work. I would say that notify-osd's positioning is one of those
occasions.

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Luke Benstead]

>
> So, probably, the solution is rather to find some clever algorithm that
> places them dynamically based on the current desktop conditions, but we
> won't be motivated to search for this algorithm if we resort to creating
> more options as soon as someone complaints.

Heh, OK you've almost won me over, the thing is, allowing overriding
of the default position would be a solution that could happen right
now, and would please people until this algorithm comes about. But I
do see your point.

Personally, somewhere along the bottom would solve all the issues I
can think of (window decorations, firefox search bar/box etc.) - the
only thing against that is what Mark said about the async
notifications growing upwards, but I still don't see why that's a
problem (it would look pretty cool if the existing text moved up, then
the new line faded in below).

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Luke Benstead]

2009/10/21 Mark Shuttleworth :
> Luke Benstead wrote:
>
> The only thing against that is what Mark said about the async
> notifications growing upwards, but I still don't see why that's a
> problem (it would look pretty cool if the existing text moved up, then
> the new line faded in below).
>
> That would be worth a flash mockup, or code mockup, to see in practice.
>

Err.. ok... anyone any good with Flash? Or could someone point me at
an OSS app that makes Flash animations?

Thanks,

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Luke Benstead]

2009/10/21 Johan Euphrosine :
> On Wed, 2009-10-21 at 18:09 +0100, Mark Shuttleworth wrote:
>> That would be worth a flash mockup, or code mockup, to see in
>> practice.
>>
>
> Hi,
>
> Here is a tentative clutter mockup:
> http://bitbucket.org/proppy/clutter-repl/raw/2f7b36efb1fe/logs/session13.ogv
>
> Luke, let me know if it implements properly the behavior you described.
>
> Hope that helps.
>
> --
> Johan Euphrosine 
> Development and services around Free Software
> http://aminche.com/
>

You legend! Yeah, exactly that kind of thing, I think it would look pretty cool.

Thanks a lot!

So, good idea?

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Luke Benstead]

2009/10/21 Matt Wheeler :
> 2009/10/21 Luke Benstead :
>> You legend! Yeah, exactly that kind of thing, I think it would look pretty 
>> cool.
>>
>> Thanks a lot!
>>
>> So, good idea?
>
> Are you actually suggesting that messages that stay visible for longer
> should bob up and down depending on whether there is a newer message
> beneath it?
> (if that is not the case then perhaps the messages in the video need
> to be numbered rather than just labelled "new" and "old").
>
>
>
> --
> Matt Wheeler
> m...@funkyhat.org
>

No. At the moment in the top-right, notify-osd displays sync
notifications above the async versions. Mark said that one of the
reasons why the notifications are at the top of the screen is that
async notifications can grow. At the top of the screen when a new line
is added, the bubble grows downwards. The mockup is to show that you
can move the text upwards and fade in the next text when it grows, so
the bubbles can grow upwards and still look good. At the bottom of the
screen the sync notifications would be below the async so that bubbles
don't move around when the async grows. Make sense? It make sense in
my head at least :p

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Luke Benstead]

2009/10/21 Martin Albisetti :
> Mark Shuttleworth wrote:
>>
>> Johan Euphrosine wrote:
>>>
>>> Here is better mockup:
>>>
>>> http://bitbucket.org/proppy/clutter-repl/raw/4b8460e1e300/logs/session14.ogv
>>>
>>
>> Let's hear what others think.
>
> It feels odd to read from the bottom to the top. I played around with moving
> things on the screen upwards and downwards, and it's easier to follow them
> as they go down rather than up.
>

It's funny you should say that, because this way it mimics the
behaviour of IM clients such as Empathy and Pidgin (previous text
scrolls up, the most recent appears at the bottom).

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Luke Benstead]

> In IM clients the text does not disappear , so you can take your time to
> catch up with the text.
> Try this , try reading text in an irc chat room with heavy traffic,[eg:
> #ubuntu]. You'll notice it is not easy to catch up.
>

Thinking about it, I don't believe comparisons with IM or IRC are fair
(I know, it was I who first compared to IM :p )

Both IM and IRC have a major difference in that the scrolling text is
from multiple sources (users) whereas notification bubbles come from
one source. Context switching like this will obviously take longer to
read than text from a single source. Also, the sheer quantity of text
to read in both IM and IRC is far more than your typical notification
bubble. Finally, in the notification bubble we can make the text slide
up, rather than jump up, and also fiddle with the display time and the
width of the bubble (so more text fits on a single line). I'm not
convinced that text scrolling up in the notification bubbles will
actually cause a problem.

> What we could do is:
> - Place the Async bubbles in the lower right, at a height keeping in
> mind the max[10 lines] allowed for append. So the bubble is in the lower
> right position but not exactly in the corner. This would make the
> bubbles not have a problem of scrolling text.
> - Place the sync bubbles to be in the lower center. At the same height
> as the async bubbles but centered. [Similar to where the upstream
> volume/brightness notifications are placed]
>
> -OR-
>
> - Revert back to the dynamic positioning of the bubbles and place the
> bubbles in the lower right at the height assuming for 10 lines of text.
>
>
>
> Then again we might get complaints that the bubbles are not exactly in
> the corner... ;)
>

I think either of those solutions could work. The point of my original
suggestion was that positioning at the bottom of the screen (where
there are usually fewer screen elements) should not be ruled out just
because the async bubbles will extend. I actually think Johan's
mockups look pretty nice :)

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Regarding Flash like demonstrations

[Luke Benstead]

2009/10/21 Martin Owens :
> On Wed, 2009-10-21 at 18:46 +0100, Luke Benstead wrote:
>>
>> Err.. ok... anyone any good with Flash? Or could someone point me at
>> an OSS app that makes Flash animations?
>
> The only thing close enough would be to hack some SVG using Inkscape and
> a text editor, add on the FakeSmile javascript library for firefox
> compatibility and you might be able to do a demo.
>
> http://doctormo.wordpress.com/2009/06/22/svg-animations-just-like-flash/
>
> http://doctormo.wordpress.com/2009/05/20/who-needs-flash-i-dont-svg-for-me/
>
> At least with a bit of practice you could pull off something interesting
> which can be viewed in a browser. Although we don't as of yet have a
> library to export frames for compilation into videos.
>
> Regards, Martin
>
>

Thanks, those links are really useful!

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Lucid theme - window controls location

[Luke Benstead]

On 12 March 2010 14:26, Siegfried Gevatter  wrote:
> 2010/3/12 David Balch :
>> Please could the design team explain the rationale for moving the
>> window control buttons from the right to the left, and the benefits
>> expected to result.
>
> http://www.ivankamajic.com/?p=281
>
> (I don't like them at all on the left, btw.)
>

There's no rationale for the change in that blog post, just 100+
comments of testers wanting them moved back.

And it finishes with this:

"Is it better or worse?

It is quite hard to tell."

and

"Personally, I would have the max and min on the left and close on the right."

Which would at least be a more usable position than the current one.

Scott's blog post[1] mentions some of the many reasons why this change
is a bad idea, yet I haven't seen a single reason for why it's a good
idea.

So to reiterate the question, what is the rationale for such a
disruptive change? Is it just an experiment that will be reverted
before beta?

Luke.

P.S. Further reading:

[1] http://yokozar.org/blog/archives/194
http://ubuntuforums.org/showthread.php?t=1422422
http://brainstorm.ubuntu.com/idea/23899/
http://www.omgubuntu.co.uk/2010/03/poll-do-you-want-ubuntu-window-controls.html
http://www.omgubuntu.co.uk/2010/03/easy-gui-window-button-switcher-for.html
http://jonathancarter.co.za/2010/03/12/purple-vs-orange/

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Tooltips

[Luke Benstead]

> But for the default use, no, we won't animate the "you've got a message"
> icon indefinitely when you've got a message.
>
> Mark
>

I agree that a constant animation would be a bad idea. But is there
any chance of getting a colour change when there are messages waiting?
The current icon (showing the envelope in full brightness) isn't
enough to catch attention when you are working, I've lost track of the
number of times I've missed file transfers and messages over IM over
the last couple of weeks because I don't notice they are waiting. I
don't have this problem in Karmic though, the contrast between icon
states is more definite.

I was thinking it would be cool to show the envelope as Aubergine*
when there are messages :)

Luke.

* Green or Ubuntu Orange would look good too ;)

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Fwd: Proposal of new UI element for windows in Ubuntu: Esfera

[Luke Benstead]

On 26 March 2010 13:53, Jim Rorie  wrote:
> On Fri, 2010-03-26 at 09:30 -0400, Scott Kitterman wrote:
>>
>> "David Siegel"  wrote:
>>
>> >I think maximize, minimize, and close are taken for granted -- they're
>> >unquestioned assumptions carried over from a dusty desktop computing past.
>> >Frankly, I'm not convinced that any of these buttons are worth the price
>> >paid by users in time spent thinking about how to arrange their windows.

I think something worth thinking about is the link between the
minimize/maximize buttons and the window switcher. The window switcher
applet actually duplicates the window button functionality (e.g.
clicking the window in the switcher will minimize or restore the
window depending on its current state).  If we are rethinking the
buttons I think it's redesigning them with the taskbar in mind.

Luke.

P.S. I find the default Gnome taskbar quite cumbersome, DockbarX is a
little better (e.g. one icon per application, all app windows are
listed on hover) but I still think there are massive improvements to
be made here - and I'm still not convinced that Gnome Shell's overview
is the right approach.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Gallery

[Luke Benstead]

On 31 March 2010 07:58, Victor  wrote:
> Thanks for high-lighting that, Martin.
>
> I really like this particular theme.
>

+1

What's really interesting though is it's surprisingly quite feasible.
DockbarX has close to that dock behaviour anyway, with the new RGBA
Gtk+ stuff you could get the theme to work. The applets would
obviously need writing, but it's not an impossible task. I think it
looks awesome :)

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] message indicator.(colour palette)

[Luke Benstead]

On 1 April 2010 10:52, Thorsten Wilms  wrote:
> On Thu, 2010-04-01 at 10:02 +0100, Mark Shuttleworth wrote:
>
>> There should be a rationale and guidance for the use of the various
>> colours. For example, red is clearly an alert colour, as is orange. When
>> would one use red and when orange? Both indicate a caution or warning.
>> Green indicates something that one should be aware of that is NOT a
>> warning or caution, such as a message. So I would expect the document to
>> include:
>
> Leaving color-deficient-vision issues aside (the usual advice is to not
> rely on color alone, but to use other clues such as shape):
>
> Red is used to mean Stop on traffic signs and lights. It stands for
> record armed or in progress in the audio realm.
>
> I'd use orange for warnings and red for state or use only one of the 2.
>
> Taking from traffic and audio again, green stands for go!, you-can-pass,
> playing (playback, not toys). It shouldn't be used if something is not
> in an all-OK state, I think.

Also, someone mentioned (I can't remember where, a forum or something)
that Blue is usually associated with conveying general information
which is certainly the case for road signs in the UK at least, and
searching Google images for "information icon" comes up with a load of
Blue icons :)

I'd suggest that Blue makes more sense for something like "new mail"
rather than Green.

e.g.

Red = Error/Alert
Orange/Amber = Warning (it could be argued that restart required
belongs here really (e.g. security update))
Blue = Information (e.g new mail)
Green = It's OK for you to go ahead and do something (e.g. signing
into something)

Although +1 for the icons changing with the colour.

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Indicators for showing progress

[Luke Benstead]

On a slightly related note, check out Solution #5 from this brainstorm
idea: http://brainstorm.ubuntu.com/idea/24130/

I think that sort of set up would open up a load of possibilities for
tighter integration of notifications of file transfers/downloads/syncs
etc.

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] User feedback from the new WM control order

[Luke Benstead]

Just to quickly add my experience to this. I've not yet accidentally
hit the close button, however I have on several occasions hit minimize
when aiming for the Applications menu. I also tweeted about it in
frustration: http://twitter.com/kazade/status/12155652979

I'm now totally confused, because I'm liking the left side but this
continual mishitting will probably force me to change it, which is a
shame. If we do pick up Gnome Shell for 10.10 where there is a
hoverable "Activities" menu in the same place as the current
Applications menu then I think this will just get worse.

Luke.

On 15 April 2010 09:51, Conscious User  wrote:
>
> I've gave the buttons a chance ever since they were proposed.
> My overall conclusion is that it is not difficult to get used
> to with respect to "forgetting the old habits". After a couple
> of days I was already going always to the left side by instinct.
>
> But I also concluded, from actual incidents, that accidental
> clicks are something that will always sporadically happen
> despite how used to you are. Most of it has to do with the
> thinness of the menu bar.
>
> I've recently moved the buttons back to the right, and for me
> the feel was of closing a papercut: a trivial fix to a small
> but annoying usability issue that is probably affecting a lot
> of users.
>
> When the "exciting ideas for the right" side are actually
> implemented I will give it another chance. Until then, I see
> no reason for deliberately introducing a papercut in my
> desktop for no actual gain. :)
>
>
> Le jeudi 15 avril 2010 à 13:38 +0530, Vishnoo a écrit :
>> Hi,
>>
>> Not to rehash the same old boring topic, but to just give a user
>> feedback from using the 2 new positions of the window controls.
>>
>> I'v been patiently trying to use the new positioning and trying to see
>> if it is better or doesnt really matter.
>>
>> With the "old"[earlier alpha order] order of < max,min,close: >  on the
>> left side, I used to occasionally hit the maximize button instead of
>> hitting the "File" menu in the menubar. But this wasnt a big deal as i
>> could unmaximize the window and no harm was done and nothing was lost.
>>
>> But with the final order < close,min,max: > I find it easier to
>> accidentally *close* the windows and it is rather frustrating when I
>> have to re-open the nautilus window and get back to the location /
>> re-open firefox & re-load all the pages. Luckily most apps ask for
>> confirmation before closing unsaved documents, but still a bit
>> frustrating when being prompted when all i wanted to do was open the
>> "File" menu.
>>
>> >From using the new positions, probably < max,min,close: >  was much
>> better.
>>
>> The close on the left-most probably works better in OSX ,since they have
>> a global menu and the menubar isnt near the window controls.
>> However, we have a very thin menubar [20-25px?] and it is easier to
>> accidentally hit the window controls instead of the menu options.
>>
>> Since I end-up accidentally closing the windows on several occasions , I
>> had sighed and just considered this a PEBKAC and changed the order in my
>> system to < max,min:                       close > [close on the
>> right-side.]
>>
>> What prompted me to send the feedback is, I noticed this >
>> https://twitter.com/popey/statuses/12207605002 and thought there are
>> probably many more users going "D'Oh!", in front of their computer
>> screens which the UX isnt being aware of.
>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] User feedback from the new WM control order

[Luke Benstead]

> I don't think it will be an issue with GNOME Shell, as the top-left corner is 
> a
> hot corner for triggering the overlay mode so you don't need to click the
> button, just flick your cursor to the top left corner. The button is just 
> there
> for discoverability and to provide tablet users with something to poke, I 
> think.

My point is, when moving the mouse to close/min/max you could
inadvertently hit the hot corner, although I don't have Gnome shell
here to test how far that corner extends so it may be a non-issue.

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Making workspaces great (branched from "Farewell to the notification area")

[Luke Benstead]

> I brainstormed a little on your mockup. The attached image shows
> workspaces as tabs, and inside it are the actual applications.
>
> This could easily carry dock functionality as well, where you pin some
> applications to a particular workspace.
>
> --
> Remco
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>

Interestingly I was just about to post a response to this thread with
a similar idea...

The main problem I find with workspaces is their interaction with the
window list. It would be nice if all applications were visible on the
window list all the time *but* grouped into workspaces with an "all
workspaces" section. The "all workspaces" section could take the place
of the current notification area for minimizing apps.

I've attempted to do a quick mockup for what I mean. It's basically a
mix of how DockbarX works (icon for each app, hovering lists the
windows) and grouping of icons based on workspaces. Hovering an icon
would list the windows for that workspace, or if in the "All
workspaces" section it would list all windows for that app (in the
example imagine the cursor is hovering Firefox).

Luke.
<>___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Making workspaces great (branched from "Farewell to the notification area")

[Luke Benstead]

> Interestingly I was just about to post a response to this thread with
> a similar idea...
>
> The main problem I find with workspaces is their interaction with the
> window list. It would be nice if all applications were visible on the
> window list all the time *but* grouped into workspaces with an "all
> workspaces" section. The "all workspaces" section could take the place
> of the current notification area for minimizing apps.
>
> I've attempted to do a quick mockup for what I mean. It's basically a
> mix of how DockbarX works (icon for each app, hovering lists the
> windows) and grouping of icons based on workspaces. Hovering an icon
> would list the windows for that workspace, or if in the "All
> workspaces" section it would list all windows for that app (in the
> example imagine the cursor is hovering Firefox).
>
> Luke.
>

P.S. I meant to mention that dragging windows to each workspace
section would move them from workspace to workspace (or all
workspaces).

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

[Ayatana] Hovering to open items on the top panel

[Luke Benstead]

I've just been thinking about the new indicators, and how there were
some complaints about it adding a click to get to stuff in the menus.
Then I thought, it would be pretty cool if all the menus on the panel
(including Applications, Places, System, Me menu, Indicators and the
calendar ) opened on hover. That would reduce pretty much any action
on the top panel to a single click (e.g. launching a program, opening
a folder, setting your status etc.)

It makes a lot of sense especially with complaints about hitting the
close button on maximized windows accidentally etc. if the
Applications menu appeared on hover that would remove that risk.

Any thoughts?

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Farewell to the notification area

[Luke Benstead]

On 22 April 2010 18:14, Mark Shuttleworth  wrote:
> Conscious User wrote:
>> " 1) Communicating the goals and current status to end users. The amount
>> of people who think the messaging menu is only a launcher, for
>> example, is overwhelming.
>
> If people don't figure out how to use something we designed, the answer
> is to improve the design, and not to mount a campaign to educate them :-)
>

Slightly OT: I know the indicators don't have tooltips as an
experiment to see if they are just cruft, and I know tooltips in the
notification area were being abused just as much as the notification
area itself. But I really think a hint like the ones on the
Application, System and Places menus would help. Even if it was just
"Read incoming messages and launch messaging applications" or
something. Icons can certainly go a long way at conveying the purpose
of something, but does an envelope mean "Send an email" or "Check or
email" or "Start the email program" or "Send a fax"? I think putting
sensible "this does xyz" tooltips might really aid discoverability.

One thing I really like about tooltips is they don't appear
immediately. This sort of mimics life outside of the computer; if you
are to make a decision to do something, you'll sometimes pause to
decide whether it's what you want to do. I find tooltips can give that
nice little nudge to say "yep, you do want this" or "no, this isn't
the menu you're looking for".

Anyway, just my $0.02

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Making workspaces great (branched from "Farewell to the notification area")

[Luke Benstead]

On 23 April 2010 11:10, Vishnoo  wrote:
> On Fri, 2010-04-23 at 10:14 +0100, David Siegel wrote:
>> Guys, this is an excellent discussion. Will someone please volunteer
>> to organize some of what's been said on a wiki page, or Google
>> Doc/Wave, or something? Otherwise these ideas will likely never escape
>> this thread.
>>
>> David
>>
> There you go :
> https://wiki.ubuntu.com/Ayatana/Workspaces/Concepts

Cool, I'm seeing if I can knock together a working implementation of
my mockup in Python. I'll upload it somewhere once it's at least
slightly working (so far it grabs the windows/apps from different
workspaces correctly, I'm just fiddling with the Gtk+ stuff to make it
visible). If I don't have time to finish I'll improve my mockup (the
existing version of which has several flaws after thinking it through)
and upload it there.

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Making workspaces great (branched from "Farewell to the notification area")

[Luke Benstead]

On 23 April 2010 14:17, Roth Robert  wrote:
> I have just been looking at the gnome-shell wikis, and I have found some
> mockups for suggested window management. I think the idea is quite good,
> could replace the workspaces. Someone has already sent a mail with a mockup
> similar to these, but this is a bit more detailed... check them out.
> http://live.gnome.org/GroupBasedWindowManagement

That's basically what I was saying (and implementing). Although I fail
to see what the advantage of re-ordering the groups would be, dragging
the windows between them would be enough IMO.

The other part of my idea is to merge the concepts of old style system
tray icons (e.g. one click to maximize/minimize) with pinned
application windows (e.g. those that appear on all desktops). I think
we can treat these in the same way and they can form a special "Pinned
apps" group like the ones in the mockup. This will allow to nicely
handle apps that don't support indicators, and also Wine applications
that use XEmbed. However, I'm not keen on allowing menus - I don't
wanna recreate the old notification area - so Wine compatibility still
needs some thought.

I've attached a screenshot of what I have so far. It currently only
scans the workspaces at start up (it doesn't listen for window actions
yet) and only works with Compiz disabled because Compiz treats its
multiple workspaces as one really big one which means I need to do
some programmatic trickery to determine where windows actually are.
Still, WIP.

Luke.
<>___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Farewell to the notification area

[Luke Benstead]

On 25 April 2010 18:39, Marc Deslauriers  wrote:
> On Sun, 2010-04-25 at 13:55 -0300, Paulo J. S. Silva wrote:
>> That is the reason while the pop-up/under/what ever is a BAD idea. And
>> the reason is that it is asynchronous, so the user is getting taught
>> to respond to (possibly fake) windows request their password. This is
>> a path for disaster if we ever get remotely close to solving Bug n. 1.
>
> Option #1: Display an icon in the notification area that nobody clicks,
> as a result security updates never get installed and system is
> compromised from the lack of important security updates.
>
> Option #2: Pop-up the update dialog demanding attention, most users
> click to install the important updates and system is secure as system
> security updates are always applied.
>

I really don't see why this is an either/or thing. Display an
indicator showing whether updates are available and give a menu to
allow updates to be installed or the package lists to be refreshed. It
can even glow a nice red if security updates are available, or amber
if they are just normal updates. Then if a user doesn't install them
for a week or whatever THEN give them a more obvious prodding
(although I firmly believe the current solution of popping under a
window is not a good idea for the reasons already mentioned).

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Panel menu in 10.10 Netbook UI

[Luke Benstead]

On 27 April 2010 17:24, Jeremy Nickurak  wrote:
> What about windows with long titles? Web browsers ofter put the title of the
> page you're viewing in the window title, so it's HUGE. Not much extra room,
> if any, in that case.
> Maybe a cut-off title with ... and the full thing in a tooltip?
> Maybe just not merging the menus into the panel if it's too big.
> Conceptually spill-over into the application window.
> Alternatively, is there another place the page title, or other information
> revealed via the window title should end up?
> --
> Jeremy Nickurak -= Email/XMPP: jer...@nickurak.ca =-
>

The most obvious way to handle this is to limit outrageously long
title text, (in the way you suggested with ... and a tooltip) but do
nothing if the window gets too small. For example, resize any window
so that it doesn't fit the menu items - the menu items just get
clipped. I've attached a hacky mockup of what I think, a.) is what
everyone is talking about and b.) is bloody awesome :)

Luke.
<>___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Reducing Resistance to Change

[Luke Benstead]

>> On point 1: Looking at the tooltip bug in particular. The argument was
>> made that "menus don't have tooltips". But the *main* ubuntu menus,
>> for Applications, Places, and System, *all* have tooltips. As far as I
>> know, this was never addressed.
>
> That's easily addressed, thanks for the reminder ;-)
>
> Mark
>

I know it's slightly OT, but I think it would make more sense if menus
without text had tooltips, but menus with text didn't. So essentially
the reverse of what we have now. Because, no matter what we do with
those icons, they are never going to accurately describe exactly what
the menu is for without the user having to click to find out and then
remember. I don't mean restoring the overly verbose and cluttered
tooltips of notification icons past, but just what the menu text would
have said if it was a text menu item. Sort of like the alt="" text of
an HTML image. Of course we can do without tooltips on menus
altogether, and we'll get by, but I think done right they add polish.

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

[Ayatana] Is it time we killed "minimize to tray" ?

[Luke Benstead]

I've been giving this a lot of thought recently, well actually, I've
been irritated into giving it thought after not being able to find my
Rhythmbox window. I've been trying to work out why we have "minimize
to tray" functionality at all and all I can come up with is that it is
because the window-switcher applet is so horrible.

The window switcher applet has a bunch of problems, mainly that each
entry takes up too much space, and with an entry for each window you
fill up the space pretty quickly. When that happens you can't read the
titles of the windows, so you may have 5 Firefox windows and have to
hover over all of them to find the right one. You can, of course,
group them but even then that doesn't really help when each entry
still takes up a large portion of the space and requires a click to
access the windows in the group.

It's because of this shortage of space that I believe "minimize to
tray" exists. Minimize to tray is essentially "I don't need this
window cluttering up my taskbar, but I need to leave it running" and
the only reason I can think that normal bog-standard minimize isn't
suitable here is because the window-switcher is cluttered and the
window gets in the way.

I've been running DockbarX for a little while now, which groups
windows by their application icon, and displays a list of windows with
*full* titles when you hover that icon with the cursor. The massive
advantage of this is that you can open a hell of a lot of applications
before you run out of room, in fact right now I have 12 applications
(even more windows) running and I've not even filled half the panel
and I'm not on a widescreen resolution either. In this situation
minimize to tray is:

a.) Effectively the same thing
b.) A pain to work with because now there are two possible places that
your window could be minimized to

So, my suggestion is that we remove the minimize to tray functionality
from the indicator applet for apps outside the messaging menu and
replace the window-switcher with DockbarX or some other switcher which
follows a similar principle. I'm not saying DockbarX is ideal, but
it's a massive improvement on what we have already.

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Is it time we killed "minimize to tray" ?

[Luke Benstead]

On 5 May 2010 15:42, Victor  wrote:
> No, it is not time.
>

Care to elaborate?

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Is it time we killed "minimize to tray" ?

[Luke Benstead]

On 5 May 2010 20:06, Gavin Langdon  wrote:
> On Wed, May 5, 2010 at 1:19 PM, Jarlath Reidy 
> wrote:
>>
>> A better functioning taskbar would eliminate the need for yet another
>> desktop metaphor. There are too many on the desktop at the moment (double
>> click icons, oh-no, that's a toolbar shortcut, single click that one, single
>> click menu entries and web-links - oh, sorry forgot to mention, that feature
>> is in the right click menu - got all that?!)
>>
>
> I think the main reason developers feel they need a tray icon for their
> applications, and implement a 'minimize to tray' feature, is because they
> don't have control over what information or widgets the taskbar item
> displays when its application is minimized.

This is what the indicator applet is does. Applications can register
with the indicator applet for these kind of functions, unless I'm
misunderstanding?

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

[Ayatana] Export/Import idea for Windicators

[Luke Benstead]

Morning all,

I've just been thinking about Windicators and how they could be
useful. I vaguely remember someone posting an idea (before the
Windicator announcement) of being able to send files and data between
applications. I think Windicators could allow us to do this in a very
consistent way...

My idea is this, each application has two indicators called "Export
to..." and "Import from...". I'm not sure what the icons would look
like to convey those concepts, but that's the general idea. Basically,
these menus would adapt based on:

1. The types of file that the application handles
2. The applications which are open at the time (for "Import from..." only)

This is how it would work for example:

I'm working in Inkscape, I've knocked together an SVG image, but I
want to open it in the Gimp for bitmap editing. So I click the "Export
to.." Windicator and select "The Gimp". This then prompts me to save
the file, before firing up the Gimp with the file open.

Another example, I've been working in OOo Writer. I've written a long
letter and I decide to send it by email. I go to Evolution, and select
"Import from..." and "Writer" is on the list (as it is open). I click
it and it creates a new email with the text inserted from the
document.

Another, I've got an image open in Shotwell. I'd like to post it to
Twitter. I click "Export to..." -> Twitter. This uploads the image to
Twitpic (or similar) and opens up Gwibber with the image link
populated in the input box ready to send.

I could come up with these all day. But basically rather than using
the file manager to find files for opening, we could use Windicators
to pipe data between applications/the Internet.

Comments?

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Export/Import idea for Windicators

[Luke Benstead]

>
> Make sense?
>
> Mark
>
>

Yep, perfectly. I should've really given it more thought before
lumping the idea in with Windicators - it definitely would belong in
the File menu. It's just the kind of thing that would require a
consistent API so that applications would adopt it and Windicators
would have provided that. Oh well :)

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] No "application bucket" needed

[Luke Benstead]

On 17 May 2010 10:52, David Siegel  wrote:
> 
>
> If you are designing an interface, and suddenly you believe you need
> to add a "bucket", this is a good sign that your initial design failed
> somewhere. I would encourage you to "shelve the bucket" and revisit
> your earlier assumptions. Shake things up a bit and ask yourself "what
> could I do differently so that I don't need a 'bucket'?" Challenge
> yourself to make a fundamental change to your design so the bucket
> isn't needed.

As I mentioned in another thread, the *bucket* would just be
duplicating the window switcher, just like minimizing to tray does.
Which are plasters over the fact that the window-switcher applet just
doesn't deal well with many windows - so minimize to tray exists to
free up space. Unity is on the right track with its dock, but is
obviously tailored to netbooks, we could really do with something
similar for the desktop (*cough* dockbarx *cough*) :)

Anyway, ideally we'd have one place to look for application windows,
at the moment we have two (window-switcher and notification
area/indicator applet), potentially several if you factor in
workspaces*.

Luke.

*P.S. I'd love it if whatever window-switcher replacement grouped
windows by workspace, I'd then actually use them.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] No "application bucket" needed

[Luke Benstead]

On 17 May 2010 11:40, David Siegel  wrote:
> More specifically, I'm interested in why people use minimize-to-tray
> instead of regular minimize. My suspicion is that it's easier to
> recall minimized windows by clicking on indicators than by clicking on
> the window list.
>
> If a window "minimizes to tray" instead of closing when the Close
> button is clicked, this just means that Close has become another
> Minimize button, and the tray has become another window list. Ugly!

Like I said, I believe it's simply down to lack of space. The default
window-switcher is rubbish with many windows and truncates titles
quite quickly. Using a dock that uses icons like dockbarx, (which
groups by application and shows full window titles in the apps window
list on hover), I can run my email client, music player etc. minimized
and it doesn't get in my way. Without dockbarx and I start using
minimize to tray for those apps because it clutters the window list.
Most of the feedback from my other Ayatana thread "Is it time to kill
minimize to tray?" seems to indicate other users agree.

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] No "application bucket" needed

[Luke Benstead]

On 17 May 2010 11:58, Mark Shuttleworth  wrote:
> On 17/05/10 11:40, David Siegel wrote:
>> More specifically, I'm interested in why people use minimize-to-tray
>> instead of regular minimize. My suspicion is that it's easier to
>> recall minimized windows by clicking on indicators than by clicking on
>> the window list.
>>
>
> My assumption has been that people want to get the window OUT of the
> Alt-TAB list, and off the task bar.
>
> Mark
>

Alt-TAB list definitely, but I think people only want it off the task
bar because of lack of space. DockbarX has a ppa[1] give it a try,
replace your window-switcher applet and then don't use the
minimize-to-tray functionality of the indicator applets/notification
area. It's much more usable IMO.

If DockbarX also removed minimized windows from the Alt+TAB list - it
would be perfect :D

Luke.

[1] https://launchpad.net/~dockbar-main/+archive/ppa

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] No "application bucket" needed

[Luke Benstead]

> Luke, thank you for the excellent description of your use case.
>
> David

No worries. The window-switcher and minimize-to-tray (I firmly believe
the latter exists because of the former) is my #1 bug bear ;)

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] progress dialog mockups

[Luke Benstead]

On 28 May 2010 15:33, Alex Launi  wrote:

> The indicator should probably convey the cumulative progress so you can
> just flick a glance in the corner and get an idea of the progress without
> having to click or even move the mouse.
>
> --
> -- Alex Launi
>
>
It would be really cool if the icon changed colour to show this... for
example starting really dark blue, getting brighter as the progress moves
on, then turning green at the end to indicate completeness.

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Putting some brakes on the enthusiasm

[Luke Benstead]

> My question is: isn't it time to put some brakes on the
> enthusiasm and start prioritizing polishing instead of new
> features? The current approach is not scalable, and this is
> starting to show...
>

Really just a +1 to everything said. Although I particularly agree with
David Siegel's comment about not shipping things unfinished.

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Opening URL's that point at downloadable objects

[Luke Benstead]

Hi Jeremy,

I think trying to *fix* this situation would be potentially very hard, if
not impossible, to do robustly and correctly. Of course, the reason that
clicking a link opens the web browser is that the browser handles the
http:// protocol, just as it may also handle https:// ftp:// and potentially
others.

Say for example we changed this to what you suggest, and that clicking an
http:// or ftp:// link would first grab the file header, read the mime-type,
and then open the correctly assigned application, what would control the
download process? It's not a simple as just opening it, obviously if the
file was very large, or the connection very slow, there would need to be
some way to cancel the action. So we'd likely need an application for that,
perhaps we can use gvfs and Gnome's built in download manager. But this
still blurs the line of what should be handling what. I assume that if you
were browsing using the web browser, then the browser would have the
opportunity to handle the mime type first before passing it onto the system,
otherwise the Internet just wouldn't work.

I'd argue that we are looking to fix this in the wrong place, really we
should be fixing this in the browser. The web browser is already set up to
consistently handle the protocols assigned with it (along with detecting
unsafe sites, invalid SSL certificates etc.) The only problem is that the
browser is opening up an entire instance (or new tab/window) to download the
file; this is totally unnecessary.

It would be far simpler, more robust, and more cross-desktop compatible to
fix the browser so that it checks the mime-type first before opening a
window, if it's not a mime-type it can handle it should popup the open/save
dialog only. Everything from that point on would behave as it currently
does, with the exception that if the browser process had only spawned to
download that file, then it would exit and if that was the case, there never
would have been a browser window open, just the open/save dialog and the
download dialog.

Luke.


On 3 June 2010 18:24, Jeremy Nickurak  wrote:

> Here's a UI experience pet peeve I'd be curious to hear some feedback
> about, especially with regards to whether it's confusing/unintuitive to a
> regular user:
>
> You're in an application, maybe an email client, or an IM conversation, or
> (heaven-forbid) a terminal. There's a URL you'd like to click on, that goes
> to a PDF, .zip archive, or any other file that's not actually going to be
> viewable in a web browser. You click it.
>
> What should happen? It'd be nice to see the content open up in the correct
> application. We have application and content preferences for this sort of
> thing. We can look at mime times, in particular.
>
> What happens? A web browser window opens, with no content, and then the WEB
> BROWSER opens the http connection to the content you asked for, and then
> downloads it or streams it to another application.
>
> Is this by design? Or would it make more sense for the desktop to poke the
> web server, get the mime-type of the content, and then open the relevant
> app? The desktop could even download the content, and continue streaming it
> to the application...
>
> There's a catch that this requires 2 http connections, one to check the
> type of the content, and then one to open it. However, I'd argue that this
> type of interaction isn't going to be making so many connections that that
> would be a bottleneck in any way, or even likely a noticable delay in most
> cases (certainly not more than the delay of opening a web browser window).
> If it was critical, the double-connection issues could be addressed with a
> little clever proxy work...
>
> Thoughts?
>
> --
> Jeremy Nickurak -= Email/XMPP: jer...@nickurak.ca =-
>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Fwd: Open Letter: The issues with client-side-window-decorations

[Luke Benstead]

I'm not going to pretend I understand all the issues relating to CSD, but
from here they don't sound like they best way to go. I use Chromium as my
default browser and I switched to native decorations the moment I right
clicked on the taskbar and got a totally unfamiliar menu without "Always on
top" as an option. If CSD is going to open the door to this kind of
inconsistency throughout the desktop, for apparently little (if any) gain, I
think abandoning the idea may be better than opening Pandora's box. I'm
still waiting for someone to counter Martin's points, he certainly seems to
know what he's talking about and I can understand why he's getting
frustrated.

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Is it time we killed "minimize to tray" ?

[Luke Benstead]

> And if anyone is willing and able to fix gnome-panel to make long-lived
> minimized windows more compact, please submit patches for that too. :-)
>
>
Is there a reason why DockbarX is not suitable for this? I've attached a
screenshot incase people dunno what I'm talking about :)

Luke.
<>___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Farewell to the notification area

[Luke Benstead]

On 14 June 2010 08:31, Matthew Paul Thomas  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Scott Ritchie wrote on 23/04/10 06:48:
> >
> > I like where you're going, but what do we do about interoperability?
> >
> > There's a hint in your post that we'll simply leave apps broken, stick
> > up our middle fingers, and tempt developers with our millions of users.
> > That may work for open source projects in our repository, but we need
> > to accept the reality that there will be programs that don't conform.
> >
> > The most obvious example is any software originally written for Windows
> > and running in Wine.  Wine uses XEmbed to create its own systray, and
> > the most reasonable place to put Wine's system tray is the notification
> > area.
> >...
>
> You mentioned at UDS that before Wine began inserting notification area
> items into the Gnome notification area, it put them in a separate
> window. I suggest that it return to doing that. Java applications will
> be in the same situation.
>
>
Hi Matthew,

A massive portion of Ubuntu users use Wine or Java apps to some degree. If
we are trying to improve usability, how would relegating
non-application-indicator-conforming apps to floating windows improve a
user's experience compared to the current situation of having the (empty
most of the time) old style notification area alongside the
indicator-applet?

I'm all for moving as many apps as possible to application indicators, but I
can't see a better solution than leaving the notification area applet there.
A Wine indicator applet would be nice, but Windows applications simply
listen out for mouse click messages and do whatever they want when they
receive them, so it's just not possible to do it in a way that would work
consistently.

That said, if there was a Windows version of the indicator applet and
libraries, we might see some applications move to it - you never know :)

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Farewell to the notification area

[Luke Benstead]

On 15 June 2010 10:32, Conscious User  wrote:

>
>
> > A massive portion of Ubuntu users use Wine or Java apps to some
> > degree. If we are trying to improve usability, how would relegating
> > non-application-indicator-conforming apps to floating windows improve
> > a user's experience compared to the current situation of having the
> > (empty most of the time) old style notification area alongside the
> > indicator-applet?
> >
> > I'm all for moving as many apps as possible to application indicators,
> > but I can't see a better solution than leaving the notification area
> > applet there. A Wine indicator applet would be nice, but Windows
> > applications simply listen out for mouse click messages and do
> > whatever they want when they receive them, so it's just not possible
> > to do it in a way that would work consistently.
> >
> > That said, if there was a Windows version of the indicator applet and
> > libraries, we might see some applications move to it - you never
> > know :)
>
> How about a middle-ground compromise? Not using a full blown window,
> but putting the Wine tray icons inside an indicator menu.
>
> Horrible mockup attached for illustration.
>
>
I thought about that, but AFAIK you can't have right clicking (perhaps also
double clicking) inside an indicator menu.

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Farewell to the notification area

[Luke Benstead]

On 15 June 2010 10:39, Conscious User  wrote:

>
>
> > How about a middle-ground compromise? Not using a full blown
> > window,
> > but putting the Wine tray icons inside an indicator menu.
> >
> > Horrible mockup attached for illustration.
> >
> >
> > I thought about that, but AFAIK you can't have right clicking (perhaps
> > also double clicking) inside an indicator menu.
>
>
> Are we talking about an impossible-to-overcome-by-design-gtk-limitation
> or a workable-around-jumping-through-some-hoops limitation?
>
>
We are talking about an
impossible-to-overcome-by-application-indicator-design-limitation.

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Farewell to the notification area

[Luke Benstead]

On 15 June 2010 19:10, Mark Shuttleworth  wrote:

> On 15/06/10 10:42, Luke Benstead wrote:
> > We are talking about an
> > impossible-to-overcome-by-application-indicator-design-limitation.
>
> AppIndicators can't do this, you're right. But the system indicators
> like Network and Me menu's can, so a Wine one could too. We just need to
> think if that's a good enough UX.
>
>
Cool, I wasn't aware of that - well that gives us a little bit more
flexibility :)

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Farewell to the notification area

[Luke Benstead]

On 16 June 2010 12:28, Conscious User  wrote:

>
>
> > Well, any closed but not replaceable application that can't or won't
> > adapt, as well as any open application that has yet to be fixed. The
> > latter should hopefully disappear over time (but how much time?), the
> > former also goes into the "never will "category for the purpose of
> > this discussion at least. Some software in use may not even have
> > developers or even code any more.
>
> > I think the way forward is to fix all apps that are possible, via bug
> > reports and patches, and replace the rest with good alternatives over
> > time.
>
> > I don't think the way forward is to sabotage a user experience because
> > they need (or even want to) use applications which can not yet be
> > replaced, or at least yet have to receive a patch.
> >
> > I think that easy ways to conform and pointing out the benefit of
> > belonging should be enough "pressure" to adapt without actively
> > breaking applications, and probably just about as fast.
>
>
> "Breaking" is too strong of a word. Putting Wine/Java icons in a
> separate window or indicator menu would make them suboptimal,
> sure, but still fully functional.
>
> So the question is: can Wine/Java apps be considered cornercase-y
> enough for this sub-optimality to be accepted?
>
>
Well, I don't think that's the question at all. We already have a
near-optimal solution to this in sticking the old-style notification area
alongside the new indicator applet. An optimal one would be some kind of
indicator that gave good UX and integrated nicely with the indicator applet.


The question is more, "how can we fix this to provide the best user
experience?", rather than than "how many people will be affected by us
implementing a bad user experience (moving to a window)?" We should be
trying to improve the situation, not make it worse for the people that do
use Wine and Java apps.

Luke.

P.S. Scott has the stats somewhere, a very large portion of Ubuntu users use
Wine, add on Java users to that and we are talking a substantial portion of
our userbase. Granted they won't all be running apps that create tray icons
though but that's almost impossible to quantify.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

[Ayatana] Is it just me, or are the Users and Groups dialogs horrible?

[Luke Benstead]

Hi all,

This has been bugging me for a little while. Most of the dialogs underneath
Preferences and Administration are generally pretty well laid out and
designed, the big glaring exception is the Users and Groups dialogs which
seem messy and confusing.

To better explain what I mean, I've created a wiki page here:
https://wiki.ubuntu.com/Ayatana/UsersAndGroups

I think we can do far better than what's currently there.

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Is it just me, or are the Users and Groups dialogs horrible?

[Luke Benstead]

On 16 June 2010 14:54, Omer Akram  wrote:

> the 'about me' and 'users and groups' will be replaced by User accounts
> diagloue in maverick.
>
> On Wed, 2010-06-16 at 14:39 +0100, Luke Benstead wrote:
> > Hi all,
> >
> > This has been bugging me for a little while. Most of the dialogs
> > underneath Preferences and Administration are generally pretty well
> > laid out and designed, the big glaring exception is the Users and
> > Groups dialogs which seem messy and confusing.
> >
> > To better explain what I mean, I've created a wiki page here:
> > https://wiki.ubuntu.com/Ayatana/UsersAndGroups
> >
> > I think we can do far better than what's currently there.
> >
> > Luke.
>

Awesome, I figured someone else would be working on it :)

Thanks,

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Is it time we killed "minimize to tray" ?

[Luke Benstead]

On 15 June 2010 08:10, Martin Owens  wrote:

>
> On Mon, 2010-06-14 at 14:08 +0100, Luke Benstead wrote:
> > Is there a reason why DockbarX is not suitable for this? I've attached
> > a screenshot incase people dunno what I'm talking about :)
>
> That is what you would get if you removed the ... from the bar when they
> get resized.
>
> I never understood why there was a ... when no text could fit.
>
> Martin,
>
>
That's quite obviously a bug worth reporting :D

Regarding DockbarX, it does behave differently in than the default in that:

1. It always groups by application icon
2. It displays the application windows on hover, rather than on click

This makes it incredibly easy to use, any time you need to access a window,
say a Firefox window. You immediately move to the Firefox icon and select
the correct window with a single click. I've been trying to come up with a
better window switcher but I can't think of anything.

Luke.

P.S. I did try creating a DockbarX style window switcher with indicator
applet style menus (rather than the slightly inconsistent Cairo based
DockbarX ones) but I had no luck getting the menus to show and hide
correctly on mouseover/exit - I think that would have been pretty cool :)
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Windicators

[Luke Benstead]

On 17 June 2010 15:58, Matthew Paul Thomas  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Roth Robert wrote on 03/05/10 13:22:
> >...
> > Starting a new topic to discuss the suggestions, comments, ideas
> > regarding the windicators
> >  Mark blogged about.
> >...
>
> With help from Ted Gould of the DX team, I have now (mostly) finished a
> specification for windicators, with a few examples.
> 
>

Hmm... here is a quote from Mark in an earlier thread that I started:

"For designing indicators, ask yourself:

 - what is the *status* I am conveying, and
 - what options are there to manipulate that status?

If you don't have both, especially the status, don't use an indicator.
Use a menu."

So... what's the "status" for the Gimp and F-spot mockups? Scale and tags
don't seem to fit at all with the original Windicator idea. In fact the only
one that seems to fit the status argument is the Firefox one, but you can't
manipulate the status so it shouldn't be a Windicator

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Windicators

[Luke Benstead]

>
> Hmm... here is a quote from Mark in an earlier thread that I started:
>
> "For designing indicators, ask yourself:
>
>  - what is the *status* I am conveying, and
>  - what options are there to manipulate that status?
>
> If you don't have both, especially the status, don't use an indicator.
> Use a menu."
>
> So... what's the "status" for the Gimp and F-spot mockups? Scale and tags
> don't seem to fit at all with the original Windicator idea. In fact the only
> one that seems to fit the status argument is the Firefox one, but you can't
> manipulate the status so it shouldn't be a Windicator
>
> Luke.
>

To be a little more productive, here are some ideas :)

Evolution:
   Connection status -
  Icons: Connected / Disconnected
  Options: Online / Offline

Firefox:
   Connection status -
 Icons: Connected / Disconnected
 Options: Online / Offline
   Ad-blocking Active -
 Icons: Coloured Adblock logo / Greyed Adblock logo
 Options: Enable / Disable
   Javascript Active:
 Icons: Coloured cog / Greyed Cog
 Options: Enable / Disable
   Bookmarked status:
 Icons: Yellow star / Empty grey outlined star
 Options: Bookmark / Delete bookmark

Gedit:
Save Status -
   Icons: Coloured disk / Greyed Disk
   Options: Save / Revert

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Windicators

[Luke Benstead]

On 18 June 2010 16:25, Conscious User  wrote:

>
> > We'll have to think about that :-)
> >
> > Suggestions? Show the ones that most recently changed status?
>
> I think that would introduce an unpredictability factor
> that a lot of users wouldn't like.
>
> Like it happens with the panel, I think we should consider
> that even without the space problem there is the simple fact
> that cluttering the indicator area diminishes its
> usefulness.
>
> I've always been a supporter of enforcing a limit on
> indicators, like the Windows 7 notification area does
> by throwing the excess icons in a popup (and allowing
> the user to choose which ones have priority), because
> trusting application developers to follow common sense
> simply does not work.
>
> For windicators the problem is even worse, so at the
> risk of someone calling me by the Godwin word, I'd
> support even flat out *forbidding* more than a certain
> number via library constraints, not only separating
> them to a popup. :)
>
>
Agreed. We think we should be careful to specify EXACTLY when a Windicator
is suitable and restricting the number, otherwise we could end up with the
notification area all over again...

I think it might even be a good idea to come up with a preferable set of
Windicators that apps can use (e.g. sound, save state, connection state,
shared state).

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

[Ayatana] Do you want to delete the applet from your configuration?

[Luke Benstead]

Hi all,

Here's this week's bug bear of mine:
http://img258.imageshack.us/img258/6311/as7ob3.png

Can we make that any less user friendly? We present the user a dialog, which
no matter which option they choose leaves them with behaviour they don't
want. Choose "Delete" and you lose your applet permanently, choose "Don't
Delete" and you lose it until the panel is reloaded. Either way this isn't
how we should be dealing with panel applet load errors.

This dialog turns up in a couple of situations, specifically:

1. You've uninstalled the applet program from the system, but not removed it
from the panel
2. The applet has failed to load due to some error

Now, 1. really should be detectable. If I've uninstalled Tomboy, and the
Tomboy applet is still in my configuration, Gnome should either ignore the
configuration entry totally, or silently delete it from the configuration.

2. happens. And 90% of the time, a killall gnome-panel gets it working
again. Surely Gnome panel should attempt to reload it again at least once
before producing the delete/don't delete ultimatum? If it really won't load,
we should have a slightly better dialog box with a "Report this bug" type
feature (how exactly do you report an applet bug?)

Thoughts?

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Brainstorming the Me Menu again

[Luke Benstead]

On 29 June 2010 12:21, Conscious User  wrote:

>
>
> > Yes, the "broadcast field" is certainly a learnable feature in the
> > MeMenu.
> > It will make publishing your current thought to the world very
> > comfortable, i'm sure.
> > But please somebody help me understand why i have a field to publicly
> > log my thoughts next to IM presence status settings, while i can't
> > even inform my contacts about why exactly i do not want to be
> > disturbed right now..
> >
> > I still don't understand the idea behind this configuration..
>
>
> The MeMenu always had both broadcasting and custom IM status in
> the specification:
>
> https://wiki.ubuntu.com/MeMenu
>
> In fact, you can see that the custom status part is supposed to
> be quite rich in details. The implementation just needs to be
> completed, which IIRC is supposed to happen in Maverick.
>
>
I agree, once the implementation is complete things will be a lot better,
but I think we can simplify the menu a bit more. I think we should have a
divider between the social networking stuff, and the IM statuses as they are
not related. Also, I'm not entirely sure why we need the name on the me menu
when there is a name on the Me-menu button itself. I've attached a hacked up
version of MPTs mockup from the wiki page.

Luke.
<>___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

[Ayatana] Blue for information

[Luke Benstead]

Hi all,

A while back we were discussing using blue to represent "information" in the
indicator applets. Mark said it was worth looking in to:
https://lists.launchpad.net/ayatana/msg01205.html

I'm bringing this up again, because with the discussion about a green
"flash" to indicator success of Me Menu updates, it looks to me at least
that green for new messages (information) as well as to represent a
successful action completing seems inconsistent. IMO blue (which seems to be
a pretty globally used colour for conveying information) would be more
suitable.

I'm not sure if using blue was investigated, the thread seemed to trail off
soon after, did this just get forgotten?

Luke.

P.S.

I still think that the following would be a nice standard to adopt:

Blue -> Informative
Green -> Success (a flash if the success state is momentary rather than a
prolonged state).
Red ->Error
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

[Ayatana] General System Responsiveness

[Luke Benstead]

Hi everyone,

This is just something that I've noticed recently, if it wasn't so tricky to
fix it would definitely belong in the "papercut" category as one of those
things you learn to live with / stop noticing.

I've had a Vista install alongside my Ubuntu install for some time, but
never really used it. Recently I've had some Flash issues in Ubuntu so it
was easier just to reboot in to Vista to watch some online video. One thing
I noticed was how much more "solid" Vista *felt*. For a while I couldn't
figure out why this was, something just gave the illusion of being more
robust than Ubuntu.

Just now I figured out what it is, I've just logged into my work PC, and
fired up Thunderbird, Netbeans, Firefox etc. and I sat and watched a desktop
that appeared to be doing nothing.

There are really two issues here, one is feedback to the user after starting
an application. When you start an application from the menu, there is no
indication that anything actually happened (aside from the menu vanishing),
there's no "I'm thinking about it, one second..." indicator. In Windows of
course there is the little busy cursor, our busy cursor doesn't seem to
trigger in this situation. I'm not saying that a busy cursor is a good
solution to this, but we could do with some kind of "The application is
launching" indication.

The other issue is that if some app starts accessing the hard disc / use
some CPU, everything seems to stop completely. Just now I ran some updates
while trying to type this email and Firefox started "grey screening" me
every few seconds. Why? The updates seem to use all the CPU and leave the
applications struggling to even refresh. I'm not saying this is an Ubuntu
specific thing, obviously we've all seen Window's "The application is not
responding" dialog, but I know that I see the greyed window on Ubuntu far
more than that dialog on Windows. And in my experience, the Windows dialog
actually appears when that program is hanging, not because another program
is busy.

I don't know the solution, (better CPU scheduling? Prioritizing of GUI
threads? CPU limiting the update manager?), but we should really try to do
something to improve this.

Luke.

P.S.

Apparently I'm not the only one that thinks so too:
http://brainstorm.ubuntu.com/idea/85/
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] General System Responsiveness

[Luke Benstead]

> How about starting just Firefox from the terminal so you can track what it
> does?
>
>
> Anzan
>
>
Firefox was just an example, I experience poor responsiveness pretty much
everywhere. The bugs that Dylan linked are quite probably related, this
comment is quite worrying (the poster did a lot of work on CPU scheduling in
the kernel, he knows what he's talking about)
https://bugzilla.kernel.org/show_bug.cgi?id=13347#c59

This thread is basically describing that Vista and Windows 7 feel a lot more
responsive than Ubuntu does, that's not right. If I'm running updates in the
background I shouldn't have to wait for them to finish before I can watch a
YouTube video (for example) and that's the situation I've seen on all my PCs
(work and home, desktops and laptops). My text editor shouldn't stutter when
installing applications.

I'm trying to describe what is a general issue, but the majority of
instances may well stem from that kernel bug.

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Restart Required

[Luke Benstead]

On 30 July 2010 16:31, Frederik Nnaji  wrote:

> hello there ;)
>
> is anybody working on the FUSA currently?
> Allow me to raise the topic for brief elaboration..
>
> "Restart Required" seems incorrect to me:
> after executing a partial upgrade, Ubuntu shows two red elements in the
> indicator area of my top panel
> * dysfunctional conman
> * FUSA in alert condition
>
> first of all, "restart required" is not an action, it is an informative
> sentence, therefore it doesn't belong into any menu as an interactive menu
> item.
> One could instead place it above the FUSA as it is opened on click via its
> indicator icon in the panel.
>
> Furthermore, the red color on the indicator-session icon calls ERROR or
> network-failure to mind, this is not correct in this case. We are not
> failing anything, there also is no error, so red is incorrect in this
> situation.
> Perhaps yellow or orange, maybe blue. The fact of colorization alone should
> be informative enough for the user to notice timely. A hover in that screen
> corner should also reveal the suggested action: "upgrade complete, please
> restart the computer".
>
> The menu item should not change IMO, it should still be called "Restart".
>
>
+1

The red indicator has been a bug bear of mine for a while, red is far to
severe a colour for something that isn't an error condition. I'd again
suggest blue for information, or at most an amber to indicate a warning (I
guess it's possible a kernel update had a security fix).

Also, "Restart required" isn't an action, and it's not required. "Restart
(recommended)" might make more sense, brackets differentiating the action
from the recommendation.

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Restart Required

[Luke Benstead]

On 30 July 2010 18:26, Mark Shuttleworth  wrote:

>  On 30/07/10 16:44, Luke Benstead wrote:
> > The red indicator has been a bug bear of mine for a while, red is far
> > to severe a colour for something that isn't an error condition. I'd
> > again suggest blue for information, or at most an amber to indicate a
> > warning (I guess it's possible a kernel update had a security fix).
>
> The strong likelihood is that you are insecure until you reboot, so we
> class it as a warning and make it red.
>
>
OK, fair enough :)


> > Also, "Restart required" isn't an action, and it's not required.
> > "Restart (recommended)" might make more sense, brackets
> > differentiating the action from the recommendation.
>
> Agreed, the language is bad. The current plan is to change it to
> "Restart, completing updates..." which is more accurate. Still open to a
> better choice of words if you have something in mind.
>
> Mark
>
>
"Restart, completing updates..." seems to indicate something is in progress.
In fact it may *deter* people from restarting as they may see "completing
updates..." as a warning that that is happening in the background. I think
differentiating from the "Restart" action is important (as the action
doesn't change, we are just adding additional information). So perhaps
"Restart (to complete updates)" or my previous suggestion: "Restart
(recommended)"

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Space in the sound menu

[Luke Benstead]

On 4 August 2010 05:51, Mark Shuttleworth  wrote:

>
> I blogged about the layout of the track metadata in sound indicator at
> http://www.markshuttleworth.com/archives/446
>
> With a mockup like:
>
>
>
> In comments on the post, Mike Rooney pointed me to a thread that
> included
>
> http://picasaweb.google.com/100804433705878937883/Mockups#5493946264489470306
>
>
>
> It's certainly nice and clean. I think a combination might rock.
>
> I do think the play/pause/next/previous buttons have some work in the
> pipeline that will improve the styling.
>
> Mark
>

Just a thought, but taking that second mockup. If the buttons were moved
above the artist and album. You could have the track title along the full
width underneath the image, and the artist and album to the right of the
image. Bad ASCII art follows:

|-|
| |   [ << | > | >> ]
| |
| |   Tracey Chapman
|-|   Tracey Chapman
Across the Lines, W...re to go?

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

[Ayatana] Do indicator applications need minimize?

[Luke Benstead]

This is just something I've thought about...

In 10.10 we'll have two "group" indicators; the messaging and sound menus.
Both of these menus allow applications to run inside them, by this I mean
when the window is closed they continue to run in the background available
from the indicator. So these "background" applications are Gwibber,
Evolution(?), Empathy and soon Rhythmbox. There are of course others that
attach to the menus.

Now, what I've experienced is a range of inconsistency outside of the
default applications. For example, there is a Thunderbird plugin for the
messaging menu, but closing the Thunderbird window quits the application,
which is not what I expect.

I think it would be a good idea to remove the minimize button from
applications that appear in the group indicators (and run in the
background). For two reasons:

1. This removes the ambiguity surrounding "where did my window go". At the
moment, if the Gwibber window isn't visible, it's either in your taskbar, or
it's available in the indicator. If there was no minimize button then the
only option would be "close" which would send it back to the indicator
applet. You'd always look there for Gwibber.
2. It forces non-default applications to behave consistently. Without the
possibility of minimizing, application developers would make sure that if
they integrate with a group indicator they continue to run when the main
window is closed.

Thoughts?

Luke.

P.S. I'm only talking about apps that run in the group indicators, not
things like Transmission which have their own indicators.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

[Ayatana] USB Device Removal Indicator

[Luke Benstead]

Hi all,

Yesterday I was making a USB startup disk to install UNE on my girlfriend's
new netbook (she loves it btw!) and when the process finished I went to
Eject/Safely Remove the USB stick. I instinctively moved my mouse to the
indicator applet (I dunno why) and then realized there is no place to do it
there. Then I realized that safely removing the USB drive means either
showing the desktop (and thus minimizing all my windows which I was working
with) or opening up Nautilus to do it there.

This morning I entirely independently stumbled across this through one of
Jono Bacon's blog posts:
http://dl.dropbox.com/u/7138409/indicator-usb/indicator.html

I think it would be a really good idea if this indicator (or one with
similar functionality) was in the default install. Most of the time you want
to remove a USB device you will have been doing something else (e.g. copying
images into F-Spot) and having to find a somewhere where you can remove the
drive completely disrupts what you are doing.

Thoughts?

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Reliability: Realtime Experience for Maverick

[Luke Benstead]

This is not just isolated to the installer. It would be nice if every button
press system wide showed some kind of indication that the click was
received. What might be nice is if the button text disappeared and a little
circular progress indicator showed for a second or two before being replaced
back with the button text again (a cross fade to the spinner, and back to
text would look pretty cool actually).

Luke.

On 9 September 2010 12:28, Frederik Nnaji  wrote:

> Dear all,
>
> after hesitating for quite some time now, i installed Maverick on my
> production machines, and it is running like a charm!
> Thanks to the everybody @ Canonical for all the great work, thanks to the
> entire community for making this possible in the first place ;)
>
> Reliability:
> As in the physical universe, not all interaction objects are realiable.
> Yet, when a process fails to start, i know immediately that something is
> wrong.
> The most unlikely thing to happen is that i press a button or switch, only
> to be left guessing for a quarter of a minute, whether anything has been
> invoked, activated or started by my action.
>
>
> http://lh6.ggpht.com/_1QSDkzYY2vc/TH7Lkl4Jd-I/Byc/ttFY5lOV3cA/ubuntu-10.10-screenshot.png
> and
>
> http://lh4.ggpht.com/_1QSDkzYY2vc/TH7Lk9DqKYI/Byk/w27hJZiRIII/ubuntu-10.10-installer2.png
> show dialogs containing "Forward" buttons in the installation dialog, which
> show no feedback upon click.
>
> The Forward button should react in realtime when clicked: at the moment
> there is no reaction for about 10-20 seconds.
> This is insufficient, e.g. because:
> * user doesn't know if the button was clicked or not
> * user doesn't know if the click started anything or not
> * user might click again, to make sure (confirming Forward on the next page
> accidentally)
> * user is irritated and becomes impatient after the instant interaction
> feedback time (~ 0 - 1 sec) is over
>
> Realtime Interaction is the impression of live interaction with a system.
> This impression is a model of what we experience as physical reality, it is
> easy to model after that symbolically.
> Every interaction, input or gesture creates ripples on the surface of the
> GUI, just like a finger that touches a "surface" indents the surface or
> changes its state.
>
> The simplest way of solving the "Forward" button problem here, is to add
> another frame/state to the forward button, i.e. "pressed".
>
> thoughts?
>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Luke Benstead]

On 15 September 2010 17:25, Greg K Nicholson  wrote:

> On 15 September 2010 16:54, Conscious User  wrote:
> > I know it's the space for the confirmation bubbles, but I think it
> > would be much better if those appeared in another place entirely,
> > like a bottom corner.
>
> I've suggested before that synchronous notifications (e.g. volume)
> should appear horizontally centred. Then the asynchronous
> notifications (IM etc.) can appear immediately below the top panel, at
> the right.
>
> No-one has come up with any drawback whatsoever to this design—yet ;)
> --
> Greg
>
>
That's definitely the best solution I've heard yet. Why are we not doing
that?

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Luke Benstead]

>
>> We could do better with the fading, but I find myself unable to imagine
>> a situation where someone simultaneously (a) needs to see what's under a
>> notification bubble and (b) "needs the cursor elsewhere". Can you give
>> an example?
>>
>>
> I think Michael Jonker already provided one at this very thread; that's why
> I elaborated on it. When working with the Gimp, he needed to see the layers
> panel while working on the scene, and it was obscured by the bubble.
>
> This will happen in general whenever the top-right corner of the
> application contains an information panel, which is intended to
> contain readable data that can be read with a glance while working on the
> main interface. This is quite usual in IDEs and design tools.
>
>
Also of course, the Google search box in FF which I find regularly
obstructed while typing (unless that's been fixed in Maverick or by
"cursor", MPT meant cursor or caret).

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] unity and notifications

[Luke Benstead]

On 20 September 2010 16:55, Mark Curtis  wrote:

>  Trying to find an area of the screen that won't obscure all applications
> is fruitless. There is no single location that won't end up obscuring SOME
> application's interface.
> Popular applications such as GIMP (right and left), Inkscape (bottom and
> left) and Firefox (top) total to using all sides of the screen.
> OpenOffice.org Impress alone uses every side of the screen and is an
> application included by default.
>
>
I can only think of two options to display notifications while trying not to
obscure a user's workspace:

a.) Don't display notifications in the working area (e.g. display them in
the panel, Android-style)
b.) Resize the working area to allow the notification to display (e.g. slide
up from the bottom resizing all open windows - potentially jarring)

If we are accepting we must obscure the user's working area (which isn't
really ideal) we should allow the user to either configure the notifications
so they don't interrupt their specific workflow, allow them to be closed
(still not ideal; interrupting flow), or just be a little arrogant about it
and if they don't like it they can remove them (current approach).

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

[Ayatana] Executable file dialog box...

[Luke Benstead]

Hi everyone,

We all know that on Linux any file can be marked as executable and unlike
Windows we don't rely on the extension of the file to determine that. But
this of course leads to ambiguity when someone double clicks a file from
Nautilus, should the file be executed or displayed? The current workaround
is to display a dialog box which will leave any non-technical user
scratching their heads.

The dialog itself is pretty confusing and ugly for several reasons:

* The default action is to "Cancel" which is very likely not what the user
wants
* There are two different run options (Run in Terminal and Run)
* The "run" options are at opposite ends of the dialog and not explained at
all
* The text of the dialog wraps randomly (it doesn't extend to the full width
of the box)
* The user hasn't got a clue what they want to do, if it's a text file
they'll probably think they want to "Run" it when really "Display" is what
they are actually trying to do

I'm wondering if we need this dialog at all, surely we can code in a little
bit of logic here. How about:

If the file is executable and:

1. If the file is binary and the extension not associated to a program,
attempt to run it
or
2. If the file is text and has the #! line at the top, try to run it. Add
"Run as a Program" and "Run as a Terminal Program" to the right click menu
or
3. If the file is text, open it in the default editor and add "Run as a
Program" and "Run as a Terminal Program" to the right click menu

That way double clicking a file will do what the user expects most of the
time, and give the option of alternative behaviour if necessary.

Thoughts?

Luke.

P.S. I'm not totally sure this is the right mailing list for this, but it's
a user experience issue so I'm guessing so. If it's not the right place,
please point me to the best place to deal with this, is it worth making a
bug report?
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Executable file dialog box...

[Luke Benstead]

On 21 September 2010 13:54, Remco  wrote:

> On Tue, Sep 21, 2010 at 12:38, Luke Benstead  wrote:
> > I'm wondering if we need this dialog at all, surely we can code in a
> little
> > bit of logic here. How about:
> >
> > If the file is executable and:
> >
> > 1. If the file is binary and the extension not associated to a program,
> > attempt to run it
> > or
> > 2. If the file is text and has the #! line at the top, try to run it. Add
> > "Run as a Program" and "Run as a Terminal Program" to the right click
> menu
> > or
> > 3. If the file is text, open it in the default editor and add "Run as a
> > Program" and "Run as a Terminal Program" to the right click menu
> >
> > That way double clicking a file will do what the user expects most of the
> > time, and give the option of alternative behaviour if necessary.
> >
> > Thoughts?
>
> This may have security implications. What if the file is a malicious
> bash script? GNOME attempts to help the user avoid running malicious
> code. Double clicking a text file downloaded from the internet should
> not be a gamble. You double click the file to study it, and suddenly
> it deletes all your files.
>

I did consider this, however, when you download a file from the Internet via
Firefox the executable bit is turned off, you have to already consciously go
and enable it otherwise double clicking the file just opens it in a text
editor.

The current dialog doesn't seem to be about security (otherwise there would
be a warning stating that) it seems to exist because Nautilus doesn't know
what you want to do with the file.


> Maybe also add a clamav scan. Since many people have Wine installed,
> it is even more important to scan untrusted executable files for
> viruses.
>
>
Wine applications already have to have the executable bit set to run, if you
try to run it without it you will see a dialog informing you.

Just to clarify, my suggestion is only for files already marked as
executable, obviously adding "Run as a Program" to non-executable files is a
massive security issue.

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] What do app authors do for Account Dialogs?

[Luke Benstead]

Hi,

I'm sort of thread hijacking a little here (apologies for that), but this is
actually close to something I've been meaning to bring up here for a while.

On my phone, when I set it up for the first time I was asked if I want to
set up certain accounts (e.g. flickr, Facebook, Twitter etc.) and by doing
so I unlocked features (e.g. downloading contact pictures, uploading
pictures to flickr etc.).

What with Ubuntu becoming "social" I'm wondering if we should be doing
something similar, a sort of online account manager which manages the
accounts across the desktop.

Here's my thinking, imagine the first time you login to Ubuntu you are
provided with an account setup wizard that allows you to register accounts
for different purposes. For example:

* Imgur, Flickr, ImageShack, Picasa TwitPic, FB* (image hosting services)
* Twitter, Facebook*, Identica, Google Buzz (social networking)
* Ubuntu One, Dropbox (file hosting services)
* Google Talk, MSN, Jabber (IM services)
* Gmail, Hotmail, Yahoo (email services)

Adding each of these would add them to the appropriate application (e.g
Gwibber, Evolution, Empathy) but would also unlock features (e.g. Right
clicking and image in Nautilus might have a "Share on Flickr" option).

I think some kind of global account system, with an API would allow us to
code some really cool stuff into the desktop. So, as a concrete example,
Shotwell might be able to query for a list of available image hosting
services that the user has accounts for, and provide an "Upload to..."
option.

I'm also thinking that the account manager itself could use a extension
system for the accounts, so installing packages like account-manager-flickr
would add it to the account manager... or something like that.

Anyway, sorry to take this slightly OT, just thought I'd throw this out
there,

Luke.

On 8 October 2010 14:03, Matthew Paul Thomas  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> frederik.nn...@gmail.com wrote on 08/10/10 09:48:
> >...
> > On Fri, Oct 8, 2010 at 02:37, Jorge O. Castro  >...
> >> I have an upstream working on an application, he wants to add an
> >> account dialog to his application, this is what he came up with:
> >> http://i.imgur.com/9vFZF.png
> >>
> >> So at first glance I thought "That doesn't look right". Here's
> >> gwibber's account dialog: http://i.imgur.com/e504n.png
> >>
> >> Gwibber's is based on Empathy. Ken decided that it was important for
> >> the Gwibber account manager to operate as a separate application
> >> outside of Gwibber itself. While he was reimplementing it, he took the
> >> opportunity to streamline it and change the design to make it more
> >> consistent with the account dialog that Empathy had at the time.
> >> (Because hey, why not, make them behave the same!)
>
> Empathy's has improved a bit, partly influenced by a design I did for it
> a year ago. 
>
> I still think it's an annoying problem for Empathy's "Accounts",
> "Personal Information", and "Preferences" to be three separate windows.
>
> >> Here's a separate design that Ryan had come up with (just to put it
> >> out here):
> http://s3.amazonaws.com/scrnshots.com/screenshots/191324/gwibber-home-screenpng
>
> That's probably giving it undue prominence.
>
> >> From playing with both the empathy and gwibber dialogs they seem
> >> similar enough for most people to not care -- though there are some
> >> small inconsistencies that should be fixed. Evolution is different, as
> >> well as other apps. Searching through the GNOME wiki and HIG doesn't
> >> seem to give me any answers. Has anyone out there done research into
> >> this topic? Is there supposed to be an example application where can I
> >> point upstream application authors to emulate when it comes to adding
> >> account information? Is anyone aware of GNOME handling what app
> >> authors should do? I'd be more than happy to take the conversation
> >> upstream if that's where it should be.
>
> I haven't seen any Ubuntu application present accounts well yet. So I'd
> rather see more experimentation, than projects agreeing on a
> consistently bad design.
>
> > Luke started a thread a while ago.. he addressed the User Accounts
> > dialog, but this is a beautiful solution that can also work for many
> > other types of account setup wizards etc..
> >
> > On Wed, Jun 16, 2010 at 16:10, Allan Day  > > wrote:
> >...
> >> [1] http://fedoraproject.org/wiki/Features/UserAccountDialog
> >
> > i think this is the most reasonable thing to look at for now, if one
> > is looking for a good design to model an accounts dialog after..
> >...
>
> The main issue with that design (as I told its developers a couple of
> years ago) is the excessive modality. There shouldn't need to be a
> separate "Changing password for" dialog, or a separate "Restrictions"/
> "Account Information" dialog.
>
> - --
> Matthew Paul Thomas
> http://mpt.net.nz/
> -BEGIN PGP SIGNATU

Re: [Ayatana] clipboard information in context menu

[Luke Benstead]

On 12 October 2010 16:50, Mark Curtis  wrote:

>  Will 11.04 have no "sys-tray"? Canonical is behind a release from the plan
> you posted given 10.10 still has the old clock, network (and power?)
> applets.
>
>
Also, what's happening about Wine and Java applications, has that been
sorted yet?

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Flies in the Ice Cream...

[Luke Benstead]

On 27 October 2010 21:35, Caio Alonso  wrote:

> Recently, I've noticed several usability issues in Ubuntu that really are
>> big annoyances that I think are being overlooked. After watching Mark's
>> keynote the other day I thought I'd pen them down to see if perhaps we can
>> fix some of them this cycle. I'm never sure if the Ayatana list is for
>> general usability issues, or just specifically for usability features (e.g.
>> indicators) so if this is OT I apologise.
>>
>> The first one is the following use-case: A user wants Empathy to start on
>> login.
>>
>> Now, right now, stop what you are doing and go and make Empathy start on
>> login without Googling for help or using the terminal.
>>
>> Some of you will search Empathy's preferences; you guys are wrong.
>> Some of you will head for Startup Applications, you won't find it in the
>> list, you will click add and then stare at a horrible dialog that leaves you
>> no clue what to do next.
>>
>> This is a common use case, not just for Empathy but also for email
>> clients, or browsers. Why is it so hard? Why when I click browse on the
>> dialog am I sent to a file browser rather than a list of applications? Why
>> isn't Empathy in the list by default if it's installed? (BUG:
>> https://bugs.launchpad.net/empathy/+bug/322314)
>>
>> My dream would be that we'd have a decent task scheduler so that we could
>> set applications to start on login, at certain times, or when the network is
>> connected.
>>
>
> I've made a mockup of my opinion of how the dialog after you click the Add
> button should look like. Two things still concern me with this interface:
> how to make the user know that he either selects a program OR enters a
> custom command and also the size of the dialog for low resolution systems.
>
> [image: Startup_Program_Page_1.png]
>
> One thing I noticed is that on the menu entry it is called Startup
> Applications, but inside the window all the labels are "startup programs".
> Is that an inconsistency?
>

Thanks for the mockup! That's pretty much what I was considering. Regarding
the naming, judging from the names of the items in the list, this should be
"Startup Services" rather than "Startup Applications/Programs". The fact
that you can add startup applications seems to be an after thought.

This makes me wonder, should we be differentiating between "Applications"
(e.g. programs a user would launch) and "Services" (background programs). If
I was redesigning this, I'd probably totally remove the add button from that
dialog, rename it "Startup Services" and come up with a better system for
making applications launch on login. I'd probably add a "Task Scheduler" GUI
which works with cron, and dbus to trigger applications at certain times and
after certain events (e.g. login, network connected).

Luke.
<>___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Global Menu behaviour

[Luke Benstead]

On 27 October 2010 22:27, Conscious User  wrote:

>
> Before any kind of conclusions, a survey with long-time
> OSX users should be made. After all, not only they use
> a Global Menu all the time, but a lot of them also
> have huge monitors.
>
>
Heh, yeah because that would be unbiased :p We're pretty good at getting
used to a system, even if it's inefficient, and we'll defend that system
because we are familiar with it. It doesn't mean it's a good idea!

I think the main problem with having a global menu bar on a high resolution
is that with a high res you'll likely have multiple floating windows (rather
than one fullscreen one as in UNE), in that situation you will need to
continually click the correct window to get focus so you can access its
menu, also obviously there is the travel distance of the mouse, and the
potentially huge distance between associated elements. I can't imagine
someone using Eyefinity would be too impressed with a global menu.

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

[Ayatana] Global Menu on the Desktop

[Luke Benstead]

Hi all,

So I stumbled across this answer earlier:
http://askubuntu.com/questions/10481/does-will-unity-support-disabling-the-global-menu

We are getting the global menu by default on the desktop edition. I'm
actually overwhelmingly disappointed by this, there were actual logical
reasons why the global menu existed in the Netbook edition. Likewise there
are very real logical reasons why it makes little sense on a
high-resolution, multi-window system.

Like the window control position, monochome icons, OSX like side-dock,
position of the me menu, identical location of the Ubuntu/OSX icon, purple
colour scheme etc. We are again duplicating OSX instead of innovating.

I'd love to hear the reasoning.

So, so disappointed.

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Global Menu on the Desktop

[Luke Benstead]

Read Jorge Castro / Neil Patel's reply, they are the guys working on this.
The blueprint isn't official (aside from being approved for discussion at
UDS) and doesn't mention the global menu.

Quote:

“*Yes, the Desktop version of Unity will use the global menu by default*.
There might be some added intelligence for multi-monitor setups, but I’m not
sure and there has been no design as yet.” ~ Jorge Castro

Luke.

On 1 November 2010 12:59, Mark Curtis  wrote:

>  I don't mean to sound rude, but did you even read the answers to the link
> you posted?
> One of them shows this blueprint which wouldn't use the global menu for the
> desktop version.
>
> https://blueprints.launchpad.net/ubuntu/+spec/packageselection-desktop-n-specialized-unity-form-factor
>
> So it seems the desktop version would have room to innovate when it comes
> to the menu.  Do you have any particular ideas?
>
> --
> Date: Mon, 1 Nov 2010 10:04:46 +
> From: kaz...@gmail.com
> To: ayatana@lists.launchpad.net
> Subject: [Ayatana] Global Menu on the Desktop
>
>
> Hi all,
>
> So I stumbled across this answer earlier:
> http://askubuntu.com/questions/10481/does-will-unity-support-disabling-the-global-menu
>
> We are getting the global menu by default on the desktop edition. I'm
> actually overwhelmingly disappointed by this, there were actual logical
> reasons why the global menu existed in the Netbook edition. Likewise there
> are very real logical reasons why it makes little sense on a
> high-resolution, multi-window system.
>
> Like the window control position, monochome icons, OSX like side-dock,
> position of the me menu, identical location of the Ubuntu/OSX icon, purple
> colour scheme etc. We are again duplicating OSX instead of innovating.
>
> I'd love to hear the reasoning.
>
> So, so disappointed.
>
> Luke.
>
> ___ Mailing list:
> https://launchpad.net/~ayatana  Post to
> : ayatana@lists.launchpad.net Unsubscribe : 
> https://launchpad.net/~ayatanaMore help :
> https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Global Menu on the Desktop

[Luke Benstead]

On 1 November 2010 13:11, David Prieto  wrote:

> Hi,
>
>
>  I don't mean to sound rude, but did you even read the answers to the link
>> you posted?
>> One of them shows this blueprint which wouldn't use the global menu for
>> the desktop version.
>>
>> https://blueprints.launchpad.net/ubuntu/+spec/packageselection-desktop-n-specialized-unity-form-factor
>>
>> So it seems the desktop version would have room to innovate when it comes
>> to the menu.  Do you have any particular ideas?
>>
>
> Mark, that blueprint was apparently opened by a community 
> memberand
>  does not reflect the actual plans for Unity. That said, I do agree with
> having the global menu even in the Desktop version of Unity.
>
>
>
My question is why?

When they were implemented in UNE we had a great blog post by MPT about the
reasoning: http://design.canonical.com/2010/05/menu-bar/

It made sense. Netbooks have limited vertical space, UNE focuses one window
at a time, global menus are a perfect fit.

At the same time Mark posted on his blog (
http://www.markshuttleworth.com/archives/359) with the following quote:

"There are outstanding questions about the usability of a panel-hosted menu
on much larger screens, where the window and the menu could be very far
apart. Those questions are greatly diminished in the netbook environment, by
definition."

Again, clarifying that although they make perfect sense on netbook
resolutions, they won't necessarily make sense on desktops.

Perhaps we could start removing menus, and specifying a standard, consistent
way to do so (e.g. like Chrome). Perhaps the menus should appear in the huge
space we've opened up to the right of the title bar. Perhaps there is
another way to go, or perhaps we already have an optimal setup. We won't
know without doing usability testing and making sure we aren't making a
mistake.

Instead, we appear to be plagiarizing Apple's menubar just because we can.
On top of that it currently won't be consistent as not all the common UI
toolkits support it. So we are introducing inconsistency, and massive
behavioural change that could very well be less optimal than our current
solution, but without any concrete reasons.

To reiterate, I understand the reasoning for the global menu on netbooks,
and I totally agree. Why is a global menu better on a modern high-resolution
or multiple-monitor desktop than the current system?

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Global Menu on the Desktop

[Luke Benstead]

On 1 November 2010 13:59, frederik.nn...@gmail.com  wrote:

> On Mon, Nov 1, 2010 at 14:40, Luke Benstead  wrote:
>
>> To reiterate, I understand the reasoning for the global menu on netbooks,
>> and I totally agree. Why is a global menu better on a modern high-resolution
>> or multiple-monitor desktop than the current system?
>>
>> Luke.
>>
>
> because.
> * it cleans up the application window
>

Well, it frees up a little vertical space if that's what you mean.


> * it removes redundancy from the desktop
>

How? We still need individual application menus, but instead we have to
focus the correct window to get to them. Those menus aren't redundant they
are just being hidden where they are more difficult to get to.


> * it makes the entire desktop surface cleaner
>

Well, this is really your first point, I don't see where it makes anything
but the windows cleaner. If anything on the desktop it makes the panel
cluttered.


> * it's easier to do innovation on 1 global AppMenu than on every app's
> individual menu
>

True. But if the single menu is a step backwards, we're innovating on
something suboptimal.

None of those things make up for the extra mouse travel, multiple monitor
issues and increased window focusing/clicking.

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Global Menu on the Desktop

[Luke Benstead]

On 1 November 2010 19:47, Shane Fagan  wrote:

> I agree with the idea of less wasted space. So putting in the global
> menu into the desktop for maximized apps is a good idea.


Well, ideally the way to get rid of that wasted space would be to not have
the bar there at all. Think about it; Unity has a side bar from bottom to
top, the indicator applets sit top right *exactly* where there is an open
space on any maximized window. So why can't the indicator applet just
"float" top-right and there be no panel between the left bar and the
indicators? Any maximized window would fill the gap with the title bar.
Something like this? http://imgur.com/I30k3.png



> If its a huge
> screen its a lot easier to throw your mouse up to the top of the screen
> than go for the menu bar in the app I think. It might be slightly
> further but it requires about the same effort or even less maybe because
> you are just throwing your mouse to the top without thinking about where
> its actually landing.
>

That was why Apple did it originally. It's easier to fling the cursor to the
top, but there is quite obviously a limit to the size of the screen where
the efficiency of that is outweighed by the mouse travel and the detachment
of the menu from the window itself, and the required window focusing.

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Global Menu on the Desktop

[Luke Benstead]

On 1 November 2010 20:40, cmaglothin  wrote:

> Why exactly would there need to be a distinction at all? It would be
> pleasing to the eye if it just blended perfectly with the gradient of the
> maximized window border.
>
>
Mainly to show that:

a.) The indicator applet is floating (e.g. non-maximized windows can go
behind it too)
b.) The indicator applet is global and not associated with the window

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Unity - Web and People

[Luke Benstead]

> On 02/11/10 16:05, Seif Lotfy wrote:
>
>>
>> I am trying to figure how would be the best way to do it. If the feedback
>> is ok on the ayatana side i think i could have the "backend" done within 2 -
>> 3 weeks
>> Cheers
>> Seif
>>
>
>
Here's what I'd love from a "People" place:

1. The ability to import contacts from Gmail
2. The ability to easily merge/edit contacts
3. The ability to email, IM, Tweet, Skype a contact
4. The ability to transfer a file to a contact (by whatever means is
available)
5. The ability to invite a contact to remote desktop
6. For Gwibber, Evolution and Empathy to all pickup the contacts if they
have Twitter, Email or IM accounts respectively.
7. Ubuntu One contact sync

Just thinking aloud.

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] (In)sensitive menu itens for displaying information

[Luke Benstead]

On 5 November 2010 11:15, Matthew Paul Thomas  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> zekopeko wrote on 04/11/10 20:38:
> >...
> > Banshee, if set as the default music player, opens the song in a
> > special sidebar item called "File System Queue" (as opposed to
> > Library). Better wording and a simple strip bar (similar to the one
> > used in Nautilus for Ubuntu One) that offers the option to add the
> > songs from "File System Queue" to the Library could fix this problem.
>
> "File System Queue"? Criminy.
>
> Five-minute design exercise: Think of five labels for that section which
> would be better than "File System Queue". Go. :-)
>

External Media Files
Media File Preview
Other Media
External Media Queue
Outside Media

Erm.. I'm out.

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] More complete Applications view

[Luke Benstead]

> > 4. I've aligned Trash along the bottom next to "Get more applications"
> > which seems less cluttered
>
> After further thinking, I think that the trash icon doesn't belong on
> the applications view at all, because on unity's latest builds the trash
> is always available in the dock.
>
>
Agreed. I did think about that, and then decided just to move it down, but
yeah, it really doesn't belong there. By the way, we've hit OMG!Ubuntu!
http://www.omgubuntu.co.uk/2010/12/mock-up-application-overview-in-unity/

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Why the launcher should be on the right

[Luke Benstead]

On 19 December 2010 17:22, Mirek M.  wrote:

> Hi everyone,
> As my requests for having an option to put the Ubuntu button + launcher on
> the right have been received as insignificant feature requests, I'd like to
> explain how Ubuntu button + launcher actually make more sense and improve
> usability on the right.
>
> If they were on the right by default, then:
>
> *The whole left side of the screen would be devoted to the current
> application*
> Right now, you get some system-related commands on the right of the top
> panel, application-related commands on the left, and some more
> system-related commands on the far left.
> Moving the launcher and the Ubuntu button to the right would put all the
> system-related commands on the right and all the app-related commands on the
> left, so neither the launcher nor the Ubuntu button gets in the way when
> working with a single application.
>
> *A "hot corner" wouldn't get in the way*
> Keeping application commands separate from system commands is especially
> important to workflow when you have areas that activate on hover (e.g.
> Ubuntu button). It is extremely annoying and distracting when you
> accidentally mouse over a "hot corner"and have to wait a few seconds to get
> back to work. As the menu bar and window buttons are aligned left, and as
> most toolbars are also left-aligned, a hot corner on the right will be less
> likely to be accidentally triggered than a hot corner on the left.
>
> *The application would get the most focus*
> As most languages are read from left to right, our focus tends to start at
> the left side of the screen. If the goal of Unity is to maintain focus on a
> single task, it makes most sense to put the launcher somewhere where it
> doesn't distract from the application -- on the right.
>
> *"Tools" would be easier to target*
> Most image editors, raster or vector, have a "Tools" sidebar on the left,
> which is very easy to target when it is at the edge of the screen, but very
> hard to target when there's a launcher at the left edge of the screen.
>
> I hope that this is enough to at least consider moving the launcher to the
> right.
>
> Looking forward to follow-up comments,
> Mirek
>

I agree completely, unfortunately I think this is a decision that's already
been made :(

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] [Bug 692921] Re: Allow for the panel to be disabled (wishlist)

[Luke Benstead]

On 21 December 2010 11:21, Mark Shuttleworth  wrote:

>
> We definitely need a natural way to move between "full screen" (no
> panel) and "panelled" mode, across multiple apps. And perhaps we need a
> good way for things like indicators to show up at appropriate times,
> when the panel is not being displayed.
>
> Just to clarify, do you mean that there would be a system-wide on/off
switch for the Unity panel (my request) or do you mean that entering an app
into a "fullscreen" mode would remove the panel (which, while a cool
feature, is not quite what I was after :) )


> So kudos to the Elementary team for their explorations with wingpanel.
>
> In terms of space efficiency, though, if you maximise a window and have
> wingpanel float over it, you effectively have the same thing as the
> design goal for 11.04 Unity: maximised windows put titles / window
> controls / windicators into the panel themselves. And if you're not
> using a maximised window then space efficiency is by definition not your
> primary concern.
>
>
The obvious difference is of course the global menu. Indicator-appmenu is my
only gripe with Unity, and the reason is that I use more than one monitor
and focus follows mouse on my work desktop; a global menu isn't a great fit
for this. I want a consistent experience across all my PCs and so if I
remove indicator-appmenu from one, I'll remove it from all. This leaves me
with a rather irritating blank panel stretched across the desktop that I
can't do anything with. Wingpanel is for me the ideal solution; hence the
bug report, I'd like to run Wingpanel + Unity Dock together (which would be
my ideal setup, I even mocked up this exact setup on Ayatana before
Wingpanel even existed: https://lists.launchpad.net/ayatana/msg04044.html )


> I can see that there's a "lightness" of the desktop without the panel,
> yes. So I think this idea has merit and is worth exploration. I would
> welcome mockups and discussion on the Ayatana list, cc'd.
>
> Mark
>
>
>
Cool :)
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] The Wall instead of "Desktop"

[Luke Benstead]

On 4 January 2011 11:19, Cyrille Ngassam Nkwenga  wrote:

> Hi All Friends,
>
> Warning : I'm not a designer, but just a daily user of Ubuntu.
>
>
>
> So let have a look on the "Desktop" paradigm.
>
> We used to understand the "Desktop" as the one on real life.  The "desktop
> contains our files(can contain Personal Data, Music, Pictures, Movies), this
> is the way we used it just now. But in this way , the Desktop means the same
> thing as our Home Folder.  it is a bit confusing. When we are working on
> Computer, we don't have any sight of the "Desktop", so for most of the time
> is irrelevant for us to keep on going with the "Desktop" as a Folder.
>
> I think they was/are active discussion about this "Desktop" paradigm.
>
> Here is my Idea : Why not start thinking of the Desktop as just A Big
> (pin)Wall !
>
> So we could add Notice , link (shotcuts), pictures, and more relevant
> things to the Wall through Widget. as a background for the Wall, light
> 'Wall'papers are just a logical choice.
> Designer could think about any other possibilty the Wall paradigm  could
> bring to the user's experience.
>
> Thanks All for reading me
>
>
>
This seems quite relevant to this discussion:
http://live.gnome.org/TheBoardProject/

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] The Wall instead of "Desktop"

[Luke Benstead]

> another thing that disturbed me was that i now had no generic place to put
> stuff which i didn't want to have in my face all the time..
>


^^ this

I only ever use the desktop for stuff I need temporarily or that is yet to
be organized. I wish there was a corner of the screen where I could drag
files into a "box" that was then hidden away (autohide-style) where I could
retrieve them later. I'd also like to be able to save files to this box
(e.g. download files to it). Sometimes I'd like to empty it (which would
move the files to the rubbish bin). I'm visualising a slide-out drawer here.

The big problem with using the Desktop for this functionality is you have to
clear your workspace while you access the contents. What I'd like, (and I'm
sure I'm not alone) is a globally and quickly accessible temporary storage
area which is similar to the Rubbish Bin, but more accessible and for stuff
not necessarily destined for deletion.

Luke.
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Implementation of a built-in screencaster in Unity like there is in GNOME Shell

[Luke Benstead]

On 14 February 2011 11:07, Matthew Paul Thomas  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> ks64 wrote on 01/02/11 18:27:
>>
>> Despite all the hype about Unity, there is one thing that is making me
>> miss GNOME Shell: built-in screencasting. Press Ctrl+Shift+Alt+R and you
>> can start and stop screencast recording in GNOME Shell. If a similar
>> feature existed in Unity, it could be an excellent advertising tool:
>> Users could easily record a screencast in Unity and upload it to
>> YouTube, thus building an Ubuntu fan base that could in turn help to
>> overthrow Microsoft's evil empire. There's just one problem: Unity does
>> not have a built-in screencaster!
>
> If anyone is interested in implementing a simple combined screenshot and
> screen recording utility, for Ubuntu to ship by default instead of
> gnome-screenshot, I would be happy to help them with the design.
>

Kazam* is a nice clean screen recorder that could probably be adapted
for the purpose, although it's been low on commits recently.

Luke.

* 
http://whyareyoureadingthisurl.wordpress.com/2010/06/29/introducing-a-screencaster-called-kazam/

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Menu bar integrated in title bar in Unity

[Luke Benstead]

On 18 February 2011 11:10, David Stevenson  wrote:
> On 18/02/11 04:38, Greg K Nicholson wrote:
>>> Why not integrate (and hide) the menu bar in the title bar instead for
>>> ummaximized windows?
>>
>> This makes sense logically.
>
> I also like this idea. My top panel has always been full, the first
> thing I do on any install is to delete the bottom bar and put all the
> information I want in the top bar. So now I need to hide information I
> have been used to having visible to make room for menus while leaving a
> title bar empty.
>
>> The massive downside to all of this is Fitts's law: the effective
>> target area of a menu bar is vastly reduced when it isn't at the
>> screen's edge. For that reason alone, and despite its logical and
>> aesthetic elegance, I think we have to reject this idea.
>
> Have users really been having problems clicking on menus? I know we are
> all different but I would not have thought this affected many users.
>
> David
>

Yeah, I don't think it's that much of a problem. Fitt's law keeps
being quoted as an excuse to do stuff over and above other factors.
I'm still unhappy that the global menu has been implemented despite
not-working well with dual-monitors, focus follows mouse, or really
large resolutions, but whenever this gets mentioned "Fitt's law" seems
to be the overriding excuse. We need to stop putting so much emphasis
on Fitt's law, it's only one element of good usability.

My suggestion is that we shouldn't be hiding menus behind titles, it
would be far more sensible (IMO) to consistently display the
application name in the title bar of each window as a menu, whose
submenu consists of the current menu bar (e.g. display "Firefox" next
to the window controls, clicking "Firefox" would display a drop down
menu containing "File", "Edit" etc.). If a window is maximized then
the panel becomes the title bar.

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Menu bar integrated in title bar in Unity

[Luke Benstead]

On 18 February 2011 12:25, Luke Benstead  wrote:
> On 18 February 2011 11:10, David Stevenson  wrote:
>> On 18/02/11 04:38, Greg K Nicholson wrote:
>>>> Why not integrate (and hide) the menu bar in the title bar instead for
>>>> ummaximized windows?
>>>
>>> This makes sense logically.
>>
>> I also like this idea. My top panel has always been full, the first
>> thing I do on any install is to delete the bottom bar and put all the
>> information I want in the top bar. So now I need to hide information I
>> have been used to having visible to make room for menus while leaving a
>> title bar empty.
>>
>>> The massive downside to all of this is Fitts's law: the effective
>>> target area of a menu bar is vastly reduced when it isn't at the
>>> screen's edge. For that reason alone, and despite its logical and
>>> aesthetic elegance, I think we have to reject this idea.
>>
>> Have users really been having problems clicking on menus? I know we are
>> all different but I would not have thought this affected many users.
>>
>> David
>>
>
> Yeah, I don't think it's that much of a problem. Fitt's law keeps
> being quoted as an excuse to do stuff over and above other factors.
> I'm still unhappy that the global menu has been implemented despite
> not-working well with dual-monitors, focus follows mouse, or really
> large resolutions, but whenever this gets mentioned "Fitt's law" seems
> to be the overriding excuse. We need to stop putting so much emphasis
> on Fitt's law, it's only one element of good usability.
>
> My suggestion is that we shouldn't be hiding menus behind titles, it
> would be far more sensible (IMO) to consistently display the
> application name in the title bar of each window as a menu, whose
> submenu consists of the current menu bar (e.g. display "Firefox" next
> to the window controls, clicking "Firefox" would display a drop down
> menu containing "File", "Edit" etc.). If a window is maximized then
> the panel becomes the title bar.
>
> Luke.
>

Quick mockup of what I mean: http://i.imgur.com/a763I.png clicking the
orange Firefox button would bring down a drop down menu.

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Menu bar integrated in title bar in Unity

[Luke Benstead]

On 18 February 2011 13:23, Andrew Laignel  wrote:
> *Cough*
> https://wiki.mozilla.org/File:Firefox-4-Mockup-i06-%28Win7%29-%28Aero%29-%2
> 8TabsTop%29.png *cough*
>
> :)

Err... yeah, like that :)

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] No one will ever use the upper-left Ubuntu button

[Luke Benstead]

On 10 March 2011 09:25, Mark Shuttleworth
 wrote:
>
> Let's see what people who try it have to say. Don't worry if there is
> negative feedback, that's what exploring and testing are all about.
> Thanks for making the testable mockup.
>

I really like the flipping* dock idea, it declutters the "application
area", I like the separation of applications and places. It's touch
friendly, easily discoverable (well, as discoverable as the Dash...)
and simple. What's not to like?

Luke.

*Obviously, a vertical rotation of the dock around the Y-axis would
look awesome!

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] 'Control Center' should be in 'Launcher' not in 'Session Menu'

[Luke Benstead]

On 11 March 2011 15:43, Lee Hyde  wrote:
> On 11/03/11 14:41, Mark Curtis wrote:
>> Someone else suggested putting it in the Me Menu
>> This would solve both problems of not being close to Shut Down nor
>> cluttering up the Launcher
>>
> I can't imagine any justification for placing a Control Centre entry
> within the Me Menu (other than desperation). It simply doesn't fit the
> Me Menus brief in that it has nothing to do with identity and online
> status. One could make a case for including an entry for Users and
> Groups within the Me Menu, but a Control Centre entry would be even more
> misplaced than the current (in stock Maverick) Ubuntu One entry (which
> oddly enough is moving to the Messaging Menu in Natty).
>
> Regards,
>
> Lee.

Absolutely, the control center doesn't fit at all in any of the
indicators (although certain elements of it do).

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Design problem: Menus hidden by default in Unity

[Luke Benstead]

On 15 March 2011 20:13, Vishnoo  wrote:
> On Tue, 2011-03-15 at 15:51 -0300, Conscious User wrote:
>>
>> Thorsten Wilms wrote:
>> > The alternative would be to show both title and menu, but giving
>> > the menu priority. For habituation and quick aiming, it's important
>> > that the menu always starts in the same spot from the left (assuming
>> > LTR reading direction). To guarantee that, without using an offset
>> > from the left that will always be too small or too large, the title
>> > would have to be right-aligned to the right side of the window or
>> > panel. But clipped/faded-out on the right, when necessary.
>>
>>
>> And where would the window buttons go?
>>
>> If this discussion ends up concluding that they are better on the
>> right, the universe will probably explode with irony.
>>
>
> I dont think we should decide _not_ to do the right thing just for the
> sake of irony..  ;-)
>
> Sane design trumps irony any day.. ;p
>
> --
> Cheers,
> Vish


Erm, I hate to point out the obvious, but why don't we just put the
menu back in the windows and abandon appmenu as a failed experiment?
Keep the title and window controls in the panel for maximized windows
only (at least just for Natty).

I can already imagine the replies to this email, so let me save you
guys the trouble:

1. Someone will bring up Fitt's Law. Yes I know what it is. No, I
don't think it should be used as an overriding reason to squash,
overlap, and generally complicate a UI and shove it into an edge. I
especially don't see why Fitt's law is so important for menu bars,
when users get on perfectly fine with buttons, sliders, window resize
grips and icons, and well, everything else.

2. Someone will likely bring up the space saving of the global menu.
Firstly, the global menu only saves vertical space on a maximized
window, on non-maximized windows they only save on "chrome". By
keeping the title in the panel for maximized windows, we are still
saving 22px on Gnome 2, with the removal of the bottom panel that
brings it up to 44px. It's about finding a balance of space saving vs
usability and I really think we have shot past that balance point with
the global menu.

So, the question again raised is why exactly are we using a global menu?

I know I've brought it up before, but alongside the issues we are
having fitting it into the panel with the title, it also brings issues
with dual monitors, large resolutions and focus-follows-mouse. It
doesn't fit all use cases.

I think we should revert the global menu for Natty, and spend the next
6 months innovating on the menu bar, finding a replacement that
doesn't have the chrome but is easy to use. Firefox and Chrome have
come up with their replacements and Elementary are removing it
altogether in their apps. Now we have a dbus API for exporting the
menus maybe there is another, better, more compact, way to display
them to the user?

The only other suggestion I can come up with is to make the title a
button that displays the menu bar as drop down menu (Firefox style).

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Design problem: Menus hidden by default in Unity

[Luke Benstead]

>> 1. Someone will bring up Fitt's Law. Yes I know what it is. No, I
>> don't think it should be used as an overriding reason to squash,
>> overlap, and generally complicate a UI and shove it into an edge. I
>> especially don't see why Fitt's law is so important for menu bars,
>> when users get on perfectly fine with buttons, sliders, window resize
>> grips and icons, and well, everything else.
>
> That's looking at it backwards, I think. Screen edges are efficient
> target areas for whatever is put there. Given that, what should they be
> used for? Menus are used a lot, ergo, they're a good candidate to be
> made more efficient.

Last time I brought up the global menu, the I was pointed to an image
of someones cursor-tracking while using an application and the fact
that menu bars were NOT used much was used as argument for the global
menu

>> 2. Someone will likely bring up the space saving of the global menu.
>> Firstly, the global menu only saves vertical space on a maximized
>> window, on non-maximized windows they only save on "chrome".
>
> It also saves space whenever two or more windows are stacked vertically.
>

Fair point, but uncommon.
                                                          By
>> keeping the title in the panel for maximized windows, we are still
>> saving 22px on Gnome 2, with the removal of the bottom panel that
>> brings it up to 44px. It's about finding a balance of space saving vs
>> usability and I really think we have shot past that balance point with
>> the global menu.
>
> "Space saving vs usability" is a false dichotomy. Space saving reduces
> scrolling and memory load, which is part of efficiency, which is part of
> usability.
>

Not always, this menu hiding thing is a perfect example. Hiding the
menu saves space and as you've said yourself has made usability worse.
There is a point when finding ways to save space will hinder
usability. My opinion is that the global menu is just past that point,
and your opinion is that it isn't.

>> So, the question again raised is why exactly are we using a global
>> menu?
>
> Benefits:
> *   Much faster to use.
> *   Saves vertical space.
> *   Menus no longer need to be cramped by, or overflow beyond, the
>    window width (e.g. Empathy, Gimp, Inkscape).
> *   Menus no longer surprisingly open upwards when the window is near
>    the bottom of the screen.
> *   Allows the desktop to have the same menus as any other folder
>    (which, in turn, will reduce the complexity of context menus).
> *   In future, will allow dialogs to have "Edit", "Help" etc menus
>    consistent with other windows.
> *   In future, will allow visual unification of title bars and toolbars.

1. Really? Do we have recent usability studies to prove this across
multiple resolutions? I know Apple did research into this a long time
ago, but I don't think that this research upscales to the HD and
widescreen resolutions we deal with today. Although hitting the target
may be faster, I honestly believe that the context switch (determining
which window is focused/focusing the right window) and mouse travel
time outweigh this.
2. True
3. Unless of course we are putting window controls, dash buttons,
indicators and window titles along with it, you'll still run out of
space, granted it's less likely. I've also never noticed this to be a
problem.
4. True, but really REALLY uncommon
5. Well, we did have the menu bar before which was almost exactly the
same anyway
6. and 7. Well, OK.

>> I know I've brought it up before, but alongside the issues we are
>> having fitting it into the panel with the title, it also brings issues
>> with dual monitors, large resolutions and focus-follows-mouse. It
>> doesn't fit all use cases.
>>...
>
> Dual monitors are not a problem (though if they're stacked vertically,
> the bottom one loses its speed benefit). Large screens make the menus a
> bit slower, but not nearly as slow as they would be inside windows. The
> loss of focus-follows-mouse is a real tradeoff, though. (I've specified
> how it could be made compatible, but no-one has been interested enough
> to work on it yet.)
>

I don't agree that dual monitors / large resolutions aren't a problem.
I've used appmenu with dual monitors and the detachment from the menu
is a real issue. Take a look at this animated gif:
http://www.omgubuntu.co.uk/wp-content/uploads/2011/02/lo-appmenu.gif
That isn't even a large screen and still the user stops to click the
correct window before going to the menu. That does not happen without
global menus and the mouse distance to travel is less.

Just to clarify, I am totally in favour of the global menu on small,
netbook size screens. Because on small screens you are a.) nearly
always operating fullscreen windows and b.) limited on vertical space.
On large screens with multiple small windows and ample vertical space,
I don't think it fits.

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to 

Re: [Ayatana] List of running windows of an application in the launcher quicklist

[Luke Benstead]

On 23 March 2011 14:13, Bilal Akhtar  wrote:
> Hello all,
>
> I filed bug [1] in unity today, and it was marked 'opinion' by sabdfl as
> it needed more discussion before it could be implemented.
>
> The current way of switching between windows of the same app is
> time-consuming. The launcher icon has to be clicked twice for the
> 'spread' compiz view to get activated, and then we switch between windows.
>
> Alongside this, it would be good to have a numbered list of running
> windows of an app, in its launcher icon's quicklist. This list would be
> separated from the rest of the quicklist items by a separator line. An
> example of such an implementation is in Gnome-Shell.
>
> Awaiting your comments,
>
> Bilal Akhtar
>
> [1] https://bugs.launchpad.net/bugs/740862
>

I agree, I think switching windows in Unity is cumbersome and
frustrating. Windows 7 actually gets this right IMO, if you hover the
application icon you are shown a list of that application's windows.
You can select the window you want in a single click, it's extremely
fast and easy to use.

DockbarX also implements this for GNOME and also gives the option of
window previews instead of a list. I urge anyone who hasn't tried
DockbarX to give it a spin under GNOME 2.x I think it would be a huge
improvement to Unity if this kind of window switching was implemented.

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Indicator-sound and highlighting the track on mouseover

[Luke Benstead]

>
> I dint realize it copied info to clipboard either.
> Why is that "copy to clipboard" so easily accessible, btw? Do a lot of
> people use that info frequently?
>
> I was actually expecting that clicking on the song info, would open the
> player and focus on that song.
>
> --
> Cheers,
> Vish

+1. That would the obvious behaviour. I only knew about the copy +
paste functionality because I read about it on this list when it was
introduced! :)

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] New style of Minimize button for Natty

[Luke Benstead]

On 2 April 2011 09:17, Muhammad Nabil  wrote:
> SInce the applications window minimize to the launcher (which on the
> left) in Natty Narwhal, how about change the current style of Minimize
> button to this :
>
> http://i.imgur.com/AxKxD.png
>
> What do you think?
> --

Genius. +1

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] why global menubar/application menu isn't such a great idea

[Luke Benstead]

On 5 April 2011 13:47, nick rundy  wrote:
> There are a lot of other applications that benefit from the additional space
> afforded by merging the titlebar and menubar into the panel besides the
> web-browser. Nautilus, media players, music players, word processors, e-mail
> clients, text editors, burning software, etc. Not all applications place
> tabs over the titlebar. Most applications waste enormous space by devoting a
> whole line to just a few menu items. Also please note that even if the
> web-browser places tabs over the titlebar it does not provide any additional
> vertical space when compared to Unity. For example, Unity has the 1.) panel,
> 2.) web-browser tabbar, and 3.) web-browser URL bar. A default install of
> Windows has the 1.) Windows taskbar, 2.) web-browser URL bar, and 3.)
> web-browser tabbar, and 4.) the titlebar if the tabs are not placed over it.
> Apple Mac is even worse. It has titlebar and a bottom Dock.
>
> Unity's design is the best of the three and the most useful for creating
> vertical space.

I'd still give my right arm if there for an option to enable the
global menu for maximized windows only. That would be perfect for me.
Would patches for that be accepted?

Luke.

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp