[ANN] new version of services available for preview
Romain Robbes
romain.robbes at lu.unisi.ch
Fri Sep 30 21:11:59 UTC 2005
On Sep 30, 2005, at 10:27 PM, Hernan Tylim wrote:
> Hi,
>
> I am with Tim here. Clicking and double-clicking inside a text
> field is a today de-facto standard for positioning and selecting text.
>
> This might not be a good standard (to me it is) but is a standard
> nonetheless. So changing it will only frustrate every user who
> don't know, or remember, that squeak has such distinct behaviour.
>
> I also don't think that making things clickable while they don't
> give visual feedback of clickability will help avoid user confusion.
>
> What do you think about using CTRL+ALT. I read that you couldn´t
> use ctrl and alt separately, but what about both keys?. If
> possible I would also underline all clickable words while CTRL+ALT
> are being pressed. This would give the visual feedback I just
> mentioned and will advertise to a user that something can be done
> with that words.
>
Well I have quite a few possibilities there ... I'll try some of
these and see what is the best.
I think the problem in this respect (using alt or ctrl) is that
these events are swallowed by squeak
so I'll need to do some treatments at a lower level probably.
But I'll look into this.
Romain
> Just my opinion.
>
> Regards,
> Hernán
>
> tim Rowledge wrote:
>
>> Please don't do this mangling of click behaviour. It can only
>> confuse most users, especially those of us with a long history.
>> It will slow down editing. It won't really speed up finding
>> senders/implementors since the time to ask for the list is small
>> by comparison to the time for the list to be built and presented.
>> How would it work with the other uses of d-click? i.e the d-click
>> at the beginning of the line/view/quote-delimited area/etc ? I
>> think you are inappropriately overloading a gesture so common it
>> can only cause problems.
>> Consider some alternatives -
>> a metakey with the click. shift is already used to extend the
>> selection though and the others are implicitly used for single
>> button systems.
>> triple-clicking. I've used systems with t-click and they tend to
>> be a pain; d-click is pretty much a trivial reflex finger action.
>> t- or quad- click requires you to count and slows you down.
>> hotkey. we already have them and they work quite well.
>> menu. slower but the action needs to be there for completeness.
>> toolbar button. reasonable - after a d-click one pretty much has
>> to have the mouse in-hand and so a small motion to a reasonably
>> sized button not too far away will take very little time and
>> negligable cognitive effort.
>> drag-to tool. slightly off the wall but consider being able to
>> drag the selection to a tool that will do the action. such a tool
>> would be a 'senders browser' and anytime you drop a selection on
>> it it would display the senders. It could be a stacking browser
>> so that all/some/ many recent sets of senders would be available.
>> Similar tools would show implementors, references, class refs,
>> variable usages, commentary, spelling and thesaurus info, etc
>> etc. Instead of adding loads of function to a plain browser you
>> just add the drag/drop and then have new specialised browsers.
>> See? There's lots more exciting ways to improve code exploring
>> than ruining my editing experience.
>> tim
>>
>
>
>
>
>
>
> ___________________________________________________________ 1GB
> gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del
> mundo http://correo.yahoo.com.ar
>
>
--
Romain Robbes
http://www.inf.unisi.ch/~robbes/
More information about the Squeak-dev
mailing list
|