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

List:       kde-usability
Subject:    Re: Is "anchor widgets" clear?
From:       Peter <gostelow () global ! co ! za>
Date:       2009-06-15 13:04:29
Message-ID: 200906151304.32432.gostelow () global ! co ! za
[Download RAW message or body]

On Monday 15 June 2009 11:43, Diego Moya wrote:
> 2009/6/10 Matthew Woehlke <mw_triad@users.sourceforge.net>
>
> > IMO best suggestions so far are: 'pin', 'anchor', 'lock' (maybe 'stick'
> > but I don't know how you'd make an icon for that). Also 'lock' is nice
> > if it becomes non-configurable at the same time.
>
> How about the more obvious 'still' and 'stop'? I'm not sure anyone has
> suggested them.

They suggest the plasmoid will no longer update itself. What I think we're 
looking for is a working plasmoid in a state that ignores the user's attempts 
to move, resize, and possibly close it.

This is not the same as 'lock screen', which supresses application output 
while locked. A 'locked' plasmoid will continue to update itself and interact 
with the user, but ignore (all?) window manager functions. However, using 
'lock' with different meanings can confuse an user who may think 'lock 
screen' is the global equivelant of 'lock widget' and use it to prevent all 
widgets from being moved, or conversely, think 'lock widget' is the local 
equivelant of 'lock screen' and will require user authorisation to access it.

The problem is that lock is a sensible choice for both meanings, but creates a 
problem when the meaning cannot be disambiguated. 'lock widget's position' 
and 'lock screen access' are longer, but more clearly define the meaning in 
each case. We could create various locks, such as 'access lock' and 'move 
lock' and their icons.

>
>
> Also, every proposal until now has been a verb. That makes sense when it's
> associated to an action ("Lock screen"), which produces a temporary effect.
>
> But the action discussed at bug
> 193943<http://bugs.kde.org/show_bug.cgi?id=193943>seems to be about a
> configuration option, which is a persistent state
> (widgets get locked or unlocked until the option is changed again by the
> user). IMHO configuration states work better when described with nouns
> and/or adjectives.
>
>
> Thus if you change the focus from describing action to describing state,
> you have a whole new vocabulary to choose from:

I also thought the plasmoid's state is what we're dealing with, that's why I 
included freeze. Also, harden/soften refer to the plasmoid's state.

>
> Snapped, pinned, located, fixed, embedded, impaled, immobile, frozen,
> inhibited, attached,
> trapped, hold, bound, contained, restricted, limited, fastened, secured,
> stuck, persistent,
> parked...  Widgets.

Unfortunately, most English nouns can also be verbs: Pin is either the name of 
an item, or doing something. Usually the context identifies whether the word 
is a noun or verb: 'Pin the tail on the donkey; This is the donkey's tail 
pin.'; 'stick the stick on the desktop'; 'You can park at the park's car 
park'. The -ed refers to past tense, so pinned may mean a past action, or the 
current state as a result of a past action. We are looking at a future state, 
rather than a pa	st one.

>
>
> Even more, you can describe the _opposite_ state as well:
>
> Free, unpinned, locatable, unfixed, dug up, mobile, melted, uninhibited,
> detached, released, loose, unbound, released, unrestricted, unlimited,
> unchained, unsecured, temporary, departed.
>
> And instead of an icon you get a check mark. I don't know if this is
> against the HIG for KDE though, having non-commands in context menus.

Regards,

Peter
_______________________________________________
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]