Hi David,

Regarding my points #3 and #4.

#3 - It is jarring and out of character ... The tool bar is not 
neutral.  It has it's own colour and style scheme.  This may or may 
not go with a client dictated colour and style scheme when open in 
the balance of a program.

White would go a long way to helping. It is neutral.  That is a 
personal observation and probably taste.  Your comments on perhaps it 
being for the end user as deployed in their final product versus the 
developer, is right on.  It makes it really obvious that it is "The 
Tool Bar".  I like my final product to look as if it came from some 
sort of whole cloth.

So this one is a touchy feely thing.

#4 Regarding the placement of the Tool Bar at the top. I have clients 
wanting more and more to show on a single screen.  This is especially 
true if their employees are good computer users. A full interface 
with good mix of serial and lateral navigation (a) makes work flow 
very efficient and (b) reduces the learning curve on the program. 
This makes every inch of the screen real estate valuable.

However, I believe that to a large extent current screen designs are 
consumer driven, specifically to give wide screen media reproduction 
on the computer screen. With the exception of bookkeeping, where for 
ledger purposes, the wider the better, even though we talk of a 
paperless society, business is paper driven, specifically letter and 
legal size, portrait orientation. That makes some screen real estate 
for FileMaker usage more valuable than other parts of the screen. 
The, depending on paper size where you are, 8.5" swath down the 
screen with maximum depth to minimize scrolling is the real estate 
used for WSIWYG forms. In some applications divorcing the data entry 
from the final form is fine.  In others, seeing the actual form on 
screen with a minimum of scrolling is very important. This is The 
Prime FileMaker application screen real estate.  Unfortunately, this 
is also, at the top of the screen, where the tool bar resides.

Dave

>Hi Dave and Steve,
>
>Thanks for sharing. 
>
>Dave...
>
>I can appreciate your annoyances, particularly your point 2.  They 
>got the automatic window resizing a bit messed up, and hopefully 
>will fix/improve that in a future version.
>
>You also said:
>
>>  Also, I confess to not knowing that it could be customized. The 
>>big thing would be could that customization be scripted?
>
>And Steve you said...
>
>>  It seems this is not a setting that we can script. Do I assume 
>>that it also is not saved with the file? So a user can alter the 
>>setting at will...
>
>No, it can't be scripted as far as I'm aware, nor is it saved with 
>the file I think - or at best, if it is, it's certainly overridable 
>by the user.  I believe the point of it is (as mentioned by someone 
>else earlier today) to leave that stuff in the users' domain as it 
>is with every other Mac program. 
>
>It really is just the standard operating system functionality that 
>is available there.  It's FMI trying to bring FM more in line with 
>modern applications... right?  (Though why did that have to take 8 
>years??!)
>
>
>As a user, frankly I hate it when some applications have some custom 
>toolbar implemented that is out of character with every other Mac 
>program.  Usually it's the apps written in java or other common-code 
>cross-platform apps - developers trying to provide the same 
>interface across platforms on their apps, or just porting an ugly 
>windows app over to the Mac as is, instead of building each 
>platform's version of their interface in line with each platform's 
>native GUI.
>
>So really, perhaps we developers should not be enforcing a 
>particular view of the toolbar on our users.  The users' ability to 
>customise the toolbar however they want is there with every other 
>Mac app, and so it should be there with FileMaker.  That said, to be 
>honest, I don't even think the toolbar is meant to be for us 
>developers. 
>
>I believe FMI's target market falls into two distinct groups:
>
>1. Developers like us, and our clients, who together use FileMaker 
>Pro as a tool to build custom applications - users of which from a 
>practical point of view, may not even even need to know or care that 
>their apps are written in FileMaker any more than they care that 
>Microsoft Word (I believe?) is written C++.
>
>2. The market that often we developers seem to forget - more "basic" 
>users who *don't* engage us, but use FileMaker as its own 
>application to organise their own stuff.  A glorified Bento.  A 
>graphical and data oriented Excel.  Or even just like the Address 
>Book & iCal for that matter.
>
>It is my belief (and the only thing that really makes sense to me) 
>that the toolbar is there primarily for group 2. Given that (1) it's 
>a damn sight more flexible than the sidebar used to be, and (2) now 
>finally it has been brought inline with the OS by having a toolbar 
>instead of a sidebar, surely it's an improvement, right?
>
>But maybe it frustrates us developers, because it's just pretty and 
>useful enough to tempt us to incorporate it into our apps (to save 
>us having to build some of our own custom UI), but it's just not 
>quite flexible enough.  It's an end user tool and perhaps it's *not* 
>meant to be a development tool, but it's close and so if only they 
>could just go that extra bit so it could be...?!
>
>Would that be an accurate description of our frustration as developers?
>
>
>All that said, what I still don't understand is your (Dave) points 3 
>& 4 (which I know aren't just your own).  Aside from its quirks 
>mentioned in your point 2, why is it that a toolbar at the top of 
>every other Mac window doesn't offend, but the toolbar at the top of 
>the FileMaker window does? 
>
>That's the big bit I don't get.  My apologies if you answered that 
>and I missed it.
>
>
>
>David Thorp
>All About Abundance Pty Ltd
>Sydney / Brisbane.  Australia.
>[log in to unmask]
>ph:	+61-4-0558-8065
>fx:	+61-2-9475-1444
>
>
>
>On 12/12/2010, at 7:40 PM, Steve Cassidy wrote:
>
>>  On 12 Dec 2010, at 06:08, David Thorp wrote:
>>
>>>  Still, setting the icons to small and removing the text does 
>>>indeed reduce the screen real estate issue significantly.  In 
>>>fact, I'd argue that with it set to show icons only and set to 
>>>small icons, the toolbar takes up no more space than it used to
>>
>>  David
>>
>>  Thanks for noting this. It's new to me, too. I've barely used FMP11 so far.
>>
>>  It seems this is not a setting that we can script. Do I assume 
>>that it also is not saved with the file? So a user can alter the 
>>setting at will...
>>
>>  This reduces its usefulness somewhat. You could design a layout to 
>>fit a screen size based on the minimal (say Text Only) toolbar, but 
>>the end user will likely be using the default (giant icons).
>>
>>  Or am I missing a way for the developer to take control?
>>
>>  Steve
>
>...AND...
>
>On 12/12/2010, at 10:33 PM, David McQueen wrote:
>
>>  Hi David,
>>
>>  As another poster said ... It's annoying
>>
>>  1. I don't run programs with the status area open in general.  The 
>>only time I wanted it open would be for a continue/cancel button. 
>>With the side bar it was front and center.  Now it it hidden away 
>>on an expanse.  Even if it is another colour, it is small and not 
>>front and center. If I use it that way, people hate it.
>>
>>  For people who do want to run that way and have a whole lot of 
>>things visible,I imagine it is a whole different kick. Also, I 
>>confess to not knowing that it could be customized. The big thing 
>>would be could that customization be scripted?
>>
>>  2. I run my programs in "adjust window size to fit" mode, not 
>>maximized.  On Windows this does not make much difference unless 
>>you also scale down the FileMaker window, but on Mac it leaves easy 
>>access to what is behind the open program on the desktop.  This 
>>leads to two more annoyances:
>>
>>  a.) When I flip the status area open, the layout does not drop 
>>down properly and I have to manually pull the window down larger to 
>>see the full layout.
>>
>>  b.) I have some layouts that are page width.  When I drop open the 
>>status area with these layouts, only part of the tool bar will 
>>show. So not only do I have to pull down the layout to make the 
>>window larger, but I have to pull it sideways too.
>  >
>>  Do this 100 times on a heavy development day and you are just ticked.
>>
>>  3. It is jarring and out of character with the rest of the program.
>>
>>  4. In a good design context, it should occupy "spare" screen real 
>>estate. With current monitors, that real estate is located at the 
>>side of the screen, not at the top or bottom. This offends me, 
>>especially as that is the way it used to be.
>>
>>  So there is nothing terminally wrong with it, but I don't find a 
>>whole lot right with it either ... OR ... I am looking for it to be 
>>less than what it is and find the features out of context and in 
>>the way for what I am doing.
>>
>>  Justy my $.02 CDN
>>
>>  Dave
>>
>>  --
>>  David A. McQueen
>>  LICHEN Software
>>  705-720-9022
>>  www.lichen-software.com
>>  Little Helper 2.0 Now Released

-- 
David A. McQueen
LICHEN Software
705-720-9022
www.lichen-software.com
Little Helper 2.0 Now Released