Name ONE Good Reason To Upgrade to FMP 16

I know I'm going to do it eventually, but I'm one of those cautious (or perhaps lazy) people who usually waits for a month or two for all you early adopters to do the gamma testing for me and for FMI to issue its x.x.1 bug-fix release before I take the plunge on all the various machines I superintend. But perhaps there's some hot new feature that's so compelling that I just shouldn't wait that long this go-round.

Make the case for me. What is there about FMP 16 that's so good I should just leap at it right away? And why?

Just ONE thing, now; we don't need a lot of fanboy gushing on this thread.

And if you want to identify something that should warn me off about it, start your own thread.

However, we will not move any of our clients to it until the first patch is out as we know there are some issues with it.

We have clients that will not need any of the new features unless they ask for a redevelopment or some new features that would be done better in the new version.

It makes sense for some people and for some it doesn't.

I can say that the pre-release version helped me restore a bunch of value lists I deleted from the wrong file, using the new 'copy value lists' feature - a seemingly minor thing but saved me as a developer a couple of hours.

I'm hardly an FMP fanboy, but 16 looks like a great release to me. IF you need the features.

Having said that, there's nothing in 16 I really need to have or that would make me that much more productive so I'm not currently planning to upgrade. Check out the videos and materials here and decide if it's worth it for you.

Of the 60 missing things I would like to see in FMP, I've only removed one of them (Data Viewer limitations) from my list and slightly updated two others. I still can't adjust font size in the data viewer so it remains difficult to read on a high-res MBP requiring me all the time to move the DV window to another monitor. And, (within FMP itself) there's still no SQL assist or being able to type SQL without using ExecuteSQL. The new DV only pastes the ExecuteSQL template into the DV window. I still have to type in the query and there's no assist there at all.

I don't mean to sound negative (because FMI clearly did a lot of good work in 16 for users who have different needs than I) when I say I'll probably wait for 17.

Name one good reason not too? It's one of the best versions they have ever released which should be obvious if you have followed all the news about it. SDI on Windows is probably the best one since it finally makes it useable on the Windows platform and costs nothing to implement. Cloud /JSON integration would be two for me and then the new card windows.

I'm on FM14 now, Cards is the main reason I want to move to 16 (Look and feel, plus enhanced speed as this will allow me to get rid of some very slow portals I have)

The main reason I will not be upgrading is, too many bugs and I HATE the new script step to hide menus. This is a disaster, as far as I am concerned. My previous pop ups that worked well are now all broken and when I add a script step to hide menu in that script it does it for my solution instead of just on that window.

+1 Lee!!! I have 3 clients that jumped right on the first version of FMS 16 right away so they could get rid of robots running FMP on the same server to generate PDFs. Now FMS can do that in service side scripts (schedule scripts, PSoS, etc.). I usually like to wait for the first .1 version to come out before upgrading production systems, but this feature alone impacted several of my clients big time.

If you are working professionals with FM, either developing or superintending, you should be updating in order to familiarise yourself with each new version, even if you want to wait a bit before advising it for those your superintend.

Jim Brear, I'm afraid I see your SDI complaint differently. There is no way I would go back to not having SDI windows for the complaint that you have. Solutions such as including a navigation button that scripts closing or hiding all windows, etc. Not to mention if you want to just see your desktop, then hold down the Windows and hit "D". Or you can design the User Interface to stay in the same Window. All of these are in your control as the developer.

The feedback I have from my clients so far is that they love having multiple windows that they can put on separate monitors, etc. It is a real winner with all of my clients so far. You are the first person I've heard complain about the new SDI and I believe your complaint can be addressed with scripting.

I guess I was just really surprised to hear this complaint since it had been so requested by many people over the years.

I think you should let your clients try it and see which they prefer and get feedback from them on which they prefer.

I can't duplicate your issue or I don't understand your issue. I click the minimize buttons on all the Apps then you can see the Desktop. Alt+tab will let you switch between the apps easily and the Windows + D takes you to the desktop.

Having come from an exclusively Windows-based development environment for 8 of my 10 years working in FM, I can see that there will need to be a shift in development patterns. There are several items you don't worry about, or think about, when your file windows are trapped in a limited space ( the Application window ). I know I had undergone several design pattern changes when I started working more with Macs, and for the most part, only on Macs.

I don't think it's a bad thing, long term. Though short term, I can see how there will be a little bit of pain. In the big picture, it has the ability to vastly improve control and designs for those on Windows.

The main reason I will not be upgrading is, too many bugs and I HATE the new script step to hide menus. This is a disaster, as far as I am concerned. My previous pop ups that worked well are now all broken and when I add a script step to hide menu in that script it does it for my solution instead of just on that window.

can't you just disable the "Menu Bar"-flag under "Window Options" on the "New Window"-script step? This works by window, so you don't need the "Hide Menu"-script step...

If somebody has a workaround (which should not be Necessary) I would like to know about it.

As I wrote in another place, whilst I really like the new behaviour on PCs, I too have clients for whom having multiple windows visible will be at best a confusing change and at worst - well who knows (it depends how well I programmed things in the past!)

I guess you could mimic the old behaviour by hiding all windows except the one you want to be active. Perhaps a script something like this would help

I totally agree. Some short term pain, especially with older solutions, but it will be worth it. It reminds me of the 6 to 7 upgrade a little; some things that were implicit are now explicit - we now have more control, but also more responsibility.

Overall, I am very excited about this release for both platforms - I just wish i had some more time to 'play'

Hi Jim, not sure I'd consider it a work around per say, because really the issues speaks to the differences in the way the MacOS operating system has always handled multiple windows for a given application vs. ways the Microsoft Windows operating system handles multiple windows: the vast majority seeming to be a multiple document window model since Windows 95 and a single document window model for most applications in Windows 3.11 and prior (FileMaker 15 and prior for Windows being a somewhat rare exception in sticking with the single window interface in the Microsoft Windows version).

So, if you want to hide all windows of common application in Windows (sorry, only tried on version 10, can't speak to other versions) you can set the task bar option for "Combine taskbar buttons" to the value "Always, hide labels."

Then, fire up as many windows of FileMaker Pro 16 as you'd like, then SHIFT + right click on the grouped task bar item, and you'll see an option to "Minimize all Windows" and it will minimize all windows for that app, having basically the same effect as "Hide FileMaker Pro" from the FileMaker Pro menu you referenced. Which, since it is really an operating system function, can also be achieved by right clicking the application's icon on the dock, and clicking hide.

Task bar setting:

SHIFT + right click on a grouped task bar item context menu:

Conversely, once a group is minimized, SHIFT + right click a second time and the "Restore all windows" will become available, and will put all the windows right back to where they were prior to their being minimized, the functional equivalent of clicking a Mac application's dock icon after performing the hide command for the application.

Since I can do just about everything already using FMP 14 that 16 has, to me, 16 is at most a $99 upgrade. I would gladly pay that.

I realize I'm in the minority so please don't be put off by or upset from my response. There's a real value proposition in play here. And, while I think 16 is a solid release, and clearly a lot of hard work went into it, it doesn't have things I needed or had hoped it would have in my (now) 61 missing FMP features.

Users just want to get their jobs done and not look stupid in the process. That's a basic point Alan Cooper makes in his About Face user interface book as in well-designed software that doesn't frustrate users, etc. Thus, to your point, if users are productive and getting their work done with 13, why implement a new look and feel unless it adds exceptional value and the loss of productivity while users learn it will be offset down the road with that feature?

It may be no consolation, but I have a group of 25 users who can't get off their Visual FoxPro 9 application. VFP has been dead now for going on 10 years. The cost to convert it to FMP (probably a year's effort with all the framework code and other logic, reports, etc.), then host on FMS, then buy concurrent licenses is a total non-starter. So, they just keep plugging along...

If your users don't have the budget for or are not interested in further development of their system then they can stay on what ever version they have now for as long as they like I suppose. I still have a few customers on 11 and one on 10 because of special circumstances. If however you want to continue to innovate and maximize your investment in the platform you should upgrade as as soon as it makes sense from a compatibility and scheduling stand point. Most customers should be on an annual agreement anyway so they already own it in most cases so why with hold it from them?

No release of FM will EVER have all the features any of us would want. This release though in my opinion is significant and adds real value for those that want to take the time to utilize it. I suspect the next few releases will follow the same pattern to best not to fall too far behind.

Hardware does die, has to be replaced, new hardware comes along with - let's say - "Sierra", suddenly you get black windows instead of the fully rendered search windows you used to get 500 times a day, you call Siplus.

Or you read about Siri and upgrade to Sierra because it's sexy, and your FMP 12 starts misbehaving. First thing you do: you call Siplus.

I think to some degree, there is also a side of the conversation that says you may realize more value as you use the features. I know as we look at features we need to add or enhance in our custom app that runs the entire company, the new features in 16 have opened up a lot of possibilities. Ones we may not have thought of, had we not been using 16.

I was really saying I could implement (and integrate with FMP) all the features (JSON, etc.) externally before 16 came out and already have with some of these features, plus I've added word import/export, and other cool functions.

Again, I'm not taking away anything from 16. It's a great release for some. Just not what I wanted or needed.

As I said, it's important to understand life cycles and perceived added value for customers.

They ask me "what does going from 13 to 16 bring me" and I HAVE to say: "as a matter of fact, nothing" because I did not implement anything yet based upon 16. I still don't have refresh portal instead of refresh window (flush) all over - a FMP 14 feature - or placeholder texts or bullets in specific input fields. Why ? Because for me the user is spelled all caps and I don't want to ruin my relationship towards her/him by forcing a unwanted / unexpected / useless expense.

Apple and Filemaker deciding to bring out a major release every year no matter what is total nonsense, it's just bragging and marketing, the end user is frustrated, puzzled and - top of worse - stressed by this policy.

No news, good news is the refrain for my users. They want stability and tradition, they want to use the fast path, which is the one they know, not the faster one they have to erase brain in order to use.

Exactly ... Users could care less about "new features" and want more "USABLE", easy, software not software with more USES (aka, features). Familiar = good. New = bad. It's almost that simple.

If I had just a nickel for every time I heard at some "DevCon" (different companies/technologies) that ... "wow, this spanking new feature x" will make your life (the developers' lives, of course, presumably) sooooo much easier. Yeah, right! (Still waiting ....)

At least I have you as a new friend in the upgrade non-hysteria minority!

Apple and Filemaker deciding to bring out a major release every year no matter what is total nonsense, it's just bragging and marketing,

To some extent that's true, but for me the bigger question is this:

Are you not better off making incremental changes year-by-year, even if they are minor, instead of having to make a much bigger change when the hardware is no longer supported, or when you get that gung-ho feature that will make an huge improvement in efficiency or UX?

These can force a major redesign and thus be far more disruptive to end-user experience and interim productivity.

As an in-house developer I find it MUCH easier to stay current so that I can implement gradual change as and when it's appropriate & beneficial. The latest release is a genuine winner on that score card.

Software development is also about moving ahead with the tools you have. So in almost all cases, this is how we proceed:

For an existing, static, user base, you develop for the lowest common feature set. For older, existing, solutions, that will involve a little change as you develop new features. In some cases, you will be able to shift those clients to new features that you, as the developer, can provide. Because you have new tools. And if nothing else, you can be more efficient with what you do deliver.

For new clients, you can open the throttle a bit. And provide them with a larger set of options to satisfy their needs. In my experience, these clients will get the most feature rich custom app.

For existing, but more dynamic businesses ( the younger generation of business owners, and well-established companies with an open mind ), there is opportunity to add-on to what they have. Either expansion of the existing custom app, or redesign of something existing, that doesn't quite fit the current workflow. This user base is the most common I've run into recently. Though it's in close contest with #1.

At any given time, it's not uncommon to be working with clients in 2 or 3 of these three categories. It certainly isn't going to always be a significant value-add for every client. And not even for every developer. But after having worked with 16, we are finding the possibilities, pretty impressive. Some features we thought were ok, but not great, have been a bigger deal that we first thought. Other features that I thought were great, were, well, fantastic. The performance, developer value-adds, and the UX we can provide with the tool set in 16, has had an overall positive impact on our users. ( bug-squashing is happening faster, new features are being delivered quicker and with higher quality, and common actions of the users are snappier ). That has been our experience.

See, in your second paragraph you already use the term "change" twice.

Psychology 101: change is detrimental.

Practically: When you have something like 100 filemaker servers serving 2 to 50 users each and incoming challenges like QR-based invoices or a completely redesigned performance catalog (TarMed 1.09) and a limited resource pool, you might end up spending 100 days on updating clients (remember: it's not just importing data, it's mostly dedicating 2 days per FMS of Q & A with n users)

Iif users are productive and getting their work done with 13, why implement a new look and feel unless it adds exceptional value and the loss of productivity while users learn it will be offset down the road with that feature?

There's another aspect to this; using the new features (like Card) you could create visually the same thing but make the system more performant, more ready to scale up because of the reduction in schema overhead etc.

The point has been made before: whether clients upgrade is entirely a value preposition; developers should (IMHO) get a copy to get deeply familiar with the new features. As always there will always be features that bring unexpected benefits. It may not bring direct value to your customers but it has direct value to you as a developer.

And please, can someone explain me, why replace dialog in one window is blocking the second? I thought, they will be independent like tabs in Web browser.

FileMaker is a strictly procedural language. If you want to 'multi-thread' then you can use the "Perform script on server" script step with the wait checkbox turned off. An operation like "replace" is the perfect sort of operation to perform on the server even with "wait" turned on because it will happen much faster there if you have any sort of network lag - WAN access for example.

FileMaker is a strictly procedural language. If you want to 'multi-thread' then you can use the "Perform script on server" script step ..

procedural doesn't imply single-threaded - procedural is just the programming paradigm - and only FM script might look procedural since it uses that model but has many other paradigms like data-flow-control, functional and predicative etc.

Thanks for the responses from everyone who replied to my post on the windowing.

The concept of SDI is great. It would allow for the use of multiple screens within Filemaker on the Windows platform.

My point is it is a half-baked implementation of what happens on a Mac.

There is a Menu Item to hide Filemaker on the Mac. I learned today about the ctr-d trick (thanks Carl) which is probably faster than finding a menu button (the same as using the scroll mouse is multiple times faster than clicking buttons to navigate between records)

Problem is when I select Filemaker in the task bar to return to the appI am faced with a list of available windows. My users just want to go back to where they were, not have to work out which window to select to return to that place. I have deep reservations the problems this could cause.

On the Mac selecting Filemaker on the taskbar takes you back to where you were.

I realise this is probably an O/S limitation, and was probably the reason the original style of interface was implemented in the first place.

All my users are on VLA’s so it is not a question of cost. User experience is the main factor and I could not inflict this on my Users.

I spent a couple of days training on 16 last week and came away very impressed. Just cannot use in a multi file solution.

I have a multi file solution and just hide the other windows when not in use, Yes they will now be available view the task bar but I can train the users not to select them from there and just navigate the windows via the UI I have created. Many of my users have two monitors and the new windows management I feel is going to be great for them. I think there are ways to address the multi file issue so you can move to 16. I think holding users hostage in old versions unnecessarily is short sighted but maybe that's that just me.

Nothing wrong with version 14. That's where it looks like I'll be for a while.

Actually, for my interfaces, which I keep very simple for my users (who appreciate that), I could have stuck with version 12 - and maybe in hindsight should have. AFAIK, FMI has done nothing to improve SQL since 12. Scripts still run very slowly, no debugging in CFs, and many other things "I" would like to see improved....haven't.

This is not a matter of FMI "baking the cake". I believe this is how Windows works. You have the same issues with Word and Excel. Most WIndows users are used to this behavior in general. I agree it is an adjustment and a big change for Filemaker, but lets stop blaming Filemaker. They are simply working with what the OS provides.

There are other differences between Mac and Windows as well. Mac has a single menu bar with different Window instantiations. Windows has a menu bar in each Window.

I do not think it is an unreasonable expectation that users can go back to where they were in a multi file solution by clicking on the task bar. They could do that in previous versions and on a Mac. It is a fundamental design fault that must be fixed before 16 can be used with multi file solutions

I would also highly recommend Alan Cooper's book: The Inmates Are Running the Asylum as another relevant book on software, computers, developers, and the current state of software (still not that great).

Alan's other book, "About Face" was required reading in two separate jobs I had. One of those jobs did a daily brown-bag until we covered the entire book and the book's ideas were enforced in code reviews.

That's power. Our bug lists went way down. Many fewer calls to the help desk. All project metrics positive.

(these were not FMP projects, but the idea is the same.)

---------

After reading lots of these UI and user-goal books, I now separate the "new and cool" (mostly from a developer's perspective) from what users want and need (the real world).

Watching users actually use your software is an eye-opening experience for any developer.

As I said, again, not to take anything away from the solid new 16 release, there's nothing there I want or need. I would gladly pay $99 for the new features, or by feature, $5 for this new feature or that one. $329? No way.

I agree with you regarding bugs. It has to be evaluated before upgrading. Bugs in 15 where severe and now in 16 many fixed but new ones introduced - severe bugs are everything in regards of data integrity and consistency.

My clients want to look at correct data - how they look & feel doesn't help if they cannot trust it.

I wouldn't mind an even more frequent update schedule. But annually is decent. I think this release represents and excellent value in the scope of Filemaker updates. I'm more concerned with price creep in general. I've prepaid for support out as far as I reasonably can to mitigate costs.

Being able to do reporting out of WebDirect is a BIG DEAL in my opinion. Go price other products that have similar BI type features and Filemaker is a relative bargain from that perspective. Filemaker is lacking in some other areas, but that is the nature of compromise.

I think most postings that have titles like this one have conversations that go all over the place. That's normal at least in the last few years, anyway. I think it's kind of interesting to see the conversation flow.

All of us are very guilty of not answering the question that was asked: "What is ONE good reason to upgrade to FMP 16?"

You are of course right, definitely. But I could simply not answer, could not give one of the major new features as the single reason. Because just one of them could justify an upgrade for my company and most of our customers. PDF on server/WE, Card Style Window, Object Pallette, REST(!!!!!), JSON, Modern Windows on Windowsetc.

Well, well, well ... I am paralysed like a rabbit looking at a cobra snake ... to many obvious correct answers ...

If I asked my selv which one of those I would accept being taken from me my answer is I would fight for each of them ... thereby driving the point home that this time there are many reasons not to stay with 14-15.

If somebody had asked me about ONE good Reason to upgrade from 13-14 to 15 my answer would have been WebDirect and general WAN performance improvement. And if they got me on the wrong foot I would have answered "concealed input field"

First pit stop: people expect to get more from something they pay for than from something they get for free.

Google is free, my software is paid. But I'm slower. In their minds, before ever having the opportunity to tell them something, they develop a negative image of me, and I have to explain, correct, fix etc that. Daily. So: speed, "just fix it". It's overall, from ExecuteSQL to SortValues.

I still have a Mac SE which takes 20 seconds from being turned on to allowing me to write text into MS Word. My last gen iMac can't reach that performance.

It's unacceptable to suck that deep on the speed side after decades, with gigs of ram and SSDs and processors which should be able to calculate the weather on a 100 km2 area in milliseconds and all the progress which we pretend having reached in 30 years.

I would welcome a v17 version which adds nothing but only makes everything 10/20/30 % faster.

However, we will not move any of our clients to it until the first patch is out as we know there are some issues with it.

We have clients that will not need any of the new features unless they ask for a redevelopment or some new features that would be done better in the new version.

It makes sense for some people and for some it doesn't.

I can say that the pre-release version helped me restore a bunch of value lists I deleted from the wrong file, using the new 'copy value lists' feature - a seemingly minor thing but saved me as a developer a couple of hours.

I was hoping for functions to encrypt in RSA 2048 mode, we will have to settle for a 64 mode.

We NEED it, not to make it pretty, but for security reasons and for guaranteed the inalterability of the data.

For now in 10 years, I have not made a profit from my upgrade purchases from FileMaker so we will wait for version 17 and like many, I would like more speed and fewer graphical bugs in the development interface.

No need to wait. You can do that today using any version of FMP that has INSERT FROM URL.

Here's a quick RSA 2048 example I whipped up in about 5 minutes. The public and private keys are all on my computer. and were generated by the program (you can specify any legal RSA key length. I picked 2048). You'd then need to distribute your public key as you would with any public key encryption approach:

RSA-2048

Original Text (using generated public key): "Text to be encrypted"

Encrypted Text: [B@3d24753a

Decrypted Text (using generated private key): "Text to be encrypted"

I also saw this interesting article on RSA Key Lengths vs. brute force attacks and other considerations: RSA key lengths

So, you can easily do 2048 encryption if you use FMP with an external micro-service. I could show you how to do that, but it would require some setup on your side.

There may be some plug-ins that have that functionality canned. I prefer to use standard libraries under my control, however.

fmpdude: There are some great uses for cards that I have already made. However, it is like many other features where inappropriate or overuse detracts from functionality. I think there is a good balance of when to use the card feature and it is of benefit already to my customers in some limited situations. I agree with you that developers need to step back and watch how users use their software and look for ways to improve the UI to make their job easier. In general, businesses are looking more for ease of use and efficiency than beauty. But there is something quite professional and polished when you can get those things to merge. I haven't read Alan Cooper's book, but will have to take a look. Thanks for the suggestion.