One of my big priorities for BaseElements 3 was to reduce the number of objects on each layout to reduce complexity, and make it easier to work within BaseElements. There is a lot happening in BE, and trying to make things clearer will always help.
First, no more id fields.
One of the first things I thought about was the id fields. These aren’t real fields or details in FileMaker, these are the internal ids that FileMaker generates for every object (layout, script, field, TO etc) that users never see until they run the DDR. We import these and use them for matching of related records.
In BE 1.0 the ids took centre stage, they were listed first, before the object name itself. I realised that this wasn’t necessary, and in version 2, they were moved to the end of the item, as well as being removed from the portals altogether. You never needed to see the ids in a portal to understand what was going on, so removing them just meant I could show more detail in portals.
So in version 3 I was thinking about them again, and decided that they didn’t need to be on any layout at all. I’ve almost never used them, but if they’re required for one particular use case, then the fields are still there and whoever needs them can just add the field to the layout as required. ( There is full layout access in BaseElements )
I think this is wise, as 99% of the time, they’re not used, and take up space and make everything else harder to work with. For the 1%, they’re still available on demand whenever needed.
Second, the “Items that use this” count.
The other item I didn’t like was the counts for “Items that use this xxx” or “Items used by this xxx”. For example this one in the fields layout :
This takes up a lot of room, and doesn’t provide a wealth of information, considering that in most cases more than half of the totals were empty. When I started doing conditional formatting on the tabs, I realised I could easily use that to display the “in use” or “not is use” status that these counts were taking up. There were two other functions that these fields were showing : the actual number, and the quick link that you had by clicking on the field label to go directly to that item.
My first attempt was to try to build the count into the tab name itself. Because it’s a field not an actual tab name, that could work, but I couldn’t come up with a format that looked good and displayed the right level of information. In the end I went back to think about it a little more. The critical thing is whether or not there are related records, the actual count is almost superfluous. If there are 3 or 30 it’s not important as long as you know they are there. So the highlight works well enough, and I disposed of the counts.
The only other thing was the quick links. I haven’t yet put these back into BE3. I’m not sure if there is a good way to go about it. You could have the ability to go directly to a list of items by option clicking on the tab or something similar. The only issue is that I’m alreading using option, shift and command clicking to do different things with GTRR so it may confuse things. And there isn’t any sort of user interface convention that does this that I know of, so it would be a very non-obvious feature. I’m still considering options there…