Hierarchies in FileMaker

Wrote an whitepaper on how to implement hierarchical structures in FileMaker 8 or above. Here's the PDF and a sample FileMaker file.

Does anyone know how to suggest whitepapers to FileMaker, Inc.?

Comments

[David Graham]

Are you an FBA member? I'd start with the Technical Liason and he'll point you in the right direction.

I skimmed the white paper and found this bit at the end interesting:

"What about a tree view in a portal? I have no idea how to do this. I don't do this myself, because showing dynamic content in a portal means the portal must be filtered and I consider this a bad practice."

I've found that almost universally the need to have a hierarchical structure coincides with a workflow that makes list views impractical. As a result, I've always built mine in a portal. Why the you consider filtered portals bad practice?

- Dave

[m.edoshin]

Thanks, Graham; we'll try to go this way.

About filtered portals: I hardly ever use such portals at all. That is if a list of related records needs to be filtered, I find it simpler to display these records as a list (perhaps in a separate window) and use search and sort tools to get whatever filtering is necessary. This is simpler to set up, more flexible, doesn't require compound keys, and the main portal remains usable for searching.

I'm also rather skeptical about portals that are meant to be interface-only widgets. E.g. like a list of elements on the left of a form, as in iTunes, a “global” list, not related to a particular record. To me it's somewhat unnatural to FileMaker :) I believe portals were not meant to be used this way, so such a setup makes me jumping through too many hoops.

It's not that I never use this, but by default I don't, and it normally remains so, unless a filtered portal turns out to be absolutely necessary.

[Matt Petrowsky]

Here's my opinion on portals used as interface widgets.

If you limit the use of portals to data only [as a practice], then you somewhat have to concede that you're willing to limit your user interface in terms of capabilities. Regardless of what the developers' original intent was for portals, the fact that they can be used for a variety of things (such as interface and user environment tools) means they should simply be considered a "display tool", not an intended "data display tool".

Whether you are using them to display user functionality/features or data, the degree to which you might apply logic such as "Using a portal for interface display adds to network overhead for the solution" is an argument which should be addressed on an as needed basis [1], not because of perceived intent. While it's true that additional table occurrences to the graph, for the purpose of display portals, adds to interpretive overhead, clear naming conventions and good organization will always tend to remedy this problem.

The beneficial functionality of using portals for interface display lend themselves well to facilitating a more useful interface. I venture to quantify this by the example of using a portal to show possible user actions (create, delete, duplicate, etc) and being able to control the visibility of those actions based on user privileges.

Anyway, my take is that they're there as a tool to facilitate how the solution works as a whole. If they work for data and I can use them for interface, then it's unlikely they'll [fmi] take them away or change they way they work so drastically that it breaks their use as interface widgets.

Matt Petrowsky
http://www.filemakermagazine.com

[1] Plus, the number of options you show within a portal for the purpose of the interface are typically quite low and any overhead acquired as a result, is ( in my opinion ) mitigated by enhanced usability ( which already suffers due to the lack of such UI based usability tools which would [should] be native to Layout mode).

[m.edoshin]

Hi Matt,

I once saw a FileMaker application that used a name of a value list to drive a portal. There was some special function to examine a layout, find fields, get their value list and depending on what it was, change portal contents. So a value list technically can be used for this purposes, but I don't think this should be a recommended practice :)

That is in many cases I see that developers try to make portals to replace functionality that already exists. Maybe in slightly different flavor, but it's still there, and normally is simpler and easier to use than what the developers get as a replacement. This is especially obvious with filtered portals that are used as a search tool: their best result doesn't even come close to what is possible to achieve with a plain list view in find mode. And even this little result requires ten times more work to set up.

Same for interface-only portals, I think. E.g. if want some users to add/delete records and other users only to view these records, I'll set this in Accounts in Privileges. Then the New, Duplicate and Delete commands in my custom menu for this layout will be enabled or disabled automatically depending on the current user's privilege set. And not only these commands, but also buttons on the toolbar and matching commands in the context menu. To me this is more simple than hiding or showing buttons using some combination of artificial portals.

I cannot say that the set of FileMaker layout tools is perfect. But adding more tools or making them more sophisticated means adding more complexity. And everyone uses FileMaker exactly because it is not complex. Despite of what developers say, by the way :) Really powerful but complex features, like XSLT transformation, or custom menus, seem to get underused. So I perfectly understand why FMI is so conservative in their changes :) It's not possible to just add and add features, because the target audience doesn't want features, it wants simplicity. And adding more simplicity is very different from adding features.

[Allen Poole]

Thanks, Mikhail, for sharing this nice work on user interface & automation for hierarchical data. I'm working on a related project, and I wonder if you have any resources to direct me toward.

I'm working on a data model to support a complete taxonomy of foods, from raw ingredients and the seeds/juveniles they grow from to complex processed foods that include complex ingredients, multiple processing steps, and branding & ownership. I believe the data model for such a classification system must include a hierarchical component, but there must also be a way for nodes to be associated with nodes on other branches, and for different categories to be applied to nodes on different branches and at different levels in the hierarchy. If you've worked on something similar and would be willing to share your thoughts, or if you can recommend a favorite reference on theory & implementation of complex systems of classification, I'd be much obliged!

Allen Poole

[m.edoshin]

Hi Allen,

Yes, it seems that at least ingredients are truly hierarchical. Or, rather, not ingredients themselves; an ingredient may belong to more than one product, so they should be kept in their own table, but links to them could form hierarchical “recipes”. And, perhaps, a processing step may be a part of a recipe similar to an ingredient.

But I don't think that there could be a ‘proper’ model of such stuff, because it all depends on what the system is expected to do. It's just too easy to over-engineer a solution :) Feel free to write to me to talk about this in more details. Here's my email: m.edoshin at mac.com.