Re: Buttons to navigate forms

[Murray Cumming <murrayc murrayc com>]

Please use reply-to-all with mailing lists instead of just replying
directly to me.

On Thu, 2010-03-04 at 18:44 +0100, Frederik Vande Rieviere wrote:
> I'd also like the idea to see the navigational functionality thats standard at the bottom of the screen, to 
> be be available in any button.

Could you give me an example of when this would be useful, just so I
know that it would be meeting a real need? Could you give examples for
the other things too, please.

>  Also new/delete and maybe have more like duplicate.

>  That would allow you to place those buttons anywhere you like, instead of having them fixed in one place.

I wouldn't want to move the standard navigation buttons though.

> > > Those would be very useful. If not possible already : i'd like a
> > > functionality where you can set the editable status of a field, so you
> > > could have a non-editable field with an "Edit" button next to it,
> > > which renders the field in an edible state when clicked. Very handy
> > > for a kind of "first off" protection for certain critical fields you
> > > don't want to have edited unless absolutely certain.
> >
> > Whether a field is editable is normally controlled by the users'
> > privileges in the Users/Group window. Couldn't we generalize this into
> > some generic "Warn the user before allowing them to change this field's
> > data" checkbox?
>
> That would render the "button" of the edit feature into the entire field,

I'm not sure what you mean, but there's nothing to stop this feature
being implemented as a button next to the field, just like date fields
automatically have calendar buttons next to them.

However, I wonder if this would be best as just a confirmation dialog
when you enter the field for editing.

I'd also like a real world example so I can think about this more.

>  rather than a small button next to it. I was looking to use such functionality for a quite large field, so 
> behavior like this would be quite annoying for my application. Might be a good idea for other purposes, 
> though.
>
> Instead, what about adding a flag to a field, something like "standard not editable" (but better worded), 
> and when a user is allowed to edit the field, render an "edit" button next to it, so he can click it and 
> modify the content?

Right, that's what I meant above.

> > > I'd also like fields with scroll bars for bigger text blocks.
> >
> > Good idea. That should be easy. I'll try.
>
> Other field items you might consider : radiobuttons and checkboxes. 

Boolean fields are already presented as checkboxes.

For radiobuttons, that could be an extra formatting option for the
existing Choices option. At the moment, it just uses a drop-down list,
and can force the user to choose one of the items from the list.

For multiple-choice checkboxes in one field, I can't imagine what result
this should have in the actual field value. For instance, if I click
"foo" and "goo" in a text field, what is the text value of that field. I
guess that separate fields make more sense.

> > Yes, the drag-and-drop layout is still not mature.
>
> What I do like about it is that its scales with the window, its better that way than having a good fixed 
> editor that doesn't scale (like with older filemaker pro apps)
>
> Newer Filemaker Pro versions have an interesting idea with anchor points, which both work horizontally and 
> vertically.
>
> I'd also like the ability to disable the list tab, and to rename or the details tab or to disable tabs 
> altogether. Or even better, allow them to be used as layout modes, instead of having them fixed within the 
> application.

Again, I'd like some real world example. 


-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com