Re: [Ayatana] Two suggested designs for the Sound Indicator

[Martín Soto]

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] Default to single click to open files and folders

[Thorsten Wilms]

On Wed, 2010-05-12 at 13:57 -0700, Tyler Brainerd wrote:
> Agreement with Conscious user. To implement single clicks solves no
> problem and creates a whole list of new ones.

The solves-no-problem part is simply not true.

For some people performing a double-click is hard. May it sound like a
cliché, but my mother is much happier since I switched her system to
single-click. She would be even happier if single-clicking would also
work in file dialogs and Thunderbird's attachment.

For a while I had issues with my fingers and double-clicking made it
worse. It just feels so ridiculously arduous once you got used to single
clicking. 


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/


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

Re: [Ayatana] Two suggested designs for the Sound Indicator

[Martín Soto]

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

[Martín Soto]

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] Default to single click to open files and folders

[Conscious User]

> Why? How is selecting an item first, then initiating a drag more
> discoverable that simply dragging it? To my mind they're both as hard to
> discover as each other.

I'm not talking about selecting an item first and then initiating
a drag. I'm talking about starting a drag *without wondering
whether you will activate the link or not*.

As for all the other points you brought up:

Until I read your response, I didn't realize I was treating "require
double-clicking" and "require two clicks" as the same thing, which
is not true.

My major worry about defaulting to single-clicking is losing the
concept of "selecting", for other actions other than opening. That
does *not* mean I'm in favor of double-clicking as it is today
(two clicks which *must* be close to each other). Yes, it's awful
and hard to learn.

Wouldn't be a good compromise if files could be opened with a
single click *if the file is already selected*? Think of it as
a double click with *infinite time* allowed between the two
clicks. That would, at the same time, avoid accidental opening,
would not require speed and would allow alternative actions.

In summary, here is a clarification of my position:

1) I *am* in favor of getting rid of the concept of double-clicking,
as in "two clicks really close to each other". It's hard to
learn and non-intuitive, I completely agree.

2) I am *not* in favor of opening files/folders with a single
click. Accidental openings and losing the concept of selection
are too high of a price to pay, in my opinion.

3) I do not believe those two options are the only ones. Why not
open a file with a single-click *only if the file is already
selected*?

Thoughts?



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

Re: [Ayatana] Default to single click to open files and folders

[Alex Lourie]

So how would a simple selection be solved? If I want to select a file or a
folder, I single-click on it.

If this behavior changes, then A LOT of people will have to change their
behavior.

So if changing this hurts more people than helps, I'd say it requires a lot
of thinking ahead.

On Thu, May 13, 2010 at 11:31 AM, Thorsten Wilms  wrote:

> On Wed, 2010-05-12 at 13:57 -0700, Tyler Brainerd wrote:
> > Agreement with Conscious user. To implement single clicks solves no
> > problem and creates a whole list of new ones.
>
> The solves-no-problem part is simply not true.
>
> For some people performing a double-click is hard. May it sound like a
> cliché, but my mother is much happier since I switched her system to
> single-click. She would be even happier if single-clicking would also
> work in file dialogs and Thunderbird's attachment.
>
> For a while I had issues with my fingers and double-clicking made it
> worse. It just feels so ridiculously arduous once you got used to single
> clicking.
>
>
> --
> Thorsten Wilms
>
> thorwil's design for free software:
> http://thorwil.wordpress.com/
>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
___
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] Default to single click to open files and folders

[Conscious User]

> In today's paradigm, the second selection works as the "rename"
> function. So changing that to "open" would definitely
> cause some relearning to have place.

> On the other hand, it may make more sense to actually open the
> folder/file on the second click than to rename it. Renaming
> is much less used operation in the life of a file/folder than opening,
> so there can be some mindset change here.


Is this true in Nautilus? It does not work for me...

Anyway, I wouldn't particularly mind changing this particular
mindset, in my opinion second click to renaming is anything
but intuitive.



___
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] Default to single click to open files and folders

[Remco]

On Thu, May 13, 2010 at 11:29, Alex Lourie  wrote:
> So how would a simple selection be solved? If I want to select a file or a
> folder, I single-click on it.
> If this behavior changes, then A LOT of people will have to change their
> behavior.
> So if changing this hurts more people than helps, I'd say it requires a lot
> of thinking ahead.

I think single click should not be default, but there is one way of
improving single selection in that mode: put a checkbox before each
file and folder. This also makes it easier to do multi selection in
any mode.

-- 
Remco

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

Re: [Ayatana] Default to single click to open files and folders

[Alex Lourie]

On Thu, May 13, 2010 at 1:02 PM, Remco  wrote:

>
> I think single click should not be default, but there is one way of
> improving single selection in that mode: put a checkbox before each
> file and folder. This also makes it easier to do multi selection in
> any mode.
>
> --
> Remco
>

And how would it be implemented in icon mode?

-- 
Alex Lourie
___
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] Default to single click to open files and folders

[Alex Lourie]

On Thu, May 13, 2010 at 12:45 PM, Conscious User wrote:

>
>
> > In today's paradigm, the second selection works as the "rename"
> > function. So changing that to "open" would definitely
> > cause some relearning to have place.
>
> > On the other hand, it may make more sense to actually open the
> > folder/file on the second click than to rename it. Renaming
> > is much less used operation in the life of a file/folder than opening,
> > so there can be some mindset change here.
>
>
> Is this true in Nautilus? It does not work for me...
>
> Anyway, I wouldn't particularly mind changing this particular
> mindset, in my opinion second click to renaming is anything
> but intuitive.
>
>
>
My point exactly.

-- 
Alex Lourie
___
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

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


> A fridge with a just-in-case, thermostat-override button would
> speak very poorly about its manufacturer, wouldn't it?

My fridge has a thermostat control to set the desired temperature, and
it's from the best brand in my country. 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).


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

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 (even if it's not expected to be used in normal
usage and is somewhat hidden), because this kind of complex
automations include a bit of "guessing" what the user intended to do.

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). But the fuzzy
rules that control when a user needs a given function [which
temperature is needed] don't belong in the same class and can't ever
be exactly calculated. There will ALWAYS be some wrongs in guessing
user intent, even with limited scope.

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

A good rule of thumb is that automatic processes with behaviors
leaking into the user mental model should have some level of manual
adjustment.


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

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 "?
;-)


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

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.

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.

___
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] Combo Indicator Applets

[Mark Shuttleworth]

The apps should always degrade to older / alternative behaviours. It's a
bug if they don't, and I'm sorry if the Empathy case was badly handled,
we should patch things up with upstream :-)

If the category indicator (sound indicator in this case) is not present,
then AppIndicators or the SysTray (till 11.04 on Ubuntu) are available
and should be used.

However, we want the default behaviour to be:

 - don't offer the ability to put it in either/both places
 - just have one "Put it on the panel" option, which either uses the
Sound Indicator or AppIndicator or Systray

Mark



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Default to single click to open files and folders

[Thorsten Wilms]

On Thu, 2010-05-13 at 11:18 +0200, Conscious User wrote:

> I'm not talking about selecting an item first and then initiating
> a drag. I'm talking about starting a drag *without wondering
> whether you will activate the link or not*.

Well, both opening of files or folder in Nautilus with
single-click-to-activate mode and following links in Firefox happen on
mouse-up. Thus a drag is guaranteed to be interpreted as drag.


> Wouldn't be a good compromise if files could be opened with a
> single click *if the file is already selected*? Think of it as
> a double click with *infinite time* allowed between the two
> clicks. That would, at the same time, avoid accidental opening,
> would not require speed and would allow alternative actions.

You would get rid of the pesky timing issue, but introduce state and
still require 2 clicks for the most common action (if opening is not the
most common action on files or folders, I would suggest something is
going wrong).


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/


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

Re: [Ayatana] Default to single click to open files and folders

[Diego Moya]

On 13 May 2010 14:08, Thorsten Wilms wrote:
> You would get rid of the pesky timing issue, but introduce state and
> still require 2 clicks for the most common action (if opening is not the
> most common action on files or folders, I would suggest something is
> going wrong).

There will be (short) sessions when opening is the most common action,
but then there are also sessions where selecting - for copying,
moving, renaming - is the most common action.

Actually I'd dare to say that the most frequent usage of the file
manager is the second one. The preferred way to open files and
applications in the modern desktop is through the top menus and
instant-search tools like Gnome-DO. So why should "open" supposed to
be the most common action? I don't think that assumption is true.

___
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] Default to single click to open files and folders

[Frederik Nnaji]

On Thu, May 13, 2010 at 12:02, Remco  wrote:

> On Thu, May 13, 2010 at 11:29, Alex Lourie  wrote:
> > So how would a simple selection be solved? If I want to select a file or
> a
> > folder, I single-click on it.
> > If this behavior changes, then A LOT of people will have to change their
> > behavior.
> > So if changing this hurts more people than helps, I'd say it requires a
> lot
> > of thinking ahead.
>
> I think single click should not be default, but there is one way of
> improving single selection in that mode: put a checkbox before each
> file and folder. This also makes it easier to do multi selection in
> any mode.
>

KDE defaults to this in dolphin.
it also defaults to comfortable single click.
___
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] Default to single click to open files and folders

[Remco]

On Thu, May 13, 2010 at 12:07, Alex Lourie  wrote:
> On Thu, May 13, 2010 at 1:02 PM, Remco  wrote:
>>
>> I think single click should not be default, but there is one way of
>> improving single selection in that mode: put a checkbox before each
>> file and folder. This also makes it easier to do multi selection in
>> any mode.
>
> And how would it be implemented in icon mode?

A checkbox somewhere on the icon. I remember seeing this on a Windows machine:
http://malektips.com/windows-7-explorer-checkbox-select-file.html

-- 
Remco

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

Re: [Ayatana] Default to single click to open files and folders

[Frederik Nnaji]

On Thu, May 13, 2010 at 14:48, Remco  wrote:

> On Thu, May 13, 2010 at 12:07, Alex Lourie  wrote:
> > On Thu, May 13, 2010 at 1:02 PM, Remco  wrote:
> >>
> >> I think single click should not be default, but there is one way of
> >> improving single selection in that mode: put a checkbox before each
> >> file and folder. This also makes it easier to do multi selection in
> >> any mode.
> >
> > And how would it be implemented in icon mode?
>
> A checkbox somewhere on the icon. I remember seeing this on a Windows
> machine:
> http://malektips.com/windows-7-explorer-checkbox-select-file.html


thanx, remco

note: checkbox appears on mouse-over.
this behaviour works best, if all thumbs are of the same size and muscle
memory is honored by the checkbox position.

for those who want to test this behaviour live: try Dolphin, it's just a
command away:
$sudo apt-get install dolphin
___
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] Default to single click to open files and folders

[Frederik Nnaji]

On Thu, May 13, 2010 at 14:17, Diego Moya  wrote:

> On 13 May 2010 14:08, Thorsten Wilms wrote:
> > You would get rid of the pesky timing issue, but introduce state and
> > still require 2 clicks for the most common action (if opening is not the
> > most common action on files or folders, I would suggest something is
> > going wrong).
>
> There will be (short) sessions when opening is the most common action,
> but then there are also sessions where selecting - for copying,
> moving, renaming - is the most common action.
>
> Actually I'd dare to say that the most frequent usage of the file
> manager is the second one. The preferred way to open files and
> applications in the modern desktop is through the top menus and
> instant-search tools like Gnome-DO. So why should "open" supposed to
> be the most common action? I don't think that assumption is true.
>

like somebody said on the xdg list... exposing hierarchical filesystems in
user space is the actual problem.
in German we would now say "jetzt haben wir den salat", meaning we are now
exposed to increased communication entropy within the UI ;)

honestly, please name the use cases for file operations.
i want to see thumbs for photos, not filenames.
i want to read metadata (artist, album, title, artwork) for songs.
other stuff should have titles or other forms of identification, not
filenames.
filenames are, nowadays, something to handle automagically; and with them
the absolute path of the respective file.

about clicking problems with drag and drop:
instead of complaining about how difficult drag operations will get when
clicking gets easier, better think about how to make single-clicking more
fault tolerant.
___
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

[Martín Soto]

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

Re: [Ayatana] Two suggested designs for the Sound Indicator

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

On May 13, 2010 7:00 AM, "Martín Soto"  wrote:

2010/5/13 Diego Moya 

> > 2010/5/13 Martín Soto: > > Or you implement the automation properly so
that it reliably delivers...

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

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

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

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

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

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

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

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

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 are you supposed to
understand it? Thus, "degrading gracefully" actually means expanding your
scope to cover a larger set of use cases, which can easily take you to the
point where you're not able to address any of those cases properly with a
single, manageable design.

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
___
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] Default to single click to open files and folders

[Conscious User]

> like somebody said on the xdg list... exposing hierarchical
> filesystems in user space is the actual problem.
> in German we would now say "jetzt haben wir den salat", meaning we are
> now exposed to increased communication entropy within the UI ;)
> 
> honestly, please name the use cases for file operations.
> i want to see thumbs for photos, not filenames.
> i want to read metadata (artist, album, title, artwork) for songs.
> other stuff should have titles or other forms of identification, not
> filenames.
> filenames are, nowadays, something to handle automagically; and with
> them the absolute path of the respective file.

Which, again, is another argument *against* single-click to open
rather than *for* it. If the usual way of dealing with files is
supposed to be *not* via a filebrowser, then it's reasonable to
assume that when using a filebrowser actions *other* than simple
opening will be frequent.

> about clicking problems with drag and drop:
> instead of complaining about how difficult drag operations will get
> when clicking gets easier, better think about how to make
> single-clicking more fault tolerant.

It's "better" if you accept that single-clicking is the best
solution, which is what I am questioning. Why should I shift
my focus on working around problems on a certain path, if I'm
yet not convinced that such path is the best one?



___
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] Default to single click to open files and folders

[Conscious User]

> You would get rid of the pesky timing issue, but introduce state and
> still require 2 clicks for the most common action (if opening is not the
> most common action on files or folders, I would suggest something is
> going wrong).

I have nothing against making the common action easy. The problem is:
when you make it *too* easy, the other actions become annoying.



___
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] Default to single click to open files and folders

[Jan-Christoph Borchardt]

On 13 May 2010 11:29, Alex Lourie  wrote:
> So how would a simple selection be solved? If I want to select a file or a
> folder, I single-click on it.

Currently, it is implemented by Ctrl + click. Not the best solution,
but double clicking for opening a file is much much worse.


> If this behavior changes, then A LOT of people will have to change their
> behavior.
> So if changing this hurts more people than helps, I'd say it requires a lot
> of thinking ahead.

That is the difference between intuitive and learnt interfaces.


On 13 May 2010 15:00, Frederik Nnaji  wrote:
> On Thu, May 13, 2010 at 14:17, Diego Moya  wrote:
>> On 13 May 2010 14:08, Thorsten Wilms wrote:
>> > if opening is not the
>> > most common action on files or folders, I would suggest something is
>> > going wrong).

+1


>> There will be (short) sessions when opening is the most common action,
>> but then there are also sessions where selecting - for copying,
>> moving, renaming - is the most common action.
>>
>> Actually I'd dare to say that the most frequent usage of the file
>> manager is the second one. The preferred way to open files and
>> applications in the modern desktop is through the top menus and
>> instant-search tools like Gnome-DO. So why should "open" supposed to
>> be the most common action? I don't think that assumption is true.
>
> honestly, please name the use cases for file operations.

Second that. Files are not for renaming and ordering, but for using them.

> i want to see thumbs for photos, not filenames.
> i want to read metadata (artist, album, title, artwork) for songs.
> other stuff should have titles or other forms of identification, not
> filenames.
> filenames are, nowadays, something to handle automagically; and with them
> the absolute path of the respective file.

Absolutely +1. Coverflow, folder thumbnails and digital picture frames
(and, well, the iPad) are prime examples of this.



Conscious User 
> Which, again, is another argument *against* single-click to open
> rather than *for* it. If the usual way of dealing with files is
> supposed to be *not* via a filebrowser, then it's reasonable to
> assume that when using a filebrowser actions *other* than simple
> opening will be frequent.

What is the primary tool that the system provides to users to look at
their files? It may not be supposed to do it, but that does not matter
because it is done anyway.

But I agree in some way: »File manager« in itself is a really broken
concept. Users really don’t care about managing (e. g. renaming) their
files – why do they have a computer anyway?


> It's "better" if you accept that single-clicking is the best
> solution, which is what I am questioning. Why should I shift
> my focus on working around problems on a certain path, if I'm
> yet not convinced that such path is the best one?

Because you have to see it from a user’s point of view: Why would I
double click? As Luke Morton said: »As a final thing to consider: if
no-one ever told you to double-click, how would you know to do so?«

___
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] Default to single click to open files and folders

[Conscious User]

> note: checkbox appears on mouse-over.
> this behaviour works best, if all thumbs are of the same size and
> muscle memory is honored by the checkbox position.
> 
> for those who want to test this behaviour live: try Dolphin, it's just
> a command away:
> $sudo apt-get install dolphin


Add a handle for dragging and I might start to like this idea. :)

Since the main subject of this discussion is reducing what the
user is supposed to know a priori, then I think that, if we are
going in the single-click route, then we should go
all the way and not require him to know that the
single-clicking-and-holding and single-clicking-and-releasing
are different things. Therefore, drag-n-drop also deserves
its mouseover handle, methinks...



___
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] Default to single click to open files and folders

[Conscious User]

> What is the primary tool that the system provides to users to look at
> their files? It may not be supposed to do it, but that does not matter
> because it is done anyway.

I agree that a compromise with current ways should be reached, but
dismissing the entire matter "because it is done anyway" is a bad
idea in the long term. I don't want this discussion to start all
over again when non-filesystem based ways of handling your system
start becoming more popular (which is already happening on netbooks)

> Because you have to see it from a user’s point of view: Why would I
> double click? As Luke Morton said: »As a final thing to consider: if
> no-one ever told you to double-click, how would you know to do so?«

See my previous messages, I'm *against* double-clicking as it is
today. My suggestion is the compromise of requiring selection before
action, which I don't think it's absurd.



___
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

[Frederik Nnaji]

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.
>
..or based on the current attention mode of the user.

watching a movie with my girlfriend, i don't want calls to break audio or IM
bubbles to jump into Batman's face. that's something we are not yet
addressing, and also the settings in the Me Menu don't quite cover that
yet..

Busy aka Do Not Disturb perhaps.. yeah.

and in that mode, i wouldn't want any blips or bubbles.
the only case i can think of as being relevant is a warning about imminent
hardware failure or such..

otherwise, read ahead the sum of active audio streams, calculate RMS and
duck[1] it to the notification sounds. if notification sounds are designed
well, then we DO want to hear them.
so now that they are actually helpful and don't suck anymore, please let me
know somehow, if they are muted.

[1] http://www.sweetwater.com/expert-center/glossary/t--Ducker
___
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] Default to single click to open files and folders

[Jan-Christoph Borchardt]

On 13 May 2010 17:08, Conscious User  wrote:
>> What is the primary tool that the system provides to users to look at
>> their files? It may not be supposed to do it, but that does not matter
>> because it is done anyway.
>
> I agree that a compromise with current ways should be reached, but
> dismissing the entire matter "because it is done anyway" is a bad
> idea in the long term. I don't want this discussion to start all
> over again when non-filesystem based ways of handling your system
> start becoming more popular (which is already happening on netbooks)

Yes, but that is not the point of the discussion anyway. Sorry for
getting off topic.


>> Because you have to see it from a user’s point of view: Why would I
>> double click? As Luke Morton said: »As a final thing to consider: if
>> no-one ever told you to double-click, how would you know to do so?«
>
> See my previous messages, I'm *against* double-clicking as it is
> today. My suggestion is the compromise of requiring selection before
> action, which I don't think it's absurd.

That is not a compromise, it is just having more time for the second
click. What would then still result in people double-clicking a file
or folder if they want to open it.


On 13 May 2010 16:48, Conscious User  wrote:
> On 13 May 2010 14:55, Frederik Nnaji  wrote:
>> for those who want to test this behaviour live: try Dolphin, it's just
>> a command away:
>> $sudo apt-get install dolphin
>
> Add a handle for dragging and I might start to like this idea. :)

I’m sorry, but then why all the discussion? I brought up KDE / Dolphin
in my second post.


> Since the main subject of this discussion is reducing what the
> user is supposed to know a priori, then I think that, if we are
> going in the single-click route, then we should go
> all the way and not require him to know that the
> single-clicking-and-holding and single-clicking-and-releasing
> are different things. Therefore, drag-n-drop also deserves
> its mouseover handle, methinks...

A mouseover handle: That’s more of a compromise. :) This could solve
the discoverability issues.

It should then be placed so everyone knows the complete icon is
draggable. The files themselves should still be treated as physical
and movable objects. Moving iPhone icons to indicate they are
draggable comes to mind.

___
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

[Diego Moya]

2010/5/13 Martín Soto:
> 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.

You've never pressed the wrong floor button in an elevator? That's the
kind of overriding I'm referring to, not big "emergency stop red
buttons" everywhere.


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

We're arguing in circles around the definition of the word
"automation". When I say the user must be able to override a complex
automation, I don't mean the automation stops working. These are my
assumptions in what was said above:

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


> 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. The above
business rule (notifications=higher volume) is defined as "the right
behavior".

- I suggest there should always be an obvious way for the user to
decide which of this states to put the system, and prevent the
automation to change it while the "manual override" is active. The
automation may still be active and making its minor tweaks in the
background as expected for the current state; it's just that these
tweaks can't go outside the scope of the user's desired effect. See
Mary's use case below for an example.


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

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



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

To which I as a user will say, "no matter how hard you try, you'll
miss some details I couldn't articulate during the research phase, or
you'll miss my cousin's needs because she was not present during the
research, or you'll miss some needs I don't know I have yet because
they'll appear one year from now. So your design won't be perfect
anyway".

I understand your position as you express it, and I think it's not
enough for a good design. See reasons below.


> Afterwards, you're
> free to decide if you want to use it or not." This is not

Re: [Ayatana] Default to single click to open files and folders

[Frederik Nnaji]

On Thu, May 13, 2010 at 17:50, Jan-Christoph Borchardt <
inqu...@googlemail.com> wrote:

> I’m sorry, but then why all the discussion? I brought up KDE / Dolphin
> in my second post.
>

sorry, that was about 20h and like 30 mails ago in this thread alone :D
birdseye perspective is not so easy anymore..

Conscious:
good idea with indicating dragabilty ;)

Jan-Christoph:
yeah, iPhone is a good example for what i'm about to suggest:

to follow the thought of creating an intuitive, consistent and thereby
easily depth-discoverable interface, we need to think dumb sometimes.
"smart" is then the product of intuitive thinking, not of complicated
pirouettes of mind.

how do i know that what i am touching can be moved?
how do i know that i'm selecting it, not activating or focusing it
(zoom/scale/spacial highlighting)?
altogether:
how do i know what i can do with an object, without previously knowing the
object?

we use little indications overlayed with the respective representation of
the object, be it a symbol or the object itself.

such indications or indicators can be:
a) mouse cursor shape
*hand (open in a drag and drop zone, clutching if something is being
held/dragged)
*finger (to indicate that i'm about to add to selection upon click)
*arrow (color: default/none for "go, open, run", blue for "info layer upon
click"...)
*bubble (for indicating the ability of immediate textual communication)
*text cursor (type without letting any mouse pointer get in the way of your
focus)
*[...] u name it!

b) status bar information
c) tooltips aka mouse-over info
d) pointer-focus-oriented morphing of symbols/icons/objects
e) [...] u name it!

just brainstorming.
i think i have always been quite good at thinking dumb ;)
___
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] Default to single click to open files and folders

[Conscious User]

> I’m sorry, but then why all the discussion? I brought up KDE / Dolphin
> in my second post.

I *still* do not agree with single-click opening, but if I *can* suggest
improvements to it then I *must* do so because the only way to fairly
compare two scenarios is to imagine both of them as refined as possible.

If all possibilities of refinement for both scenarios are exhausted,
and single-click ends up looking better, I'll be the first to admit it.

Until them, it's my "moral obligation" to share ideas for improvement,
even if it's for the "rival" proposal. :)



___
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

[Frederik Nnaji]

2010/5/13 Diego Moya 

> 2010/5/13 Martín Soto:
> > 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.
>
> You've never pressed the wrong floor button in an elevator? That's the
> kind of overriding I'm referring to, not big "emergency stop red
> buttons" everywhere.
>

take this idea to an elevator manufacturer [1] [2], but GPL it first!
The russians have it already [3], but communism doesn't acknowledge patents
[4] :D
(Undo button for the elevator UI) ;) tellem to run the UI computer with
busybox :D
i'm sure this time Eben Moglen wouldn't have too much work on his hands, if
you do it right from the start!
great metaphor, i won't forget this one for months to come!

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

:/ +1


[1] http://www.whynot.net/ideas/185
[2] http://jackodile.com/2009/09/21/i-want-a-cancel-button/
[3] http://www.flickr.com/photos/ifl/4116127364/
[4]
http://www-cs-faculty.stanford.edu/~eroberts/cs201/projects/communism-computing-china/intelproperty.html
___
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] Default to single click to open files and folders

[Diego Moya]

>>On 13 May 2010 17:08, Conscious User wrote:
>> are different things. Therefore, drag-n-drop also deserves
>> its mouseover handle, methinks...

Good idea!


On 13 May 2010 17:50, Jan-Christoph Borchardt wrote:
>A mouseover handle: That’s more of a compromise. :) This could solve
>the discoverability issues.
> It should then be placed so everyone knows the complete icon is
> draggable.

I attach a quick-n-dirty mockup of a visual design for how this can be
suggested.

- The file icon is given a frame on mouse over like the one in the
mockup, a box with a drag handle on its side.
- Clicking on the drag handle will select the file.
- Single-clicking on the icon will open the file.
- Dragging anywhere on the icon or file handle will begin a drag-and-drop.
<>___
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] Default to single click to open files and folders

[Diego Moya]

On 13 May 2010 18:31, Diego Moyawrote:
> I attach a quick-n-dirty mockup of a visual design for how this can be
> suggested.

... and a second version with several files, one of them with the mouseover.
<>___
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

[Alex Launi]

2010/5/13 Martín Soto 

> 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


^^ Everyone on this list read that phrase an internalize it. That is the
single most important statement made on this list, ever.

Nicely said, Martin.

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

Re: [Ayatana] Two suggested designs for the Sound Indicator

[Diego Moya]

2010/5/13 Frederik Nnaji:
> 2010/5/13 Diego Moya
>> You've never pressed the wrong floor button in an elevator? That's the
>> kind of overriding I'm referring to, not big "emergency stop red
>> buttons" everywhere.
>
> take this idea to an elevator manufacturer [1] [2], but GPL it first!
> The russians have it already [3], but communism doesn't acknowledge patents
> [4] :D

8-)

Actually I had thought of pressing twice the button to unselect the
floor, but then again this global "cancel" button is more
discoverable.


> [1] http://www.whynot.net/ideas/185
> [2] http://jackodile.com/2009/09/21/i-want-a-cancel-button/
> [3] http://www.flickr.com/photos/ifl/4116127364/
> [4]
> http://www-cs-faculty.stanford.edu/~eroberts/cs201/projects/communism-computing-china/intelproperty.html
>

___
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] Default to single click to open files and folders

[Frederik Nnaji]

pretty!
where would you now place the checkbox for multiple selection?

On Thu, May 13, 2010 at 18:35, Diego Moya  wrote:

> On 13 May 2010 18:31, Diego Moyawrote:
> > I attach a quick-n-dirty mockup of a visual design for how this can be
> > suggested.
>
> ... and a second version with several files, one of them with the
> mouseover.
>
>
___
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] Instant-messaging as an indicator menu

[Jeremy Nickurak]

We've been talking a bit about the advanced capabilities a volume-control
indicator menu could have, and that's got me thinking a bit about how the
empathy contact list works...

We go to the indicator to open the contact list. We select items there, and
interact a bit. Then (if you're like me) you close the contact list window
so it's out of the way until you want it again.

This sounds a lot like the behavior of a menu.

What if opening an 'IM' indicator opened as a menu that you could interact
with, that would show the contacts, their status (with icons) and options to
interact with it (start conversations, voip sessions, add/remove contacts,
join conferences, etc).

This would do a couple really interesting things in my mind:

1) I used to like the 'systray' behavior for empathy, because it gave me one
location on the panel where I could show/hide the empathy window. With a
menu-like approach, all the open/close behavior for the contact-list dialog
becomes unified at one location again.
2) The 'close' vs 'hide' debate over what the big 'X' on the contact list
window's titlebar becomes irrelevant... there's never a real window any
more.

If you're like me, the 'contact list' window is usually long and narrow
(like a menu), with a  long vertical list of entries to interact with (like
a menu).

This would also play nicely with the other IM/social-networking interfaces
that go into indicator menus, like the status-setting UI.

Thoughts?

-- 
Jeremy Nickurak -= Email/XMPP: jer...@nickurak.ca =-
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Default to single click to open files and folders

[Diego Moya]

On 13 May 2010 18:42, Frederik Nnaji wrote:
> pretty!
> where would you now place the checkbox for multiple selection?

Oops! I forgot about that feature :-)

Maybe a "pin" icon at the top of the handle, instead of a checkbox?

___
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] Default to single click to open files and folders

[David Hamm]

"Maybe a "pin" icon at the top of the handle, instead of a checkbox?"

I like the checkbox better, it has more of a human feel. I also added
the handle on the opposite side for more balance.
<>___
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] Default to single click to open files and folders

[Diego Moya]

On 13 May 2010 19:36, Diego Moya wrote:
> On 13 May 2010 18:42, Frederik Nnaji wrote:
>> pretty!
>> where would you now place the checkbox for multiple selection?
>
> Oops! I forgot about that feature :-)
>
> Maybe a "pin" icon at the top of the handle, instead of a checkbox?

... like this one. (Though it's getting a little bit unclean now).
<>___
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] Default to single click to open files and folders

[David Hamm]

Anyone else feel like seeing avatar again? In all honesty single
clicking isn't something that should be brushed off.

For the short term I would copy windows7 to the T.
Hovering over and icon selects it.

For the long run I would consider making it default; with touch in mind.

Normally single clicking doesn't really present any problems. And I
would liken it to driving faster on the road. But when you remove the
right click it starts to get interesting.

___
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] Default to single click to open files and folders

[Tyler Brainerd]

Good usability does not mean we aim for the lowest possible denominator, it
means we find the most usable possibility. in the current icon mode of
layout, simply switching to single clicking is going to make other functions
impossible, not easier. my point was simple that it creates many other
problems that would have to be thought through, we can't just switch it and
think we're good to go.

On Thu, May 13, 2010 at 1:31 AM, Thorsten Wilms  wrote:

> On Wed, 2010-05-12 at 13:57 -0700, Tyler Brainerd wrote:
> > Agreement with Conscious user. To implement single clicks solves no
> > problem and creates a whole list of new ones.
>
> The solves-no-problem part is simply not true.
>
> For some people performing a double-click is hard. May it sound like a
> cliché, but my mother is much happier since I switched her system to
> single-click. She would be even happier if single-clicking would also
> work in file dialogs and Thunderbird's attachment.
>
> For a while I had issues with my fingers and double-clicking made it
> worse. It just feels so ridiculously arduous once you got used to single
> clicking.
>
>
> --
> Thorsten Wilms
>
> thorwil's design for free software:
> http://thorwil.wordpress.com/
>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
___
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] Default to single click to open files and folders

[Neil Broadley]

I'm curious to how "pure" this discussion is.  Is the aim of Ayatana simply
to provide the most intuitive design ever, or does it take into account how
things are done in Windows and Mac and make reservation for it?

Single-click to open is the reason I immediately dismissed Mepis in 2005 and
ended up with Ubuntu.  Only much later did I discover that KDE offers the
ability to change this behaviour.  But it was the default behaviour that
turned me away.

Also, I'm a Windows user for roughly 9 hours of my (working) day.  Then I
come home to a house I've fully converted to Ubuntu Lucid.  I
*need*consistency.  This is, for example, why my window controls are
back on the
right and that's why they'll stay there until Microsoft decide to offer the
left as an option.

I don't want to sound to knee-jerk here, but some things need to be put into
the context of the wider world.  It's already been said by Conscience, I
believe, but if this change comes through, you'd better be incredibly
confident about its implementation!

First impressions and consistency.  This counts for a lot and I get the
impression from the short time I've been following this list that it's
greatly underestimated.

Neil.

On 13 May 2010 17:42, Frederik Nnaji  wrote:

> pretty!
> where would you now place the checkbox for multiple selection?
>
>
> On Thu, May 13, 2010 at 18:35, Diego Moya  wrote:
>
>> On 13 May 2010 18:31, Diego Moyawrote:
>> > I attach a quick-n-dirty mockup of a visual design for how this can be
>> > suggested.
>>
>> ... and a second version with several files, one of them with the
>> mouseover.
>>
>>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

Re: [Ayatana] Default to single click to open files and folders

[Thorsten Wilms]

On Thu, 2010-05-13 at 13:02 -0700, Tyler Brainerd wrote:
> Good usability does not mean we aim for the lowest possible
> denominator, it means we find the most usable possibility.

This sentence seems to be devoid of actual sense.

>  in the current icon mode of layout, simply switching to single
> clicking is going to make other functions impossible, not easier. my
> point was simple that it creates many other problems that would have
> to be thought through, we can't just switch it and think we're good to
> go.

What becomes impossible?


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/


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

Re: [Ayatana] Default to single click to open files and folders

[Luke Morton]

On Thu, 2010-05-13 at 16:34 +0200, Conscious User wrote:
> 
> > honestly, please name the use cases for file operations.
> > i want to see thumbs for photos, not filenames.
> > i want to read metadata (artist, album, title, artwork) for songs.

I thought long and hard about the use cases for wanting to select a file
last night, and the best I could come up with centres around metadata:

Miranda likes notes. She leaves them plastered around her house as
reminders. She also annotates her files using the Notes Sidebar in
Nautilus. She uses these notes to help her identify files, and as a
reminder of what the file contains and sometimes as a checklist of
things that need to be done to the file. 

To enable this kind of metadata review in a single-click environment,
Miranda will need to learn to use either the Ctrl key as a modifier to
switch from 'activate' to 'select', or she'll have to use the keyboard
to navigate. If using the mouse she'll have to select a file, deselect
it, then select another. That's a lot more overhead than just one click
per file. But it's also an edge case.

> Which, again, is another argument *against* single-click to open
> rather than *for* it. If the usual way of dealing with files is
> supposed to be *not* via a filebrowser, then it's reasonable to
> assume that when using a filebrowser actions *other* than simple
> opening will be frequent.

All other use cases (renaming a file/folder, moving a file/folder,
moving multiple files/folders) are supported just as well in a
single-click environment.

Luke.



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

Re: [Ayatana] Default to single click to open files and folders

[Tyler Brainerd]

Perhaps read the rest of the conversation and you will read all the
previous examples of difficulty with some functions.

On May 13, 2010, at 1:18 PM, Thorsten Wilms  wrote:

> On Thu, 2010-05-13 at 13:02 -0700, Tyler Brainerd wrote:
>> Good usability does not mean we aim for the lowest possible
>> denominator, it means we find the most usable possibility.
>
> This sentence seems to be devoid of actual sense.

I'm not sure what's difficult. Good design does not mean we make
things the most simplistic, or to cater to users with only one finger
or whatever example gets thought of; good design means creating the
best mix of feature and ease of use for the  widest range of users,
and providing the ability o alter them further for particular
difficulties in the way they used the computer. I was responding in
particular to a response that said it was difficult to double click if
you have a finger injury. The majority of users do not. So we should
not design for the small majority but the larger majority.


>
>> in the current icon mode of layout, simply switching to single
>> clicking is going to make other functions impossible, not easier. my
>> point was simple that it creates many other problems that would have
>> to be thought through, we can't just switch it and think we're good
>> to
>> go.
>
> What becomes impossible?
>
>
> --
> Thorsten Wilms
>
> thorwil's design for free software:
> http://thorwil.wordpress.com/
>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp

___
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] Default to single click to open files and folders

[Luke Morton]

On Thu, 2010-05-13 at 11:18 +0200, Conscious User wrote:
> I'm not talking about selecting an item first and then initiating
> a drag. I'm talking about starting a drag *without wondering
> whether you will activate the link or not*.

I've never had that problem. But if you have, then I guess others would
too.

> My major worry about defaulting to single-clicking is losing the
> concept of "selecting", for other actions other than opening. .

It's still possible, it just requires a different approach: drag a
selection box over the file/folder(s) or use a modifier key. Nothing's
lost, but learnt behaviours would have to change.

> In summary, here is a clarification of my position:
> 
> 1) I *am* in favor of getting rid of the concept of double-clicking,
> as in "two clicks really close to each other". It's hard to
> learn and non-intuitive, I completely agree.

Cool.

> 2) I am *not* in favor of opening files/folders with a single
> click. Accidental openings and losing the concept of selection
> are too high of a price to pay, in my opinion.

I understand your concern.

> 3) I do not believe those two options are the only ones. Why not
> open a file with a single-click *only if the file is already
> selected*?

This would work, but as Thorsten mentioned it would introduce state and
still require two clicks.


___
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] Default to single click to open files and folders

[Luke Morton]

On Thu, 2010-05-13 at 11:14 -0700, David Hamm wrote:

> For the short term I would copy windows7 to the T.
> Hovering over and icon selects it.

The overlay idea seems sound to me. It would have the added advantage of
making draging, etc far more easily discovered.

> For the long run I would consider making it default; with touch in mind.
> 
> Normally single clicking doesn't really present any problems. And I
> would liken it to driving faster on the road. But when you remove the
> right click it starts to get interesting.

There is a Simulate Secondary Click option under the Accessibility tab
in the Mouse Preferences that should solve that problem. Although I
remember having issues with it on a multi-touch trackpad in the past.


___
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] Default to single click to open files and folders

[Luke Morton]

On Thu, 2010-05-13 at 18:12 +0200, Frederik Nnaji wrote:
> On Thu, May 13, 2010 at 17:50, Jan-Christoph Borchardt
>  
> how do i know that what i am touching can be moved?
At the moment you don't, but overlays could fix that.

> how do i know that i'm selecting it, 
At the moment your cursor is an arrow.

> not activating 
At the moment your cursor is a hand.



___
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] Default to single click to open files and folders

[Luke Morton]

On Thu, 2010-05-13 at 14:36 +0200, Frederik Nnaji wrote:
> On Thu, May 13, 2010 at 12:02, Remco  wrote:
> On Thu, May 13, 2010 at 11:29, Alex Lourie 
> wrote:
> > So how would a simple selection be solved? If I want to
> select a file or a
> > folder, I single-click on it.
> > If this behavior changes, then A LOT of people will have to
> change their
> > behavior.
> > So if changing this hurts more people than helps, I'd say it
> requires a lot
> > of thinking ahead.

I completely agree. Changes like this should be backed by data gathered
by formal user testing. I would love to see single-click be the default
as I believe it to be a superior method of interaction, but if it causes
more problems than it solves then it shouldn't be the default.

> I think single click should not be default, but there is one
> way of
> improving single selection in that mode: put a checkbox before
> each
> file and folder. This also makes it easier to do multi
> selection in
> any mode.
> 
> KDE defaults to this in dolphin.
> it also defaults to comfortable single click.

How does dolphin behave in list/tree view? The space for overlays in
those instances is dramatically reduced.



___
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

[Martín Soto]

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

[Jan-Christoph Borchardt]

2010/5/13 Diego Moya :
> 2010/5/13 Martín Soto:
>> 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.
>
> 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 (even if it's not expected to be used in normal
> usage and is somewhat hidden), because this kind of complex
> automations include a bit of "guessing" what the user intended to do.

At the moment, the manual safety switch isn’t the problem because it
is already implemented in form of the global sound slider. It is the
automation that we must have.


On 13 May 2010 17:19, Alex Launi  wrote:
> 2010/5/13 Martín Soto 
>> 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
>
> ^^ Everyone on this list read that phrase an internalize it. That is the
> single most important statement made on this list, ever.
> Nicely said, Martin.

+ 2, from me and Jakob: http://www.useit.com/alertbox/20010805.html

»[…] basic rules of usability:
* Watch what people actually do.
* Do not believe what people say they do.
* Definitely don't believe what people predict they may do in the future.«

___
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

[Martín Soto]

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] Default to single click to open files and folders

[Tyler Brainerd]

How in the world is highlight selecting folders for copying or moving
supposed to be easier on the user?

Further, what I said was "in the curren icon mode" as in, if we are going to
do this, we have to rethink everything about it, not just changing open to a
single click. As in, we have to rethink how we present selecting items,
copying them, moving them. To just 'simply switch it' is going to make it
difficult for users to use it, not easier.


On Thu, May 13, 2010 at 2:42 PM, Luke Morton
wrote:

> On Thu, 2010-05-13 at 13:02 -0700, Tyler Brainerd wrote:
> > in the current icon mode of layout, simply switching to single
> > clicking is going to make other functions impossible, not easier.
>
> That's simply not true. Everything you can do in double-click mode you
> can do in single-click, including selecting a file. The method changes,
> but the feature set remains the same.
>
>
>
>
___
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] Default to single click to open files and folders

[Luke Morton]

On Thu, 2010-05-13 at 15:26 -0700, Tyler Brainerd wrote:
> 
> How in the world is highlight selecting folders for copying or moving
> supposed to be easier on the user?

I never said selecting a folder for copying or moving would be easier.
In fact, I said the methods for doing so (some of them) would have to
change. Note that "not easier" is not the same as "harder".

> Further, what I said was "in the curren icon mode" as in, if we are
> going to do this, we have to rethink everything about it, not just
> changing open to a single click. As in, we have to rethink how we
> present selecting items, copying them, moving them. 

No, it doesn't. In fact, very little has to change.

Take copying for example. There are a variety of ways to do this, and
while the lists below are by no means exhaustive, they are indicative.
(In the examples operations are separated by commas, copy and paste
commands are interchangeable between examples, and compound operations
are indicated by a + for keyboard controls and > for menu navigation.)

In a double-click environment
* left-click folder, Ctrl + C, [navigate], Ctrl + V
* right-click folder > Copy, [navigate], right-click > Paste
* left-click-drag selection over folder, right-click folder > Copy,
[navigate], right-click > Paste

In a single-click environment
* Ctrl + left-click folder, Ctrl + C, [navigate], Ctrl + V
* right-click folder > Copy, [navigate], right-click > Paste
* left-click-drag selection over folder, right-click folder > Copy,
[navigate], right-click > Paste

The only difference is the additional requirement for the Ctrl key in
selecting a folder in a single-click environment. 




___
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

[Diego Moya]

2010/5/14 Martín Soto:
> 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.

Never did I. Playing the notification at a higher volume is the new
state changed by automation. The high sound volume of volume can be
perceived by the user as an automatic state change (even if the
sliders are unchanged), IF you have and individual volume control for
each application as the original design suggested.



> I never claimed that automatically picking up the volume for notifications
> is a complete design for any purpose.

But you claimed that a full design can be made to support all purposes
for a given class of users. Moreover, you suggested that if a user
doesn't have all her purposes covered by the design, she shouldn't use
it.

In my view, those both claims turn the effective size for the set of
target users to 0 if followed to their logic consequences. There is no
way you can "understand what people really require in order to perform
a particular task" to a perfect degree, not even by restricting the
number of users studied. This is why I argue for keeping safeguards,
to create a design that can support errors in the design.



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

That's what I'm trying to do, by suggesting a way by which missing
aspects can be addressed other than by an upfront design by committee.
You seem confident that *any* weakness can be discovered during the
design process. The idea here is that *even this open discussion could
miss important aspects of the design*, so we should design against
this possible (may I say likely) failure.



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

Sorry if I sounded harsh or unintentionally took your words out of
context. I was using the notification volume as an example to
illustrate my abstract reasoning, my argument didn't depend on it nor
assumed that this case was your full proposed design. The crux of it
is, I still think your assumption that a *perfect* design can be
created just by careful user observation and testing is flawed.



> Agreed. How about looking at the concrete problems we have, and trying to see 
> which design approach seems
> better for them?

With respect to the sound panel: I submitted a mockup to the list
based on my "override the wrong automations" idea (the same one posted
as Solution #6 in http://brainstorm.ubuntu.com/idea/24627/ ).

This design is compatible with your suggestion to give a louder sound
to notifications. In the case where "louder notifications" is not the
desired state, the user can override that with a single selection.
Same with any other states that you'd want automate (muted
applications, different relative volumes), the user will always be
able to open this menu and change what the automation decided on a
per-sound-source level.

This design doesn't depend on creating special goal-oriented modes for
presentations, movies, games or music. It works in the same way for
these cases, and as far as I can see, for mostly all the user stories
you submitted. Why do you opposed so strongly this "lightweight
override" idea, and does your objection hold for my mockup? Is there
some fundamental flaw in this design that I can't see? How would you
solve the same needs in a different way?

___
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] Default to single click to open files and folders

[Sohail Mirza]

On Thu, May 13, 2010 at 5:37 PM, Luke Morton
wrote:

> Nothing's lost, but learnt behaviours would have to change.
>


Changing learnt behaviours is easier said than done!

A cost of this change is the frustration of users who are accustomed to
Windows' default behaviour at their workplace, or at home.  This is
potentially a level of frustration equal to (or greater than) that of users
fed up with double-clicking.  It's very easy to understate this cost, as you
have done.

If indeed the cost of having users relearn file interaction is greater than
the benefit of single-clicking, then it is not the right thing to do.

I would also like to point out that single-clicking was attempted by default
in Windows 98 SE (or was it ME?).  You'll note that Microsoft abandoned that
default setting very quickly (presumably because of the cost of having users
relearn the behaviour involved in file manipulation).  Anecdotally, that
"feature" annoyed just about everyone I know, including myself, and to no
small degree.  Having nothing happen when you single click a file is, imho,
far less annoying than having an application launch when you simply meant to
select the file.

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

Re: [Ayatana] Default to single click to open files and folders

[Luke Morton]

On Thu, 2010-05-13 at 20:18 -0400, Sohail Mirza wrote:
> Changing learnt behaviours is easier said than done!

I agree.

> A cost of this change is the frustration of users who are accustomed
> to Windows' default behaviour at their workplace, or at home.  This is
> potentially a level of frustration equal to (or greater than) that of
> users fed up with double-clicking.  It's very easy to understate this
> cost, as you have done.

Again, I agree (although I don't think I understated cost--I didn't
mention even mention it).

> If indeed the cost of having users relearn file interaction is greater
> than the benefit of single-clicking, then it is not the right thing to
> do.

Agreed (again). In fact, I said exactly this in another reply.

"Changes like this should be backed by data gathered
by formal user testing. I would love to see single-click be the default
as I believe it to be a superior method of interaction, but if it causes
more problems than it solves then it shouldn't be the default."


___
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] Default to single click to open files and folders

[Sohail Mirza]

I'm sorry if I misunderstood your position.  Thanks for the clarification.
:)


On Thu, May 13, 2010 at 8:35 PM, Luke Morton
wrote:

> On Thu, 2010-05-13 at 20:18 -0400, Sohail Mirza wrote:
> > Changing learnt behaviours is easier said than done!
>
> I agree.
>
> > A cost of this change is the frustration of users who are accustomed
> > to Windows' default behaviour at their workplace, or at home.  This is
> > potentially a level of frustration equal to (or greater than) that of
> > users fed up with double-clicking.  It's very easy to understate this
> > cost, as you have done.
>
> Again, I agree (although I don't think I understated cost--I didn't
> mention even mention it).
>
> > If indeed the cost of having users relearn file interaction is greater
> > than the benefit of single-clicking, then it is not the right thing to
> > do.
>
> Agreed (again). In fact, I said exactly this in another reply.
>
> "Changes like this should be backed by data gathered
> by formal user testing. I would love to see single-click be the default
> as I believe it to be a superior method of interaction, but if it causes
> more problems than it solves then it shouldn't be the default."
>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>



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