dbTalk Databases Forums  

Skinning a FM solution?

comp.databases.filemaker comp.databases.filemaker


Discuss Skinning a FM solution? in the comp.databases.filemaker forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Wes
 
Posts: n/a

Default Skinning a FM solution? - 07-07-2004 , 01:43 AM






Has anyone ever tried to 'skin' their FM pro solution?
I tried an interesting experiment by accident, and now I want to
expand on the idea. I envision a set of buttons made out of images,
that get replaced based on a users preferences. I'm curious to know
how many controls can be changed or manipulated based on a 'theme' or
'skin'. Are there any tools that can skin controls already?

Thanks.
------------------------
Wes
http://www.LostPants.com
"we build applications to help
you keep your shorts!"

Reply With Quote
  #2  
Old   
Lynn allen
 
Posts: n/a

Default Re: Skinning a FM solution? - 07-07-2004 , 01:53 AM






Wes <wchester (AT) lostXXXpants (DOT) com> wrote:

Quote:
Has anyone ever tried to 'skin' their FM pro solution?
I tried an interesting experiment by accident, and now I want to
expand on the idea. I envision a set of buttons made out of images,
that get replaced based on a users preferences. I'm curious to know
how many controls can be changed or manipulated based on a 'theme' or
'skin'. Are there any tools that can skin controls already?

It's mostly a pain in the ass. One can keep globals full of images, or
repeating fields in a 1-record preferences file. I even built a system
whereby users could pick their own header and body colors (from a
limited selection) which were popped into container fields as the user
logged in.

It's necessary to keep user records for this, track their prefs, give
them access to change their prefs, and put these fields onto every
layout. Then you need to make the fields non-printing or provide
separate printing layouts. Mostly, it's a lot of work for very little of
FUNCTIONAL value to the user. As for different icons for each user, it
makes it confusing and difficult to write documentation or training
docs, since one user may not SEE "the button with the little printer on
it."

I've gone very minimalist and Zen with my interfaces, using soothing,
neutral colors, as much white space (or very light gray space) as I can
get on a screen, and mostly small text blocks instead of buttons or
icons. I may put in a Home icon, but lately, not. Just a small Verdana
9pt "HOME" in a mildly contrasting color. Looks amazingly good. Since
most icons have to be labelled anyway to make sense to new users, why
not just go for labels only? Pay good attention to consistent screen
position, and after a short time, words are as good as pictures.

Lynn Allen

--
Allen & Allen Semiotics www.semiotics.com
FSA Associate Filemaker Design & Consulting


Reply With Quote
  #3  
Old   
42
 
Posts: n/a

Default Re: Skinning a FM solution? - 07-07-2004 , 04:22 AM



Lynn allen wrote:
Quote:
Wes <wchester (AT) lostXXXpants (DOT) com> wrote:


Has anyone ever tried to 'skin' their FM pro solution?
I tried an interesting experiment by accident, and now I want to
expand on the idea. I envision a set of buttons made out of images,
that get replaced based on a users preferences. I'm curious to know
how many controls can be changed or manipulated based on a 'theme' or
'skin'. Are there any tools that can skin controls already?



It's mostly a pain in the ass. One can keep globals full of images, or
repeating fields in a 1-record preferences file. I even built a system
whereby users could pick their own header and body colors (from a
limited selection) which were popped into container fields as the user
logged in.

It's necessary to keep user records for this, track their prefs, give
them access to change their prefs, and put these fields onto every
layout. Then you need to make the fields non-printing or provide
separate printing layouts. Mostly, it's a lot of work for very little of
FUNCTIONAL value to the user. As for different icons for each user, it
makes it confusing and difficult to write documentation or training
docs, since one user may not SEE "the button with the little printer on
it."

Another significant issue that Lynn didn't mention at all is that when
moving from record to record on such a setup, the 'field' based layout
objects must be refreshed. On slower computers over a network this can
slow the application down significantly, and can cause irritating screen
'flicker'.

Quote:
I've gone very minimalist and Zen with my interfaces, using soothing,
neutral colors, as much white space (or very light gray space)
Hmmm... to each their own. I prefer subtle too, but I'm not afraid of
colour. A screen shouldn't be garish, but it needs to be engaging and
interactive... you don't want your users eyes to slide right off it

Quote:
as I can
get on a screen, and mostly small text blocks instead of buttons or
icons. I may put in a Home icon, but lately, not. Just a small Verdana
9pt "HOME" in a mildly contrasting color. Looks amazingly good. Since
most icons have to be labelled anyway to make sense to new users, why
not just go for labels only? Pay good attention to consistent screen
position, and after a short time, words are as good as pictures.
I disagre. Labels may be required for newbies, but eventually they will
respond faster to the icons. They aren't just 'eye-candy'. That said, I
minimize icon use myself, as in many applications coming up with
intuitive icons that are only one one layout is a nearly pointless pita.

But home, reports, print, delete, etc..using icons is a good thing.


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.