Re: [Ayatana] "Power information" notifications
On Wed, 2009-06-03 at 10:42 +0200, Mark Shuttleworth wrote: ... > Battery low > 25 minutes remaining (15.67%) > That's all that's needed. We shouldn't use generic titles like "Power > information" and then put the detail in the body - we should put the > key information in the title itself. Reading the title should give me > the key idea - my battery is low. Just a little comment: 15.67% doesn't say a lot more than just 15%, which is arguably easier to read. I would round this value to the next multiple of 5 or something. Extra points if the icon also reflects the value, at least to some extent. 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] Getting users to care (was Re: [Fwd: Re: Update manager])
On Tue, Jun 16, 2009 at 1:20 PM, Scott Kitterman wrote: > On Tue, 16 Jun 2009 11:40:12 +0530 mac_v wrote: > ... > >It is accepted that the icon is NOT very useful and also ignored > ... > > I have to disagree. This has been repeatedly asserted, but I don't recall > any actual studies that support this. > > This change has been overwhelmingly negatively received by all classes of > user. Would you mind showing us some evidence of said "overwhelmingly negatively" reaction? From what I've seen on the mailing lists so far, those complaining about the update pop-under mostly belong to a small, yet very vocal group of power users. Power users are often adamant about having absolute control over their computers, so it is no surprise that some of them find it very irritating when their computers open windows without their explicit consent. I'm not sure, however, that this is the case for most users (myself included, and I'm a power user, for sure). I would expect most people to just confirm the updates and keep going with their lives, but, as I said, if you have clear evidence that contradicts my expectation, I'll be glad to see it. My own view is that the old method was quite reasonably discoverable for > users that cared about updates and that being more obvious isn't going to > cause signficant numbers of users that don't care to suddenly start doing > so. I think mostly this change is annoying both groups. I think I've heard someone mention usability studies showing this not to be the case, but I can't find it right now. It would be good to have hard evidence here, anyway. ... > 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] Getting users to care (was Re: [Fwd: Re: Update manager])
2009/6/16 Vincenzo Ciancia > Please, let's keep the "this is something that only power user > like/dislike" old argument out of this discussion. I see this is not > your intention, but as we are all power users this is an effective > dialectic technique to lower the value of our observations. I wouldn't want to lower the value of any observations you've made, as long as these are observations about other people's behavior and not about your own behavior, tastes or preferences. This is the reason why I was asking Scott to produce some explicit evidence, because, so far, I have the impression he's mostly speaking based on his own feelings. I may be wrong about this, of course. Also, I already said this elsewhere. Either design a poll, or don't say > that a group of persons is small. You don't have a scale for comparison. > The whole launchpad can be considered a small group of users. Ubuntu > developers are a small group of users. > If you think you "didn't see the numbers yet" and want people to start > an advertising campaign to send angry users that may not have the will > to report the bug here, I can do that (yes it's a joke). > > Let me also remark that the bug had some 20 duplicates. These are > persons that _did not know_ the problem before and went to report. Hence > they don't belong to a "small group" as you said. I am one of these. I believe you that you and Scott are not the only guys who hate this feature. Still, the problem with saying "there are 20 people in Launchpad who hate it too" is that all of you conform a self-selected sample. If you hate the feature, you report it as a bug in Launchpad or get noisy about it in the mailing lists. If, on the other hand, you like the feature, or, at least, don't have a problem with it, you normally don't write to the mailing list just to praise it. Do you write to the mailing list every time you like something about Ubuntu? Now let's get to the point of which evidence we have that people do not > like popups in general. For update-notification, if you want evidence, > again, create a poll and find a way to gather the opinion of users. I > won't do that because I already have good experience. The risk of such a poll is the same: Self selection. Obviously, people are much more likely to participate if the are bothered by the feature, which will immediately introduce a strong bias. Although I'm a scientist, I'm not an expert in this kind of research, so I guess I'll ask my poll-designing colleagues here at work what they would do in such a situation and see if they have a better answer. > The typical computer user I saw in my life tend to close immediately any > popup without reading it. Especially if it's not a good moment to do > what is requested. This is my experience, I teached ubuntu to many, and > I taught courses at university to non-computer scientists, (I was forced > at the time to use windows, and here I could have a good sample of > behaviours w.r.t. popups) but I am not an usability expert. > > If you accept my past experience as an example, my impression is that if > a non-power-user sees a popup requesting to do an action and it's not > the right moment, she closes the popup. After a while, closing the popup > becomes an habit. And it's never used again, it's just considered an > annoyance. If doing upgrades was a "do it in 5 seconds, and be sure not > to have consequences" kind of thing, probably users would learn to just > click ok instead of closing the window. But it's not the case. > You are speaking about pop-ups here, but the update notifier is rather a "pop-under". It remains discretely behind other windows until you select it. The only way it can be intrusive, as you already pointed out, is by getting in your way when you're trying to switch windows with Alt+Tab. In any case, I agree with you that we don't know if the new solution is any more or less effective than the previous solution. > > Power users are often adamant about having absolute control over their > > computers, > > This is NOT the case in the problem we are talking about. We want a > cleaner, less disturbing system. We are not asking for esotheric feature > or millimetric customization. I even reject the solution of editing the > appropriate gconf key quite because, even if I know how to customize my > system down to the bare hardware, I _prefer_ to use the standard > settings of ubuntu. Sometimes I don't even change my background for a > long time after a new installation. Achieving a less disturbing system is, of course, a valuable goal. The problem here is that if your system is, for example, running an insecure network stack or a file system module that may destroy all of your data, you'd rather be disturbed about it. My hunch is that the pop-under will be more effective at calling most people's attention in such a case, but, of course, I don't have hard data to prove it. > so it is no surprise that some of them find it very irritating when >
Re: [Ayatana] Updates on Login (was: Re: [Fwd: Update manager])
On Tue, Jun 16, 2009 at 10:01 PM, David Siegel wrote: > I am glad this is being explored. I originally suggested we consider > updates at GDM (1) to challenge our thinking about this problem through > inversion, and (2) to rebrand updates as something fun and exciting to > receive, not a system maintenance chore that takes place during a dark > shutdown scenario. I find this idea laudable, but I wonder how viable it is. The type of updates we are talking about are a chore, because they are exclusively aimed at closing security holes and fixing critical bugs. It is not that we are going to the user with a smile and bag of assorted goodies. It's rather like we're suddenly knocking at his door and telling him "we just noticed there's a big hole in your roof and, unless you let us do our work ASAP, it'll soon start raining in your living room." In a way, it's not that bad: We're pointing out a serious problem (if it isn't serious, why are we releasing updates anyway?) and offering a solution free of charge, but he must be bothered to open his door and let us mess around for a while. Trying to hide this reality behind a nice present icon sounds kind of sneaky to me. Sort of if I give you a mop wrapped in colorful present paper, in the hope that you clean my floor with it. My strategy would be to be honest and make it clear that this is a chore, that, as any other chore, must be completed rather sooner than later. We understand, however, that the user may have something urgent going on and may not be able to do it right now, but we'll keep insisting. > Also, we do fsck at boot, so bookending the user experience with two > drawn-out, systemic maintenance tasks seemed very imposing. > > We should definitely consider as many update scenarios as possible in order > to find the one that users will prefer. We are very quick to start > implementing updates and shut down without considering something radically > different because many of us have experiences updates at shutdown when using > Windows. Neither solution is perfect, both have their merits, and this is > the perfect place to discuss them. Agreed. Recent answers in this thread show that updates at login, at logout, or at some point in-between may be appropriate depending on the user and situation. How about using them all? But before we move into that, let me pose a more basic question. How important is it for the Ubuntu community that users install their updates in a timely fashion? I ask this because I think that no technical solution will work unless the community stands behind it. Any attempt at getting users to install their updates will involve a certain degree of pestering, which, in turn, will result in negative reactions from at least some people. It is important that the community has a consistent, friendly and, above all, positive answer for these people. I can think of all sort of arguments that can be presented positively, ranging from "we're making sure that your valuable data is safe" to "we are good Internet citizens and want to make sure that Ubuntu is no place for botnets and malware to flourish." Once we have some basic agreement about this point, we can think of ways of pestering people in the less "pestery" way possible ;-) 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] Idea: letting users of the testing distribution participate in testing and report feedback on different UI choices if they wish
2009/6/16 Vincenzo Ciancia > The point is not if I hate or not something. The point is "how many" hate > this. Now there are two ways to see this. Either you want to use launchpad > features as a metric or not. In the first case you compare the number of > duplicates, subscribers (not only comments!) with other bug reports. > Comments come from vocal persons, but reports do not necessarily. So > duplicates are perhaps better than comments. I was wondering today about this discussion and arrived at a personal conclusion. Let me try to summarize it: Of course, I accept that there are a number of people who don't like this (mis)feature, and I believe their opinion is important. All I'm trying to say is that they are probably not as many or as terribly bothered as some people here try to make it appear. Some messages sound like "this pop-up thing is so horrible that 98% of Ubuntu users will suddenly migrate to Windows because of it, and never come back, unless, of course, our beloved warning icon is reinstated..." I agree that there is a problem, but there is no need to exaggerate it in order for it to be taken seriously. My guess is that most people actually don't care. Indeed, most people I know don't seem to care about web sites throwing all sorts of trashy pop-ups on their faces. Should I expect them to be deeply bothered by a discreet pop-under appearing once a week? Come on! They're used to computers doing much weirder things on a daily basis. That makes me think however, that their finger memory will dismiss this pop-up/under as quickly and obliviously as it dismisses any other pop-up. The interesting question, then, is how can we motivate people to install updates for their own good, and that without alienating them in the process. I already started to try and contribute in this direction by answering to relevant messages in other threads, and I guess you (Vincenzo) are doing so as well. If you think that launchpad is biased as you explain, and I certainly AGREE > WITH YOU (surprised??), hehe, no, this is why I'm arguing with you, to start with... > then you have to invent another way. In both cases, saying that 20 > duplicates means 20 users is a very bad estimate. You'd need to know the > average of users that suffer from a bug w.r.t. those who take the burden to > try to report it. AFAIK we do not have ANY CLUE about that. Unless we start > messaging a bit in the default distribution about bugs we will never have > this metric, but I guess that going out and talking to your friends can > give _you_ a good idea on the impression of people about the popup. I did > that and reactions are laughters or just "I don't care about updates > anyway". OK, so we'd rather concentrate on the important thing, as I said: How do we motivate them? Even better: we can actually implement, or mockup in a clear way, the > possible design choices, and then in the poll ask users to test each choice > for some time, and in the end tell us what they preferred. After all testing > is for testing and for reporting. Why must testers jailed into bug finding? > Can't they also be involved in the decision process? I will propose this as > a separate thread but is ayatana the good place? Perhaps > ubuntu-devel-discuss would be better. If we manage to come this far (and I hope we do at some point) this is already a usability experiment. We'd have to design it properly though, so that results can be considered valid. Although I'm a > >> scientist, I'm not an expert in this kind of research, so I guess I'll ask >> my poll-designing colleagues here at work what they would do in such a >> situation and see if they have a better answer. >> > > There must be one! Please report your findings. I will, as soon as I manage to find out something. Achieving a less disturbing system is, of course, a valuable goal. The >> problem here is that if your system is, for example, running an insecure >> network stack or a file system module that may destroy all of your data, >> you'd rather be disturbed about it. >> > > Yes this was a strongly advocated point in favour of the new system. I just > still think that the red-border white triangle with an exclamation mark in > the notification area would be as good. I´d rather think people will ignore both of them... We could use the testing distribution as a testing environment only for > those users who, prompted by a clear question (a popup window maybe :P) when > they install karmic (or karmic+1, I do not think we are in time for k), > decide to participate in usability tests, involving changing the system in > various ways for a week or so and then report feedback in a > number-crunchable way. This is an excellent idea. We may have to delay discussing it, however, until we have something to actually test. Otherwise, we'll probably be discussing at a too abstract level. M. S. ___ Mailing list: https://launchpad.net/~ayatana Post to
Re: [Ayatana] notify-osd + fullscreen + multiple monitors
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
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
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
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
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] notify-osd + fullscreen + multiple monitors
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
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] [Bug 410220] Re: Indicator applet Always shows icon
On Tue, 2009-08-25 at 08:44 -0500, Ted Gould wrote: > On Tue, 2009-08-25 at 11:15 +0100, Mark Shuttleworth wrote: > > There is no need for a Preferences for the Messaging Menu, and this > > use case does not justify the creation of one. > > We have specified a preference dialog for the messaging menu. The > reason is for blacklisting applications. Maybe I'm missing something, but wouldn't it make sense to include exactly those applications for which the user already defined an account? This may be hard to do from a technical point of view, but seems like the right behavior. For example, If someone has no e-mail account defined in Evolution, then there's no reason to include Evolution in his messaging menu. Conversely, if he already went trough the trouble of adding his account to Evolution, he presumably wants to see Evolution in the menu. This would get rid of the entire application blacklisting problem by showing the applications that are relevant to the user. 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] Regarding Notify-OSD's Position in Karmic Koala
On Wed, Oct 21, 2009 at 1:13 PM, Martin Owens wrote: > [...] The first thing I've noticed from this experimental opinionated > stance is a tendency to alienate and frustrate people who want to > collaborate. There are people who will give up their personal visions > for yours without lots of hard data, but most of those are called > employees... > It is impossible for a single product to encompass the personal design visions of a random group of people, who come from different backgrounds, have various levels of experience with UI design, and are targeting diverse sets of requirements. If you want to achieve something, you need a common vision. As for giving up personal visions, I don't think anyone is being asked to do that. You can share Ayatana's (or, if you will, Mark's) vision and try to contribute accordingly, or you may not, in which case you can fork the code, or start a new UI project, or simply not do anything at all. In any case, this is not an attempt to exclude you or anyone else. Is just an attempt of a certain group of people to concentrate their efforts on a particular set of clearly defined goals so that they can be more productive and actually achieve something. [...] The key here is 'distribution default'. I will congratulate you on the > decision to prevent choice paralysis in normal users, insisting upon a > single application per function at distribution time is the right > choice. But this is development, this is upstream, that logic may not be > relevant. I notice that you don't insist upon one application per > function available in the repositories or launchpad PPAs. > And if you or anyone else were to create a different UI, I don't think it would be excluded from those repositories either. It is only that the resources of the Ayatana project wouldn't be dedicated to it. > > > In Ayatana, we'll take an opinionated stance, and we'll apply some > > common principles to the design process, > > This principle isn't common, it's something I haven't seen in any other > projects, even the ones that I would aspire to with regards to design > and vision. > This principle is very common. Indeed, I'd say it lies behind every single successful free software project. Let's make a little Gedankenexperiment: Imagine you find an interesting free software project with an active and dedicated community. When you look into it in some more detail, however, you find quite a number of things you don't like. The code is not organized according to you liking, and the set of features offered doesn't appear quite right to you. Being such a good programmer as you are, you proceed with no further delay to rewrite 80% of the code in order to fix these issues, and send a patch back to the community. Now, back to reality, what would be the likelihood of this patch to be accepted? I would say, almost none. Why? Because this community formed around a particular vision of what their program should be. The vision was probably set by the original program creator. It was also probably never clearly expressed in words, but it was expressed through the code. For these reasons, when you contribute a patch to an already established project, you are expected to play by the rules of that project. If you don't want to, you are always free to fork the project or start a competing one, but you shouldn't claim that they are excluding you just because the don't want to adapt their vision to yours. > > > I have no interest whatsoever in making it possible for anybody to > > have any environment they want - we already have that. > > > Hmm, I can't actually believe you would say that. It sounds so, > authoritarian. To dictate what is in the best interest of the masses and > removing the choices of those who aren't believers in the one true > vision. > It seems to me you're concentrating too much on the "I have no interest whatsoever..." part of Mark's quote, while deliberately ignoring the "we already have that" part. > > It certainly doesn't sound like "I am because of my community", it > sounds like "I am because of what Mark likes to see". Scary in a way. > This can also work the other way around. I could say that your my-customized-to-the-last-pixel-way-or-the-highway stance is a pretty selfish one, and that someone who is willing to sacrifice some of his own very personal needs and desires in order to work on what the large majority of people actually need and can use is a much better community member. What do you think about this? > > Principled Regards, Martin Owens > Ditto, Martín ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala
2009/10/21 Paulo J. S. Silva > In my humble opinion this is one of best ways to end a conversation: > takes your "opponent" point of view and turn it into a caricature that > make it sound unreasonable. > Well, I thing exposing the weaknesses in other people's argumentation is at the core of any real debate. I'm not trying to say that he's completely unreasonable (he isn't indeed!), I'm only implying that his argument is not as community-oriented as he may like to make it sound. > As far as I can see Owens point is that we don't need such a radical > "one size fits it all" minding set because that is not really possible > in all cases. One size does not fit it all always. I don't think that > everybody else that asked for customizations wanted > "my-customized-to-the-last-pixel-way-or-the-highway". Usually we ( I > have already asked for customization in this list) want a way-out from > what we consider bad UI decisions that are really making our life > worse when using Ubuntu. > While it is true that one size cannot fit everyone, when dealing with UI, it is surprising how certain sizes can actually fit incredibly large numbers of people. Almost by principle, customization detracts from finding such a sweet spot. This is why good designers try their best to avoid it. > > For example in the osd-notify positioning, adding the possibility of > selecting one of the corners would be enough. It would be certainly > enough also to hide such option requiring gconf-editor to change it. > This would be enough for you, of course, because you would just fire gconf-editor, change the option, and never think of the problem again. I think Mark's point was to avoid precisely this, and I agree with that entirely. By adding the option, we're just dodging the problem, not solving it. > Can't we just see that in some cases it is *really hard* if not > impossible to find a default setting that would not step on many > peoples toes and add a gconf-entry to select it? If an UI decision, > for example, generates a bug reports with hundreds of comments it may > be a good indication that the decision is not good for a very large > number of people even if it is good for most of the people. Then we > can work really hard to find the best default setting without really > left part of our community behind. > Changes to a user interface almost always cause some irritation at the beginning. Most users just live with that, because they don't have another option, but we computer experts know better. We can fiddle with the computer, so our tendency is to look for the option that lets us put the thing back where it used to be and forget about it. I bet that most of the people who are complaining now are reacting precisely like this. They see the change, sort of don't like it, look for the give-me-back-my-old-environment option, and become pretty much upset when they don't find it. Their next step is to log into Launchpad as quickly as their fingers permit. I bet that most people who aren't computer experts wouldn't bother at all about notifications slightly changing their position. Actually, most of them won't even notice the change. Now, that said, you are right in that options may be the right solution in some cases, but such cases are rarer than you think. Finding a proper solution is hard, and, in this case, it may take several further attempts to find something that works really well. It is just too early for giving up. 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] Regarding Notify-OSD's Position in Karmic Koala
On Wed, Oct 21, 2009 at 3:16 PM, Luke Benstead wrote: > [...] I think the reason that notify-osd's positioning is a particular > sticking point with many people is that it is something where no > default location will suit the majority of people. Users with visual > problems, non-default layouts, applications that have elements right > where the notification pops up all would like, perhaps need, some way > to move them out of the way. And the real reason that it causes such > an issue with people is it's a bloody good idea and they want to be > able to use it. > This is a good point. > I understand fully what you are saying about both sensible defaults, > and how too much configuration is a bad thing, (I'm a programmer, I > know how much more work it adds to make something configurable) but > sometimes you need to allow some kind of override switch. > >From reading this paragraph, though, I get the impression that you see configuration options as the only, or, at least, the better solution in this case. Are you really sure? Suppose you go to a user and ask "how would you like your notifications, top-right corner, middle-right side or lower-right corner?" Most people, even those technically minded, wouldn't be able to answer. Actually, they would have to try each option for a while, and it may turn out that all three are equally disrupting, except that the particular conditions in which they happen to cause disruption may vary from one to the next. So, probably, the solution is rather to find some clever algorithm that places them dynamically based on the current desktop conditions, but we won't be motivated to search for this algorithm if we resort to creating more options as soon as someone complaints. It is not that problems shouldn't be addressed. They should. The point is, however, that customization is almost never the right way to address them. Best wishes, Martín ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Message Indicator: Listing apps in menu even if they are not on
On Sat, Nov 7, 2009 at 5:12 PM, Mark Shuttleworth wrote: > The current discussions I had with MPT about a related matter panned out > roughly like this: > > - the main, default apps should be here by default (Evolution, Empathy, > Gwibber) > - other apps should install themselves here when first used >- if in future we can tell WHO installed an app, they could get it in > the menu when they install it >- we don't want something minor to show up here for all users of a > system when one user installs it > Maybe I'm missing something, but wouldn't it be possible to show only those applications for which the user has already configured accounts? Without account access data, they won't work anyway, so, why listing them at all? Cheers, Martín ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Reducing Resistance to Change
Hello Martin (and everyone): Just a few comments on your post: First of all, I also believe that better communication with the (technical) community would be very valuable. Obviously, Canonical and the UI team have failed so far in selling their work to large fractions of the Ubuntu community and I agree that this can cause serious problems in the long (or maybe not so long) term. I wonder, however, what sort of approach would work better in this regard. You seem to favor open discussion and justification of design decisions. Interestingly enough, this is precisely what several members of the design team (including Mark Shuttleworth) have been doing these days, by blogging extensively about their design aims. Although I find their expositions very interesting and illustrative, I'm not sure they'll satisfy the large majority of technically-oriented community members. Problem is, techies and designers tend to have very different mindsets. You normally have designers arguing in terms of subjective criteria: For a particular design, they try to strike a balance between a number of more or less subjective and often competing quality attributes. This makes designs very hard to justify, since it's rather a matter of designers arriving to a point where they feel that, all things considered, their design is right. Technically-minded people, on the other hand, strive for strict, objective, black-or-white criteria for making technical decisions. They also normally see interaction design as merely a set of technical choices. Combine these two, and you'll probably see where the problem lies: they'll expect every single change to be justified in clear, incontrovertible terms, and this is something they'll never be able to get from a competent interaction designer. This is probably the reason why, for almost every single UI change in Ubuntu, you'll find a number of very vocal people complaining loudly, and reacting with righteous indignation when no satisfactory justification comes out from the designers responsible for the change. Now, with more than 15 years of Linux experience and a PhD in computer science, I happen to be a very technical user. Still, I'm able to see the value of good design, and personally greatly appreciate Canonical's efforts in this direction. I think, however, that awakening this same sense of appreciation in many of my fellow technical users will be a very difficult endeavor (the expression "herding cats" really comes to mind here...) I would really appreciate any ideas in this direction, because I don't have many. The few I have are based on my own experience: First, as an advanced user, it is easier for me to adapt to UI changes than it is for less advanced people to deal with the technical complexities of a standard Gnome desktop. Second, a good design is beneficial for me and makes my computing experience a lot more pleasurable in the long term, even if adapting to it is annoying because of my habituation to the idiosyncrasies of previous software versions. Can we build a compelling argument based on these and similar ideas? Thanks, Martín ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Reducing Resistance to Change
On Wed, Apr 28, 2010 at 6:55 AM, Diego Moya wrote: ... I'm the first one to defend a simplified design for entry-level to > average users even if it doesn't support expert features. But this > kind of design should be only for new features and never, ever be put > in place of a previous design already in use. This is the golden rule > of computing - if ain't broke, don't fix it. > But our current UI is broken in many respects! Thing is, motivated users can wrap their heads around almost any UI, as shown by the fact that vi and emacs still have such a strong following, to mention just one example. The fact that human brains posses such a high plasticity, however, is no excuse for us not getting our act together. Whenever you change a UI, you will break someone's habituation to that UI. Unfortunately, habituation is a very complex issue: For example, people can be very creative while working around a program's limitations, and this often involves using the program in ways that were never taken into account by its original designers. This means that, given a large enough user base, even changes that appear completely innocuous will likely end up irritating at least some users. Braking people's habituation will always cause problem, but absolutely necessary if you want to make progress. Cheers, Martín ___ 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] Two suggested designs for the Sound Indicator
Hello Sense:
As far as I can see, in your mail you only mention using PulseAudio's
functionality as the main justification for your design, which is a purely
technical reason. We should rather start by thinking about use cases: what
are people supposed to do with this functionality?
My problem with your design is that, as far as I can tell, the large
majority of people won't want to play more than one sound source at the same
time. You are watching a video, or playing some background musing, or
chatting with someone, but doing two or more of these at the same time is
very rare, because they clearly interfere with each other.
So, for example, if you're playing background music and want to watch that
video you just got from your pal over IM, you'll probably pause the music.
And if someone calls you over Skype when you're watching the video, you'll
pause it before taking the call. Given that this is the case, a single
volume slider should suffice. The only "normal" situation I can think about
where it makes sense to have sound mixed or superimposed is when
notification sounds ("you have new mail") play on top of other sources. For
this case, the volume of notifications should be made so that they're
audible over the sound that is currently playing, which is something that
probably can be achieved automatically anyway.
This said, there are some people who will want to mix sound from several
sources, such as DJs and other performance artists or people working on
sound production. I doubt, however, that they will want to use an indicator
menu as their UI, and will have to be provided with a specialized solution
anyway.
Do people see other use cases I'm missing?
Cheers,
Martín
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Reducing Resistance to Change
2010/4/30 Diego Moya
> 2010/4/30 Martín Soto :
> > The fact that human brains posses such a high plasticity, however, is no
> > excuse for us not getting our act together. Whenever you change a UI, you
> > will break someone's habituation to that UI.
>
> Not if you support both interactions, the old and the new. In many
> cases this is easier to do than it seems - just keep the old features
> as deprecated, instead of removing them.
>
In many cases, though, it sounds easier to do than it really is. You leave
the old features around and people will stumble upon them at the worst
possible of times. Old, poorly designed features often also get in the way
of a clean and straightforward design. But this is something we should
discuss on a case-by-case basis, rather than at this generic level.
> Unfortunately, habituation is a
> very complex issue: For example, people can be very creative while working
> around a program's limitations, and this often involves using the program
in
> ways that were never taken into account by its original designers.
You say that as if it was a bad thing.
>
It's not good or bad, that's just the way it is.
So, you're not going to support those users that create their own
> workflows? There will be only One True Way of using the system?
>
I simply doubt that, in the long term, it is viable to support every single
conceivable way of using a particular UI. People end up standardizing in a
single way of doing things, and this makes sense, because otherwise the cost
and complexity would become unbearable over time.
>
> You can design for simplicity, or you can design for flexibility. You
> can even do both at once, which I recognize is much harder to do.
Maybe so much harder that it becomes impossible in practice. But once again,
we should discuss this on a case-by-case basis.
> In any case, you must make very clear which one is the house manual of
> style. "We don't support that kind of users" is a valid reason to
> close a wishlist bug as wontfix, but only if you have a clear
> description of the supported users. This way people will know whether
> they fit in the target group and when to back off from a discussion
> about the system design.
>
I agree with you here. As others have already pointed out, having some
personas, for example, would be very valuable for Ayatana.
[...]
> Benevolent dictatorship ("I do this way because it's what I think is
> good for the project") is a traditional management style in open
> software, but try to use it as a last resort if you don't want its
> side effects - people complaining about the dictated decisions.
>
Given the sheer size of the Ubuntu community, any design that attempts to
satisfy everyone is very likely to be a design that ends up not satisfying
anyone. The design team is making relatively bold decisions, and this is
probably good because it will likely result in a design that is satisfactory
to a significant number of Ubuntu users. A significant portion is not
everyone, however, so this also means that some people will end up
dissatisfied with the results. It is not surprising that at least some of
these people complain loudly, but I can't really see a way around that.
> Braking people's habituation will always cause problem, but absolutely
necessary if you want to make progress.
> Is it progress when you're making people inconvenienced? You should
> take great care to distinguish progress from "change for the sake of
> change". And when in doubt, refrain from it.
>
If a large number of people are served by the changes, it is probably OK if
some people are inconvenienced. Particularly, in this case the changes don't
make it impossible for the inconvenienced people to use the new system, they
just break their habituation, but habituation can be rebuilt by using the
new system for some time, so this is not catastrophic. Of course, telling
exactly how many people will be served by the changes and how many will be
annoyed by them is very difficult, and designers can make mistakes in this
regard as well, but I don't think anyone here is trying to annoy people just
for the sake of it.
Martín
___
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] Two suggested designs for the Sound Indicator
On Mon, May 3, 2010 at 1:23 PM, Chow Loong Jin wrote:
> I think listening to music while chatting is not rare at all. I do it, and
> many
> other people I know do the same. And considering how much noise was made
> over
> the one-application-rules-the-sound-card bug that existed prior to ALSA's
> dmix
> coming into the picture, I think it's not rare at all to have more than one
> application playing sounds at the same time.
>
Some people do listen to music while talking to someone else on the Internet
phone. I do it myself on occasion, but I don't think this is so common,
though. The common case for simultaneous sound playback is a lot more
related with applications such as IM clients playing short sounds while
something else is playing in the background. People want to listen to music
and still be able to tell when an IM arrives.
I'd be exceptionally bothered if my sound was automatically paused in order
> to
> play notification sounds which appear every time someone sends me an
> instant
> message (think rapid succession from someone who types fast, which is not
> at all
> uncommon these days).
>
I guess almost everyone would be bothered in this case. This is the reason
why I wrote:
> The only "normal" situation
> I can think about where it makes sense to have sound mixed or
> superimposed is when notification sounds ("you have new mail") play on
> top of other sources. For this case, the volume of notifications should
> be made so that they're audible over the sound that is currently
> playing, which is something that probably can be achieved automatically
> anyway.
That is, notification-type sounds should be mixed with whatever else that is
playing. I think, however, that their volume can probably be selected
automatically in such a way that they are heard on top of the background.
This way we don't force people to fiddle with another volume slider in order
to hear their notifications.
> As for playing videos, keep in mind that not all videos have sound. When I
> watch
> a video that has no sound, I keep my music playing. When I watch a video
> that
> has no useful sound (stupid background music that annoys me), I mute my
> browser
> and keep my music playing. Such videos are pretty common on Youtube.
>
I bet most people won't bother to mute the video. Since most youtube videos
aren't longer than two or three minutes, they'll just endure the music if
they have to. So this is probably a rather advanced use case, but I may be
wrong.
> So, for example, if you're playing background music and want to watch
> that video you just got from your pal over IM, you'll probably pause the
> music. And if someone calls you over Skype when you're watching the
> video, you'll pause it before taking the call. Given that this is the
> case, a single volume slider should suffice.
I have a habit of playing music (softly) while talking to friends on Skype
> due
> to my multitasking habits, and due to the fact that I can't really function
> properly without music playing.
>
Although I thing, as I said above, that this is not so common, it's still an
interesting use case. If I'm listening to music and a call arrives, for
example, I'd rather have the music paused automatically as soon as I take
the call.
___
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] Two suggested designs for the Sound Indicator
On Mon, May 3, 2010 at 4:11 PM, Chow Loong Jin wrote: > Think of all those flashy annoying myspace pages that play music and don't > provide any controls. Do you honestly believe that all the video and audio > players out there embedded into web pages have volume controls? > > And what about all those Facebook games out there that have annoying > background > music that cannot be muted? I think Firefox is a great candidate to have a > sound > control of its own in the sound indicator, similar to the way it's > currently > done in Sound Preferences. > > There is a further thread somewhere down the line about how annoying it is > to > have to switch to the appropriate application and turn off sound for a > call. Now > imagine how much more annoying it would be to look through ~30 different > tabs to > figure out which webpage is making sound and disable it. > This sounds perfect for a new Firefox extension. Martín ___ 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] Two suggested designs for the Sound Indicator
[I'm really sorry about this, GMail bit me while handling it!] 2010/5/3 Martín Soto > On Mon, May 3, 2010 at 1:23 PM, Chow Loong Jin wrote: > > I have a habit of playing music (softly) while talking to friends on Skype >> due >> to my multitasking habits, and due to the fact that I can't really >> function >> properly without music playing. >> > Although I thing, as I said above, that this is not so common, it's still an interesting use case. If I'm listening to music and a call arrives, for example, I'd rather have the music paused automatically as soon as I take the call: the call quality can be bad and I need silence to understand, I may not want this particular caller to know I listen to my music, etc, and I still may have to take the call quickly. If, afterwards, I notice that this is going to be a longer, chatty call, I can just go to the music player, restart the music, and adjust the volume *there* so that it doesn't interfere with the call. What I conclude from this is that putting a mixer-style interface in the sound menu, as proposed originally is not a good idea, even for more or less advanced use cases like this. What would be interesting is a mechanism for pausing playback automatically when more urgent sources need to take over. Martín ___ 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] Two suggested designs for the Sound Indicator
2010/5/3 Chow Loong Jin > There's a difference between "not so common," and "non-existent." I > understand > your concern that my use cases may be uncommon, but what you appeared to be > doing earlier was saying something like "well most people would do X, so > let's > assume that everyone acts the same way and remove all other use cases." > Well, this is more or less what I was implying ;-) The more use cases you try to address with a single design, the less able you will be to address them properly. We are also speaking here about the default volume control for Ubuntu, so this is something that must address use cases that are relevant to a large majority of Ubuntu users. Martín ___ 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] Two suggested designs for the Sound Indicator
On Mon, May 3, 2010 at 5:23 PM, Sense Hofstede wrote: > Many people have said that adding all sound using applications is not > useful because they wouldn't use it. A few points: > * There is nothing that prevents you from ignoring the applications > in the list. In fact, I think we should make it very easy to quickly > access the main volume slider > By adding elements to the UI, you make it harder for people to make sense of it. You also make it harder to use it in the long term, if only because people will have to identify the right element among a larger total number of elements. For these reasons, every single additional element has a cost. Unfortunately, asking people to ignore those elements they don't need or like simply doesn't work because, if the elements are there, their brains will perceive them. > * The fact that some people don't use it doesn't mean that all people > don't use it. We've seen in this discussion that a lot of people came > up with uses for it quickly. We shouldn't oversimplify our desktop. > The important question when deciding if a feature is appropriate is not whether someone will use it: most of the time, you will find someone who wants it. The question is how many people will benefit from the feature and how many won't. Because, for those who won't, the feature is just clutter, which actually makes the UI less usable for them. > Keeping it clean is important, but it should be easy for people to get > extra tools when they want it. (Not that I think these volume sliders > are power tools.) > Providing tools people can install to satisfy specialized needs is the Right Thing to Do (TM). Trying to support specialized needs in the default user interface at the expense of a large majority of users is just plain wrong. * It is easy to have a central place to control the sound, like Chow > Loong Jin already said. It's no use to go through all tabs and writing > a Firefox plugin doesn't provide much consistency and still isn't > central. > This is the sort of question that cannot be entirely settled without user testing. That said, putting volume controls in the application is probably easier for most people, because they can make a direct connection between the sound source and the corresponding volume control. A central mixer, on the other hand, requires you to first recall the application name and then look it up in the mixer menu before you can do something. This appears a lot more complicated from a cognitive point of view. The book "The Design of Everyday Things" by Donald Norman explains this issue quite well (look for term "mapping"). More direct, spatial connections between controls and the items they control can improve interaction quite a lot. Best wishes, Martín ___ 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] Two suggested designs for the Sound Indicator
2010/5/3 Diego Moya Norman's direct mapping would be the best model if each application > had volume completely independent of each other. This isn't true > though, as there is a system-wide volume control that changes all > applications at once, thus making individual application volumes > relative to each other. > IMO, we should start by getting rid of the system-wide volume. It adds lots of complexity without providing any significant advantages. A global volume control is useful when you're mixing several channels, but this is not what people will be doing with the default volume controls in Ubuntu. And the problem is that the global control negatively affects even the simplest and most common use cases. Consider, for instance, someone who is listening to a single sound source, such as a music or video player. I'd say this is, by far, the most common use case we have. Unless you're a sound engineer or some such, this is what you're likely to be doing 99% of the time your sound card is active. Setting the volume in this case should be absolutely straightforward but it's not in current Ubuntu. You have to deal with two sliders, one usually inside the player (e.g., the button/slider in Rhythmbox's top-right corner) and one in the volume indicator that interact with each other in a funny, unintuitive way. Sliding any of them down, for example, will mute sound, but if you want to reach the maximal volume, you'll have to slide them *both* all the way up. Of course, if you understand that the sliders correspond to two separate volume filters that are connected serially, you'll be able to deal with this system just fine. But most people won't grasp this--or at least, it will be a long time until they do--and they'll be confused and frustrated. A centralized control that shows in one place the relative weights of > all applications is a good design in this case, IMHO. You speak about "all applications". How many applications do you expect to have running and producing sound at a given time? I'd expect a maximum of two, and that only for the relatively unusual cases where people talk on the Internet phone and listen to music or watch videos at the same time. > This way one can > give more or less emphasis to one application with respect to the > others, without having to switch between applications. > My guess is that this relative control would be unintuitive for most people. All sound sources they deal with in the real world (TV, stereo, phone, etc.) have absolute volume controls, not relative ones. If you want to talk on the phone and listen to music at the same time (which is rather unusual because most people will turn off the radio, anyway) you just fiddle a bit with both the phone and the radio until it's OK for you. It is not that you turn a big "Room Loudness" knob until you're satisfied, and then adjust the "Radio" and "Phone" relative knobs behind that panel in the wall. A design where you directly control the absolute volume of applications is likely to be a lot more familiar to people. This doesn't means one couldn't also have one standard application > volume control for each application as a windicator; in this case, > having redundant controls wouldn't hurt - as they support different > use cases (controlling sound in the current application vs setting > global sound preferences). > I'm still not sure about the ideal location for individual controls. Having them inside the application windows (either as part of the app or as windicators) will definitely help people to associate them with the right application. A central control may still be useful in some cases (like quickly muting whatever is sounding) so this may be a situation where redundancy is worth its price. Cheers, Martín ___ 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] Two suggested designs for the Sound Indicator
2010/5/4 Frederik Nnaji > a) how about listing mute toggle and play/pause for relevant apps? > This may be useful, maybe more so than controlling volume. > a buttoned interface with columns or rows for the respective > apps..with little 3 Bit digital volume meters (2 for stereo/surround, 1 for > mono) attached to each app icon > How many applications would you expect to find in practice on such a table/list? I would expect a maximum of two, and that only in rare cases. Also, do you really want to control stereo balance separately for each application you use? b) do we really need "main volume"? > I agree with you, we don't need it (see my last message in this thread for details) > c) do we need a global mute button? This is likely to be important, especially for those situation where you need to react quickly. Best wishes, Martín ___ 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] Use cases for volume control
Hello everyone: I just tried to collect some use cases (user stories) based on our recent discussion about volume control. Here they are: * Mary often listens to music from the computer in her room, while she's chatting with friends and browsing the web. She needs a quick way to set the volume to adapt it to her mood and to the recording level of the current song. * Betty frequently uses an Internet telephone application to communicate with her daughter, who lives overseas. She needs an expedite way to set the playback volume of the phone program to adapt it to the amount of noise in the surrounding environment as well as to variations in communication quality. * Javier works at home and uses Internet chat intensively to communicate with colleagues and clients. Since this is part of his job, it is very important for him to hear the audible signals when chat messages arrive. He's often worried about playing music from the computer because he fears that the music may prevent him from noticing an important message. * Gerhardt listens to music from his office computer all day while he's working. If the telephone rings (Gerhard uses both the telephone in his desk and an Internet phone application) or someone knocks on the door, he's glad to have a quick way to mute the music for a while until the conversation is over. * Axel spends hours every evening talking with his girlfriend on the Internet phone. Sometimes, he wants to play music while he's talking, and would appreciate to have an easy way to set up the volume so that he can listen to the music without missing parts of the conversation. * Karolina loves playing games from the Internet, but often finds their music abhorrent. She would like to be able to mute the music (and eventually listen to her own music) while still being able to play the game. IMO, the first four cases must absolutely be well served by the default design in Ubuntu (they aren't right now!). It would be nice to accommodate the last two cases also, but given that they are probably relevant to a small number of users, I'd wouldn't find it bad if an additional application/extension is necessary to support them properly. Constructive criticism is of course welcome. I'd especially like to know if people find important cases that are still missing. Cheers, Martín ___ 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] Two suggested designs for the Sound Indicator
On Tue, May 4, 2010 at 10:54 PM, Alex Launi wrote: > Before this discussion continues, it's essential that we define the problem > we are trying to solve..-- > I agree with you. I just sent a message to the list, containing a set of use cases for volume control. IMO, the problem is that we are not currently supporting even these simple use cases properly. I'd really appreciate it if you guys could look at them so that we can continue the discussion around refining them. Best wishes, Martín ___ 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] Use cases for volume control
2010/5/5 Alex Launi
> 2010/5/4 Martín Soto
>
[...]
>
> * Mary often listens to music from the computer in her room, while
>> she's chatting with friends and browsing the web. She needs
>> a quick way to set the volume to adapt it to her mood and to the
>> recording level of the current song.
>>
>
> This case is flawed. We can automate this. Mary shouldn't have to give two
> flips about the volume of her IM client sounds. Mary just wants to listen to
> music, and be alerted when her friend Jane sends her a new message. What the
> hell does volume of an IM client mean anyway? That idea in itself is
> confusing.
>
I think that by mentioning her side activities ("while she´s chatting with
friends and browsing the web") I introduced some confusion here. This case
was about the volume of music, not the volume of IM. Would it help if I
write "while she´s doing her homework" instead? (additional suggestions are
welcome, of course!)
> This use case should be adapted to target some changes to pulseaudio. Pulse
> should be able to identify transient streams, such as IM notification
> sounds, and adjust their volume to be audible above the other currently
> playing streams, without blowing out Mary's ears. Now Mary is just happy,
> and didn't have to do anything.
>
I´ve been also thinking along these lines: the volume of notification sounds
should adapt automatically to other playing streams so that notifications
remain audible. But this is part of the solution; let´s try to get the
problem definition nailed down first, at least in an initial, workable form.
[...]
> * Javier works at home and uses Internet chat intensively to
> communicate with colleagues and clients. Since this is part of his
> job, it is very important for him to hear the audible signals when
> chat messages arrive. He's often worried about playing music from
> the computer because he fears that the music may prevent him from
> noticing an important message.
>
What's the difference between this case and Mary's case?
>
This should be clearer after my explanation above: this is the case about
the volume of background sounds, the other one is about controlling the
volume of media playback.
>
>> * Axel spends hours every evening talking with his girlfriend on the
>> Internet phone. Sometimes, he wants to play music while he's
>> talking, and would appreciate to have an easy way to set up the
>> volume so that he can listen to the music without missing parts of
>> the conversation.
>>
>
> I think Axel's girlfriend would prefer him paying full attention to her,
> but it's their relationship, not mine .. :P
> This is pretty much the same as Betty's.
>
Hehe, yeah, although speaking from personal experience, there are times when
you want to remain connected without really having an active conversation
(ahh, the luxuries of the Internet age...) You still want to here if the
other person talks, though.
Subtleties aside, the difference between this case and Betty´s is that here
mixing is necessary. Betty´s case is about plain volume control during VOIP
calls. We may of course merge the two, but I think Axel´ s case is a lot
more power-user-oriented and may have to be treated separately.
> * Karolina loves playing games from the Internet, but often finds
>> their music abhorrent. She would like to be able to mute the music
>> (and eventually listen to her own music) while still being able to
>> play the game.
>>
>
> Yeah, I guess can get down with this. The issue here is that Karolina is
> almost definitely going to just adjust the volume present in the game on the
> internet, she probably won't think "oh I should turn down firefox".
>
As evidenced not only but your comment but by other answers in this thread
(thanks everyone, by the way!) there is a whole bunch of issues that are
specific to sound coming from Internet applications. This seems to be a good
reason to leave this case here, and to probably add more that cover this
area, because it's obviously an important area to many people.
[I´ll answer to your point about synchronous and asynchronous streams in a
separate message.]
Best wishes,
Martín
___
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] Use cases for volume control
On Wed, May 5, 2010 at 9:08 AM, Ralph Green wrote: > 2010/5/4 Martín Soto : > > * Mary often listens to music from the computer in her room, while > > she's chatting with friends and browsing the web. She needs > > a quick way to set the volume to adapt it to her mood and to the > > recording level of the current song. > Howdy, > For the ogg and mp3 files in my collection, I have encoded most of > them with the replain gain tag. This can help the player set the > volume as you explain here. It is fairly easy to go gag and tag audio > files with this tag. > I'm also a fan of ReplayGain and use it whenever I can. The use case, however, is there to show the need, not the solution. Indeed, the best possible solution is one that doesn't require any user intervention to achieve the desired effect, and, for this case, ReplayGain belongs definitely to this league. Maybe we could write this case in a somewhat different way to convey the fact that the volume has to be adjusted, without implying that this adjustment has to be manual. Any suggestions? Martín ___ 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] Use cases for volume control
2010/5/5 Alex Launi > I think the take home message of this is that there are two distinct types > of sound streams. I'm going to use the analogy we've been using in > notifications- Synchronous and Asynchronous. > >- Synchronous streams are those that are user initiated. Banshee, >Empathy Voice/Video chat, Youtube videos, etc. Streams that come from >explicitly user initiated actions. >- Asynchronous streams are those that are *not* user initiated, and are >triggered by environment events. Incoming IM sounds, alert noises. > > Asynchronous streams should be handled by the system, but we should design > a means of allowing users to adjust the volume of synchronous streams. > Although I generally agree, my take on this is that it's better to classify sound sources based on different criteria. My suggestion is to use the following categories: 1. Notification: sounds used to provide feedback for user actions or to notify about environmental events. These are short sounds, not expected to play for long periods of time. Also, listening to these sounds is never the user's direct purpose. 2. Media playback: sound streams resulting from playing music or videos, also game sound tracks. These can play for long periods of time and can be played in the background while other tasks are being performed. They are often high-quality. Listening to these is desired by the user. 3. Conversation: streams from VOIP applications. These can play for long periods of time. Since a conversation is ongoing, they normally require constant user attention. Their sound quality can be poor. Volume for Type 1 should definitely be handled automatically whenever possible. People don't want to fiddle with this, they just want to hear their notifications. Types 2 and three require manual adjustment, and probably can be handled uniformly for the most part. I'm making the distinction mainly because of the differences in interaction, namely, background vs. foreground. Based on the previous comments, I'm also tempted to add a fourth category: Sound spam: unexpected/undesired sound streams coming from Web pages. Of course, muting these automatically would be ideal, but can be very difficult given their often malicious nature. Any ideas in this direction are greatly appreciated. Martín ___ 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] Use cases for volume control
2010/5/5 Alex Lourie > > I'd suggest, again, to begin with the "problem" cases, not solutions. For > example, when is the intervention needed to control volume? > Sure, this is the purpose of writing use cases. I was just acknowledging that ReplayGain and, in general, fully automated solutions are not excluded from the solution space, even if the writing of the use cases seems to suggest that they are. > > 1. I'm listening to a great rock music (meaning pretty loud), and VOIP call > comes in. So, do I want to pause music, or make it more quiet relative to > the volume of the voice chat (and maybe system will do that automatically > when I answer the call). > I think this is covered by Gerhardt's case, isn't it? Your question about what to do in this case is of course valid, but answering it takes us immediately into the solution realm. > > 2. I'm in a voice chat session. Do I want to hear other system sounds or > not? Do I want to hear them louder than the call or more quiet? > This would be covered for the most part by Javier's case, I guess. There are probably situations, however, when a conversation is too important to be interrupted by any notification sounds. A use case to the effect may be valuable indeed. > > So I suggest to describe flows that require an intervention. If it is > complicated to handle a flow then great, you have found a "problem" > definition. > I'd say that uses cases should describe the whole palette of user tasks/activities we want to support. If they are easy to support, better for us, but having them all covered is important to make sure that the design is complete. Martín ___ 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] Use cases for volume control
2010/5/6 Tommaso R. Donnarumma > * Johann Sebastian wants to listen to music without interruptions. He > needs a quick way to mute all sound sources except his music player. > There seems to be a general need for a way to say the system "please do not disturb". This also applies to important VOIP conversations, presentations and maybe others. I'll probably add a case for this. > * Wolfgang Amadeus wants to listen to music, but he must accept some > interruptions, like incoming calls (both via VOIP and standard phone). > He needs a quick way to mute spam sound, as well as a quick way to pause > his music when he takes a call, and a quick way to restart the current > song, when he's done. > In which way is this different from Gerhardt's case? Martin ___ 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] Two suggested designs for the Sound Indicator
On Fri, May 7, 2010 at 3:58 PM, Matthew Paul Thomas wrote: > [...] > It is awkward that we have separate system and application-specific > volume settings, but I don't see how getting rid of the system volume > setting would work. > PulseAudio has a solution for precisely this problem: the so-called flat volumes [1, 2]. Basically, what they do is setting the global volume in such a way that the original volumes defined for the various streams are kept unaltered when mixed into the final, single stream (i.e., a high volume set for one of the streams will result in a high overall volume.) This is already implemented in PulseAudio, by the way, but inactive in Lucid. If you want to activate it, though, it's as easy as changing the flat-volumes setting in /etc/pulse/daemon.conf to "yes". I suppose this feature is currently deactivated because it makes the main volume slider behave in a very strange way. Actually, the right solution when flat volumes are active would be to hide this slider completely, and rather provide a slider that controls the currently sounding stream. I have the impression that this would be a lot more intuitive to use for most people. > Ensuring the alert sounds are loud enough to be heard over other sounds > - -- whether by making them temporarily louder, or making the other sounds > temporarily softer -- is an interesting idea, but it seems out of scope > for the sound menu itself. > I proposed the idea of automatically controlling the volume of (or around) notification sounds as a way to eliminate one more aspect with which users must currently fiddle. If we managed to implement this (I know it isn't so easy) this would definitely simplify the user interface, which is one of the main goals you stated. My idea to implement this, by the way, would be to measure the perceptual loudness [3] of the current stream using Replay Gain [4] or similar. The resulting (instant) value would be used to set the volume for the notification stream. This can probably be all done inside PulseAudio by creating an appropriate module. Since I'm not an expert in signal processing, however, I don't know how difficult it would be to implement Replay Gain or a similar loudness measure in a way that can be used for this purpose. I also wonder what the impact on battery life would be. I'll try to look a bit more into these issues and report here when/if I find some answers. Of course, any useful pointers will be greatly appreciated. Cheers, M. S. [1] http://0pointer.de/blog/projects/oh-nine-fifteen.html [2] http://www.pulseaudio.org/wiki/WritingVolumeControlUIs (there's a section called "Flat Volumes" down the page) [3] http://en.wikipedia.org/wiki/Equal-loudness_contour [4] http://en.wikipedia.org/wiki/Replay_gain ___ 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] Two suggested designs for the Sound Indicator
2010/5/12 Frederik Nnaji > Ensuring the alert sounds are loud enough to be heard over other sounds >>> - -- whether by making them temporarily louder, or making the other >>> sounds >>> temporarily softer -- is an interesting idea, but it seems out of scope >>> for the sound menu itself. >>> >> > can be handled automatically by "side-chaining". > does pulse know side-chaining? > I don't think so, but it's probably possible to create a module for that. Anyway, thanks for the pointer, I'll look further into this idea. > [...] > i wouldn't want main volume to change automatically.. > this is a very individual thing that should be left to the user's > individual preference/control.. > People want to control the volume of the streams coming out of the computer: music, VOIP, movie, etc. I think we all agree that control over those volumes should be left in the user's hands. The question is what's the best way for them to exert that control. Our current method involves setting volumes for a number of individual streams, which are then combined into a single stream for which the user must also set a volume (the so-called main volume). This is complicated and confusing for most people. The flat volumes system, on the other hand, determines the main volume automatically based on the volumes set for the individual streams. The idea is to look at the individual volume settings as absolute, not relative to the main volume. So, for example, if someone sets his Rhythmbox volume to 70%, we interpret that she wants music to play at 70% of her sound card's maximum volume, and automatically set the main volume in such a way that this is achieved. This method doesn't impose any limitations on the user, because she'll still be able to precisely set the volume for whatever she's listening to. The advantage is that she'll be presented with a simpler model: just set the volume for whatever source you're listening to, and that's precisely what you'll hear. > [...] > Altering the dynamics of digital audio information would alter the > information or message itself.. > I probably wasn't clear enough, but indeed I'm not proposing to *alter* any playing streams, but just to *measure* them and otherwise leave them alone. The idea is that you determine the loudness of whatever is currently playing, and then use that to adjust the volume of any notification sounds that are played on top of that. So the only thing that would be altered would be the volume of the notifications. Now, I suggested Replay Gain because it's able to measure the perceived loudness of a piece of audio, but there are probably better options. Notice that, for this purpose, you wouldn't have to measure the entire stream, but only a piece as long as the notification sound you're going to play. There's indeed no need to have the loudness measuring algorithm running continuously. Cheers, Martín ___ 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] Two suggested designs for the Sound Indicator
2010/5/12 Diego Moya > The problem with automatic controls is, you still need a simple > interface to override their behavior when the programmed automation > provides a wrong result. Maybe you can hide them a bit, but the same > options must be available. > Or you implement the automation properly so that it reliably delivers the right result. Granted, we have often seen products that failed at automating something, but this doesn't mean the solution is to implement override buttons all over the place. A fridge with a just-in-case, thermostat-override button would speak very poorly about its manufacturer, wouldn't it? Getting automation to work is a matter of proper design, implementation and testing. I'd rather concentrate on finding out how to do these properly in our community, so that we can deliver solutions that don't need to be overridden because they operate as expected. Martín ___ 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] Two suggested designs for the Sound Indicator
2010/5/13 Diego Moya > If you can tell me how to do that, for all situations and usages, I > think there's a Loebner prize awaiting for you. Contextual adaptation > is a strong Artificial Intelligence problem. > And that's precisely the reason why you don't design for all situations and usages: it's horribly hard. The alternative is to pick a narrower scope and target it with your solution. People with needs outside that scope will have to use other solutions, but such is life. Martín ___ 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] Two suggested designs for the Sound Indicator
2010/5/13 Diego Moya > 2010/5/13 Martín Soto: > > Or you implement the automation properly so that it reliably delivers the > right result. > > The "right" result as defined by who? The designer or the user? > By the designer, of course. It is his task to determine how the product should behave. My fridge has a thermostat control to set the desired temperature and it's > from the best brand in my country. This is obviously not what I'm talking about. A temperature setting knob is sensible. A button that overrides the thermostat and lets you start and stop the freezing compressor by hand, isn't. > If I'm going to buy a lot of > food this afternoon and I need the fridge to be extra-cool in advance > to keep the unbroken cold chain, how is the fridge supposed to > automatically know that in advance? (Hint: my freezer also has a > manual Extra-Freeze button that overrides the thermostat wheel and > keeps constant cooling for a day). > It overrides the temperature *wheel* by temporarily setting the desired temperature to the minimum available. It's doesn't deactivate the thermostat letting you turn the compressor on and off at will. Automation is still working, even when you press that wonderbutton. > I agree with the "all over the place" part, but IMO you MUST have an > override (a "manual safety switch") for all complex functions that try > to automate user goals The keyword here is "user goal". To go back to the actual topic of this (sub)thread, we are speaking about automating the volume setting for the notification sounds, nothing else, nothing more. I contend that setting this volume is not a user goal. On the other hand, being able to hear the notifications appears to be much closer to whatever the user goal is. This way, automating the actual volume setting so that the notifications can always be heard seems like a proper design goal. > Of course calculations for physical processes [a thermostat to keep a > temperature] don't need to be overridden (they have a precise > definition, and either they're correct or there's a bug). Sound loudness can also be measured and calculations can be made to set the volume of a sound in such a way that it can be heard on top of another one. This is the point here. > [OK, there are some automations that don't need to be exposed > directly. The water dirtiness detection in my fuzzy Japanese washing > machine, I don't want to manually override. But then, there is a "my > clothes are extra-dirty" button too.] > The number of hidden automations in our daily lives boggles the mind! If they all had an override mechanism, our world would be full with red buttons behind Plexiglas covers. I'm glad this isn't the case, by the way. So you're suggesting the proper design is, "I've thought of everything > you can do in advance, everything else is impossible. If you want to > do something I didn't think of, then look for some other product "? > ;-) > Now we´re starting to understand each other! Although you're expressing it in a weaselly sort of way, this is indeed the main idea. I'd rather put it like: "I'll do my best to identify your needs in a particular, narrow area, and come up with a product that addresses them properly. Afterwards, you're free to decide if you want to use it or not." This is not about imposing anything on anyone, it's about designers taking responsibility for their products. As counterintuitive as it may be, understanding and addressing user's needs is the designer's task, not the user's task. Picking a narrower scope makes your design more manageable, but it > doesn't address the need for manual overrides in the features that > made the cut. Even if you could predict all possible situations in > your given scope, that won't prevent you from defining the wrong scope > in some subtle way that will only be apparent when your users are > manipulating the software. > In this case, you look at people using your software (or a prototype of it) identify the problem, and fix the design accordingly. And if they really have special needs, they should use special software. No need for override buttons here. > So no, even though I'm a big fan of user-centered design I don't buy > the "I know exactly what's best for you" (for a narrow definition of > "you"). You can still design flexible products that degrade gracefully > for users outside their predicted scope. > Interestingly enough, user-centered design is a lot about "I know exactly what's best for you", although not in the arrogant way you're trying to make it sound. It's about working hard to understand what pe
Re: [Ayatana] Two suggested designs for the Sound Indicator
2010/5/13 Walter Wittel > Wouldn't reducing the volume of the other streams in x db below the > notification be much easier to implement and achieve the goal of hearinf the > notification? X could be different based on the urgency of the notification. > > The problem is that if those other streams are much louder than the notifications, reducing their volume won't be enough. You will only hear a strange gap with volume going down and up, but you may not hear the notification in the middle of the gap. If we want notifications to be audible, their volume must be matched to that of whatever is currently playing. Martín ___ 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] Two suggested designs for the Sound Indicator
2010/5/13 Diego Moya > - An automated UI behavior is one feature that visibly changes the > user interface in ways that can perceived by the user (i.e. the > automation changes elements that are included in the user mental > model). For the sound menu, this means changing the absolute volume > for notifications. > > - The automation will change between various states according to some > predefined "business rules" that are not action-reaction with respect > to user actions. You suggested changing the notification volume to be > always slightly higher than the current background stream. > You're mixing in your own design/implementation assumptions. I'm suggesting to play notification sounds at a volume that is higher than whatever is currently playing. However, I never suggested to achieve this by directly affecting the slider used to control the volume for user notifications or any other UI element, for that matter. > Sound loudness can also be measured and calculations can be made to set > the > > volume of a sound in such a way that it can be heard on top of another > one. > > This is the point here. > > Exactly! My point is that you can't assume that doing this will always be > valid! > > - As I understand, you suggest that we don't need a way to control > which states the automation will decide to change the UI. I'm not sure I understand this sentence. In any case, I'm not suggesting an UI that changes the contents of visual controls automatically. Actually, so far I haven't proposed any visual UI at all. > Except that your design doesn't account for the case where hearing > notifications is not the user goal. > In your user story for Mary, she's > trying to enjoy listening to music and she doesn't want the frequent > sounds from the chat program, window manager or even a nearly dying > battery; these sounds quickly become annoying. She already has her > attention on her focused program, anyway - so why should those sound > alerts have a higher volume? What she needs is "ducking" the alerts > volume until she finishes with this scenario. > > (Note, this is just the opposite case from Javier, who actually needs > to not miss any notification). > > You'll say, "OK, then expand the design to also include this need by > providing a new specific feature for Mary". And I say, "but you missed > this use case the first time, how will you know you're not also > missing some other needed features?" > I never claimed that automatically picking up the volume for notifications is a complete design for any purpose. In particular, I didn't claim it to be a complete solution for the whole set of use cases I compiled. It should be no surprise that this idea alone is not sufficient to handle them all, and I think it's not fair from you to put it out of context just for the sake of making your point. Indeed, you don't have to come this far to show that I can miss an important aspect of a design: I concede that directly. This is the reason why I'm trying to discuss these issues openly here, so that any weaknesses in my and other people's ideas can be identified and fixed through discussion and constructive criticism before they are turned into a piece of software that doesn't work. But let's go back to the point before this derails the whole discussion. I agree that there's a need for temporarily suspending notifications. Cases for that include presentations, watching movies and "dedicated" music listening. This is however a problem that should be handled by the whole notification system. When watching movies or making presentations, for instance, you not only need the sounds out, but the visual notifications as well. I'm afraid this conversation is becoming too offtopic for the thread, > as we're mainly talking about general design principles. I suggest > either creating a new thread or taking it off-list except for the bits > where we actually comment on the sound panel design. > Agreed. How about looking at the concrete problems we have, and trying to see which design approach seems better for them? Martín ___ 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] Two suggested designs for the Sound Indicator
On Thu, May 20, 2010 at 11:08 AM, Mark Shuttleworth wrote: > This strikes me as being too much of a nanny. If music is already > playing, and someone starts playing something else, that's their choice, > isn't it? I guess it depends a lot on the situation. Suppose you´re listening to music while reading your RSS feeds and, at some point, you see a link in a blog post that points to an interesting video, or recorded speech, or any other thing containing sound. It´s reasonable to expect that you just click on that link without thinking too much of the potential consequences for your sound setup (this is something we could call an "impulse click"). The video starts to play on top of your music and cacophony ensues. Of course, you can always blame the user--after all, he clicked on the link, didn´t he--but It´d be a nice touch if the system would handle this by pausing or otherwise muting the background music while the video plays. This appears a lot more forgiving and humane to me. Martín ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Regarding the Sound Menu Spec's closing of inactive audio applications
On Tue, Feb 8, 2011 at 4:54 PM, Brett Cornwall wrote: Well, all that is written in the spec is: > > "*A compliant player should also keep playing if you close its window > while it is playing; exit if you close its window while it is not playing; > and remember exact state across sessions, so that after exit and relaunch it > is as if the player had never exited.*" > > I honestly don't see the benefit in such an action other than conserving > RAM. But that's the purpose of swap, isn't it? If RAM were the reason for > this behavior then it's putting more headache and CPU usage on those that > can handle lots of programs in order to reimplement an already-existing > functionality dedicated to those that run out of resources. I'm curious for > an explanation as I just don't understand the motivation. Surely getting all > these players to comply with preserving their exact state is going to take > some time to acoomplish. Why spend all the resources on something so > unexplained and seemingly trivial? > People turn their computers off from time to time. You cannot expect everyone to have his/her computer running (or, at least suspended) day and night in an endless session. As far as I'm concerned, "perfect" state saving is the right behavior for all applications, not only for music players. I want to be able to end my session at any time and for whatever reason I may have, without having to expend 10 minutes trying to restore the my session state afterwards. Cheers, Martín ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] New natty scrollbar issues
On Mon, Apr 11, 2011 at 10:20 AM, Mitja Pagon wrote: > I see this scrollbars as another solution in search of a problem to solve > and in the process introducing more problems than it solves. When will > people realize that this is not the right approach to do things. > The main advantage of the new scrollbars is that their real estate consumption is essentially 0. This may feel as a minor change when you're sitting in front of a 25" screen, but on my tiny notebook where every pixel counts, the improvement is significant. So yes, there are still some issues, but calling the scrollbars "another solution in search of a problem" appears quite unfair to me. 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
