Because if you don’t set the label to empty, then the name of the control is displayed as the default choice. It looks like crap, and irritated me, so as a quick fix, I set mine to empty as well. There are times when there is no default choice, that any choice is as viable as the rest.
Bob S > On Jul 2, 2015, at 13:17 , Scott Rossi <sc...@tactilemedia.com> wrote: > > As far as there being a "correct type of control", that's open to endless > debate. :-) > > From what you describe, there doesn't seem to be a need for a call to > action -- this was suggested simply to address the case that a selection > MUST be made for things to work. Since this doesn't seem to be relevant > in your situation, I would imagine you'd display a default option as the > control label. > > The bigger issue is why you have an empty option at all. If that's a > setting that a user can implement, the option should read something like > "<no selection>" or "<empty>" or similar. If the empty value is something > pulled from a table that can't be acted upon, there's no need to include > it in the list of options. > > As always, I may be missing something. :-) > > Regards, > > Scott Rossi > Creative Director > Tactile Media, UX/UI Design > > > > > On 7/2/15, 12:59 PM, "Peter Haworth" <p...@lcsql.com> wrote: > >> Interesting observation Scott. Makes me wonder if I'm actually using the >> correct type of menu. >> >> For example, I might have an option menu which lists the names of tables >> in >> a database and another one that lists the columns in the selected table. >> There's no "call to action" in that situation (other than to pick a table >> and a column), so is an option menu the correct type of control according >> to HIG? >> >> On Thu, Jul 2, 2015 at 10:00 AM Scott Rossi <sc...@tactilemedia.com> >> wrote: >> >>> Often, this type of control has a call to action such as "Choose an >>> item", >>> as opposed an indication "No selection". It depends on the context of >>> your control. If a selection is required in your set up, the call to >>> action is more communicative. Otherwise, if "No selection" is a valid >>> selection then that type of message should work. >>> >>> Regards, >>> >>> Scott Rossi >>> Creative Director >>> Tactile Media, UX/UI Design >>> >>> >>> >>> >>> On 7/2/15, 8:47 AM, "Peter Haworth" <p...@lcsql.com> wrote: >>> >>>> Good point. For lots of reasons, the names of my option menus aren't >>>> suitable for display to a user. Maybe the cleanest thing to do then >>> is, if >>>> the text of the menu is empty, set its label as suggested by Richard. I >>>> like that. Most of the menus in question are under the control of a >>>> behavior so this is easy to implement. >>>> >>>> On Thu, Jul 2, 2015, 8:28 AM Richard Gaskin >>> <ambassa...@fourthworld.com> >>>> wrote: >>>> >>>>> Peter Haworth wrote: >>>>> >>>>>> So my technique of setting showname to false if the text is empty >>> is >>>>> the >>>>>> only way round this? >>>>>> >>>>>> Also, you can have a label for an option menu with empty text. Try >>>>> setting >>>>>> the text of an option menu to empty, then use the message box to >>> set >>>>> its >>>>>> label to some value. >>>>> >>>>> With the OS X HIGs not nearly as complete as they used to be I can no >>>>> longer find the relevant section on this, but I believe most HIGs >>>>> suggest that we avoid giving the user the impression the control may >>> be >>>>> broken by replacing empty items with some explanation of why it's >>> empty, >>>>> or perhaps a disabled item simply saying "None". >>>>> >>>>> -- >>>>> Richard Gaskin >>>>> Fourth World Systems >>>>> Software Design and Development for the Desktop, Mobile, and the >>> Web >>>>> >>> ____________________________________________________________________ >>>>> ambassa...@fourthworld.com >>> http://www.FourthWorld.com >>>>> >>>>> _______________________________________________ >>>>> use-livecode mailing list >>>>> use-livecode@lists.runrev.com >>>>> Please visit this url to subscribe, unsubscribe and manage your >>>>> subscription preferences: >>>>> http://lists.runrev.com/mailman/listinfo/use-livecode >>>>> >>>> _______________________________________________ >>>> use-livecode mailing list >>>> use-livecode@lists.runrev.com >>>> Please visit this url to subscribe, unsubscribe and manage your >>>> subscription preferences: >>>> http://lists.runrev.com/mailman/listinfo/use-livecode >>> >>> >>> >>> _______________________________________________ >>> use-livecode mailing list >>> use-livecode@lists.runrev.com >>> Please visit this url to subscribe, unsubscribe and manage your >>> subscription preferences: >>> http://lists.runrev.com/mailman/listinfo/use-livecode >>> >> _______________________________________________ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode > > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
