[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Menu entry: how to tell that not the whole selection is affected?
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2006-12-30 10:17:17
Message-ID: 200612300317.24632.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 30 December 2006 2:12, Friedrich W. H. Kossebau wrote:
> Hm. The dialog with the system I see rather like this:
> Gerry: "Hey, Larry, I want you to help me doing something to all members of
> the family."

this is the literal mechanism, but IME it's generally not how most people use 
systems particularly once they are familiar with them (which ends up being 
the bulk of their time spent with a system if they like it =). generally 
someone will (right-?) click on the icon thinking "i want to <task>...". it's 
usually only during exploration phases the the user is thinking "let's 
explore what i can do!"

we face this same circumstance with the kmenu, actually =)

> Yes, problem here is, that telling who exactly will be missed gets
> complicated if there are a lot. So doing it afterwards, like you propose,
> could make sense (for Simple Joe). But I personally would at least like to
> have a hint before that there is trouble ahead with a certain action.
> Something like in the attached screenshot.

problem is that in the attached screenshot it doesn't say -who- which makes it 
pretty well useless for most people. cluttering an interface with information 
that is pretty well uselses for most people is not a great strategy =)

> > in other words, it would seem much more natural to me if the computer
> > told me -after- i asked it to take an action if it couldn't do it for
> > certain individuals. personally, i'd expect this to happen with a passive
> > popup (so i don't have to click further) near my current locus of
> > attention (e.g. where the menu entry is/was).
>
> Hm, interesting idea. Where should this popup appear?

where the user's eyes last were: centered on the location where the menu item 
they selected was.

> But then, a user 
> might not be pleased if a phone call is already set and only then she reads
> in the passive popup "Sorry, Aunt Lilly and Brother Joe aren't phoned.",
> or?

you can always hang up. or cancel the email. or close the chat window.

> > chances are, i probably know that Uncle Barry doesn't have an email
> > address already anyways.
>
> Chances are. But so are chances, you don't remember, and then both Uncle
> Barry and you will be sorry to have him miss your birthday party, not?

we hate uncle barry anyways ;-P

seriously though, that's the point of the passive popup to let you know some 
people weren't invited.

another strategy might be to show a sort of tooltip if you stop and however 
over an entry in the menu showing who will (and won't) be contacted by that 
method.

and having just written that it occurs to me that those lists could be rather 
large in the case of a corporate address book =)

> At least in the usecase I have in mind, where you want to give an
> information to all in a list, it seems useful to me to see which action
> fits best for this purpose. Or?

in your screenshot they are both email based actions that do fundamentally 
different things. this will likely be the common reason for choosing (tasks) 
rather than reach (the # of people). one of the few areas i can see this 
mattering is when deciding whether to mass contact people via phone or 
instant message; and on that note, how often does one mass phone people 
anyways?

i recommend optimizing on tasks rather than reach and provide note of 
unreachable contacts via some non-intrusive additional mechanism (tooltip, 
passive popup..)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability


[prev in list] [next in list] [prev in thread] [next in thread]