Re: [Ayatana] Updates on Login

[Mike Rooney]

On Mon, Jul 6, 2009 at 10:42 PM, mac_v wrote:
> Scott Kitterman wrote:
>>
>> On the other hand, fast boot is an explicit Ubuntu design goal for a
>> variety of reasons including users typically start their computers because
>> they want to use them.
>>
>> Before getting too set on installing updates at boot, I'd suggest some
>> discussion with the people on the Ubuntu foundations team working on faster
>> boot speed.
>>
>> Scott K
>>
>
> ^+1 to Scott,
> The only problem with constant reboots is, the delay to get your work
> started, this leads to people not installing the updates at boot at all,
>  but rather later during the system use.
>
> Is there a way to explicitly *not start the package and update it* ?
>
> Like for example , now , when we do an update which asks for a reboot,
> We only need to reboot once, But when updates are done at login , we are
> rebooting twice[well not reboot exactly but starting the system twice].
>
> So is there a way to mark the packages which require reboot , and Not
> start them during the boot , but to update them and this would just
> *delay the boot by a few seconds during which the present icon is shown*
>
> This way the user never actually reboots .
>
> But, i guess ,this can be done better with updates at shutdown.
> With *updates at shutdown the user never has to actually reboot* . the
> word Reboot doesnt even have to be used!
>
> The only scenario which is against updates at shutdown is for laptops ,
> needing immediate shutdown.
> *So doing updates at shutdown and allowing option to instant shutdown*
> is more logical and user friendly.
>
> cheers,
> mac_v

Yeah, I think I see what you mean, this is kind of cool. So during one
session my updates are downloaded automatically in the background. The
next time I restart, before the desktop environment is loaded, we
display a large present graphic with an encircling progress bar that
says "Updating your system" and something like "Press Escape to boot
immediately without updates". Being pre-downloaded, this could be
pretty fast. Afterwards it goes in to the normal boot sequence, or if
a reboot is required, restarts the kernel.

I agree that log-in time is not very disruptive since I have nothing
to interrupt except my patience and if I am in a hurry I can just
press escape. That said shut-down also has some potential. I think it
is cool that we are throwing out all sorts of ideas and conceptually
iterating on them. Keep it up!

Michael Rooney
mroo...@ubuntu.com

___
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 + fullscreen + multiple monitors

[Mark Shuttleworth]

Scott Kitterman wrote:
> On Mon, 06 Jul 2009 05:49:16 +0100 Mark Shuttleworth  
> wrote:
> ...
>   
>> In this initiative, I want us to take a different approach. We will strip 
>> 
> away non-essential decisions from the user experience, at the cost of 
> flexibility in the final product. For me, that's not a bug, it's a feature, 
> though I accept that others feel differently. I'd like to build a community 
> that is aligned with that goal - here on the Ayatana list.
> ...
>
> Is this then an invitation for those who do not accept this premise to 
> leave?
>   
There will be plenty of useful conversations we can have even if we have
different perspectives, it's up to you to decide if you'd like to stay.
But for my purposes, it works better to work closely with a community
that does agree on values such as this. Imagine the endless threads it
would generate if we disagreed on this key point.

You know, classically, this was a GNOME vs KDE value, but I don't
believe it is that any more. I've seen KDE folks increasingly aligned
with this value too.

Mark


signature.asc
Description: OpenPGP digital signature
___
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] Updates on Login

[mac_v]

Scott Kitterman wrote:
> 
> On the other hand, fast boot is an explicit Ubuntu design goal for a 
> variety of reasons including users typically start their computers because 
> they want to use them.  
> 
> Before getting too set on installing updates at boot, I'd suggest some 
> discussion with the people on the Ubuntu foundations team working on faster 
> boot speed.
> 
> Scott K
> 

^+1 to Scott,
The only problem with constant reboots is, the delay to get your work
started, this leads to people not installing the updates at boot at all,
 but rather later during the system use.

Is there a way to explicitly *not start the package and update it* ?

Like for example , now , when we do an update which asks for a reboot,
We only need to reboot once, But when updates are done at login , we are
rebooting twice[well not reboot exactly but starting the system twice].

So is there a way to mark the packages which require reboot , and Not
start them during the boot , but to update them and this would just
*delay the boot by a few seconds during which the present icon is shown*

This way the user never actually reboots .

But, i guess ,this can be done better with updates at shutdown.
With *updates at shutdown the user never has to actually reboot* . the
word Reboot doesnt even have to be used!

The only scenario which is against updates at shutdown is for laptops ,
needing immediate shutdown.
*So doing updates at shutdown and allowing option to instant shutdown*
is more logical and user friendly.

cheers,
mac_v

PS:BTW, *the present icon used in update manager window would be nice*

___
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 + fullscreen + multiple monitors

[Scott Kitterman]

On Mon, 06 Jul 2009 05:49:16 +0100 Mark Shuttleworth  
wrote:
...
>In this initiative, I want us to take a different approach. We will strip 
away non-essential decisions from the user experience, at the cost of 
flexibility in the final product. For me, that's not a bug, it's a feature, 
though I accept that others feel differently. I'd like to build a community 
that is aligned with that goal - here on the Ayatana list.
...

Is this then an invitation for those who do not accept this premise to 
leave?

Scott K

___
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] Updates on Login

[Scott Kitterman]

On Mon, 06 Jul 2009 20:46:19 -0400 Joshua Blount  
wrote:
>On 07/06/2009 08:21 PM, David Siegel wrote:
>>
>>
>> Mark Shuttleworth wrote:
>>> Alex Launi wrote:
 On Sat, Jul 4, 2009 at 4:03 AM, Mark Shuttleworth >>> > wrote:

 Updates-on-login are interesting, but I think fatally flawed
 because of the common requirement to reboot after updates.


 This is actually the case where update on login works best. Any 
 other time rebooting is totally interruption. You're working, you 
 need to decide whether or not rebooting is important enough, and 
 then if you do decide to reboot, you need to save all of your state, 
 and actually do the deed. Immediately after boot you don't have this 
 problem. Instead of starting to work and then being disturbed, you 
 delay starting until you can really start, without interruption.
>>>
>>> 's a fair point.
>>
>> Also, as there is no user state before login, we can reboot the 
>> machine without user confirmation. With fast-boot and KMS, we 
>> completely remove the pain from rebooting after updates -- in fact, 
>> the user probably won't even notice the reboot (we should suppress 
>> startup sounds on the reboot).
>>
>
>This is a really good point. We would do well to remember that users 
>don't get frustrated simply at rebooting, their frustration is delaying 
>their ability to *use* their desktop. Time and the appearance of more 
>time is the source of the problem with rebooting, not the fact that a 
>machine needs to cycle due to a kernel update or whatever.
>

On the other hand, fast boot is an explicit Ubuntu design goal for a 
variety of reasons including users typically start their computers because 
they want to use them.  

Before getting too set on installing updates at boot, I'd suggest some 
discussion with the people on the Ubuntu foundations team working on faster 
boot speed.

Scott K

___
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] Updates on Login

[Dylan McCall]

On Sat, 2009-07-04 at 10:15 +0200, Steve Dodier wrote:
> I don't think (b) is a good idea for the following reasons :
> 
>  * When the user shuts the PC down, he doesn't expect to give it
> attention anymore. An update can fail or be interrupted for some
> reasons (package missing on a server, internet connectivity broken,
> kernel upgrade asks if the menu.lst should be changed, etc). How do we
> let the user control the update process in these cases ? How do we
> make sure the user's attention isn't needed ?
>  * What about laptops ? Sometimes you shutdown your laptop because
> you're about to move. Do you want, in this case, to have to wait for
> the upgrade to perform ?
> 
> I'm not against the idea itself, but I think it should be an optional
> thing, not enabled by default.
> 
> SD.

Why is there an assumption that updates on shutdown would work like
Windows, where it basically tricks the user by doing that as a default?
There are much better ways to do this with the same functionality minus
the negatives, largely because we don't depend on it. (Thanks mostly to
cleverer file systems).

I think it makes a lot of sense to have a "Shut down when finished"
check box in the update progress bar, as well as an Update and Shut Down
option that the user can optionally choose when he is logging out. As an
alternative, the former could be replaced by a smarter log out process
that detects a running process like an update and waits for it to quit
before proceeding. This would remove the cruftiness of that first
solution and scale to other things, too.

Something really important to remember is that a cancelled update is a
really, really bad thing (for us and them). Thus, we should never risk
anything that would cause such behaviour. For example, I thought for a
second it would be cool to auto install updates at boot if they have
been downloaded already (like fsck), but it would not be safe to cancel
that (unlike fsck), triggering numerous loud exclamations of a rude word
that looks similar to the command.
With that in mind, I think automatic updates are evil (downloading them
isn't so much), but the benefits can be mostly obtained by giving the
user the right buttons to press.


For the rebooting end of things... how well is GNOME's session saving
working in 9.10? Perhaps the user's session after an update could be
saved, so when the system reboots he gets something reasonably close to
what he left. A hack to automatically log in could be interesting, too,
although possibly a security disaster. (I'm no security expert, so maybe
there's a good way to do it).


I also really love the gift icon. It's cute and meaningful. Although it
may be better suited to notification about new releases :)


-- 
Dylan McCall 


signature.asc
Description: This is a digitally signed message part
___
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] Updates on Login

[Joshua Blount]

On 07/06/2009 08:21 PM, David Siegel wrote:



Mark Shuttleworth wrote:

Alex Launi wrote:
On Sat, Jul 4, 2009 at 4:03 AM, Mark Shuttleworth > wrote:


Updates-on-login are interesting, but I think fatally flawed
because of the common requirement to reboot after updates.


This is actually the case where update on login works best. Any 
other time rebooting is totally interruption. You're working, you 
need to decide whether or not rebooting is important enough, and 
then if you do decide to reboot, you need to save all of your state, 
and actually do the deed. Immediately after boot you don't have this 
problem. Instead of starting to work and then being disturbed, you 
delay starting until you can really start, without interruption.


's a fair point.


Also, as there is no user state before login, we can reboot the 
machine without user confirmation. With fast-boot and KMS, we 
completely remove the pain from rebooting after updates -- in fact, 
the user probably won't even notice the reboot (we should suppress 
startup sounds on the reboot).




This is a really good point. We would do well to remember that users 
don't get frustrated simply at rebooting, their frustration is delaying 
their ability to *use* their desktop. Time and the appearance of more 
time is the source of the problem with rebooting, not the fact that a 
machine needs to cycle due to a kernel update or whatever.


--
Joshua Blount // Ubuntu One // http://launchpad.net/~jblount

___
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] Updates on Login

[David Siegel]

Mark Shuttleworth wrote:

Alex Launi wrote:
On Sat, Jul 4, 2009 at 4:03 AM, Mark Shuttleworth > wrote:


Updates-on-login are interesting, but I think fatally flawed
because of the common requirement to reboot after updates.


This is actually the case where update on login works best. Any other 
time rebooting is totally interruption. You're working, you need to 
decide whether or not rebooting is important enough, and then if you 
do decide to reboot, you need to save all of your state, and actually 
do the deed. Immediately after boot you don't have this problem. 
Instead of starting to work and then being disturbed, you delay 
starting until you can really start, without interruption.


's a fair point.


Also, as there is no user state before login, we can reboot the machine without 
user confirmation. With fast-boot and KMS, we completely remove the pain from 
rebooting after updates -- in fact, the user probably won't even notice the 
reboot (we should suppress startup sounds on the reboot).


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

Re: [Ayatana] Updates on Login

[Vincenzo Ciancia]

Mark Shuttleworth ha scritto:

Alex Launi wrote:
On Sat, Jul 4, 2009 at 4:03 AM, Mark Shuttleworth > wrote:


Updates-on-login are interesting, but I think fatally flawed
because of the common requirement to reboot after updates.


This is actually the case where update on login works best. Any other 
time rebooting is totally interruption. You're working, you need to 
decide whether or not rebooting is important enough, and then if you 
do decide to reboot, you need to save all of your state, and actually 
do the deed. Immediately after boot you don't have this problem. 
Instead of starting to work and then being disturbed, you delay 
starting until you can really start, without interruption.


's a fair point.


I agree entirely, and for the gift icon, let me say "me too" even if 
it's not in vogue right now :) It can be presented in linked 
documentation with some propaganda sentence like "The ubuntu developers  
do a  hard work every day to ensure that the system you are using, 
besides being free (link) is also as bug-free and secure as possible, 
therefore, they have prepared a new update for your system". This would 
impress positively people, even if perhaps it should be checked with 
some study.


As the usual nobody who I am, I have two remarks, though.

1) how does this work? If the system knows that there are updates, then 
it certainly knew it before last reboot (network is typically not up at 
boot for laptots at least). Then if the system knows there are updates, 
it is good to know it as soon as possible (If I am planning to leave the 
laptop unattended because I am going away for lunch break, it's a very 
good time to do updates). So I will somewhat be interrupted before the 
login. Even if, I may decide to postpone updates, and then yes, being 
reminded just as I log in is very good.


2) if it's just a reminder in the gdm window it's good.  I did not 
follow all the threads so sorry if this is obvious, but I imagine the 
gift icon saying "updates available" *and* a checkbox appearing only 
under the selected user name, when an administrator user name is 
selected. This naturally requires an administrator password to work 
(because otherwise the system just won't let you log in as that user 
otherwise). This covers an interesting use case: the administrator does 
not use the machine. Not in a professional network, I mean, but in a 
small business or just in the family. E.g. my mother's laptop in my home 
town. Then normal users, who would not get update notifications at all, 
may be informed of updates available and eventually tell the 
administrator, without this becoming annoying. ***But*** if it has to be 
a pop-up on login, it will look like the typical microsoft-like pressure 
on the user to do things. The windows after-login experienec, with 
several pop-ups coming up trying to get the user to do anything from 
registering the anti-virus and paying money for that to installing 
updates, is the typical thing I show to people, just before showing them 
ubuntu. A pop-up immediately after login would be a big loss in the 
image of ubuntu to users IM*H*O.


Vincenzo



___
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] Updates on Login

[Mark Shuttleworth]

Alex Launi wrote:
> On Sat, Jul 4, 2009 at 4:03 AM, Mark Shuttleworth  > wrote:
>
> Updates-on-login are interesting, but I think fatally flawed
> because of the common requirement to reboot after updates.
>
>
> This is actually the case where update on login works best. Any other
> time rebooting is totally interruption. You're working, you need to
> decide whether or not rebooting is important enough, and then if you
> do decide to reboot, you need to save all of your state, and actually
> do the deed. Immediately after boot you don't have this problem.
> Instead of starting to work and then being disturbed, you delay
> starting until you can really start, without interruption.

's a fair point.


signature.asc
Description: OpenPGP digital signature
___
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: Notification in fullscreen apps

[Praveen]

On Mon, Jul 6, 2009 at 11:18 PM, Vincenzo Ciancia wrote:

> On lun, 2009-07-06 at 22:33 +0530, Praveen wrote:
> >
> >
> >
> > I recently read the karmic-notify-osd proposal and it has a section
> > for what is to done when applications are fullscreen, it currently
> > states that non-critical bubbles must be suppressed.
> >
> > Are notifications from pidgin/empathy considered critical or
> > non-critical?
> >
> >
>
> I have seen a thread here on ayatana where it was stated that the
> default policy will depend on the status as set in FUSA, because if you
> are watching a movie in a romantic mood you don't want ubuntu to get in
> the way, and if you watch the same movie alone you perhaps *want* to be
> interrupted for a chat :) As FUSA is no longer with us I don't know
> what's going on.
>
> There was also a chat about a system indicator, but no news on what it
> would be used for unless I missed some message.
>
> Vincenzo
>
>
___
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: Notification in fullscreen apps

[Vincenzo Ciancia]

On lun, 2009-07-06 at 22:33 +0530, Praveen wrote:
> 
> 
> 
> I recently read the karmic-notify-osd proposal and it has a section
> for what is to done when applications are fullscreen, it currently
> states that non-critical bubbles must be suppressed. 
> 
> Are notifications from pidgin/empathy considered critical or
> non-critical? 
> 
> 

I have seen a thread here on ayatana where it was stated that the
default policy will depend on the status as set in FUSA, because if you
are watching a movie in a romantic mood you don't want ubuntu to get in
the way, and if you watch the same movie alone you perhaps *want* to be
interrupted for a chat :) As FUSA is no longer with us I don't know
what's going on.

There was also a chat about a system indicator, but no news on what it
would be used for unless I missed some message.

Vincenzo


___
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] Updates on Login

[Vincenzo Ciancia]

On sab, 2009-07-04 at 15:31 -0300, Paulo J. S. Silva wrote:
> 
> That is a good point. However, the likelihood of a failure in a
> security
> update that doesn't allow for a clean shutdown is very low (it never
> happened to me and I use Linux since 1994). 

I know that perhaps it is overkill to talk about this right now but I
hear too many voices in favour of automatic upgrades.

It happened to me several times in my life that an update broke the
system often in unrecoverable ways. In jaunty, the pre-latest intel
update (sigh) broke Xorg, it could not start because of a problem in
detecting the LVDS. I do not have any clue on how to get elder debs, so
I had to wait next update and use karmic in the meantime. (Let me open a
parenthesis: I could not figure out how to bring the wireless network up
from command line because iwconfig seems to be a no-action nowadays -
NetworkManager does not have a command line interface; usability in
extreme situations should be taken more into account perhaps by making a
specific investigation on the current system).

You can now jump on me and say "aha! that was not a security upgrade",
but the truth is that it happened several times since when I started to
appreciate upgrades (debian potato) and I can't tell when an upgrade was
for security reasons because I never cared to make a distinction.

I think many already stated this, but if the plan is to do any automatic
upgrade, then it MUST be backed up by a sane rollback policy. It just
suffices to keep a copy of the very basic needs of apt, and a copy of
the old debs in the systems with their configuration, we have everything
in place from the technical side.

OTOH, there is the problem that an upgrade may convert e.g.
configuration files to new formats. But this is not going to happen for
a security upgrade, that could be made into a strict requirement.

I recall some discussion about automatized revert on
ubuntu-devel-discuss, but is the idea still appreciated?

Vincenzo



___
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] Fwd: Notification in fullscreen apps

[Praveen]

-- Forwarded message --
From: Praveen 
Date: Mon, Jul 6, 2009 at 12:15 PM
Subject: Notification in fullscreen apps
To: ayatana@lists.launchpad.net


I recently read the karmic-notify-osd proposal and it has a section for what
is to done when applications are fullscreen, it currently states that
non-critical bubbles must be suppressed.
Are notifications from pidgin/empathy considered critical or non-critical?

I think that the right way of dealing with fullscreen applications is to not
suppress notifications by default. instead providing a global do-not-disturb
mode is more useful as whatever we do we may never guess the intentions of
the user.

Eg.1. Say i am waiting for a IM from my friend, and while waiting i decide
to watch a movie. Then if by default i don't get notified while i am
watching the movie in fullscreen and the movie goes on for 2 hours, then
this is undesirable. Also IMs are meant to be acted upon instantly.
With email this gets more complicated. Some people with some emails want to
reply immediately and would like to be notified. Some people get 100's of
email and possibly reply only once a day to emails.

2. I set a reminder in evolution for an event to occur after 1 hour and
watch some documentary. I certainly dont want to miss the reminder.

3.I might be watching a movie while i wait for a torrent to finish
downloading. In this case notification for loss of net connection is
important,but in other cases it might not be.

So i suggest guessing what notifications user wants or doesn't want in
fullscreen is not really possible. Hence by *default* they must be *
displayed* in fullscreen and a *do-not-disturb mode along with the system
indicator+message indicator *should be  a option to be set.

What do others think on this?
___
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] Updates on Login

[Alex Launi]

On Sat, Jul 4, 2009 at 4:03 AM, Mark Shuttleworth  wrote:

> Updates-on-login are interesting, but I think fatally flawed because of the
> common requirement to reboot after updates.
>

This is actually the case where update on login works best. Any other time
rebooting is totally interruption. You're working, you need to decide
whether or not rebooting is important enough, and then if you do decide to
reboot, you need to save all of your state, and actually do the deed.
Immediately after boot you don't have this problem. Instead of starting to
work and then being disturbed, you delay starting until you can really
start, without interruption.

-- 
--Alex Launi
___
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] Notification in fullscreen apps

[Charlie Kravetz]

On Mon, 6 Jul 2009 12:15:33 +0530
Praveen  wrote:

> I recently read the karmic-notify-osd proposal and it has a section
> for what is to done when applications are fullscreen, it currently
> states that non-critical bubbles must be suppressed.
> Are notifications from pidgin/empathy considered critical or
> non-critical?
> 
> I think that the right way of dealing with fullscreen applications is
> to not suppress notifications by default. instead providing a global
> do-not-disturb mode is more useful as whatever we do we may never
> guess the intentions of the user.
> 
> Eg.1. Say i am waiting for a IM from my friend, and while waiting i
> decide to watch a movie. Then if by default i don't get notified
> while i am watching the movie in fullscreen and the movie goes on for
> 2 hours, then this is undesirable. Also IMs are meant to be acted
> upon instantly. With email this gets more complicated. Some people
> with some emails want to reply immediately and would like to be
> notified. Some people get 100's of email and possibly reply only once
> a day to emails.
> 
> 2. I set a reminder in evolution for an event to occur after 1 hour
> and watch some documentary. I certainly dont want to miss the
> reminder.
> 
> 3.I might be watching a movie while i wait for a torrent to finish
> downloading. In this case notification for loss of net connection is
> important,but in other cases it might not be.
> 
> So i suggest guessing what notifications user wants or doesn't want in
> fullscreen is not really possible. Hence by *default* they must be *
> displayed* in fullscreen and a *do-not-disturb mode along with the
> system indicator+message indicator *should be  a option to be set.
> 
> What do others think on this?

I think the option to display or turn off should always be present.
However, there should also be easy ways to change fonts and colors of
notifications. Visual impairments can make it difficult/impossible to
see the text. This is not a design team decision they should be making,
but user decisions when necessary. 

The fewer choices we allow, the more difficult we make Ubuntu to use by
all people. We have pretty much told users if you want accessibility,
go somewhere else. We don't really think you need choices here.

-- 
Charlie Kravetz 
Linux Registered User Number 425914  [http://counter.li.org/]
Never let anyone steal your DREAM.   [http://keepingdreams.com]

___
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] Updates on Login

[Alan Pope]

2009/7/4 Steve Dodier :
>  * What about laptops ? Sometimes you shutdown your laptop because you're 
> about to move. Do you want, in this case, to have to wait for the upgrade to 
> perform ?
>

I know a few people who initiate the shutdown process, and as they are
in a hurry will leave the shutdown happening as they stuff the laptop
in their bag. If the system carried on working in the bag - performing
updates - which are often fairly intensive CPU/IO wise, there's the
real possibility the laptop will overheat and become permanently
damaged.

If it was an option "Shutdown" / "Suspend" / "Shutdown with updates"
then one can clearly make the choice whether to install or not on that
occasion. I think the Windows way of doing it is worth looking at, but
with the default to be "Shutdown" and not "Shutdown with updates".

Cheers,
Al.

___
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 + fullscreen + multiple monitors

[Mark Shuttleworth]

Steve Dodier wrote:
> What about console-presenter and evince / other PDF viewers ? They're
> used too for presentations. I don't think we can maintain an
> exhaustive list of applications, so maybe we should provide the user
> with a GUI to tell which apps shouldnt be overriden and in which
> circumstances (and have our own default apps there, like Evince in
> fullscreen, Presenter in fullscreen, etc).
>
> This GUI could also maybe offer options for how to manage
> notifications in different presence settings (away / slightly busy /
> don't disturb me at any cost or kittens will die / etc), with, again,
> our default settings. This way, every user who doesn't feel at ease
> with the default behaviour would be able to make it more accurate, and
> we'd cover a good percentage of use cases.
>   
From a style point of view, you should know that I consider every extra
checkbox against the "is it worth a knuckle of my finger" test.

There's always a temptation, when two smart and well-meaning people
can't agree, to add an option so they can both get what they want. It
"costs nothing" to add the checkbox, and it creates the illusion of
consensus because "we can each have what we want" which makes it "easy
to collaborate". This dynamic drives a lot of UI - especially in open
source, where the consequence of a refusal to reach a compromise might
result in the loss of a contributor.

But options, choices, checkboxes actually DO cost a lot. My first job
was at a newspaper, and the thing I learned there was that 90% of people
will read the headline, 30% will read the first paragraph, and 1% will
read the last paragraph of any article. Attention is precious. Also, I
learned that the 10% of people who do not read the headline are actually
skipping the WHOLE PAGE. Why? Because nothing on the page jumped out of
the noise for them. Every checkbox or option or knob we add, raises the
noise level, and increases the chance that the user disengages
completely. Also, every checkbox or option results in additional code
paths, all of which generate more bugs and require more QA and more
tests in the test suite. So, while "agreeing to add an option" seems
like a low-cost way to avoid having to make a decision, it's an illusory
solution. Collaboration is hard, but most meaningful between people who
see the world differently but find a way to accept the same thing. A
checkbox is an attempt to avoid that collaboration, not a mark of it.

In this initiative, I want us to take a different approach. We will
strip away non-essential decisions from the user experience, at the cost
of flexibility in the final product. For me, that's not a bug, it's a
feature, though I accept that others feel differently. I'd like to build
a community that is aligned with that goal - here on the Ayatana list.

This baby community is already flourishing with suggestions and ideas
and code and mockups. I really loved your presentation on cleaning up
and tightening the battery level notifications, and would like to see
that pattern embraced across the whole system! In many cases, an idea
won't be included - whether it comes from me, or MPT, or anybody else
participating. That shouldn't be a disincentive to generating more ideas
or more questions. The Ayatana work will benefit most from being
examined and probed and debated from multiple perspectives, but it won't
benefit if we try to shoehorn them all into one experience. I'd like to
think we'll celebrate the fact that we decided not to confront the user
with another choice, after careful deliberation.

In most cases, we will not have a mechanism to vary a decision. In
*some* cases, there may be behind-the-scenes mechanisms, such as a gconf
option, or text configuration file option, which is not exposed through
the UI. And in very, very rare cases we will thrust our indecision on
the user in the form of an option.

In this case, notification suppression during busy activities, I really
don't think we want to expose all the permutations and combinations. In
a nightmare scenario, someone "might" want to control whether
notifications from Pidgin are displayed during a fullscreen Totem
session differently from fullscreen OpenOffice. And That's Just Nuts, TM.

Instead, we want to be able to find some core, sensible default position.

First, I think that we should define clearly, and ALWAYS display,
"critical" notifications. That means we have to be confident that we can
ensure that apps don't call their notifications "critical" when in fact
they are not. Imminent uncontrolled system status changes, like a forced
suspend on battery exhaustion, are critical. In general, the failure of
a network link, is critical. But a message from Mom is likely not (yes,
I do love my Mom, and a message *might* be critical, but tough).

In order to see which notifications are critical, Karmic is supposed to
be displaying the urgency of notifications as a debug-only label during
the development cycle (to be turned off at RC). On this

Re: [Ayatana] Updates on Login

[Paulo J. S. Silva]

Em Sáb, 2009-07-04 às 10:15 +0200, Steve Dodier escreveu:
> I don't think (b) is a good idea for the following reasons :
> 
>  * When the user shuts the PC down, he doesn't expect to give it
> attention anymore. An update can fail or be interrupted for some
> reasons (package missing on a server, internet connectivity broken,
> kernel upgrade asks if the menu.lst should be changed, etc). How do we
> let the user control the update process in these cases ? How do we
> make sure the user's attention isn't needed ?

That is a good point. However, the likelihood of a failure in a security
update that doesn't allow for a clean shutdown is very low (it never
happened to me and I use Linux since 1994).

Anyhow, problems can arise and they will only show up in the next boot,
which may be a very bad time. The same problem would happen in updates
at login.

>  * What about laptops ? Sometimes you shutdown your laptop because
> you're about to move. Do you want, in this case, to have to wait for
> the upgrade to perform ?

I don't think Mark, or anybody here is saying that updates should be
forced on logout (or shutdown). We are just saying that the option
should be presented to the user (maybe with the default action being
update, I am not completely sure about this). If the person wants the
machine to turn off fast, he/she should just skip the upgrade.

> I'm not against the idea itself, but I think it should be an optional
> thing, not enabled by default.
> 

As I said, updates at any moment should be optional (maybe if the update
is the default action).

best,

Paulo


___
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] Updates on Login

[Paulo J. S. Silva]

Mark,

Why not present the upgrade option in the three situations? At login, at
log out/shutdown and during the session (only once per session or per
day or whatever is a reasonable time)? This would be a away to encourage
upgrades. The key here is to make updates at each moment optional. So
that they do not disrupt the user work flow unless he/she accepts it.

If the user decides to update at login or during a session the system
should tell him when the update needs a restart and prompt the user if
he/she wants to continue.

best,

Paulo



___
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] Notification in fullscreen apps

[Praveen]

I recently read the karmic-notify-osd proposal and it has a section for what
is to done when applications are fullscreen, it currently states that
non-critical bubbles must be suppressed.
Are notifications from pidgin/empathy considered critical or non-critical?

I think that the right way of dealing with fullscreen applications is to not
suppress notifications by default. instead providing a global do-not-disturb
mode is more useful as whatever we do we may never guess the intentions of
the user.

Eg.1. Say i am waiting for a IM from my friend, and while waiting i decide
to watch a movie. Then if by default i don't get notified while i am
watching the movie in fullscreen and the movie goes on for 2 hours, then
this is undesirable. Also IMs are meant to be acted upon instantly.
With email this gets more complicated. Some people with some emails want to
reply immediately and would like to be notified. Some people get 100's of
email and possibly reply only once a day to emails.

2. I set a reminder in evolution for an event to occur after 1 hour and
watch some documentary. I certainly dont want to miss the reminder.

3.I might be watching a movie while i wait for a torrent to finish
downloading. In this case notification for loss of net connection is
important,but in other cases it might not be.

So i suggest guessing what notifications user wants or doesn't want in
fullscreen is not really possible. Hence by *default* they must be *
displayed* in fullscreen and a *do-not-disturb mode along with the system
indicator+message indicator *should be  a option to be set.

What do others think on this?
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp