The case of feature requests

I would have a much easier time creating convincing arguments for grids. A portal with a defined number of records per row that scales with window width. Grids are how people expect to browse things like images (google images, Instagram, etc...) and, to a lesser extent, products. The keyword here is expect.

While I like to add all sorts of cool/interesting features to our product, I've found you have to start with a baseline solution that meets ingrained expectations: a solution that conforms to the basic language of digital interfaces. In that regard the other most glaring omission in FileMaker is back/forward navigation (like a web browser).

For the longest time, I tried to change my user expectations of how one "browses". Everyone 'requested' back/forward buttons. I put that in quotes because they didn't 'request' these things, rather they asked "where is the back button".

When I gave the explanation we're all supposed to give of why that navigation paradigm doesn't apply to a database, I'd get blank stares. Or a reply like "OK, but how do I go back to where I was?"

I finally bit the bullet and built back/forward functionality. Not back to the previous layout, not the previous record, but everything: layout, record, find, sort, etc.... It was tough, but oh man- I cannot imagine going back to the old way. Snapshot links unfortunately don't suffice, but they suggest that FileMaker is almost there regarding native back/forward support.

Of course no users were amazed by the new feature- it's just what hey expected. Not meeting those expectations leaves the absolute worst sort of impression.

A custom solution is simply not possible (to my satisfaction anyways) with grids. I'm aware of FM Gallery and I have the utmost respect for that product and its developer Nick Hunter. Nevertheless, grids are my #1 request.

They are the de facto method for browsing images on digital devices.

1 Like