changing the name and value-type of a user-defined variable

On 07.03.2012, at 13:09, Bert Freudenberg wrote:

>
> On 07.03.2012, at 07:31, Scott Wallace <[hidden email]> wrote:
>
>> I think Richo's "new variable" dialog, in which name and value-type are specified together in a single dialog, is a good addition.
>>
>> And it's good that a similar dialog can be brought up to change the name and/or the value-type of a variable later on.
>>
>> But I feel that *finding* ones way to the change-name/change-type dialog is now harder -- not only does one have to fish in a menu to look for it, but one is likely to miss it, because neither the word "name" nor the word "type" occurs in the menu item.  Instead one must choose an item with wording of the form 'modify "var1"', and it has to register in the user's mind that this the correct path to the change-name/change-value-type dialog.
>>
>> To my mind the me this buries renaming and type-changing too deeply, so that people will be much less likely to find them and hence even to be aware that they *can* change the name and the type of a variable.
>>
>> So I wonder if we should consider changing the wording of this menu item to something more like "change name or type".  Or "change name and type".  Or "name and value-type".  Or in any case, *something* that directly catches the eye of a user scanning the menu for the word "name" or "type".
>>
>> Or perhaps even two menu items, "change name" and "change value-type", as before, but now both leading to the same dialog?
>>
>> Does anyone else share this concern?
>>
>> -- Scott
>
> +1

Oh, and we lost the ability to change the number of decimal places. Can only be set on new vars but not modified.

- Bert -


_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Am 07.03.2012 um 22:47 schrieb Scott Wallace <[hidden email]>:

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 -

______