January 29, 2020 Blog FileMaker Card Windowsdata entryFileMaker Communityread only Card Windows Dear FileMaker Community, I have a confession to make. As president of a Platinum-Level FileMaker firm that has been in business for almost three decades, you will hear me expound upon all of the amazing features that FileMaker has to offer the average organization, corporation or government entity. I am one to tout the awesome power of FileMaker’s reporting functionality and search capabilities. I’ve been known to brag about how I know just enough development to get myself in trouble. What you will never, ever hear me say, however, is that I love card windows. It’s true. Let me take a step backwards, and start here: Just because there is a fancy new way to do something in FileMaker does not mean we SHOULD build it that way or have to build it. Shocking, I know. Some of you wait until all the possible bugs have been worked out before implementing something new, and others of you are amongst the first to hop on the updated bandwagon. Either way, I am still seeing the implementation of this particular tool used improperly, and it saddens me greatly. Who here is old enough to remember the Dewey Decimal System? Remember the days where you’d go to the library and look up the subject, author or category on a card? You’d wander over to the card catalog drawers; read the info needed and be on your merry way. I believe that’s what card windows are intended for: read the info needed and be on your merry way. Card windows, however, have been out for a while now and I still see them being misused regularly, in my humble opinion. Just like the card catalogues, they are meant to present read-only data, not a place to enter new data. It’s not intuitive to a hardcore data entry user and requires too many extra steps. You have to move to your mouse and click into the newly presented field before entering the data. Then you have to close the window and move on to the next record. Or, you have to move your mouse over to “new record” and click on that before moving back to the field to click your cursor in again to enter more data. Signed, Frustrated Data Entry User Tl;dr: Card windows are for read-only data; not for data entry. Change my mind. By Kimberly Carlson
3 Comments Joe King Posted on 2:35 PM - January 30, 2020 Card windows inherently where not designed for read-only. If they where, I have failed to catch that point when I watched FMI engineers demonstrate card windows at Devcon and other events. If The FileMaker community has taught FMI anything over the years, is that FileMaker will find new uses for practically every feature. I like using Card Windows for Data Entry. I typically only have ‘data entry’ fields on the layout with no navigation or functionality buttons, just a ‘Save’ and ‘Cancel’ button. For new users, many do not understand when FileMaker saves data, so making this clear is not a bad thing. The save script/ button is also a very good place for data validation, contextual navigation, or audit logging. When a user is in a card window, this is one of the few times they are locking the record and/or blocking other users. It sounds like some custom menu items (which support alternate keystroke) may be helpful for you as a heavy data entry user. For example, control-s on a card window could save and close the window, or as another option, the save and close script cloud be added to the last field on the layout, so when you tab off the last field the window closes. The script which opens the new card window could easily include a ‘go to object’ script step to place the cursor into the ‘first edit table field’. I feel that card windows can be very useful, but they are not a ‘silver bullet’. I feel that consistency in a solution is far more important than whether a card window is used and in your case- a little bit more refinement to support experienced users may be time well spent. David Weiner Posted on 3:08 PM - February 3, 2020 I have to agree with Joe here. I think there are a number of ways that card windows can be useful, although they may not be as useful for dedicated high volume data entry as, say, purpose-built screens for a specific data entry process. But there are definitely some use cases in which a card window can be a BETTER data entry model than any other. For example: • Locked non-editable fields displaying data on a layout, that only become editable when you click an “edit” button to pop a card window. Now you have edit control and a “Save” or “Cancel” button. • Adding / editing data to related records without visibly switching contexts by popping a related record in a card window, allowing the data to be entered there, and closing the card. It’s much less jarring from a UX perspective than going to an entirely different screen and then making the user click to go back. Bruce Herbach Posted on 7:16 AM - February 13, 2020 My guess is you wanted to start a conversation here. Using card windows for display only is a very limiting use. Here you have a window with the correct context and record and access to everything the user needs. So of course entering new information is an ideal use for this window. Not to mention it is modal so forces the user to complete the operation before allowing them access to everything else on the original layout. It has become a great tool for me.