We use the term �gadget� to describe small useful devices but we need to distinguish between two views of gadgets. I explored this a bit in explaining why I�m more interested in what a product can be rather than what the manufacturer thinks it is. I refer to this as what isn�t. That�s why, for example, I chose to buy the Samsung i700 cellular phone � I could use my standard development tools though it still doesn�t provide enough access to the communications infrastructure.
I
bought the Panasonic SV AV-100 because it liberates me from dealing with tapes and
the video data is available for me to use on my PC. At least that's the theory,
but the products software-counterpart on the PC reduces the potential of the product
by mediating my access to the cameras capabilities. It is an interesting example
of the clash between the traditios of the consumer electronics industry and personal
computing.
The camera itself is marks a transition. Its quality is sufficient to make me stop using video tape. Though it's not ready to take on the high end video market yet, I expect a very fast evolution towards far more capable products.
It is very small so I can carry it in my pocket. The images are recorded on an SD card. It ships with a 512MB card though 4GB cards will be available within the next two years. 512MB is sufficient for 10 minute of MPEG2 and 2 hours using MPEG4. That's normally enough though obviously I can carry extra SD cards and quickly copy them to a PC. Unlike the protocols for transferring tape, I can copy the video files far faster than "real time" and there is no issue of losing frames.
The MPEG2 images can be compressed on the PC by a factor of 6 while still retaining most of the original quality.
I simply connect the camera using the USB interface (much faster when I use the
internal SD adapter on my laptop) and run the "MediaStage" application that comes
with the camera.
It
then shows me what's on the SD card and I can copy the images onto the PC and then
compress or edit them. Simple enough? Too simple.
The MediaStage application is cute and even a bit glitzy and has some nice features like playing the thumbnail in place if you drag the mouse over the image. I realize it's a first version so I forgive some of the bugs. At least I think it's a first version since there is no "About" box with the usual information. While I don't demand that all application adhere to strict guidelines, there is a reason for providing information such as an about box and taking advantage of the idioms that users expect.
When designing a product it makes sense to build on familiar metaphors but which one? We have a video camera so it makes sense to provide an interface for dealing with video images. To those of us familiar with the PC, however, the interface is idiosyncratic and frustrating both in subtle and major ways.
But that isn't as important as the lack of APIs (Application Programming Interfaces -- standard ways of connecting between programs) that give programmers the ability to create their own capabilities. When creating a consumer product, whether a device or a software application, it makes sense to focus on the user experience, especially new users who will decide whether or not to buy the product based on their initial impression. Because programs tend to build upon standard format and interfaces and, internally, they are built out of components users are able to create their own tools and products anyway.
In the early days of the PC, Microsoft sold tools for developers and Windows itself didn't have much appeal to end users until applications were available. Apple built the Macintosh for users and it came with a rich set of programs for users but underneath there wasn't a rich set of interfaces to make it easy to build new applications and those that were available were aimed at hard core programmers. Proficient users were unable to leverage their experience by building simple tools to automate standard tasks. This changed over time, especially now that OS/x is available.
Microsoft has a very rich set of tools to make it easy to extend the capabilities of the scan
ystem. The question is who can do that extending. The simplest answer is that anyone can, though it does require an awareness of what is possible. Some extensions require deep expertise and some are done with simpler approaches, often called scripting. It's basically like a script or a recipe written in terms of user actions rather than low level computer stuff. While those highly motivated programmers can ferret out the information necessary to do operations despite impediments, it's far better to have standard interfaces at both high and low levels.
Instead of just doing the program (also called an application) that the user
interacts with, one can create a library (or language) that can be used to implement that
application that users work with.
That
application is then one presentation of the lower level operations and it is relatively
easy for others' to create their own. Making that layer visible to those others
is problematic because it becomes a promise that must be kept. Yet, internally,
programs typically built as a collection of cooperating subsystems. If you
look at the directory that contains the MediaStage program you'll find it full
of DLL files. The suffixes (or extensions) or file names are used to indicate how
the file is used. The EXE means executable is a program that you run.
MediaStage
is called "MediaStage.exe".
"DLL" stands for "Dynamic Load Library" (you can add
"ly" if you want adverbs) and is a program used internally by another program. These
are the building blocks. Notice, for example, Convert2MPEG.DLL and
Convert2WMF.dll.
But the developers have not made these available to others'. With enough effort
it is possible to make them available for general use. In doing so, there is no
promise that the interfaces will be stable over time or even work as expected.
If you look inside a consumer product you'll find the same kind of structure in the chips used. Just as with software, it makes sense to build devices on standard components with standard interfaces. It's just that it is easier to build on the software interface layer.
Instead of viewing the product as the camera and user application, we can also view the product as being the camera and the software component layer.
This is not as revolutionary as it may seem. The big value of digital cameras is in making the image available so I can edit it with any tools I want and then, perhaps, print it. There are many people who don't want that--they just want to take the picture and print it directly from the camera just like they did with their snapshots when they would get two prints to distribute to friends and then lose the negatives. I wonder how many people make use of the printers design for that purpose. It's the kind of feature that tests in marketing research but, as people understand more about computers and gain the ability to make effective use the computer, the nature of photography changes and printing becomes an option rather than the goal.
The other reason for separating the missions is to develop a better product. While I am willing to accept bugs in programs I'm less tolerant of what I see as bad design. By focusing on a specification for he user (or application) level it's easy to come into conflict with the basic mechanisms and metaphors of computing. This shows up in both quirky and surprising aspects to the interface and in subtle bugs in which timing and order become too critical. There is a cost for this dissonance in making the product less pleasant to use and requiring more support. One difficultly is that today's personal computers are very complex environments with many programs interacting with each other and the user. Such variations it harder to control the full experience.
At a very simple level I see this as a cultural clash between those who want to create and sell products that do what they are supposed to do and that's that and those who see the products as much more. Sometimes it's the opposite. The VCR may have been a way to view ones home movies and to time-shift television programming but became a way to move rented movies while flashing 12:00 for some reason.
While I do forgive normal bugs I do find the quirks of the interface annoying.
Timing and the interaction of programming elements is a complicated problem. When
testing a program in isolation with cooperative users it's easy to miss the problems
that arise when one is using the program along with many others on a single machine.
Perhaps my tendency to use my system in single click mode exacerbates the problem.
The
bigger issue is simply the lack of information. For example, I have no idea where
it actually puts the images. Actually I do because I looked through the hidden files
on my machine and found where it stores the huge raw image files. If I don't know
where the images are stored how can I do a simple thing like backing them up? I
have no idea what the data format is and what the control files look like. This
means I don't know how to combine the files on my laptop with this on the desktop!
By experimenting I found that if you rename the main file as .AVI or another image
suffix it will play as long as you have Panasonic's codec on the machine. Where
do you get that Codec? I'm not sure but it does get installed with
MediaStage.
I'm not surprised that Panasonic's customer support line didn't entertain the concept of providing this information.
I'm supposed to use MediaStage to convert the image to a compressed form that will be stored somewhere on my disk. I actually figured out how to set the default directory despite the user interface. I can understand why I'm supposed to compress the image. Even at the lowest compression ratio a 37MB image goes to 5MB at 320x240 760kbps 15fps AVI format MPEG4. This is higher quality than the camera's native MPEG4 thanks to the computing power of my PC.
The problem is that I don't want to spend my time converting files right away. And, when I do, I want to do it as a batch operation. I would also like to know what is being lost when I do that compression.
But the MediaStage program doesn't disgorge the file unless I convert it and
I must do that conversion on the machine to which I first copy the file.
Good
thing I'm smarter than the average laboratory rat and realized I can place a 1GB
CF card in my laptop and use that to move the files from my laptop to my desktop
because the MediaStage program deigns to copy the raw files to such a medium.
But the program is smarter than I am and just says "no". I finally find I can transfer
files using an SD card rather than a CF card but it changes them to ASF files for
some reason. I'm very confused -- I transfer the files but don't feel I'm in control.
I've chosen to focus on the SV AV-100 because the potential of the product is very evident and so is the value that is lost when its companion PC program limits the devices potential to the simplest scenarios. In effect I can look inside a consumer appliance and see what it really can do and how little of that is made available to me.
The problem of closed products is endemic and, in fact, the norm. After all, the product manager is charged with doing a product and not creating potential that doesn't show up in the product review. In fact, such openness may be seen as an unnecessary risk and it does increase the cost of testing the program.
But that's not necessarily true!! It's only true if one has to do all of the work inside the one program that defines the product. In the case of the camera, providing adequate technical information and using standard formats allows the users to solve the problems themselves and enhance the value of the product. Sure there's a risk of increased support calls but that's an incentive to leverage existing standards and tools. This can save a lot of effort and tap into existing knowledge though it doesn't eliminate the need for the application provider to take responsibility for the user experience. By building on a common framework the responsibility will be shared.
Closed systems and closed communities tend to reinforce their own beliefs. We see this in IEEE-1394 (FireWire) which was designed to be able to carry video streams. It builds in tight timing constraints in order to assure strict timing of the stream in order to avoid requiring that the devices have local buffering and decoding. This may have made sense when those were expensive but it wires in policies that are now dated. When we copy video streams we want to be able to go as fast as the destination can accept the information and should be able to choose our own policies including allowing one to choose for lower resolution streams.
Though I have seen some demonstrations of using a TV remote control to manage ones content and video streams it seems far more awkward than being able to make full use of a PC for an interface, especially when one might want to do more than emulate videotapes. Part of the problem is simply timing. It's simply too difficult to design products years before they are to ship when we don't even understand them until we've had experience using them. This is why product cycles are so long.
It's also why they are decreasing -- we can now use the PC to redefine the products as we gain experience. And it will happen faster as more people understand how to take advantage of the PC for this purpose. Even with the PC we are still largely in manual mode.
The SV AV-100 differs from other digital cameras which come with their own support software. The file format for most cameras is obvious but the SV AV-100 requires that I depend on MediaStage as an intermediary until I figure out the formats myself and find the right tools. I do expect that to happen.
After all this I still recommend buying the SV AV-100 because of its potential. The wonderful thing about software is that it is easy to update and replace. This also applies to devices that I can build or modify. Car enthusiasts see cars as malleable but I can't easily build my own consumer devices and computer components because of their complexity. In fact, they are only accessible because there is a very large marketplace that can share the costs of creating them.
Software is different to the extent that I have a rich set of building blocks that enable me to build things myself.
More important -- I can readily share the software with others to the benefit of the community. I don't necessarily have to share the code -- it's sufficient to share insights with others.
We see the same principle at work in music. It's simple to buy a CD full of music and listen to it but where would we be if people couldn't create their own music and share it. The record companies depend on a fresh supply of "content" but they select only a small portion of the music being played everywhere. It's created by individuals who play it for their own amusement and enjoyment and then some share it with others. One form of leverage is Karaoke -- the ability to build on the work (or components) of others is very important. Too bad so much effort is being put into stymieing such efforts. It's bad enough when people create products and then limit their value. It's far worse when adding value is seen as a criminal activity.
Yet even when we have a product, like the SV AV-100, that benefits from others' ability to add value, companies fail to do it because the value doesn't accrue to the manager of that product.
The real importance of the personal computer is that it is a general platform that makes it easy to use software to add value to services, to devices and to other software. This principle extends beyond the PC but a first step is for those producing products such as the SV AV-100 to recognize the need to understand the PC as a software platform, not just as an extension to the device itself. It's important to learn the idioms and the culture of the platform and the world of software.
We'll all be the better for it. The manufacturers will have to bear less of the burden for creating the whole product and will benefit from the users' ability to add value. The users (us, you and me) will gain the ability to take advantage of the computer to act on our behalf. Why must I plead for product features when I can create them myself?
While I can't do everything myself, the little I can do gives me (and others) so much. All I ask for is opportunity.
