Table of Contents
Here is an idea of what to consider after you've finished your application and are looking to distribute it:
User Installation
Your product may run directly from the media on which it's delivered, e.g. a CD or USB-stick. However, in many cases, you want to install on the computer's hard disk and may have to program an installer using one of the popular tools that are available.
If you want to run directly from the media, you should think about data transfer rates. Running from a CD could be as slow as 150 KB/s but probably more like 5 MB/s. On a modern DVD-drive you can reckon on 15 MB/s. A good quality USB-stick is faster, something like 15-35 MB/s on USB 2.0 and maybe 50-100 MB/s on USB 3.0 – but writing speed is slower. For comparison, a hard disk can transfer data at 100-200 MB/s.
Choosing Distribution Media
Once you’re satisfied with your tests, you have to decide how you are going to distribute the app. Besides the considerations below, bear in mind what we said about transfer rates above.
Discs
CDs and DVDs, though not cutting edge, are cheap, reliable and easy to package. There is a limitation, though, that a CD can hold only around 700 MB while a DVD can manage 4.7 GB, or more if it’s double layer and/or double-sided. Another problem is that more and more computers now are delivered without CD/DVD players.
If your app is large, Blu-ray can handle up to 200 GB of data, but very few computers have Blu-ray drives.
USB-sticks
For apps that are bigger than 4.7 GB, you should consider USB sticks which are readily available up to 128 GB. All even halfway-modern computers have several USB 2.0 connectors with the faster USB 3.0 coming on strong. USB memory sticks have other advantages. They can be partitioned so that one part is regarded as a CDROM, i.e. it cannot be erased and Autorun is enabled. You can have your app on the CDROM part and still have many Gigabytes of read/write data that can be used to store work. So when you move the stick from machine to machine, you have a complete application and all its associated data.
Internet
Distribution can also be via internet, i.e. direct downloads. Download speeds vary widely depending on where you are on the globe. For example, in Sweden 40 Megabits per second is average. In Argentina, it's more like 6 Megabits/s. With an average European download speed of around 20 Mbits/sec, you can transfer 1 GB in 7 or 8 minutes.
Testing the product prior to delivery
This is a very important stage. When your app gets out into the world, you want it to work on as many machines and operating systems and languages as possible. So your testing should be thorough – carried out on as many machines as you can find. Of course, you could test on a single machine, one that can boot several operating systems. This is infinitely better than nothing, but in the end, it’s just a single piece of hardware. Your customers will be using all sorts of electronics. Of course, you can't possibly replicate all the conceivable configurations of hardware and software, but try to hit a variety of combinations.
If your product depends on a web browser, then you should test it at least with Internet Explorer, Firefox and Chrome, various versions. If your product is aimed at non-English-speaking countries, then it’s wise to test on OS’s that natively support other languages.
A “clean” OS – that is, one that is freshly installed and has not had any extras added – can be useful. Some users may use the product differently and have different programs installed. In this case, a clean OS can reveal a problem.
You're hoping to sell many copies of your app, and you want to minimize complaints and support. Even with thorough testing, it is recommended to make a small 1st batch, and then get any corrections in place before mass-producing.
Web browser incompatibilities
Many applications are meant to run online in a web browser. This immediately presents the challenge of having your product look good in all browsers. The only way to be sure is to install the various browsers on different machines. In each case, you must decide whether you will support only the very latest version or allow for the fact that users have an older one. Internet Explorer can emulate an earlier browser, i.e. Internet Explorer 8. This saves time, but again poses the question of emulation which is never 100% the same as the real thing. Earlier versions can be emulated by pressing F12 in modern IE – that is IE10 and up.
Various browsers for PDF, SWF, and other formats
Again, you're looking for standarization - the same look and feel on all browsers, assuming that your product makes use of web pages. PDF and SWF, for example, are handled by add-ons, and these add-ons, combined with the browser itself can make for some rather strange reactions. As always, we recommend testing on various operating systems, browsers, and add-ons.
Digital Rights Management
Though some consider copy protection (DRM) as a factor that just complicates and costs extra, most understand that in the long run, it more than pays for itself. If your target is iPhone or Android, and in the low-price class, then it might make sense to skip DRM, though there are some primitive protections on the market. If your target is PC or Mac, then some very sophisticated protections are available. If your app is a killer game, then you can be sure that talented hackers will jump on it the instant it's available. It's not just a question of money, but reputation and status. Anything that's to be sold to schools will also be subjected to hacking, though in this case, it's normally just a question of money, students being perpetually short of cash.
Except for Blu-ray, good copy protection for both Mac OS X and PC is available for all the distribution forms mentioned above. It's best to think about this early-on, and also make sure all beta versions and review samples are fully protected.
If potential clients want to se a demo of your application, it is better to give them an unprotected version with limited capabilities. If they get the full version with security software restricting the use to say 30 days, you really encourage your potential clients to try to break the security. It is is something else once they have paid for the software.
Virus testing
Sending out a product with virus or other malware, is of course unacceptable. Besides avoiding real malware, the following is related to minimizing “false positives” from antivirus vendors – something that can occur due to a random pattern match.
Quite simply put, this can be Hell. There are over 40 different anti-virus producers with over 70 products on the market, and testing on all - even all of the most popular can be time consuming to say the least. You can use well-known websites such as VirScan.org or VirusTotal.com. These are quite reliable, but do not always catch detections that would be detected by the actual installed anti-virus tool.
The only way to be 100% sure is to install the anti-virus product and then test it against the files in your product. Since many AV products are free, this is do-able pricewise, but still time consuming. Each AV product must be totally uninstalled before you try the next. And .. many of the best AVs are not free, so there's an expense for testing. Often you can get by with a 30-day free trial, but the producers recognize you, and are not likely to allow a second trial. So, if you want to do a really excellent job, you must actually install all of these products.
A more pragmatic approach is to wait until customers complain and then submit the product for whitelisting. Many AV manufacturers support online submission of false positives. However, the bottom line is that you must walk a tightrope. It would be dangerous to release a product with no AV checks whatsoever, but prohibitive to test thoroughly.
You should scan all input files you get, as well as anything that you send out. Apply digital signatures to all executables. This helps antivirus scanning utilities and prevents any later unwanted modifications to your application.
Production Quality Control
If you deliver on a physical media (USB-stick , CD or DVD), then it is vital that production quality is both of high quality and has sufficient margin to cope with all sorts of hardware on the market.
CD or DVD discs
An extremely cheap factory in the middle of the jungle in a poor country CAN deliver OK quality – but it is also possible that you run into what is called “false economy”. If a large percent of your customers have installation or reading problems, if only the very best drives can read the information reliably, your company image suffers.
Visual inspection actually can spot problems on the shiny lower surface of the discs.
We have seen plastic covers that left some glue residue on this surface. Scratches and other defects can also be seen.
You can also run special test software on a suitable CD/DVD drive. Most notably the C1/C2 error check. These errors can be corrected by the drive – but still the amount of such errors indicate the quality. We recommend Optidrivecontrol or PlexTools (software that works and comes with Plextor Premium drives) or Nero DiscSpeed.
Not all special functions are supported by all drives. The following drives are recommended:
Plextor Premium, PX-712, PX-714, PX-716
BenQ DW1600, DW1620, DW1640, DW1650, DW1655
USB-Sticks
The 5V voltage that USB ports deliver can be both lower or higher according to the USB specifications. We have seen USB sticks fail on portable laptops when the power adapter was disconnected. This is an example of USB-sticks that did not like anything less than 5V.
Bad solder quality or careless physical mounting of heavy components will cause failures over time. Consider having lacquer applied to seal the electronic PCB and make it resistant to environment changes.
What you can do in order to test quality, besides visual inspection, is doing a cycled stress test where overvoltage is applied while numerous read/write cycles are made. Physical stress and temperature cycling (high/low temperature intervals) should be applied, a least on a sample basis.
Notice that flash memory used for USB sticks comes in all quality grades. It is difficult to compare prices just based on specs.
Support
You can, of course, do without support, especially if your product is cheap. If it doesn't work, then you've lost one customer. OK. You're relying on volume. In general, though, if your product is going to be taken seriously, you need support. No matter how thorough your testing has been, customers are going have problems. They are going to be running all sorts of virtual machines, simulated this and that and every conceivable background process that can interfere with your software. So you have to be ready to deal with this.
Some use hotlines, but in this case, you have to have fast solutions for easily identifiable situtations. Also, telephone calls from all over the world can be expensive. In most cases, internet support is better. You can, for example, use email which gives you time to think about the customer's problem - and try to reproduce it. And then fix it or find a workaround before getting back to the customer.
For applications that cost more than a few bucks and can absorb some development costs, I strongly suggest some kind of built-in autosupport system that delivers information to you directly from the end-user's computer. In the case of sticky problems, this can be invaluable. Then, of course, you have to think about how to solve the problem once you've reproduced it. This sort of thing can be tricky, and not many programmers are qualified - or talented - enough for this demanding work. If you're lucky, you can find an electronic Sherlock who can do this sort of thing.
It's best to think about support solutions for end-users early-on when you can more seamlessly incorporate it into the product.
Build web upgrade possibility into the product
You should consider the possibility of updating/upgrading your product directly via the web. We are, of course, familiar with online updates supplied by Microsoft and Apple. For your product this can be a real lifesaver. Imagine that you've developed a product for Windows 8. Then along comes Windows 10 and suddenly you're dead in the water - and faced with the problem of satisfying a horde of frustrated and angry customers.
Delivering your application for production
If you decide to sell your app on a disc, you’ll most likely be using a professional replicator, though some do choose to burn their own. If you decide on a USB-stick, you’d still most likely choose a factory of some sort, one that can handle replication, silk-screening and packaging. If you are going to deliver via the internet, you’d be looking for someone to host the package, though, again you could set up your own sales page.
No matter whether you decide to use disc, USB-stick or internet, your app will have to be delivered to the producer. Though this should be simple, it does require some consideration. Many developers still deliver on a physical medium like DVD. This is not a good idea. Discs can be scratched, broken or smudged. You can't be 100% sure that all bits are as they should be. An electronic delivery is better, but you can also lose bits in transmission. You should use an md5 or other type of integrity check to be sure that a critical zero hasn’t become a one. Still better would be to use a compressed image such as zip or rar which have built-in integral checks and will report any error when unpacked. This also conserves bandwidth.
When delivering an image, you have the choice of placing it on your own ftp site, using the producer's ftp site or using one of these 3rd party sites that specialize in making data accessible for download - often with automatic deletion after a specified length of time.
During delivery, there are also security considerations. You don’t want someone to grab a free copy of your image. If you use your own ftp site you can secure the area, allowing access by password so that unauthorized personnel can't download it. However, you can still have good security when using the producer's or 3rd party site. This is achieved by using a password on the zip or arc. Bear in mind that even without a zip password all file names can be seen, and if someone already has one of these files, the password can be extracted.
Even something as simple as a password requires some thought. How do you communicate the password for the package? If you put it in an email, it is compromised. Anyone can read an email, and they are often copied to people who have no business seeing it. Think of an email as a postcard. A password can be texted to a mobile phone or faxed. This is quite a bit better, though to be sure that information doesn't fall into the wrong hands, it's best to split the information up into two channels. For example, send the URL by email, and send the actual password by cellphone.
Reprinting later (keeping stampers/ISO files)
It goes without saying that you should ask your factory to retain all original materials in case you want to reprint. However, I consider it essential that you not rely on the factory to do such things. Of course, you can’t be expected to keep a glass-master or a stamper or a physical silkscreen, but as much as possible you should have an archive containing all materials (graphics, ISO images, etc.) that were sent to the factory.
Having batch sequential numbers
Housekeeping is one of the most boring yet most important factors in maintaining a high-quality product. If, for example, you notice that a new reprint does not live up to the quality of an earlier reprint, you must be able to refer to a batch number – tell your producer that the logo colors in batches 3 and 4 were correct, but the colors in batch 5 were different (darker, lighter, lower-resolution).
Toast versus ISO
A toast file, created by the Roxio company has become standard for Macs, and OSX immediately understands how to mount a toast image. One great advantage is the ability to split Mac and PC files into separate partitions so that Mac files are invisible on a PC and vice-versa. There is also the option of sharing files between the two operating systems. The older and more common ISO format does not allow for hybrid discs. All files are visible both in Mac and Windows.
Post-production Testing
Once production is finished, you're ready to distribute your product. Or are you? What if something went wrong between the time you delivered the finished product to the producer and when it was ready for release. You can risk having to recall the entire shipment. Expensive and bad for your reputation. So, even though you tested your product thoroughly before delivery, it's a good idea to look at the finished item and try it out - at least on the most popular operating systems. Put yourself in the end-user's shoes. Does everything follow logically and flow smoothly?
Depending on your budget, you might consider using a professional test lab. Such labs normally have a broad range of computers and operating systems at their disposal. They are used to comprehensive testing and will supply you with a written report at the conclusion.
Packaging
Graphics – for CD/DVD or USB-stick
Up to now, we have been dealing with the finished computer product itself without thinking about graphical presentation.
If you are planning to distribute a purely electronic product, one that will be downloaded from the net and not delivered on a physical medium, then you don’t have to think too much about graphical presentation. Of course, different screens will look slightly different, but there’s not too much you can do about that – except maybe choosing colors that look good on different screens.
When using graphics on a physical medium such as CD/DVD or USB-stick, you want to be sure that the colors look the way you intended. There’s no automated way to choose printing colors. You have to convert your printed graphic (logo or whatever) to Pantone color Matching System codes (PMS) and have a sample printed out by your factory. From the PMS color code a factory should be able to hit the right color. Note that you cannot judge any printed color from how it looks on a screen.
It’s good to have a basic understanding of graphic bitmaps.
Imagine that you have a graphic that will have a size of 800 x 1000 pixels. For each one you need to specify the color. We’re talking about 800,000 dots and at least 8 bits (256 possibilities) to specify the color. For most applications 256 colors are too little, so 8 bits are used for each primary color (Red, Green, Blue). Thus 24-bits (16 million colors) is used per pixel. That means that you would have to have 0.8M x 24bit = 19.2 Megabits for one picture. Plus a little for a header to give you the number of pixels per line and so on.
Therefore, when transmitting graphics, it’s customary to compress the bitmap (BMP). Many of these picture formats we know, JPG, PNG, GIF etc., are merely various ways of compressing data. Some formats, in order to achieve high compression, make some compromises. Two pixels can be changed to one – even when they are not 100% identical. Assume you have a light-blue pixel next to a dark-blue pixel. These can be combined to single “medium blue” pixel to save data. This is what is known as destructive compression, since you can never come back to the original bitmap. JPG is a well-known destructive format, often used for photographs and for transmitting illustration on the web. Some like GIF give good compression, but you pay of the price of fewer colors. GIF is normally destructive – if your original uses 16 million colors, since only 256 are supported. PNG is often considered the best non-destructive and allows 16 million colors.
PDF, bitmap or vector graphics
Besides color and compression, there are other considerations. The final logo or other graphic can be sent to your replicator/printer as a PDF, bitmap, or vector graphics.
A bitmap has the advantage of specifying the value of every pixel, but if you have to scale it, things can get distorted. Vector graphics are made specifically for scaling. You can expand or contract or even stretch your graphic in one direction or another. However, vector graphics are applicable only to drawn graphics and cannot be used on photographs which, in their nature, are pixel-oriented.
PDF is a high-resolution bitmap, so it can contain drawings/photos while still being easy to scale – if, at any time, you think your logo or design should be blown up or reduced. With PDF you get a fixed final look – as opposed to, for instance, sending a text editor file with pictures.
Silkscreen painting limitations
If you are considering silkscreening which would be relevant for USB-sticks and CDs, then remember to stick to just a few basic colors. It's best not to try to achieve a particular color by interlacing two or more colors.
ISBN number can also be used on graphics
Since the ISBN number uniquely defines your product and will not change, it's a good idea to incorporate the ISBN into your packaging or booklet in some way.
CD/DVD-code or License key distributed with the product
There are various ways to distribute a code or key. It can be printed in a brochure, and this gives a professional impression. However, codes or keys sometimes need to be changed, and this could mean trashing and reprinting a lot of expensive brochures. A sticker, if nicely done, can also give a professional feeling, and this gives the option of either changing the sticker or putting a new one on top. A small card or slip of paper can also be a good solution. This is handy for the end-user and easily replaced.
Technical obstacles
The famous hidden forks on Mac
Even though hidden forks usually do not cause any trouble, they can unexpectedly give seemingly mysterious problems. If files with such hidden forks are copied from a Mac to a modern Windows computer or server, the hidden fork part is saved in a separate file starting with a dot. Problems will occur if a Mac packaged file (zip, rar etc) is unpackaged on a Windows computer. Windows utilities in general will not see or pay attention to the hidden fork part. Which leads us to the next advice:
Unzip on Mac, not on PC for Mac contents
Be sure that the zip or arc or whatever you use, can be unzipped on a PC for use on a PC and on a Mac for use on a Mac. Never take anything for granted. Put yourself in the position of the package's receiver and run through the procedure as he will. Also, once you've tried it, it's a good idea to tell your recipient exactly what to do - which utility to use and on which machine.
Compression utility 2 GB boundary
Many of the popular packers (ZIP, rar etc) have a proprietary format if the packed file gets above 2GB. Make sure that the receiver can unpack your large compressed file.
4GB file size limitation on FAT32
When preparing a product for distribution on CD or single-layer DVD, using FAT32 doesn't really present a problem. However if you have a larger app or file destined to be released on a USB-stick, then you should be aware that FAT32 cannot be used.
File system restrictions
The file systems on modern hard discs are NTFS on PCs and HFS on Macs. For small USB-sticks FAT can be seen, otherwise FAT32 is used for the flash partition. CDFS is used for CD-ROM partitions, also on USB-sticks. DVD-ROMs can be made many ways.
USB-sticks can have a CD-ROM or DVD-ROM partition. In both cases the USB-stick firmware acts as a physical CD-ROM, even if the logical information reports a DVD-ROM file format. For Windows this does not give any problems, but on Mac OS X, the CD-ROM driver has a limit around 2.2 GB. Thus a DVD-ROM partition on a USB-stick cannot exceed this size without giving read errors on a Mac.
Cache problems on Mac
OS X makes use of cache to a high degree. In general, this is a good thing, since execution is sped up. However, when testing this is actually a disadvantage, since it can be difficult to know whether you're actually testing the latest files - or some that were cached previously.Often when testing, you run into a problem after replacing files. In other words, you have installed an application and found that it doesn't work as intended. Then you change the offending files, but find that the error continues. This is often due to the fact that Mac's cache remembers and re-uses the previous files. In order to clean the cache, a good test technique is to simply move the application to another folder. The Mac now considers it as a new application, and the new replacement files will be loaded correctly.
Cache problems on web browsers
Web browsers also make use of caching. This enables the browser to display a page that has been previously loaded without wasting time on re-loading. Again, however, this is a distinct disadvantage when testing a product that makes use of a web browser. You want to be sure that you get the latest page, not a previous page. You can, of course, hit the reload button, and often this will be sufficient to refresh your data. Sometimes, though, it's best to right-click on the area of interest and then choose refresh. Best, though, is to close the browser and start again. A tip: For testing use “private browsing” if available.
About the author Roger Mester was educated in the USA at Rensselaer Polytechnic Institute and Stanford University. He has worked for General Electric, Lockheed, Radiometer, and Great Northern Telegraph. He was one of the two founders of Link Computer - now Link Data Security - in 1982.
