Re: [Ayatana] Updates on Login

[mac_v]

Mike Rooney wrote:
> 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
> 

Yup that is it...
I like the encircling progress bar... :)

But rather than doing auto-download of updates,
I meant when notified of updates in-session the user chooses to download
& install , packages which dont require reboot are done immediately,
but when a package requires a restart ,
the system just notifies "The following packages will be installed
during next boot", note : *we do not mention the word reboot*.

For firefox updates , the system says "Firefox will be updated when
browser is closed", and the updates window closes...
The FF updates wait till the browser is shut down and updates FF without
disturbing the user.

cheers
mac_v

___
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 Tue, Jul 7, 2009 at 2:21 AM, David Siegel wrote:

> 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
>

I'm lovin it.


On Tue, Jul 7, 2009 at 5:30 AM, Dylan McCall  wrote:

> 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?


Whether or not it asks you, the idea is still flawed. Shutting off your
computer is an, "ok- I'm finished" activity. It's really not safe to walk
away during an update. David and Ivanka are working Friday evening, 18h
roles around and it's more than time to leave. They go to shut off their
workstations and now have to decide whether to stay longer and wait for the
upgrade to complete, or have to upgrade on Monday when they return (which if
it was at login would be perfect since they'd be tired from a long weekend
of binge drinking and could use the extra minute to get some coffee and
advil). If they leave without upgrading that's it- they leave but they
remain ungraded and that's the problem we're trying to solve, getting people
to actually upgrade. If they decide to upgrade they have two options, stay
and wait for it to complete, or leave and hope everything goes ok. If they
stay we've just given them a bad start to their weekend, if they leave it's
quite possible they could arrive Monday morning and have never actually
logged out because debconf was asking them a question and the upgrade STILL
isn't finished.


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).


Even if their desktop is restored, you've still destroyed mental context,
and that's the hardest part to rebuild. It's easy to open a text editor, or
open office back up, the hard part is getting back to where you were
mentally.


On Tue, Jul 7, 2009 at 6:16 AM, 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.


This is a similar case to fsck, it's not that often so it's not really a
huge deal wrt boot times.


On Tue, Jul 7, 2009 at 7:42 AM, mac_v  wrote:

> ^+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.


Constant meaning "once every long while". It's not like we have updates that
require reboot daily. Mmost people don't mind an extra 45 seconds to get
started if it means not being bothered once they're already going.


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*
>

How are you going to not start the kernel?


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!


Rebooting isn't a problem in and of itself, the interruption is the problem.
Updates during use can be very disruptive (in the reboot case especially)
and difficult to present in a way that actually encourages users to Update
(see the debate on notification icon, pop under, etc., etc.). Updates on
shutdown totally avoid the disruption if a reboot is needed, you're
absolutely right about this; however, they absolutely do not help the second
case. Windows is case in point. Windows desktop go notoriously unupgraded,
the upgrades on shutdown has been shown to *not work*. At all. Upgrade on
login however has not (to the best of my knowledge) ever been attempted. Is
this because it's a terrible idea? Maybe, but from the discussion on this
list I'm not inclined to think that's the case. It's just *new*, and new
things are scary. In the reboot case we minimize the disruption, granted we
don't eliminate it, but we take enough of the pain away that it's
effectively no longer an issue and also we have a much more prominent
display that updates are needed. Your full attention is now given to "Should
I upgrade", instead of having a pop under window or a notification tray icon
that you don't notice. I think people are likely to say yes when it's so
prominently displayed in the UI, and they're not already focused on
something else.


The only scenario 

Re: [Ayatana] notify-osd + fullscreen + multiple monitors

[Martín Soto]

On Thu, Jun 4, 2009 at 9:20 PM, 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).


How many applications are there that are *commonly* used for giving
presentations? Five? Ten, maybe? I really don't see a reason why this
couldn't be done in a per-application basis.

Cheers,

M. S.
___
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

[Alan Pope]

Hi,

2009/7/7 Martín Soto :
> How many applications are there that are *commonly* used for giving
> presentations? Five? Ten, maybe?

How many web browsers are in main? Given cloud based presentation such
as Google Docs, they can all be used to give presentations, and I
suspect can all be made to go full screen.

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

[Vincenzo Ciancia]

Martín Soto ha scritto:
On Thu, Jun 4, 2009 at 9:20 PM, 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).


How many applications are there that are *commonly* used for giving 
presentations? Five? Ten, maybe? I really don't see a reason why this 
couldn't be done in a per-application basis.


Martin: it suffers from the same problem as full-screen movies. If I am 
preparing for a presentation, I can be interrupted by mom, and if I 
don't want it I can set my state to busy. If I am actually showing the 
presentation, then I certainly don't want to be interrupted by ordinary 
notifications.


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

[Steve Dodier]

So is it possible to know *before* when a reboot will be required ? Very
likely yes, right ? It only happens when hardware drivers and kernel get
updated ?

The packages list is updated when the computer is turned on, anyway, but
let's assume Mr. User didn't do his updates Monday, then Tuesday he can be
offered this update on GDM (i don't think its feasible on boot if we already
list other OSes according to the new Boot specs, and since there is already
disk encryption  + fscheck). And if the user clicks on "Updates available
(reboot needed afterwards)" in GDM he's asked to identify in order to
process the updates, and then it updates and reboots.

But if Mr. User refuses to do the updates, update-notifier should bother
him, or not ? And on next computer boot, should it still be on GDM ?

As for updates on shutdown, Alex raises a good point. It requires the user
to stay in front of the computer, so I suggest that instead of doing updates
"on shutdown", the shutdown GUI says "There are updates available, it is
recommanded to do them before shutting down, click here to open the Update
manager", and it opens the Updater Manager. Once updates are done, it offers
to proceed with shutdown.

I know that in most cases this is not needed since the update will happen
well, but i think its better to make users expect to have to act. If their
mirror goes down, if debconf asks if a file should be merged, if a dep is
broken, if a public PPA key is missing, then the user will need to be able
to act in order to solve the problem.
___
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

[Praveen]

You are right and hence the only sane way of solving the problem seems to be
to give user the control to seta  global do-not-disturb mode when he needs
it and logging the messages that he misses.This has several advantages such
as

1. No need to predict anything as predictions go wrong a lot.
2. Since user is in control there is less uncertainity.
3. The do-not-disturb mode is useful in many situations apart from
fullscreen apps. Say i am writing a document in openoffice and it is very
important and i must not be disturbed in any way. Then i simply set the
do-not-disturb mode. Voila. 1 setting many uses.

And there are no disadvantages of this solution which i see.

2009/7/7 Vincenzo Ciancia 

> Martín Soto ha scritto:
>
>  On Thu, Jun 4, 2009 at 9:20 PM, Steve Dodier > sidnio...@gmail.com>> 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).
>>
>>
>> How many applications are there that are *commonly* used for giving
>> presentations? Five? Ten, maybe? I really don't see a reason why this
>> couldn't be done in a per-application basis.
>>
>
> Martin: it suffers from the same problem as full-screen movies. If I am
> preparing for a presentation, I can be interrupted by mom, and if I don't
> want it I can set my state to busy. If I am actually showing the
> presentation, then I certainly don't want to be interrupted by ordinary
> notifications.
>
> 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
>
___
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

[Martín Soto]

On Mon, Jul 6, 2009 at 6:49 AM, Mark Shuttleworth  wrote:

> Second, I think we want to do some useful inference of busyness. I like the
> fullscreen idea and was a promoter of that, but I think there have been
> compelling counter-arguments on this list.
>

The problem with fullscreen is that it is too ambiguous as an information
source. As pointed out by others, fullscreen can mean that you're busy, but
it also can simply mean that you want to make better use of your screen's
real state. As you say, however, the idea has merits, so we should probably
explore it further.

I would say that notifications on top of fullscreen are generally not a
problem when the user is the only person looking at the screen. If I'm
testing my presentation or watching a movie on the train, being notified of
a new IM message is probably OK. On the other hand, if 10 people are looking
at my presentation, or my date is watching the movie with me on the
widescreen TV, I probably don't want IM texts or e-mail subjects being
pasted all around. The question is, then, can we reliably detect the fact
that video is being sent to an external projector or TV and block
notifications in that case? I realize this can be tricky, because many
people have multi-screen setups which aren't intended for presentation, but
I guess the idea is worth exploring, anyway.


> One approach might be to extend the queue-life of notifications, so that if
> one enters fullscreen mode for a minute, say, one still gets notifications
> that queued up, but if one does it for longer they start to die off in the
> queue. We certainly don't want people to get ancient notifications, or
> flooded with notifications when they come out of fullscreen. So this is a
> fruitful area of discussion.
>

This is a related, but separate problem, I think, as it happens also in
other situations, such as when the screen saver is active. Holding
notifications for a while is a good idea, so that you know if something
happened in the last few seconds/minutes before your arrival. For example,
if I just came back to the computer or finished delivering my presentation,
knowing that someone sent an IM two minutes ago is useful, because it's
still a good time to answer.

On the other hand, if the IM was 30 minutes ago, answering now may or may
not be OK, but knowing that someone wrote during the time I was away (or
busy) is still useful. How about replacing the specific message
notifications in this case by something like "You have 3 pending IM
messages"? The general idea is that when you are back to the computer or
come out of the busy mode, you'll be notified of what happened in the time
you were away. However, the level of detail must be adjusted based on the
amount of information available and on its relevance at the time the
notification is finally delivered. This means that you don't necessarily
discard older notifications completely but put them together as necessary to
not overflow the user with data.


>
>
> Third, I think we want some way for the user to influence this, but we want
> it to be systemic (i.e. ONE knob for the WHOLE system, not
> knobs-per-app-per-condition). We've talked about using the presence state
> that is exposed in the FUSA work that Ted Gould did for 8.10. I like that,
> but need to think about the real meaning of the various states we expose
> there, with regard to notifications. The last sketch I saw added a
> "Presentation" state, which was like "Available" but silenced notifications.
> I think it's wrong to use the term "Presentation" because that's only one
> use-case, but I haven't formulated that thinking clearly enough to have a
> strong counter-proposal yet.
>

I would also say the relevant mode is not strictly "Presentation" but rather
"people are looking, don't embarrass me, mom!" It's clear to me that
detecting the "don't embarrass me" situations automatically is not always
easy (yes, your boss may be looking over your shoulder...) but there are
certainly some obvious ones we can handle. The idea of detecting the active
video out goes precisely in this direction.

Cheers,

M. S.
___
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

[Martín Soto]

Hello Vincenzo:

2009/7/7 Vincenzo Ciancia 

> Martin: it suffers from the same problem as full-screen movies. If I am
> preparing for a presentation, I can be interrupted by mom, and if I don't
> want it I can set my state to busy. If I am actually showing the
> presentation, then I certainly don't want to be interrupted by ordinary
> notifications.


Take a look at my last message to this thread: I think it addresses your
point much better. In summary, I think we should not pay so much attention
to the data source, but to the data destination. If you're displaying to the
TV or to a projector, you'd rather not have notifications there.

Best wishes,

M. S.
___
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

[Matt Wheeler]

2009/7/7 Martín Soto :
> Take a look at my last message to this thread: I think it addresses your
> point much better. In summary, I think we should not pay so much attention
> to the data source, but to the data destination. If you're displaying to the
> TV or to a projector, you'd rather not have notifications there.

How do you differentiate between displaying to a TV or projector for a
presentation, or using an external monitor as your primary display
when you're preparing, or watching a video on your own?



-- 
Matt Wheeler
m...@funkyhat.org

___
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]

Alex Launi wrote:
> Whether or not it asks you, the idea is still flawed. Shutting off your
> computer is an, "ok- I'm finished" activity. It's really not safe to
> walk away during an update. David and Ivanka are working Friday evening,
> 18h roles around and it's more than time to leave. They go to shut off
> their workstations and now have to decide whether to stay longer and
> wait for the upgrade to complete, or have to upgrade on Monday when they
> return (which if it was at login would be perfect since they'd be tired
> from a long weekend of binge drinking and could use the extra minute to
> get some coffee and advil). If they leave without upgrading that's it-
> they leave but they remain ungraded and that's the problem we're trying
> to solve, getting people to actually upgrade. If they decide to upgrade
> they have two options, stay and wait for it to complete, or leave and
> hope everything goes ok. If they stay we've just given them a bad start
> to their weekend, if they leave it's quite possible they could arrive
> Monday morning and have never actually logged out because debconf was
> asking them a question and the upgrade STILL isn't finished.
> 

Why do they have to wait! there is no need , it is just
install+shutdown! User just selected install and shutdown!
We Just Make sure we send proper updates. Also... we can set rules that
if the shutdown stalls for x mins , cause a forced shutdown.

But users *has to wait for the updates at login* .

As ScottK has said , there are policies in place which ensure updates
dont break stable releases. Most of the problems occur for us during the
alpha and beta releases.

You are looking at things only from one perspective,
You are focused on only 1 use case that computers are used from 9-6 ,
but think of the average user.
Average users use the computers at any time they want. Not everyone
wants to wait for updates to get to their work [or] hungover every time
they start their machine...

*Most often people want to work* , *not procrastinate at the beginning*
of the day!

> 
Steve Dodier wrote:
>  so I suggest that instead of
> doing updates "on shutdown", the shutdown GUI says "There are updates
> available, it is recommanded to do them before shutting down, click here
> to open the Update manager", and it opens the Updater Manager. Once
> updates are done, it offers to proceed with shutdown.
> 

You are doing the same process! both are the same.
you are saying user finishes work >update then shutdown.!
what everyone else is saying is :
user finishes work > update while shutting down!

What is the difference?

> 
> Constant meaning "once every long while". It's not like we have updates
> that require reboot daily. Mmost people don't mind an extra 45 seconds
> to get started if it means not being bothered once they're already going. 
> Â 

Same way, most people wont mind spending the extra 45sec at the end of
work.
How many times have you stretched/relax just after finishing work?
So many times you hear people saying "just give me a sec, let me stretch
out, before i head out"
Not everyone is in a hurry to run away from their system/office.

It is more often you see people relaxing just after work and spending
some time chatting with the co-workers before they head out. Even if
they are waiting , a 45secs  while they are chatting doesnt matter.

While the same wait at the start of work is really frustrating.

There is also the option for users who just want to shut down immediately!




> 
> 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*
> 
> 
> How are you going to not start the kernel?
> Â 
> 

Thats is exactly why there are problems with login updates.! It always
needs a reboot! atleast until something comes up where we dont start the
kernel.


> 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!
> 
> 
> Rebooting isn't a problem in and of itself, the interruption is the
> problem. Updates during use can be very disruptive (in the reboot case
> especially) and difficult to present in a way that actually encourages
> users to Update (see the debate on notification icon, pop under, etc.,
> etc.). Updates on shutdown totally avoid the disruption if a reboot is
> needed, you're absolutely right about this; 

finally ! That is what *we have to focus on Minimizing Disruptions* ,
the user shouldnt even realize they are updating. we should Only focus
on least intrusion methods.


> 
> And unfortunately for updates at shutdown, laptops are a huge primary
> use case, probably more than desktops at this point. I know I haven't
> owned a desktop for years, and neither have most of the people I kn

Re: [Ayatana] notify-osd + fullscreen + multiple monitors

[mac_v]

Martín Soto wrote:
>> 
> Third, I think we want some way for the user to influence this, but
> we want it to be systemic (i.e. ONE knob for the WHOLE system, not
> knobs-per-app-per-condition). We've talked about using the presence
> state that is exposed in the FUSA work that Ted Gould did for 8.10.
> I like that, but need to think about the real meaning of the various
> states we expose there, with regard to notifications. The last
> sketch I saw added a "Presentation" state, which was like
> "Available" but silenced notifications. I think it's wrong to use
> the term "Presentation" because that's only one use-case, but I
> haven't formulated that thinking clearly enough to have a strong
> counter-proposal yet.
> 
> 
> I would also say the relevant mode is not strictly "Presentation" but
> rather "people are looking, don't embarrass me, mom!" It's clear to me
> that detecting the "don't embarrass me" situations automatically is not
> always easy (yes, your boss may be looking over your shoulder...) but
> there are certainly some obvious ones we can handle. The idea of
> detecting the active video out goes precisely in this direction.
> 
> Cheers,
> 

Labeling the FUSA "Presentation" state to a "Non-critical notifications"
state with a checkbox is the simplest approach.

*We cannot decide every app using full screen* , videos too can/cannot
be disturbed by notification , several use cases have been presented
here to illustrate both scenarios. When a simple FUSA checkbox can do
the job why analyzing all the apps and breaking our heads over how to
handle it?!

cheers,
mac_v

___
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 Tue, 07 Jul 2009 06:44:33 +0100 Mark Shuttleworth  
wrote:
>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.

I think that this view limits your potential audience, but if considered it's a 
settled matter 
in Ayatana, then it's something we will have to agree to disagree on.  It 
certainly does not require the topic be rehashed endlessly.

>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.

I think everyone agrees there can be too many options.  Where too many 
starts generates a much wider range of opinion.

I think the message indicator is something that is likely to be almost 
useful to me, but that conflicts a bit too much with my work patterns.  I 
had been pondering proposing some configurability to deal with where I find 
it problematic, but I'll drop it and expend the mental energy elsewhere.

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

[Alex Launi]

On Tue, Jul 7, 2009 at 12:55 PM, mac_v  wrote:

> Why do they have to wait! there is no need , it is just
> install+shutdown! User just selected install and shutdown!
> We Just Make sure we send proper updates. Also... we can set rules that
> if the shutdown stalls for x mins , cause a forced shutdown.


Leaving the computer while it's still working is *very* likely to cause a
sense of discomfort, and chances are people will stick around and wait for
it to finish.


> But users *has to wait for the updates at login* .


Yes, but because they're starting their computer they're not trying to go
somewhere else. See the difference? When they're shutting down they're
trying to leave; by trying to do more after they've said stop, we're
delaying them from moving on.


> As ScottK has said , there are policies in place which ensure updates
> dont break stable releases. Most of the problems occur for us during the
> alpha and beta releases.


I'm not concerned with breakage from updates, that's another issue. debconf
isn't from breakage.

Average users use the computers at any time they want. Not everyone
> wants to wait for updates to get to their work [or] hungover every time
> they start their machine...


I don't know why you think I'm only looking at one use case. I'm not really
focused on any particular use scenario. You're right not everyone wants to
wait for their updates to get started, but before you start is a better time
to wait than after you finish and want to leave.

Same way, most people wont mind spending the extra 45sec at the end of
> work.
> How many times have you stretched/relax just after finishing work?
> So many times you hear people saying "just give me a sec, let me stretch
> out, before i head out"
> Not everyone is in a hurry to run away from their system/office.
>
> It is more often you see people relaxing just after work and spending
> some time chatting with the co-workers before they head out. Even if
> they are waiting , a 45secs  while they are chatting doesnt matter.


Sure, but what if the update takes 10 minutes? Having to wait to leave is so
much worse than having to wait to get started because of the fact that's
been stated in this thread multiple times about the nature of each action.
Before you start you have time. You're about to sit down, you haven't
started anything, and a reboot is not going to affect your work. If at
shutdown you have to wait, now the computer is keeping you at it when you
need to leave. This is not good.


> Thats is exactly why there are problems with login updates.! It always
> needs a reboot! atleast until something comes up where we dont start the
> kernel.
>

Really we need to get away from the issue that rebooting is a problem. It's
not. The problem is destroying the user's mental context.


> finally ! That is what *we have to focus on Minimizing Disruptions* ,
> the user shouldnt even realize they are updating. we should Only focus
> on least intrusion methods.


I don't agree with this. Upgrading is an important part of using your system
and we need to make sure they get done, but we need to do so in as
non-obtrusive a way as possible. This doesn't mean sneaking them im, it
means finding the right time and right way to present the user with the fact
that they're available, and need installed.

You are forgetting something>
> *we are not designing Ubuntu Only for the people on this list* , Ubuntu
> is used more on Desktops than laptop on the whole, that is what we have
> to design not based our personal experiences , but for the Average users.
> Your assumption that only corporate environment uses desktop is wrong.
> How many laptops are sold/used in comparison to desktops?
>

I'm not forgetting anything, I know who we're designing Ubuntu for. If you
think that laptops aren't a primary use case, you're severely out of touch.
Google around, laptop sales are much higher than desktop sales, and this
trend does not seem to be going away any time soon.


-- 
-- 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] notify-osd + fullscreen + multiple monitors

[Martín Soto]

On Tue, Jul 7, 2009 at 11:22 AM, Praveen  wrote:

> You are right and hence the only sane way of solving the problem seems to
> be to give user the control to seta  global do-not-disturb mode when he
> needs it and logging the messages that he misses.This has several
> advantages such as
>
> 1. No need to predict anything as predictions go wrong a lot.
> 2. Since user is in control there is less uncertainity.
> 3. The do-not-disturb mode is useful in many situations apart from
> fullscreen apps. Say i am writing a document in openoffice and it is very
> important and i must not be disturbed in any way. Then i simply set the
> do-not-disturb mode. Voila. 1 setting many uses.
>
> And there are no disadvantages of this solution which i see.
>

I see a big one: you can easily forget activating the do-not-disturb thing,
or deactivating it later. For example, unless you're a very experienced
speaker, you're likely to be nervous before starting a presentation. This
increases the probability that you forget that little detail of blocking
notifications... until that very personal message from your wife pops up in
front of the audience, that is.

Now, your argument about predictions going wrong is true to some extent. I
don't think we'll be able to find something that works 100% of the time. But
this is no reason to say that we should forget about it completely and let
the user do the whole work. Of course, guessing correctly is difficult, but
this is precisely the hallmark of good UI design.

That said, I don't think that an explicit do-not-disturb mode is a bad idea.
Sometimes, as you point out, people will want to stop all interruptions
because they're under pressure or something. But this, of course, doesn't go
against the idea of having the system do the right thing whenever possible
and without user intervention.

Cheers,

M. S.
___
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

[Martín Soto]

2009/7/7 Matt Wheeler 

> 2009/7/7 Martín Soto :
> > Take a look at my last message to this thread: I think it addresses your
> > point much better. In summary, I think we should not pay so much
> attention
> > to the data source, but to the data destination. If you're displaying to
> the
> > TV or to a projector, you'd rather not have notifications there.
>
> How do you differentiate between displaying to a TV or projector for a
> presentation, or using an external monitor as your primary display
> when you're preparing, or watching a video on your own?
>

Good question: As I mentioned in the other message, this is tricky, and I
don't know the right answer. The xrandr extension provides lots of
information about a video output, and it's probably possible to guess from
that if we're dealing with a projector or TV. I won't be 100% correct, but
it may work in many cases.

Also, future versions of X/Gnome wil automatically offer a configuration box
as soon as you plug in a monitor. We can consider asking the user once at
that point if this is a projector. The UI for doing this would have to be
very well thought, but I guess this could work if done properly.

M. S.
___
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]

Alex Launi wrote:

> Leaving the computer while it's still working is /very/ likely to cause
> a sense of discomfort, and chances are people will stick around and wait
> for it to finish.

As you say, "chances are" i.e> user *can wait* but is not forced to,
but for a login update user *has to wait* .

Login update is a forced behavior. while the shutdown is the users
option to stick around!

*A forced behavior is always frustrating* , while if the user is waiting
 out of his own discomfort it is not frustrating since he chooses to stay.

We are just looking for a solution that doesnt frustrate the user.

cheers,
mac_v

___
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

[Siegfried Gevatter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

2009/7/7 mac_v :
> As you say, "chances are" i.e> user *can wait* but is not forced to,
> but for a login update user *has to wait* .
>
> Login update is a forced behavior. while the shutdown is the users
> option to stick around!

Why is it forced? If I understood the proposal correctly, you'd be
asked if you want to update, and required to introduce your password
for the updates to be installed. Nobody will "force" you to do
anything.

- --
Siegfried-Angel Gevatter Pujals (RainCT)
Ubuntu Developer. Debian Contributor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iQEcBAEBCAAGBQJKUz/vAAoJEBz8IvM2PerjRiEIAJ+mnFCIeD3ounhpFa+F9xvN
budrRZ+IQl66A9rTvQBoUTFY/bH5t0ixj7/44udENteQwDh8so1kkAi6Exp/fNyb
aNa2CwKVJG74HcgzOfXA1Shyl/tjRCOQvLyXlb8oYYP7sVHbPE+ROaHdl2657BKc
FSMQWehU2LqqX+IDpanVgC/bCFMFUN5QEOPW547boDDAxcUND5sDi3iyjGgdSBDq
icPIKMHmBCIFa8xjNzK1LbfsCt+N9ro1/Qd1pBWxhX/11eHHFPIlgIisjUuopY39
nErRHntk1AxOtVhjp2IO3BvG1X1WmbxR0/6ivquwnji+ZChzggrwq4QgCHoZjzk=
=oO6H
-END PGP 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

[Vincenzo Ciancia]

Il 07/07/2009 12:55, mac_v ha scritto:

Why do they have to wait! there is no need , it is just
install+shutdown! User just selected install and shutdown!


I just don't trust the system enough to guarantee it will shut down, and 
don't trust an old laptop I use at office enough to be sure that it 
won't burn the office if left unattended for the night.



___
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

[Vincenzo Ciancia]

Il 07/07/2009 13:30, Martín Soto ha scritto:


I see a big one: you can easily forget activating the do-not-disturb
thing, or deactivating it later. For example, unless you're a very
experienced speaker, you're likely to be nervous before starting a
presentation. This increases the probability that you forget that little
detail of blocking notifications... until that very personal message
from your wife pops up in front of the audience, that is.


Yes, notifications with a message inside are a bit dangerous. The 
current behaviour could be changed in: if the chat window for the 
contact is opened but not visible, show the received message in the 
notification. If there is no open chat window for the given contact, 
just show a message notification, and the messages will be found opening 
the chat window for the contact.






___
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] Solving the "user forgets about presentation mode" problem! (was Re: notify-osd + fullscreen + multiple monitors)

[Vincenzo Ciancia]

Il 07/07/2009 15:07, Praveen ha scritto:

no please don't do such a thing. it takes away a lot of benefits of the
new messaging system. ie i can from the notification know what the other
person has to say and hence decide if i want to open the chat window now
or later.

Also if the messages shouldn't come then one should
set the do-not-disturb mode.



You are right. The problem I was trying to address is that people will 
forget to set the "presentation" state before switching to full screen, 
not deciding which notifications may be embrassing or which applications 
are likely to be presentations.


So let's try to solve that problem. A possibility is to issue a 
notification when an application goes full-screen, saying "notifications 
will be displayed, switch to presentation mode to suppress 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] Updates on Login

[mac_v]

Siegfried Gevatter wrote:
> 2009/7/7 mac_v :
>> As you say, "chances are" i.e> user *can wait* but is not forced to,
>> but for a login update user *has to wait* .
> 
>> Login update is a forced behavior. while the shutdown is the users
>> option to stick around!
> 
> Why is it forced? If I understood the proposal correctly, you'd be
> asked if you want to update, and required to introduce your password
> for the updates to be installed. Nobody will "force" you to do
> anything.
> 

Well... the user has to update at some point, right.

Even if he chooses to ignore it for now, he has to do it again at some
time. We are forcing him to wait,. He will have to sit idle , waiting
for the system to update.

While the shutdown update its his own choice to wait.

cheers,
mac_v

___
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

[mac_v]

Martín Soto wrote:
 >
> I see a big one: you can easily forget activating the do-not-disturb
> thing, or deactivating it later. For example, unless you're a very
> experienced speaker, you're likely to be nervous before starting a
> presentation. This increases the probability that you forget that little
> detail of blocking notifications... until that very personal message
> from your wife pops up in front of the audience, that is.
> 


The users cant/shouldnt expect everything to be spoon fed! The Option is
there! just because the user forgets ,it isnt a design flaw.

A crash is not the error of the car manufacturer but the driver, the
manufacturer has provided the breaks its upto the user to use it! Only
faulty breaks are design flaws.

If we start to make a too complex program , it can ,as Mark said, only
lead to more bugs.

How do we differentiate a presentation done for an audience , and a
rehearsal? we cant!


cheers,
mac_v

___
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 Tue, Jul 7, 2009 at 3:18 PM, mac_v  wrote:

> Well... the user has to update at some point, right.
>
> Even if he chooses to ignore it for now, he has to do it again at some
> time. We are forcing him to wait,. He will have to sit idle , waiting
> for the system to update.
>
> While the shutdown update its his own choice to wait.
>

This isn't much of a choice. You can wait, and know that everything is
working, or you can leave and maybe you'll come back next time and realized
that you never shut down, or your battery died in the middle of a kernel
upgrade. Choice isn't always best. In fact, it's often not.


-- 
--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] Solving the "user forgets about presentation mode" problem! (was Re: notify-osd + fullscreen + multiple monitors)

[Vincenzo Ciancia]

Il 07/07/2009 15:19, Praveen ha scritto:

hmm.. not a bad idea though one must consider that this one initial
notification will be always displayed whenever one goes fullscreen. so
if i watch a lot of movies or am review/editing a presentation i would
be going to fullscreen and back so many many times that each time if  i
get this notification i would be annoyed


Praveen: did you also reply to the list? It does not look like to me but 
I just changed my mail client so who knows.


Yes perhaps once per session per opened application (based on pid? 
window id?) would be sufficient. Nothing is perfect anyway, we have 
testing precisely for 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] Solving the "user forgets about presentation mode" problem! (was Re: notify-osd + fullscreen + multiple monitors)

[Sohail Mirza]

Isn't this whole discussion of a presentation mode making the issue more
complex than it needs to be?

I would think that taking an application into full-screen allows us to
safely assume the user is making the following statement:  "this application
is the only thing I'm interested in right now".  It follows from this that
non-critical notifications should be suppressed while viewing a full-screen
application.

The user already *has* a way of viewing an application window in
close-to-fullscreen size, and that is by maximizing the window (as opposed
to full-screening it).  Maximizing the window can be analogous to the
following statement:  "I'm only interested in this application, but am still
interested in peripheral information".  In this case I think it would be
appropriate to display all notifications.

What *does* need addressing is the use-case whereby a user wishes to
suppress notifications under conditions outside of full-screening an
application.

I hope I'm not missing anything in my analysis.  Is there a use-case of a
full-screen application that does not offer window maximization as an
alternative?

As for the issue of missed notifications, I thought it was early-on decided
that notifications were transient by nature?  Seeing as how one cannot take
direct action on a notification, they seem to be generally used as
informational messages that the user can do without, with the exception of
what have been referred to as "critical notifications" (i.e. "your battery
is nearly empty", "the end is nigh", etc.).  Notifications
*requiring*action should be handled differently, shouldn't they?  This
means that
non-critical notifications can be safely ignored.

I hope my input has been helpful.

Thanks,

Sohail Mirza


On Tue, Jul 7, 2009 at 9:11 AM, Vincenzo Ciancia wrote:

> Il 07/07/2009 15:07, Praveen ha scritto:
>
>> no please don't do such a thing. it takes away a lot of benefits of the
>> new messaging system. ie i can from the notification know what the other
>> person has to say and hence decide if i want to open the chat window now
>> or later.
>>
>> Also if the messages shouldn't come then one should
>> set the do-not-disturb mode.
>>
>>
> You are right. The problem I was trying to address is that people will
> forget to set the "presentation" state before switching to full screen, not
> deciding which notifications may be embrassing or which applications are
> likely to be presentations.
>
> So let's try to solve that problem. A possibility is to issue a
> notification when an application goes full-screen, saying "notifications
> will be displayed, switch to presentation mode to suppress 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
>



-- 
sfm
___
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

[Alex Launi]

On Tue, Jul 7, 2009 at 3:22 PM, mac_v  wrote:

> The users cant/shouldnt expect everything to be spoon fed! The Option is
> there! just because the user forgets ,it isnt a design flaw.
>
> A crash is not the error of the car manufacturer but the driver, the
> manufacturer has provided the breaks its upto the user to use it! Only
> faulty breaks are design flaws.


If the system makes it incredibly easy, it's a design flaw. If your car
manufacturer provides *brakes*, but puts them somewhere inaccessible, where
you can't get to them quickly in an emergency, it's a design flaw. Yes, this
is ridiculous, but it was your example. Not mine.

Martin's concern is certainly valid, but it may be something that should be
dealt with at the application level and not by the system itself.

How do we differentiate a presentation done for an audience , and a
> rehearsal? we cant!
>

Is there a difference at all?


-- 
-- 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] notify-osd + fullscreen + multiple monitors

[Paulo J. S. Silva]

Em Ter, 2009-07-07 às 13:49 +0200, Martín Soto escreveu:

> 
> Also, future versions of X/Gnome wil automatically offer a
> configuration box as soon as you plug in a monitor. We can consider
> asking the user once at that point if this is a projector. The UI for
> doing this would have to be very well thought, but I guess this could
> work if done properly.

I don't see how this guessing can be reliable. I usually use my laptop
in an external monitor to save my back some pain, but I want my
notifications in that case.

And the idea of asking "always" when you plug in an external monitor is
a bad one. As I said I plug one everyday, I don't want to answer the
same question everyday. However I give presentations once a month. It is
much more reasonable to me to turn on the "don't notify me" mode at that
moment.

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] Solving the "user forgets about presentation mode" problem! (was Re: notify-osd + fullscreen + multiple monitors)

[Alex Launi]

On Tue, Jul 7, 2009 at 3:29 PM, Sohail Mirza  wrote:

> I would think that taking an application into full-screen allows us to
> safely assume the user is making the following statement:  "this application
> is the only thing I'm interested in right now".  It follows from this that
> non-critical notifications should be suppressed while viewing a full-screen
> application.


Definitely not. I put firefox, and monodevelop into full screen all the
time, not because I'm super focused on reading the latest posting of
cuteoverload, but because I want the little bit of extra screen real estate.
I know many people who do this. Full screen is not a proper heuristic for
"is busy", as nice as it would be if it were.


-- 
--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] notify-osd + fullscreen + multiple monitors

[Paulo J. S. Silva]

Em Ter, 2009-07-07 às 13:30 +0200, Martín Soto escreveu:

> 
> I see a big one: you can easily forget activating the do-not-disturb
> thing, or deactivating it later. For example, unless you're a very
> experienced speaker, you're likely to be nervous before starting a
> presentation. This increases the probability that you forget that
> little detail of blocking notifications... until that very personal
> message from your wife pops up in front of the audience, that is.
> 

A good solution for this very specific case is to allow applications
that have a "presentation mode" to turn off notifications once you enter
that mode. Note that evince, ooimpress, and acrobat all have different
modes for "presentation" and "full screen". They make a difference
because those two modes are different. Once leaving the presentation
mode the application should revert the notification status.

You know, if turning off the notifications was easy (is it?), that would
count as a simple papercut! 

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

[Scott Kitterman]

On Tue, 07 Jul 2009 11:12:24 +0530 mac_v  wrote:
>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*
>

The current mechanism involves touching a file with the package postinst, 
so there is no way to know prior to install if a package update will 
require reboot or not.  

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] notify-osd + fullscreen + multiple monitors

[Alex Launi]

2009/7/7 Paulo J. S. Silva 

> You know, if turning off the notifications was easy (is it?), that would
> count as a simple papercut!
>

It would be with a global "do not disturb mode" in FUSA!

-- 
--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] Solving the "user forgets about presentation mode" problem! (was Re: notify-osd + fullscreen + multiple monitors)

[Vincenzo Ciancia]

Il 07/07/2009 15:29, Sohail Mirza ha scritto:


I hope I'm not missing anything in my analysis.  Is there a use-case of
a full-screen application that does not offer window maximization as an
alternative?


We talked about movies. I may be just watching a movie alone and want to 
be available for chat. But I want the movie fullscreen. Among other 
reasons consider that compiz can be disabled for fullscreen applications 
and those who need it will not be happy to watch movies in a maximised 
window.


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] Solving the "user forgets about presentation mode" problem! (was Re: notify-osd + fullscreen + multiple monitors)

[Vincenzo Ciancia]

Il 07/07/2009 15:35, Alex Launi ha scritto:

I know many people who do this.


Netbook users do this all the time.

___
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

[Martín Soto]

On Tue, Jul 7, 2009 at 3:22 PM, mac_v  wrote:

> The users cant/shouldnt expect everything to be spoon fed! The Option is
> there! just because the user forgets ,it isnt a design flaw.
>

I wonder what sort of design philosophy you're advocating here. One where we
refrain from automating things that can be automated just so that our users
don't become too lazy?  If this is the case, I don't think I would identify
with your ideas, anyway.

A crash is not the error of the car manufacturer but the driver, the
> manufacturer has provided the breaks its upto the user to use it! Only
> faulty breaks are design flaws.
>

This is not a matter of legal or moral responsibility. This is rather about
preventing user errors, or at least mitigating their consequences when they
happen, which, for me, would be a guiding design principle. Given you're
using the car example, let me continue with it: Since a few years ago,
engineers have been working on different types of sensor systems (such as
radar or sonar) that could automatically operate a car's breaks before it
crashes into something. Would you advocate *not* installing such systems in
commercial cars because "the pedal is there! if the user just fails to press
it on time and kills himself against a wall, it isn't a design flaw!"?


>
> If we start to make a too complex program , it can ,as Mark said, only
> lead to more bugs.
>

I will just refrain from falling into the "Mark said" type of argumentation
(see *argumentum ad verecundiam [1])*


>
> How do we differentiate a presentation done for an audience , and a
> rehearsal? we cant!
>

This is just a particular example, but I would say *in most cases* people
rehearse in front of their normal screen, but they present using a
projector. If we can differentiate between those two cases, we'll have
probably dealt with more than 90% of the practical situations. As I already
said, and this is possibly the most important point, no solution will be
100% reliable, but this is no reason to discard it.

[1] http://en.wikipedia.org/wiki/Argument_from_authority
___
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

[Martín Soto]

On Tue, Jul 7, 2009 at 3:32 PM, Paulo J. S. Silva wrote:

> Em Ter, 2009-07-07 às 13:49 +0200, Martín Soto escreveu:
> > Also, future versions of X/Gnome wil automatically offer a
> > configuration box as soon as you plug in a monitor. We can consider
> > asking the user once at that point if this is a projector. The UI for
> > doing this would have to be very well thought, but I guess this could
> > work if done properly.
>
> I don't see how this guessing can be reliable. I usually use my laptop
> in an external monitor to save my back some pain, but I want my
> notifications in that case.


A regular monitor and a video projector are different devices, and their
EDID data [1] is likely to be different enough that we can indeed
distinguish among them. EDID is not 100% foolproof however. Some devices
report partially wrong data, for example. It can also happen that the EDID
chip gets damaged and stops working at some point, even if the monitor
continues to operate. But, all in all, this may be a workable solution.

And the idea of asking "always" when you plug in an external monitor is
> a bad one. As I said I plug one everyday, I don't want to answer the
> same question everyday. However I give presentations once a month. It is
> much more reasonable to me to turn on the "don't notify me" mode at that
> moment.


The system can remember devices you have used, based on their EDID data. If
you always use the same (type of) device, you would only have to answer the
question once. Also, if your projector has completely broken EDID, you'll
have to think of disabling notifications every time you use it, anyway.
Wouldn't it be better to be reminded of that when you plug it in?

M. S.

[1] http://en.wikipedia.org/wiki/Extended_display_identification_data
___
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

[mac_v]

Martín Soto wrote:
> 
> I will just refrain from falling into the "Mark said" type of
> argumentation (see /argumentum ad verecundiam [1]*)*/
>  

I used it since i remember the users name , also.. you can note i used
ScottK's name earlier , its not about authority , but just a valid point
raised by a previous member. Just because Mark has said it, also doesnt
mean he is wrong ;)

> 
> This is just a particular example, but I would say *in most cases*
> people rehearse in front of their normal screen, but they present using
> a projector. If we can differentiate between those two cases, we'll have
> probably dealt with more than 90% of the practical situations. As I
> already said, and this is possibly the most important point, no solution
> will be 100% reliable, but this is no reason to discard it.
>  

People also present to a small group by just using the normal screen.

I just felt too much thought is being put into this, this only leads to
more bloat of the app... But if a highly intuitive simple system is to
be designed , which is atleast 90% practical, I definitely welcome it :)

cheers,
mac_v

___
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

[Praveen]

2009/7/7 mac_v 

> Martín Soto wrote:
>
> People also present to a small group by just using the normal screen.
>
> I just felt too much thought is being put into this, this only leads to
> more bloat of the app... But if a highly intuitive simple system is to
> be designed , which is atleast 90% practical, I definitely welcome it :)
>
> cheers,
> mac_v
>

True this topic isnt going anywhere it seems. someone should summarise the
discussion and someone from the developer team should just pick the best
solution.
___
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] Solving the "user forgets about presentation mode" problem! (was Re: notify-osd + fullscreen + multiple monitors)

[Sohail Mirza]

First off, netbooks are not a fair use-case for this discussion.  The
limitations of the form-factor may require entirely a different solution to
common problems.  This much is apparent when comparing Ubuntu Desktop to
Ubuntu Netbook Remix.

Now, if you're watching a full-screen movie *and* waiting for an important
notification, then I would think watching that movie full-screen isn't your
best option.  Remember, these are transient notifications... there's no
guarantee you'll notice it anyways.  If, for example, IM is your priority
then you'll likely want your contact list or the Pidgin tray icon showing
anyways.  Same goes for full-screen Firefox or monodevelop.  Are you waiting
for a notification, or busy working with an application?  I admit, I'm
proposing a trade-off between screen real-estate and the importance of a
non-critical, transient notification.

In general, I realize that for *some* people, full-screening the application
is not a fair "I'm busy" indicator, but for the wider user population I
believe this does hold true.  Remember, the notifications we're referring to
are transient, non-critical, peripheral information bits that the user
can *easily
miss anyways*.  They shouldn't represent a central part of the user's
workflow.  If they are central to a user's workflow then notify-osd isn't
the right solution.

We also have to weigh all this against the proposed alternative of
additional configuration or a "presentation mode", and the pitfalls of that
solution.  Users could forget to set presentation mode, miss the
notification that reminds them to do so, forget to come out of presentation
mode.  I think there are just too many ways for the wider population of
users to misconfigure that system.  Just consider the case where one is in a
hurry to setup for a presentation that is already starting late.  Will they
really remember to set presentation mode?  If they glance away from the
screen they might miss the reminder notification too.

For these reasons I think "full-screen = I'm busy" is a reasonable
assumption.


On Tue, Jul 7, 2009 at 9:52 AM, Vincenzo Ciancia wrote:

> Il 07/07/2009 15:35, Alex Launi ha scritto:
>
>> I know many people who do this.
>>
>
> Netbook users do this all the time.
>



-- 
sfm
___
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

[mac_v]

Alex Launi wrote:
>  If your car
> manufacturer provides *brakes*, but puts them somewhere inaccessible,
> where you can't get to them quickly in an emergency, it's a design flaw.
> 

I think the UX team can place the brakes perfectly in the right position
;)

cheers,
mac_v


___
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] Solving the "user forgets about presentation mode" problem! (was Re: notify-osd + fullscreen + multiple monitors)

[Alex Launi]

On Tue, Jul 7, 2009 at 4:39 PM, Sohail Mirza  wrote:

> First off, netbooks are not a fair use-case for this discussion.  The
> limitations of the form-factor may require entirely a different solution to
> common problems.  This much is apparent when comparing Ubuntu Desktop to
> Ubuntu Netbook Remix.



Don't think this is true. I see many presentations give on netbooks. Because
they're so portable they lend themselves to this, and with so many great
presentation apps being in the cloud, it's even easier.



> Now, if you're watching a full-screen movie *and* waiting for an important
> notification, then I would think watching that movie full-screen isn't your
> best option.  Remember, these are transient notifications... there's no
> guarantee you'll notice it anyways.  If, for example, IM is your priority
> then you'll likely want your contact list or the Pidgin tray icon showing
> anyways.  Same goes for full-screen Firefox or monodevelop.  Are you waiting
> for a notification, or busy working with an application?  I admit, I'm
> proposing a trade-off between screen real-estate and the importance of a
> non-critical, transient notification.



No ones *waiting* for a notification, we're doing stuff, and don't want our
notifications turned off. If none come, or we miss them, so be it, but we
certainly want the opportunity.



> In general, I realize that for *some* people, full-screening the
> application is not a fair "I'm busy" indicator, but for the wider user
> population I believe this does hold true.  Remember, the notifications we're
> referring to are transient, non-critical, peripheral information bits that
> the user can *easily miss anyways*.  They shouldn't represent a central
> part of the user's workflow.  If they are central to a user's workflow then
> notify-osd isn't the right solution.



Transient, but not absolutely worthless. If it's worthless, then it
shouldn't be sent in the first place. This assertion is also based on the
idea that netbooks are a different case, which I dont think is the case for
presentations. Maybe for movies and text editors, but I'm not really sure.



> We also have to weigh all this against the proposed alternative of
> additional configuration or a "presentation mode", and the pitfalls of that
> solution.  Users could forget to set presentation mode, miss the
> notification that reminds them to do so, forget to come out of presentation
> mode.  I think there are just too many ways for the wider population of
> users to misconfigure that system.  Just consider the case where one is in a
> hurry to setup for a presentation that is already starting late.  Will they
> really remember to set presentation mode?  If they glance away from the
> screen they might miss the reminder notification too.


This seems like something that should be a dialog, not a notification.


-- 
-- 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] Solving the "user forgets about presentation mode" problem! (was Re: notify-osd + fullscreen + multiple monitors)

[Sohail Mirza]

On Tue, Jul 7, 2009 at 10:48 AM, Alex Launi  wrote:

> On Tue, Jul 7, 2009 at 4:39 PM, Sohail Mirza  wrote:
>
>> First off, netbooks are not a fair use-case for this discussion.  The
>> limitations of the form-factor may require entirely a different solution to
>> common problems.  This much is apparent when comparing Ubuntu Desktop to
>> Ubuntu Netbook Remix.
>
>
>
> Don't think this is true. I see many presentations give on netbooks.
> Because they're so portable they lend themselves to this, and with so many
> great presentation apps being in the cloud, it's even easier.
>

I'm sorry, I wasn't suggesting that presentations are not given on
netbooks.  Rather, I'm suggesting that due to the limitations of the
form-factor (mainly screen real-estate) notifications may need to be
handled/suppressed differently.


> Now, if you're watching a full-screen movie *and* waiting for an important
>> notification, then I would think watching that movie full-screen isn't your
>> best option.  Remember, these are transient notifications... there's no
>> guarantee you'll notice it anyways.  If, for example, IM is your priority
>> then you'll likely want your contact list or the Pidgin tray icon showing
>> anyways.  Same goes for full-screen Firefox or monodevelop.  Are you waiting
>> for a notification, or busy working with an application?  I admit, I'm
>> proposing a trade-off between screen real-estate and the importance of a
>> non-critical, transient notification.
>
>
>
> No ones *waiting* for a notification, we're doing stuff, and don't want
> our notifications turned off. If none come, or we miss them, so be it, but
> we certainly want the opportunity.
>

Weighed against the configuration set and dialogues being proposing, I still
think that "full-screen = I'm busy" is a reasonable assumption to make with
the vast majority of the user population.  I would venture a guess that most
users don't even use, let alone understand how to, full-screen non-media
applications like Firefox or monodevelop.


>
>> In general, I realize that for *some* people, full-screening the
>> application is not a fair "I'm busy" indicator, but for the wider user
>> population I believe this does hold true.  Remember, the notifications we're
>> referring to are transient, non-critical, peripheral information bits that
>> the user can *easily miss anyways*.  They shouldn't represent a central
>> part of the user's workflow.  If they are central to a user's workflow then
>> notify-osd isn't the right solution.
>
>
>
> Transient, but not absolutely worthless. If it's worthless, then it
> shouldn't be sent in the first place. This assertion is also based on the
> idea that netbooks are a different case, which I dont think is the case for
> presentations. Maybe for movies and text editors, but I'm not really sure.
>

It's not just about the messages being transient and non-critical, but
rather about them being so in combination with the decision to full-screen
an application, which is certainly a statement of some enhanced importance
being given to the full-screen application.


>
>
>> We also have to weigh all this against the proposed alternative of
>> additional configuration or a "presentation mode", and the pitfalls of that
>> solution.  Users could forget to set presentation mode, miss the
>> notification that reminds them to do so, forget to come out of presentation
>> mode.  I think there are just too many ways for the wider population of
>> users to misconfigure that system.  Just consider the case where one is in a
>> hurry to setup for a presentation that is already starting late.  Will they
>> really remember to set presentation mode?  If they glance away from the
>> screen they might miss the reminder notification too.
>
>
> This seems like something that should be a dialog, not a notification.
>

A dialog while in a rush, with perhaps your audience sitting right there may
not be well received by the user population.  :)  And then there's the
difficulty of determining when to show this dialogue.  Only for
presentations?  How about movies?  Full-screen Firefox (I've done this for a
presentation)?  This is not even to speak of the UX (in)correctness of
pop-up dialogues.

Overall, I think the assumption "full-screen = I'm busy" holds true for most
users, in most circumstances, and should be weighed against the difficulty
of designing a set of configurations/dialogues that give more granular,
per-application control, and making these dialogues easily understood by the
common user.

I also think the "full-screen = I'm busy" assumption could be balanced by
way of a general system-level availability indicator (which I'm starting to
think should be your IM status).  Thus, if one has their IM availability set
to "busy/dnd", then all non-critical notifications would be suppressed.
Perhaps there are other ways of using the system-level status indicators to
enable the configurability that you'd prefer while retaining default
assumptions that ho

Re: [Ayatana] Solving the "user forgets about presentation mode" problem! (was Re: notify-osd + fullscreen + multiple monitors)

[Vincenzo Ciancia]

Il 07/07/2009 16:39, Sohail Mirza ha scritto:

The limitations of the form-factor may require entirely a different
solution to common problems.  This much is apparent when comparing
Ubuntu Desktop to Ubuntu Netbook Remix.


The EEEPC 1000HE has a 10'' screen on which the default gnome desktop is 
reasonable, my girlfriend has one. But certainly when one is just 
browsing, sending the browser to full screen is more comfortable. In 
general full screen may be more efficient, because compiz can be 
disabled. And also I hate anything but the black borders when I am 
watching a movie. The panels are out of question :)


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] notify-osd + fullscreen + multiple monitors

[Mark Shuttleworth]

What about putting up a notification when someone goes into fullscreen
mode that notifications are enabled and will be displayed, as a reminder
that they might want to disable them?

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] Solving the "user forgets about presentation mode" problem! (was Re: notify-osd + fullscreen + multiple monitors)

[Vincenzo Ciancia]

Il 07/07/2009 17:34, Sohail Mirza ha scritto:


Weighed against the configuration set and dialogues being proposing, I
still think that "full-screen = I'm busy" is a reasonable assumption to
make with the vast majority of the user population.  I would venture a
guess that most users don't even use, let alone understand how to,
full-screen non-media applications like Firefox or monodevelop.


Come on, forget about presentations, my mother does not do that. The 
other two full-screen apps are firefox (press F11, and I learned that 
from non-nerds) and the movie player. Plus flash which probably uses its 
own method. Just let us concentrate on movies. Do you agree that when 
you watch a movie you may be willing to be interrupted or not for 
reasons that no machine will understand at least with current 
technology? I mean: I have to wait for my colleague to contact me with a 
patch. I watch a movie in the meantime. I want to watch it fullscreen. 
This is no nerdy or special need. Just the fact that the two use cases 
(block notifications, and go full screen) are often  independent even if 
they look related. But I think there is already general agreement 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] notify-osd + fullscreen + multiple monitors

[Praveen]

This idea was brought by someone else on this list today and the problem is
that a typical user goes fullscreen and back many many times even on a
single day especially in  and hence each time i watch a movie, or want
firefox in fullscreen if i get a notification it is very much annoying.
also after connecting my laptop to the projector and staring presentation if
this notification does come up it is not a good thing.

On Tue, Jul 7, 2009 at 9:10 PM, Mark Shuttleworth  wrote:

>
> What about putting up a notification when someone goes into fullscreen mode
> that notifications are enabled and will be displayed, as a reminder that
> they might want to disable them?
>
> 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
>
>
___
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

[Vincenzo Ciancia]

Il 07/07/2009 17:40, Mark Shuttleworth ha scritto:


What about putting up a notification when someone goes into fullscreen
mode that notifications are enabled and will be displayed, as a reminder
that they might want to disable them?


This was just discussed in another thread, with he

___
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

[Vincenzo Ciancia]

Il 07/07/2009 17:40, Mark Shuttleworth ha scritto:


What about putting up a notification when someone goes into fullscreen
mode that notifications are enabled and will be displayed, as a reminder
that they might want to disable them?

Mark




The subthread "solving the 'user forgets about presentation mode' 
problem" (in other words, solve the right problem) in this thread has 
been created just to ask the same question :) You can see above the 
response by Praveen:



"hmm.. not a bad idea though one must consider that this one initial 
notification will be always displayed whenever one goes fullscreen. so 
if i watch a lot of movies or am review/editing a presentation i would 
be going to fullscreen and back so many many times that each time if  i 
get this notification i would be annoyed"


That's a good observation. But at least once per opened application does 
not seem overkill.


V.


___
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] Solving the "user forgets about presentation mode" problem! (was Re: notify-osd + fullscreen + multiple monitors)

[Alex Launi]

On Tue, Jul 7, 2009 at 5:44 PM, Vincenzo Ciancia wrote:

> Come on, forget about presentations, my mother does not do that.


Ok, except that the title of this thread has the word presentation.
Presentations are a VERY common use activity. Your mom might not, but mine
does- often- quite possibly daily.


-- 
--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] notify-osd + fullscreen + multiple monitors

[Vincenzo Ciancia]

Il 07/07/2009 17:50, Vincenzo Ciancia ha scritto:

Il 07/07/2009 17:40, Mark Shuttleworth ha scritto:


What about putting up a notification when someone goes into fullscreen
mode that notifications are enabled and will be displayed, as a reminder
that they might want to disable them?


This was just discussed in another thread, with he



One day we must talk about the usability of keyboard shortcuts :) E-mail 
sent by mistake.


V.

___
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] Solving the "user forgets about presentation mode" problem! (was Re: notify-osd + fullscreen + multiple monitors)

[Sohail Mirza]

To be quite honest, if the movie is any good, I will likely miss the
notification anyways... but that's just me!  :)

If I really wanted to watch something while waiting for a particular
notification, I would probably keep exiting full-screen to double-check my
email/IM manually (I could've missed the notification, or maybe I'm just
being antsy).  On the other hand, if it wasn't something I was waiting for,
but just mildly interested in catching, well... I would probably finish my
movie first.

I don't disagree that there might be the odd case where I'm watching a movie
and I wouldn't mind being interrupted by an IM.  In this case we should
think of a way to allow this, but without complex configuration or
additional dialogues.

One thing to bear in mind is that receiving an unwanted (non-critical)
notification is usually more detrimental than missing a wanted
notification.  I can cite two examples of this:  1)  Of course, when making
a presentation, it's an absolute no-no to have a dialogue or notification
pop-up in front.  2)  If I'm at work I generally do not want IM
notifications popping up at all in case a co-worker is strolling by and
glances at my screen.

The "fullscreen = i'm busy" assumption is one step towards eliminating
unwanted notifications.  The second step might be having notify-osd observe
an availability indicator of some sort, or just having a way of disabling
certain types of notifications.

To summarize, I think the mandate here is two-fold:  1)  To reduce the
occurrences of unwanted notifications rather than making sure every
notification is displayed.  2)  To accomplish this in a way that is
virtually zero-configuration.


On Tue, Jul 7, 2009 at 11:44 AM, Vincenzo Ciancia wrote:

> Il 07/07/2009 17:34, Sohail Mirza ha scritto:
>
>>
>> Weighed against the configuration set and dialogues being proposing, I
>> still think that "full-screen = I'm busy" is a reasonable assumption to
>> make with the vast majority of the user population.  I would venture a
>> guess that most users don't even use, let alone understand how to,
>> full-screen non-media applications like Firefox or monodevelop.
>>
>
> Come on, forget about presentations, my mother does not do that. The other
> two full-screen apps are firefox (press F11, and I learned that from
> non-nerds) and the movie player. Plus flash which probably uses its own
> method. Just let us concentrate on movies. Do you agree that when you watch
> a movie you may be willing to be interrupted or not for reasons that no
> machine will understand at least with current technology? I mean: I have to
> wait for my colleague to contact me with a patch. I watch a movie in the
> meantime. I want to watch it fullscreen. This is no nerdy or special need.
> Just the fact that the two use cases (block notifications, and go full
> screen) are often  independent even if they look related. But I think there
> is already general agreement on this.
>



-- 
sfm
___
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

[Sohail Mirza]

An additional problem is that the reminder notification might be missed, and
the consequence (a notification popping up during a presentation) would be
more detrimental than wholesale blocking all notifications while presenting.

On Tue, Jul 7, 2009 at 11:46 AM, Praveen  wrote:

> This idea was brought by someone else on this list today and the problem is
> that a typical user goes fullscreen and back many many times even on a
> single day especially in  and hence each time i watch a movie, or want
> firefox in fullscreen if i get a notification it is very much annoying.
> also after connecting my laptop to the projector and staring presentation
> if this notification does come up it is not a good thing.
>
> On Tue, Jul 7, 2009 at 9:10 PM, Mark Shuttleworth  wrote:
>
>>
>> What about putting up a notification when someone goes into fullscreen
>> mode that notifications are enabled and will be displayed, as a reminder
>> that they might want to disable them?
>>
>> 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
>>
>>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
sfm
___
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]

Em Ter, 2009-07-07 às 11:14 +0200, Steve Dodier escreveu:

> I know that in most cases this is not needed since the update will
> happen well, but i think its better to make users expect to have to
> act. If their mirror goes down, if debconf asks if a file should be
> merged, if a dep is broken, if a public PPA key is missing, then the
> user will need to be able to act in order to solve the problem.
> 
> 
I am sorry, but do you realize that the ordinary users we are talking
about here would not know what to do in any of those cases? For an
ordinary user updates should go without questions. I am not an ordinary
user but usually my updates don't ask me do any of those things.

The best idea I've seen so far is Vencenzo's one. Spend time and effort
making it possible to revert upgrades if failure occurs at next login.

Another interesting venue of thinking, would be to postpone updates that
need user interaction (the package manager started the upgrade and
realizes that the configuration file changes and wants your
intervention, he then reverts the upgrade to the original package and
warns the user in the next login that an update was pending because it
needs manual user intervention).

I believe that both ideas are worth considering.

And David Siegel, yes I can always think about specific cases where
people wants to move away from the computer or start working right now.
There is no solution that will cover all cases. We can only hope to find
a solution that works in most of the cases and is not very bad in the
corner cases. I still think that updates should be possible at any time,
let it be login, regular use, or logout.

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

[Vincenzo Ciancia]

Paulo J. S. Silva ha scritto:

Em Ter, 2009-07-07 às 11:14 +0200, Steve Dodier escreveu:

  

I know that in most cases this is not needed since the update will
happen well, but i think its better to make users expect to have to
act. If their mirror goes down, if debconf asks if a file should be
merged, if a dep is broken, if a public PPA key is missing, then the
user will need to be able to act in order to solve the problem.




I am sorry, but do you realize that the ordinary users we are talking
about here would not know what to do in any of those cases? For an
ordinary user updates should go without questions. I am not an ordinary
user but usually my updates don't ask me do any of those things.

The best idea I've seen so far is Vencenzo's one. Spend time and effort
making it possible to revert upgrades if failure occurs at next login.
  


This is not my idea: I've seen people talking on it on the 
ubuntu-devel-discuss mailing list. Just don't know how it ended.


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] notify-osd + fullscreen + multiple monitors

[Martin Owens]

On Tue, 2009-07-07 at 06:44 +0100, Mark Shuttleworth wrote:
> 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.

Yes, for front end user interaction I would always say that we should
select the best options as defaults and provide ways of changing the
most basic settings through the most basic of user interfaces.

But to claim that this also applies to code is odd, we don't want
complexity in code it's true. But nor should we be programming in
specifics. Even none expressed options that naturally occur in the
elegance of the design should be stored in configs as sensible defaults.

Then it's up to enterprising users to create the "Ultra complex,
reconfigurer" application that can express those options if really
needed, or for a sys admin to edit the default settings and see what
they do. This then allows for outside experimentation and the discovery
of new and more interesting ideal defaults.

Hopefully you didn't mean that we'd gladdy sacrifice elegance of code
and flexibility of programming structure in order to artificially
restrict the expressed options. Which is how I read your reply at first.

Regards, Martin Owens


___
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] The old "installer getting stuck at 82%" issue :-)

[Vishal Rao]

Hello,

I was wondering if bug/wishlist 294523 [1], about the installer (Ubuntu,
Kubuntu possibly others) which
"gets stuck at 82%" for long periods during installation thereby ruining the
install experience, has been
looked at by anyone for the Karmic release?

I had tried to mark it as a papercut candidate but apparently it didnt make
the cut (was that a pun?).

This issue has been discussed on mailing lists and forums [2] for at least a
few releases already.

Could it not be such that the operations done at 82% be moved to
post-install or at first login?

In my case, it ruins what would be a pleasant 5 minute install experience
into a dull/boring 20-30
minute wait and I don't think the proposed slideshow will help. As a
workaround I usually unplug
my network cable and it doesn't complain, just progressing apparently
normally. If it works without
a network cable (I think we can assume many users dont have Internet access)
why not
postpone those 82% steps to later?

Regards,
Vishal Rao

[1] https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/294523
[2] http://ubuntuforums.org/showthread.php?t=1195557
___
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 old "installer getting stuck at 82%" issue :-)

[Steve Dodier]

Hello,
The 82% step is the one when the installer looks for a mirror, and it's the
first step to download the user's locale in order to have a fully translated
Ubuntu. The locale download part has a "Cancel" button in case it's too
long, but the 82% one doesn't. I reported this to the developers of Ubiquity
about 2 months ago, and they told me that it was not as trivial as that to
get it fixed (i don't know why exactly, but i suppose they know what they
say).
___
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]

Martin Owens wrote:
> Hopefully you didn't mean that we'd gladdy sacrifice elegance of code
> and flexibility of programming structure in order to artificially
> restrict the expressed options. Which is how I read your reply at first.
>   

Elegance? No. Options? Perhaps.

Every code path needs tests. We have a relatively low level of quality
in free software *because* we don't test our code. I know the ideology
about many eyes etc, but the reality is somewhat different - there's a
lot of crappy code on an Ubuntu CD.

In part, that's because there are so many unused code paths. That code
rots, it lurks in the background, and it causes bugs and slows down
development. Every time we have "some background option" added to
appease someone, I worry that we're adding code which will slow down the
primary thrust of development and fragment the testing we can do.

There's a perception that "alternative pathways" are free. They are not.

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] The old "installer getting stuck at 82%" issue :-)

[Vishal Rao]

On Wed, Jul 8, 2009 at 11:44 AM, Steve Dodier  wrote:

> Hello,
> The 82% step is the one when the installer looks for a mirror, and it's the
> first step to download the user's locale in order to have a fully translated
> Ubuntu. The locale download part has a "Cancel" button in case it's too
> long, but the 82% one doesn't. I reported this to the developers of Ubiquity
> about 2 months ago, and they told me that it was not as trivial as that to
> get it fixed (i don't know why exactly, but i suppose they know what they
> say).
>

Yes, what happens in the background during the delay has been mentioned by
devs already, also that during a release the mirrors are hammered which
makes that stage more slow :-)

What about people without Internet connections, how does the
installation/configuration fallback then? I don't think it fails, does it?

I personally pull out my network cable, will that cause a defective
installation? Am I a bad person?

If not having a connection is not so important, perhaps the
configuration/installation of localisation/security updates/whatever can me
moved to after the install is completed - upon first-boot/first-login?

Or perhaps a checkbox in the installer that says "do not access the network
during install" which is turned off by default so it behaves by default in
the existing way, but acts as if I pulled the cable (harmless?) if checked?

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