[ANN] new version of services available for preview

Hernan Tylim htylim at yahoo.com.ar
Fri Sep 30 20:27:56 UTC 2005


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.

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 




More information about the Squeak-dev mailing list