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 frus
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 frustrati
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 h
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 volum
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) wo
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
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
> fo
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
> overr
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 stream
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 singl
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
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 consi
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 other
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
>>
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 wantin
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
>
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
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
prob
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 cli
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. (T
"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 :
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://l
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
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 fil
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 russ
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 (th
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
P
>>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 discoverabil
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 pre
> 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
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 anymo
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 el
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
> dism
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
> 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"
> 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 ha
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 behavio
> 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 proble
> 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
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
> > 2
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.
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
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 eac
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 mu
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
> > beha
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)
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-c
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 (
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'
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
>
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 w
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,
> 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 muc
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 1
> 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
wh
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:
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 prope
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
clic
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.
>>>
>>
>
59 matches
Mail list logo
