Here's What the Camera Companies Haven't Figured Out
Update: 2/17/2011 to simplify and clarify a lot of ideas, plus address questions that came up*
This should be fun.
For almost a decade now the Japanese camera makers have stuck to their tried and true formula for mainstream compact cameras: iterate them every year with a few more megapixels and a bit more lens. Oh, and make them in colors (next comes different exterior materials, like faux leather). This, they think, is enough to send the world running to their doors to purchase a new compact camera.
Of course, no one is running to their doors at all. Compact camera sales worldwide (source: CIPA):
2007: 92 million
2008: 110 million
2009: 96 million
2010: 108 million
That's almost a perfect example of what happens in a mature market when innovation has left the building. On top of the flatness of sales, there's also declining revenue per unit to contend with. In other words, the cake everyone is sharing is getting getting more air in it and is far less satisfying even though it appears to be the same size.
Yet the number of photographs being taken worldwide keeps going up. So what's wrong with this picture?
Simple: the cameras don't do what the customers want them to. What exactly is that? Simply put: distribute a user's images where they want them, without a lot of boring, manually done steps that have to be repeated each time. Really, it's that simple. We can argue about camera specs all day, but the mass market consumer is most interested in one thing: convenience. Convenience of taking an image (or movie) and getting it where they want it, whether that be email, Facebook, Flickr, their blog, iPhoto, YouTube, Vimeo, or somewhere else. Yes, it really is that simple: design a camera that does that and it'll sell. Like wildfire.
Those of you who remember my communicating, modular, programmable camera article will immediately see what I'm writing here as a variant of that. But at the low-end of the market, we don't need modular while the "communicating" and "programmable" can be highly specialized.
So here we go:
- Add WiFi to the camera. We need a communication system, it must be fast (which mostly leaves out Bluetooth) and it can't be wired.
- Write some computer software. We'll need Mac and Windows versions (bonus points if you can do it for iPad), but we need a simple program that the user can do their "configuration" with. More on that in a bit. The camera is configured by this program, and it's the primary method by which the camera communicates to the computer.
- Alter the camera's firmware to handle and store "user configuration information" sent from the dock and embed that in EXIF data at the user's request.
Believe it or not, that's it. Give me a team of engineers of my choosing and we'd be done in six months. And we'd have cameras that email, Facebook, Twitter, Flickr, and more. Without the user doing much of anything.
So how does all this work? Well, let's just take a simple example. I'm going to take the recently announced Coolpix S3100 as an example. Perfectly simple camera, and I'll bet that the folks that are buying it want to email their photos and share them on Facebook, but they eventually abandon their shiny new camera when they discover that their iPhone or Android phone does the whole job easier. Current price: US$139. We're going to up that to US$189 so that we can pay for the WiFi, but watch what happens to the difference in downstream usability.
So we put WiFi in the S3100. We write our WiFi enabled software for the other end. Oh, that's the part you haven't figured out, right? After all, communications is communications. It really doesn't matter all that much how the camera and dock communicate, there are hundreds of methods to make that work, and the user doesn't really care which is used. But the software...well, that's where we either solve their workflow issues and make everything seem like magic, or we make everything so damn complex and inflexible that the user starts pounding on the keyboard and swearing at the company that made the product. I vote for the former.
Ideally, our software program uses a modular, plug-in nature. That's because things like Facebook keep changing. We need a little mini-app (plug-in) to change when Facebook changes, not the entire program. The plug-in notion also allows us to just keep adding new things as we discover that users want them.
So the program simply has "conduits. In the example below I'll use tabs for each conduit plug-in (and the big + allows you to pick from other available conduits, perhaps even download new ones from our camera maker's Web site). Plenty of other UI designs would work, I'm just trying to give a sense of how straightforward you want to make this part of the operation to the user. I'm also not suggesting that these are all or the exact options that would apply to Facebook. Again, I'm just trying to give a suggestion of how simple and straightforward we want to keep all this:
Over time we add more and more possible conduits, and we keep them updated when the services that they connect to change. Indeed, we charge a yearly subscription to keep new conduits coming and old ones evolving. First year free. Okay, I'm a little greedy today: first six months free. Version 2 will be great. Version 3 will Microsoftalicious. ;~)
Each conduit will have different choices for what to do with incoming images that are tagged with that conduit, based upon what's possible. The camera owner simply fills in account information in our program and selects what they want to happen with their images for that conduit. They can do this once for each thing they want to use to distribute images, or we maybe allow them to create differently configured conduits for a single service (e.g. you may want some photos to go to your private gallery, others to a gallery your family can log into, and still others to your public gallery on one service). Some services/destinations are simple minded ("add to MyPictures folder") while others can probably get quite complex (e.g. the ever-changing world of Facebook). But we'll make our software plug-ins for these services as close to "pick and choose" as we can make it. Most consumers can do that much without a manual.
Okay, you're still missing a piece of the puzzle: how does the user take a picture and then determine where it will end up? Simple: remember Item #3? All the currently configured conduits get pulled over to the camera when the camera and dock do their little communicating sessions. That's why the firmware has to be able to handle configuration information. It only needs a tag and a (meaningful) name for each conduit, but the user has given us the meaningful name when they configured it.
So the only chore left is to do the assigning of conduit tags to each image. Since we don't have many buttons on the S3100, we'll do it the braindead way: if you're playing back an image on the LCD just press the OK button, which brings up a list of your conduits. Press the OK button on every conduit you want the image sent to (navigating between the installed ones with the direction pad), then navigate to Done and press the OK button again. Voila, image tagged. We could do this more elegantly, I'm sure, but I'm trying to fit this into the current camera designs, as heaven knows the camera company engineers are far too busy adding more megapixels and lens muscle to the cameras to take much time to change the camera design itself. And remember, I set a 6-month time limit for me to implement all this. (Note to self: might need to get the firmware guys to change the way videos work on some of these cameras, as they're already hoarding the OK button.)(Second note: obviously the camera's firmware should have a "master tag" option: tag all images the user takes "this way" unless overridden.)
Yes, I'm aware that there is a subtle timing issue here amongst others (you have to configure the camera before you go out and shoot). But you didn't think I was going to give away all the secrets here, did you? The purpose of this article is to suggest a simple, can-do-it-today approach that will get us 99% closer to where we want these cameras to be. I'll fix the other 1% later ;~).
So what happens if you don't assign something to a conduit? Oh come on, that's Software 101 fodder: you have the user define a default action for images in the software program. Better still, you suggest a default action and let the user accept it or change it. Oh, and did I tell you that the program renames files as it encounters them so you don't end up with multiple DSC_0001.JPG files?
We can make things more flexible, for sure, but I want to keep things relatively simple here so that we can get this out the door and into user's hands. Simple and sufficient is best for a first iteration. We can add flexibility, performance, complex task handling, and more later on (and guess what, we'll sell more cameras when we do, as once we hook the user with this idea, they'll want the latest and greatest variant). FWIW, as I've defined it this is a six-month, six-person engineering project, perhaps with another person or two on the marketing and graphics side. But it takes the right six people and the right person defining and leading the project.
Now for the funny part: Nikon and Canon could already do this with many of their DSLRs if they had thought of it. For example, on the Nikon side we've got the D7000, D300s, D700, D3s, and D3x all able to communicate via the WT-4. That's assuming, of course, that you can afford to spend the eight hours of configuration time to get the basic WiFi communication working between camera and your network. (That was sarcasm, guys and gals. But deserved sarcasm, since if a camera maker can't manage to get some basic WiFi configuration as easy as Apple makes it with Airport, they're never going to be able to pull off my little compact camera configuration program suggestion.) Seriously, Nikon View NX2 could have been a program that did everything I suggest, above, and then all the WT-4 cameras would have exactly what we wanted.
Can it really all be that simple? Yes, it can. Can the Japanese camera makers continue to not figure it out for another three, four, five years? Maybe.
* I've elminated NFC and Bluetooth as options from the original article as they kept getting in the way of people understanding what I was trying to do. Both NFC and Bluetooth are rather slow speed communications. NFC would require a dock. WiFi simplifies the idea and solves the bandwidth issue but adds programming complexity of sorts. We're now getting into some more serious coding, as we want the program on the computer (or iPad) to operate seamlessly in the background, too (i.e., if the full program is not up and running, the stub that fulfills the conduit instructions needs to be running in the background).
A few more comments on the comments I received:
- Yes, you can have the program at the computer end be more sophisticated, something more akin to a Nikon View if you want. That would allow you to do more selection and refinement before passing things down the conduit to the final destination. But you don't want to lose sight of the original goal: take a picture and it magically appears where you wanted it to. That and that alone needs to be done first and right. You can add features to the program at the center of all this later.
- Why not have a phone do all the heavy lifting? Because the phone market, if you haven't noticed, is so fragmented and fast moving as to be impossible to rely on. If all you do is make a camera/phone connection, move everything over to the phone immediately and then let the phone (via an app or apps) send things where they need to go, the phone becomes a "buffer device." That means it needs a lot of memory available ;~). Moreover, now you have the problem of having to explain to different phone users what they can and can't do and how. If you went this route, I'd say you'd have to pick one phone, which means the iPhone at this point (Android is too fragmented, Blackberry centered more on the business experience). On top of that, if all you do is get the images over to the phone and then let the user's phone apps do the distribution of images, you really haven't solved the user problem, you've just moved it. On top of that, the phones (other than perhaps the Sony/Ericksen) and apps aren't even close to being controlled by the camera makers. One point that is getting missed is that the camera maker needs to try to stay relevant through the process, not just be making an input device. If the camera maker doesn't provide the nearly complete solution, it leaves them vulnerable to someone that does.
- Eye-Fi sort of does a bit of what I suggest, but it's basically a buffer device, and one that isn't as flexible as I'd like. Moreover, there's nothing you can do from the camera end to configure where things go on a case by case or shooting basis. Compact camera use (and cell phone camera use) is intermittent and shouldn't all get sent to the same place. Think teen. This picture goes to mom and dad via email, that picture goes to my Facebook gallery, this sexual one goes to a private gallery me and my main squeeze share, etc. The number of possible places are relatively finite, but each picture taken may need to go to a different place. If you haven't used an iPhone and some key apps, that might not be obvious to you right away. But once you discover that an iPhone can do all sorts of distribution as you take images, and you're in control of it, you don't want to go back to unload card, put in reader, transfer, send things to where they belong manually.
- I was just reading a 150-page design document on a future camera from a big camera company. They. Just. Don't. Get. It. They're stuck in the old film metaphor of shoot, take roll of film (card) and do everything downstream on a computer, probably with stuff the camera maker doesn't make. Epic Fail. And then there's Nikon, who wants you to do everything through My Picturetown, even basic emailing, which they've removed from Nikon View NX2. This is just so wrong, wrong, wrong.
- Some of you may have recognized that what I described is actually already being done by one company. Say what? The company is Kodak and the process is called Easy Share. It works very much like I describe, though Kodak uses a physical dock to do the uplifting from camera to computer instead of a wireless solution. So why haven't you heard of it? Would you believe that a company that was at the forefront of innovative and compelling marketing for imaging products has...yes, you guessed it...now completely failed to be able to deliver even a simple let alone convincing marketing message? It doesn't help, of course, that Kodak's cameras are underperformers, but they still perform better than cell phone cameras. Companies fail for lots of different reasons: lack of leadership, failure in marketing, product deficiencies, slow to market, overpriced (or underpriced ;~), inability to make sufficient quantities (or making too many), poor distribution, and more.