A lot of what we struggle with as camera users these days has to do with what's happening in camera engineering. Specifically, the notion of Minimum Viable Product (MVP). The recent Canon RP, for example, is mostly MVP overall, as are products like Fujifilm's X-A5 and X-T100. Still, virtually every new camera product we're seeing now has MVP decisions in it, and those are one of the things that put us all in "wait and see" mode instead of upgrading our kits.
I'll use connectivity as one clear example of what I mean by MVP. Virtually every camera maker is practicing MVP with their Wi-Fi implementation: what's the least amount of work they have to do to obtain a minimum viable feature set and/or performance?
The camera user wants to transfer images off their camera, and they want to control the camera remotely. So those two things become the measuring stick for MVP: (1) can we transfer images from our camera over Wi-Fi?; (2) can the user control basic picture taking via Wi-Fi? If the answer to those two questions is "yes", then the engineering is done ;~).
MVP is related to Marketing Checkbox. This is where the marketing product management team builds a list of features that they believe they need in order for a product to seem competitive in the specification list. The competitor's camera can communicate via Wi-Fi? Then ours has to, too.
The problem is that a MVP capability doesn't necessarily address a real user need. Most people want Wi-Fi capability to (1) share their photos on the Internet; and (2) to replace a remote control widget with something they're already carrying. Note how this User #1 and #2 don't exactly match the MVP #1 and #2 definitions back up in the third paragraph.
Let's step through an example and see how this works.
You can use MVP #1 (transfer over Wi-Fi) to do User #1 (share images), sort of. As many readers of this site know, I did a number of experiments attempting just that using SnapBridge when the D500 first came out. Could I push some images to Twitter (my User #1 need) with SnapBridge (Nikon's MVP #1 feature)? Not without a lot of extra effort on my part. Yes, the camera could technically move a 2mp version of my image over the airwaves from my D500 to my iPhone. But that left me manually doing the captioning, tagging, and actual push to Twitter. Moreover, because MVP #1 wasn't exactly high performance, the whole experiment fell apart the minute I needed to do this with batches of images, rather than a single image.
I've since tried the same experiment with other Wi-Fi implementations from other camera makers. They all fail at solving the User #1 problem in a satisfying way. And they all fail because the camera company used MVP #1 to define the Wi-Fi function.
I actually defined the User #1 problem back in 2009, and I presented my ideas on that to Nikon executives in Tokyo in 2010. To some degree, SnapBridge is part of Nikon's response. So blame me. Not ;~). Instead blame MVP getting in the way of doing the actual user problem solving.
The real culprit here is mostly the SnapBridge app (iOS or Android, and now the Wireless Transmitter Utility on MacOS or Windows with the recent Nikon expansion of Wi-Fi connections to computers [on the Z6 and Z7]). The engineers basically defined "success" as: (a) establish a connection between camera and phone/tablet/computer/router; (b) move any images the user marks across that connection; (c) stuff those images in the Camera Roll (phone/tablet) or folder (computer). Done!
Well, yes, that job is indeed done. It's been done by Canon, Fujifilm, Leica, Nikon, Olympus, Panasonic, and Sony in some form or another. But it doesn't solve the user problem. That's because:
- (a) is fiddly, battery intensive, and not exactly done at peak Wi-Fi performance.
- (a) requires that I define which images move. And my only choices are basically (1) review an image and press a button (and sometimes also have to find and use the appropriate menu choice) to mark it for transmission; or (2) just send every image I shoot.
- there's a tendency to not complete (b), as for unknown reasons the connection gets dropped a lot.
- in dense Wi-Fi locales—lots of people on Wi-Fi in a closed area, like arenas—(b) tends to be sporadic at best.
- (c) requires me to pull up the phone/tablet/computer and do more work.
When we first designed the PenPoint operating system back in 1989, one of our design goals was to live through communication disconnects as if they didn't happen. That's because we were designing tablets that were going to use the then nascent cellular network, and cellular was even flakier then than it is today. We could have used MVP (e.g. establish connection) and let the user deal with disconnects (e.g. reconnect and retry from scratch). Instead, we solved the user problem: if a disconnection happens, notify, but automatically work to reconnect; and upon reconnection resume communication with what was left to communicate, not start over.
You could unplug a PenPoint system from a wired network or interrupt the wireless connection and it generally didn't skip a beat. The minute you plugged the wire back in or the wireless connection was (automatically or manually) re-established, the system just picked up where it left off, with no user interaction necessary.
It's those two words that keep coming back to me every time I see these MVP things the camera companies keep doing: user interaction. Any time the user is required to do something, it increases the complexity of the product for the user and makes it less likely that the right thing is done.
Again using SnapBridge as an example—Nikon isn't the only guilty party here, I'm just using the thing I know best as my example—we have all kinds of user interactions that are necessary to fully use the system effectively, and they're buried all over the place:
- Once Wi-Fi is turned on, it's on unless I turn it off, regardless of whether it's needed or not. If I'm not shooting images automatically marked for transfer, and I haven't marked any already-shot images for transfer, why does Wi-Fi need to be churning through battery? What Nikon wants me to do is turn Airplane Mode on and off to manage that process (SETUP menu, buried near the end of a long menu). The actual user need is for the camera to (a) only turn Wi-Fi on if a pending transfer request is active (automatic or user marked image); (b) turn Wi-Fi off when transfer is complete and no pending transfer request is active (perhaps with a timeout for automatic transfers); plus a setting where I can tell the camera to always leave it on in order to speed things up, should I want that.
- If I'm using the RETOUCH menu to create the image to transfer (e.g. trimming or resizing it), I have to finish the retouch operation, then make image review active, and mark that image for sending. Why can't I mark-for-send while I'm in the retouch operation (or even better, have an automatic mark-for-send trigger on retouch)?
- It used to be that you could only push 2mp JPEGs over SnapBridge, and those only from JPEGs that you shot. Fortunately, Nikon finally got around to doing an automatic raw-to-JPEG conversion if I was only shooting raw. But we're still in the all-or-nothing game here with the options (e.g. 2mp or all pixels). Note that I just said I might be using the RETOUCH menu to resize. Why can't I just specify a resize option for all images to be transferred?
- I want my images to go to Twitter (or Instagram, or Facebook, or maybe another half dozen or so somewhat common places). That means that I have to select the image(s) in the mobile app end and share it(them) from there manually. And by the way, if I want to select multiples, I have to discover the Select Photos option in the ... menu (yes, the actual menu is shown as ...). Oh, and did I want to add a comment? Can't do that. Did I want to give it a tag? Well:
- Hashtags in SnapBridge are buried in the App Options menu, and this is an all or nothing thing (i.e. all images get the same tags I pre-assign unless I go back and forth between the Camera Roll and the App Options menu for each image I want to share and do it one by one; ugh, talk about user interaction).
- Captioning? Image naming? Keywording? Not an option.
The thing is, SnapBridge works. It has clear MVP capabilities now. But that's all it has.
I use communication as my example for MVP for a reason: the camera makers wonder why smartphone users don't buy cameras. It's at least partly due to a user interaction problem. Yes, technically you can get images from your expensive dedicated camera to the Internet somewhere these days, but it's not seamless, as it is on smartphones. Nor is it without user interaction. Nor is the ability marketed at all well. In fact, I'll bet you if I walked into 10 camera shops and asked to see how the process of sharing an image to an Internet site works, most of them would fail to impress me in their knowledge of how "easy" it is (unless, of course, the salesman just lied ;~).
If you've ever traveled with a family on vacation and tried to post images to your friends back home, you know what happens with complex user interactions: your family wants to move on and do something else after you took an image, but you're sitting there fiddling forever to actually share it. Your son or daughter shared their image from their phone instantly to their friends. Do you think that's sending a message to the kids that someday they'll want a dedicated camera? ;~)
Just so I'm clear: sharing images isn't the only MVP problem the camera companies are promulgating these days. It's just one. A big and important one, but it's just one of many MVP problems users face now.
If the camera companies want more sales, they're going to have to stop doing MVP and doing more to improve (and minimize) user interaction.
