Fog Creek Software
Discussion Board




Exposing Options

Does anyone expose options to users based on API structure? For example, if I have a LOGFONT structure and I expose all member with their various options to the user.  Why not do things like this?  Wouldn't this add value to the product?

You may be thinking that you would only expose the options the user needs, but don't the various struct's give hints as to what's important to the user.

(Please note that I don't do this and am only posing a hypothetical question/scenario.)

Anon
Tuesday, June 08, 2004

Yes: Google for "PropertyGrid" or "PropertyBag".

Christopher Wells
Tuesday, June 08, 2004

Perhaps I should make myself clearer.

I am speaking of the end user.

Why not, for example, have all of the options of the LOGFONT structure available in a program when it comes time to select a font?  (Presented in a dialog box perhaps.)

Anon
Tuesday, June 08, 2004

MS articles describing the .NET PropertyGrid suggest that you might use it, for example, to let the user edit an instance of a class that contains your program settings.

Christopher Wells
Tuesday, June 08, 2004

I will have to think for a minute about how to say what I want to convey.

Anon
Tuesday, June 08, 2004

If LOGFONT were a C# (not a C) type, with get/set properties instead of public data members, then you could use the PropertyGrid control to display and edit an instance of it. You could also use "attributes" to mark some of its properties as not browsable (not displayable by the PropertyGrid).

> Wouldn't this add value to the product?

Using PropertyGrid saves you (the developer) from writing a specific dialog box resource for each structure, and the code to link the structure members to GUI components.

> Why not do things like this?

Like what exactly?

Christopher Wells
Tuesday, June 08, 2004

What Anon is trying to say is this (I think):

Any non-trivial application offers its users a number of options. Some of these options are internally reflected in Win32 API calls or structures, for example LOGFONT. So, instead of allowing the user to choose the font, the size and the style, one could expose all the members of the LOGFONT structure and pass that back to the Win32 API.

I don't think that's a good idea. It prevents leaking abstractions of course, but only because it recudes the abstraction significantly. It can offer somewhat increased flexibility, but at a significant cost. The Win32 API is often quite difficult if you're not used to it; in many circumstances, it would require the user to study the Win32 API to know just what values to use.

In addition, it would make it even more difficult to create cross-platform applications.

vrt3
Tuesday, June 08, 2004

Yes, thank you vrt3.

Win32 API calls/structs exposed to the user using a different wording.  For example, the face name of the font is always exposed to the user, but the character set is never exposed to the user.  Why not expose this using a drop down combo just like the face name except don't put ANSI_CHARSET in the combo put AMERICAN ENGLISH or HEBREW or what not so that the user can choose the character set.  Would this confuse the end user?

I understand the downsides that vrt3 speaks of but I do think that this approach to exposing options may merit some attention so as to not "hide fuctionality" from the end user.

/shrug (Maybe not too many people have to deal with this)

Anon
Tuesday, June 08, 2004

Sometimes more elegant solutions exist that allow you to hide the API while providing the same or similar, and sometimes better, functionality. Consider Bayesian spam filtering (simple UI for day-to-day operations) vs. the user maintaining his/her own list of spammy keywords (complex UI).

Some options ought not be exposed to the user.
For example, making the user choose the vertical width of menu items (in pixels), instead of writing the UI so it chooses one automatically based on the height of the font.

Derek
Tuesday, June 08, 2004

I have this 'thing' that I'm trying to say at the tip of my tounge but I don't know how to say it.

I understand everyones viewpoint, but I can't seem to express mine.  vrt3 is close.

It's about adding value, quality, functionality and flexibility by exposing every available option that would benefit the user?  Eh?  Not even that expresses it to the extent that I would like.  I have to think some more.

Anon
Tuesday, June 08, 2004

Sorry, Anon, but users really don't care about all the hidden details of the fonts as much as you believe. As long as they can choose the basic font style, the size, and common options like bold/underline/italic, then 99.9% of users will be happy. And even the remaining .1% who appreciate the extra options won't care enough to actually pay extra for the product.
  The standard font-picker dialog is simple to use. Adding more options to it will complicate its usability while adding features that most people will never use.

Sexist
Tuesday, June 08, 2004

Anon -

THe big problem is that the API view of what is important is not the same as the users view of what is important, and that the API model is rarely the same as the users mental model.

The programmers job is to translate between the API model and the USER model in a way that 'works' for the user.

Example: Right now I've just added a new feature to our GIS tool to do with customizing label backgrounds. The API model is that alpha blending runs from 0. (solid colour) to 255 (transparent). The USER model is that transparency runs from 0 to 100% in steps of 10%. So not only is the user model on a different scale, it goes in a different direction.

theWeasel
Wednesday, June 09, 2004

*  Recent Topics

*  Fog Creek Home