[etoys-dev] changing the name and value-type of a user-defined variable

[Bert Freudenberg]

Am 07.03.2012 um 22:47 schrieb Scott Wallace <scott.wallace at squeakland.org>:

> On Mar 7, 2012, at 9:04 AM, Ricardo Moran wrote:
> 
>>  … I thought "modify <var>" would be a better name for the menu item, because in some cases (just number and point for now) we have more than just the name and type.
>> 
>> I still think it's better than "change <var> name and type" (or any variation) because IMHO when you create the variable you see upfront what it takes to create it, so it's consistent to believe the same parameters would be needed to "modify" it. Maybe it's just a matter of getting used to it.
> 
> Agreed, it's a matter of getting used to it.
> 
> But if a user can't find it in the first place, it's unlikely she will ever get used to it :)
> 
> My point is only that if the words "name" and "type" are not present anywhere in the menu, the user is unlikely to stumble upon the fact that name and type can be changed.
> 
> 
>> The only inconsistency I would criticize is the "decimal places", which for user created variables it requires the new dialog, but for other slots it uses the old menu. But that has also been brought to discusion before.
> 
> Right; and apropos of the previous comment, it's even more important in the case of "decimal places" that the user be able to see the wording "decimal places" in the menu, because her experience with setting decimal places for system-defined variables certainly will lead her to expect it.
> 
> So whether there are one, two, or three menu items involved, again, I think the important point here is for the user to *see* the words "name", "type", and "decimal places" in the menu. 
> 
> 
> BTW useful balloon help is provided for the "decimal pleas…" item in the viewer menu for a system-defined variable, but for no other items in the menu.  Arguably there should be balloon help provided for all of the items -- this could help especially if we have important features "buried" behind less-than-self-explanatory menu items.
> 
> Or is it too late in this cycle to be adding strings that will need to be translated?

Almost too late, we should be quick to get the strings out.

- Bert -
-------------- n�chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.squeakland.org/pipermail/etoys-dev/attachments/20120308/94cdf39d/attachment.html>