Re: [Ayatana] New natty scrollbar issues
On Mon, Apr 11, 2011 at 10:20 AM, Mitja Pagon mitja.pa...@inueni.comwrote: 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
Re: [Ayatana] Regarding the Sound Menu Spec's closing of inactive audio applications
On Tue, Feb 8, 2011 at 4:54 PM, Brett Cornwall brettcornw...@gmail.comwrote: 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] Two suggested designs for the Sound Indicator
On Thu, May 20, 2010 at 11:08 AM, Mark Shuttleworth m...@ubuntu.com 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] Two suggested designs for the Sound Indicator
2010/5/12 Frederik Nnaji frederik.nn...@gmail.com 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 turi...@gmail.com 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 turi...@gmail.com 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 turi...@gmail.com 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 people really require in order to perform a particular task (this is often not what they think they require!) and about providing exactly that to them. In this sense, the idea of a product that degrades gracefully for users outside the predicted scope is sort of contradictory. In order for the product to behave gracefully, you must understand how it's going to be used, but if the use lies outside your intended scope, how
Re: [Ayatana] Two suggested designs for the Sound Indicator
2010/5/13 Walter Wittel witt...@gmail.com 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
On Fri, May 7, 2010 at 3:58 PM, Matthew Paul Thomas m...@canonical.comwrote: [...] 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] Use cases for volume control
2010/5/6 Tommaso R. Donnarumma tawmas.f...@tawmas.net * 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] Use cases for volume control
2010/5/5 Alex Launi alex.la...@gmail.com 2010/5/4 Martín Soto dons...@gmail.com [...] * 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 sira...@gmail.com wrote: 2010/5/4 Martín Soto dons...@gmail.com: * 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] Two suggested designs for the Sound Indicator
2010/5/3 Diego Moya turi...@gmail.com 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 frederik.nn...@gmail.com 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 alex.la...@gmail.com 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] Reducing Resistance to Change
2010/4/30 Diego Moya turi...@gmail.com 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 hyper...@ubuntu.com 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 hyper...@ubuntu.com 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
2010/5/3 Chow Loong Jin hyper...@ubuntu.com 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 qe...@ubuntu.com 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] Regarding Notify-OSD's Position in Karmic Koala
On Wed, Oct 21, 2009 at 1:13 PM, Martin Owens docto...@gmail.com 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 pjssi...@ime.usp.br 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 kaz...@gmail.com 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] [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] notify-osd + fullscreen + multiple monitors
On Tue, Jul 7, 2009 at 11:22 AM, Praveen tgpravee...@gmail.com 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 m...@funkyhat.org 2009/7/7 Martín Soto dons...@gmail.com: 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 drkv...@yahoo.com 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 pjssi...@ime.usp.brwrote: 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] Getting users to care (was Re: [Fwd: Re: Update manager])
2009/6/16 Vincenzo Ciancia cian...@di.unipi.it 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 their computers open windows without
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
