Start a new thread, lets talk about this one. I'm curious as to the use-cases.
It is number one request from developers, since 4 years.
I need it for layouts with not enough horizontal space (i.g. laptop, iPad) and a list with a number of columns is required. It is the same reason why horizontal scrolling in windows exists.
Thatâs not a use-case. I avoid horizontal movement as much as possible. Itâs not what tablets are built for, and they are terrible at it.
We have to build a true set of use-cases to make it worth the time to build.
Yes - we will get dark-mode 
No, itâs a feature. Technically, a portal is a window within a window that lacks horizontal scrolling - in FM.
With explanations like that, itâll never happen. We have to build a business case for it. Replying, âits just a missing feature everyone needsâ, just wonât help.
Iâm trying to help guide us to building a use-case that will actually make them want to do it. Because right now, your simple explanation can be handled with a webviewer and JavaScript.
We will never have it, business case or not.
I want to stick to @jormond request for use-cases because I see value there.
Here is what I would use it for:
- carousel looking display (single row, scroll left & right to display related data). A bit like slide pannels, but tied to data and not a fixed number set as an object property in the layout. I know some may say you can achieve that with a slider with 3 panels only, etc. but making a master-detail portal is also something we were able to do with tricks before they made it very simple. (All in all, I hope we agree feature requests are not about 'there is another way', but about 'there should be an easier way', I'm sure some people were grateful when repeating fields were introduced in the product back when there were no relationships, we still have to agree relationships are making a better job at this)
- Header or footer portal on a layout where vertical scrolling is already heavily used (like on a list view for instance)
- displaying something as an horizontal timeline
- anything that require related records to be compared side-by-side instead of top to bottom
- Reporting the customer expects the output to be horizontal (don't tell me you never had a customer ask you to flip the rows of your report into columns)
I guess I would start with that. I'm sure people can add to that list.
7 Likes
I agree with Bobino, though I would put the need for horizontal timeline above the need for a carousel, both would be very useful!
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
Grid has value as a feature for sure, but for context, this thread was started to look more closely into horizontal portals (mentioned in a different thread). Not necessarily to look at how different feature requests compare to each other.
@jormond's position seemed to be that he was somewhat unfamiliar with specific use-case because in his own work, he avoids horizontal movement:
Again, @jormond was seeking our input, rightly so, because simply saying we need feature x or y is not much help from the angle of product development.
Some developers get frustrated by the lack of horizontal portal in the product because (simply my guess here) it seems it would be simple to implement, borrowing from the existing vertical portal.
That said, a grid-like portal should be just as easy if they could mix and match the features we have to handle labels, with the existing portal. To @jormond's point, both yield very different use-cases.
I understand why my reply could seem off-topic. I guess my thinking was when it comes to horizontal-ality, grids are the most convincing use case.
The development of use-cases seemed to be an especially important point in this thread. I think we'd be far more likely to get horizontal portals as a subset of grids. Grids are ubiquitous (Google, Instagram, Pinterest), horizontal scrolling is relatively rare, especially outside of touch interfaces.
That's why I felt there was a parallel with back/forward navigation. You have a situation where not only can convincing use cases be made, but one could present it to FileMaker as being one stepped removed from another relevant feature (i.e. Snapshot links)
2 Likes
So the question that we end up discussing with Claris and the Product Managers is... Do we want Claris engineers spending time on ? The easy answer is 'yes', but that obviously has it's own cost. When the engineers, testing, and marketing are working through one feature, that means others are not getting done.
I'm not expressing an opinion on any given feature request here, but was thinking about how everything affects the platform long term. An example, features typically fall into one of 4 categories ( in my mind ):
- Help us build new things...
- Help us integrate with other services or frameworks...
- Help us with DevOps...
- Help make developing smoother and easier...
Some of these categories have a larger impact on the business of FileMaker, some have a bigger impact on the business of developers, some have an impact on the business of clients... and every mix of the 3 imaginable.
Ok...so to my original thought... ( this is just an example pulled from above ): Do we want engineers working on tools for us to make a grid functionality? Or would it be better for us to use technology that already handles most of that work, and it battle-tested? Examples here, JavaScript, micro-services, or other web tech. Again not expressing an opinion, just posing a thought to ponder. It's easier to have Claris build it for us to use, but is that worth it if, for example, that means we don't get "Responsive" layouts? This opportunity cost is happening every day at Claris, and the answer is not "double the engineering staff" the same as the company I work for can't double our developer workforce.
I don't know, just thoughts.
1 Like
Tablets are their own use case, but iPhone apps regularly use horizontal collections because you only have 300-400w pixels available, and you don't want users having to scroll a mile to cover all the content, or force them into a dozen levels of Master-Detail hell to browse everything.
Sliding panels might be a reasonable compromise, but they don't include behavior to create the right number of panels for a related set. If they were dynamic in this way, it would get folks 95% of the way there, for a lot of use cases. I'd like to see FMI at least do that.
Grids are more widely used in desktop or iPad apps, often for things like image or document collections. For FileMaker, I'd consider that a 'nice-to-have'. If I were leading the FMI dev team, I'd assign horizontal portals (or smarter sliding panels) a higher priority than grid views.
2 Likes