Tab bar limits

[Ugo DI LUCA]

I'm building my new database using a Tab bar interface.

Jumping from one file to another is so easy with this kind of interface, but it is difficult to determine if jumping from file A to file B should :

- drive you to a related record or not.

- drive you to a specific layout

I thought of a mini transparent button placed on the lower part of each "button" of the tab that would allow the user to either go to a related record or simply jump to the file showing all records, but this would work in a single user (the user knows that this button exists)

Are there some tips for building such an interface ?

[kenneth2k1]

Well, that would depend on what your logical flow of data is. I use a tabbed interface also, and personally I like it to go to a list view in the related file showing all related records, then they can view all records if they want, or do a search. Using a tabbed interface seems to suggest linear thought, where the current record would not change unless you change it.

Ken

[jasonwood]

"Tab bar interface"... what is this?

[andygaunt]

Hi Jason,

A tab bar interface.

It is simply a set of graphics that look like tabs at the top of the layout, that you use to navigate through a solution.

Kinda like the tabs on Apple's website. Each one can have a script assigned to it to change the layout, and anything else you want it to do. Makes it easy for the user's to see where they are (and where they can go)

HTH

[Ugo DI LUCA]

C'mon Jason ! Sure you knew what that was ! My apologizes for Tab bar instead f tabbed interface.

If not, with all the help you give on this forum, I would be curious to know the kind of interface you use.

[jasonwood]

OHHHHHH. Yeah I do that too. When I hear the word "tab" I think of the tab key.

I usually set up the "tabs" to simply go to the other database right where it left off (ie: no layout/found set changes). As a user I find that if I'm trying to go back and forth between databases, I get really frustrated when things keep changing on me.

If a button was going to go to another database and end up in a particular layout, I'd put that button in another logical location other than amongst the navigation "tabs".

[kennedy]

I've wrestled a bit with the same question.

And I think the answer depends a lot upon the semantic of the tabs vs. the logical data models.

However, given how FileMaker works, if you have a tab corresponding to most files, I think its typically best to use buttons in the layout for going to related records. I have a standard round button with arrow pointing right to mean "go to detail about the thing next to this". About half the buttons on each layout are these little arrow buttons.

When a user goes to a tab, then, he is either looking for a new starting point (since the typical workflows are embodied in those little arrow buttons), OR he's saying "go back to the X I was just on".

If you target the former (which may be the more "proper").... If you have small databases, it may make sense to always bring up the full list. However, if you have really large databases, that's not much use. Better is to bring them to a layout that is good for performing Find's... a detail layout. But then which object to show? Either the most closely related object (can be inconsistent in users' eyes) or the previously selected object (can still be bewildering). None of those choices end up particularly compelling.

If you target the "go back" reaction, then you simply want to return to where it was previously. And that can be comforting to users... particularly the users that just hit a button that took them somewhere they didn't want to go. However, depending upon your solution, it may rather perplex the user looking for a starting point. The key to avoiding that is to make sure that its clear from any layout how to get to the starting point in that file.

At least so far in my experimentation with this, I am liking the latter design... hitting the tab takes you back to where you were before... for my FileMaker relational DB.

[Ocean West]

Depending on the complexity of the solution you are building,

one thing you might consider instead of wrestling with a tabbed

interface (we all have done it) you might consider using a plugin

that will allow you to build REAL menu bar items and selections.

http://www.dacons.net/fmplugins/menucontrol

This will allow you to create a rock solid solution and also provide

you a valuable commodity, SCREEN REAL ESTATE. Tabed interfaces

when done right work great but in some cases can prevent flow

or break under certain circumstances.

I am planning a redevelopment with this plugin in mind as it will provide

not only a lot faster development (No more tweaking in Photoshop)

but add a great deal of SECURITY so you get two benefits for the price

of one ... Security AND Navigation..

SD

[Ugo DI LUCA]

I didn't know this plug-in. Thank you for this information.

It is true that I didn't imagine how hard it was to build an efficient interface, with explicit layouts and a logical navigation order. What could be logical for the developper is not always for the user.

I remember the first post I made on this forum. It was a pdf file showing my layout for my customer file. A layout with more than 15 tabs in the header (two rows !) . Having worked on this for nearly a week, I was almost impressed by my work (sometimes, it is good to be proud of our work).

When I came in the morning and display this new personalized layout to my employees, I assure you I wasn't very proud looking to their "laughing eyes". Some where nearly crying. They even didn't noticed that I had highlighted the rows (certainly one of the first tip every beginner here start with ), made a solution to sort the list (thanks to the guys working on aqua templates here in the Sample section). What a shame, what a disaster.

Now that FM Forums decided to create the attachment section, I ask the administrator to remove imediatly this post...please...

Nobody's perfect. Even my wife's spaghetti alla boscaiola wasn't really testing good yesterday night. If I can deal with that, I sure can deal with some laughing !

At least, nobody knows my e-mail adress.

Looking around on this forum, studying the structure of my favorite web sites, I just had discovered that the more logical display is a Menu Control.

And this is it. Menu Control.

For what I've seen from the example from MenuControl, it is effectively very frustrating to see that the almost best solution we can come with is using the menu of an application. It is so logical.

As a matter of fact, I was looking for a solution to achieve such a structure, using the resources of my FM Pro 5.5 with a 3 part layout rule (header, footer, and a personalized status at left), using portals only (no list views except for printings), where :

- a bunch of conditional value lists (that would show as menus) in the left side would trigger a script when selected (troi plug-ins), that would change second the file and layouts used.

- buttons at the footer for "usual" scripts for the file selected (print, new,...)

- a classic Navigation tab bar in the header

With my knowledge, non being a developper, I could have spent the 10 more years, until FM 25.02 would be released to have it done.

So I think I will really consider your USEFUL advice...