At the summer 1994 IEEE Computer Graphics and Applications editorial board meeting, then managing editor Nancy Hays suggested that I should volunteer to edit a regular Applications department for the magazine. I'm sure I brought this on myself, given my regular lament that we were not living up to the " and Applications" part of our name. But in fact, this was a concern that the entire board had discussed many times. The feedback from our readership surveys was consistently that CG&A was too academic and not sufficiently real world. In fact, I included a number of reader comments in the original Applications department author guidelines (where they remain to this day) stating a desire for more practical content, real-world applications, practice and usage, implementation details, experience-related information, and practical application of research results, as well as to bridge the gap between theory and application.

The very name Computer Graphics and Applications was originally chosen out of a desire to serve this need. But the articles submitted to us more often than not focused on computer graphics technology itself. Such technology was no doubt developed to solve many problems in general, yet seemingly none in particular. So where were the practical, real-world applications articles that our readership was clamoring for?

It still seems that across the refereed publications in our field, there's more emphasis on solving computer graphics problems than using computer graphics to solve real-world (non-computer-graphics) problems. Why is this so?

First, most graphics articles originate from computer graphics professionals in computer science departments or computer technology companies. Their job is to extend and refine graphics technology itself, and tell us of their progress. But real-world problems are often pursued in noncomputer academic departments and noncomputer industries, where the focus is on solving their practical problems and not on communicating their graphics problem-solving techniques back to us.

In addition, a lot of applied work takes place in nonacademic settings where publishing is not emphasized as much and, for confidentiality and/or intellectual property reasons, even discouraged. Plus, many academicians (and the journals they publish in) view interdisciplinary work as not quite on a par with mainstream topics in their fields. Applications articles are often viewed as "soft" and as "engineering, not science," since their methodologies and results are less clear than those arising in more formal technical or scientific work.

All of this leads to a systematic shortfall of articles telling us about new problem domains, functional requirements, and data characteristics confronted by people using graphics to solve practical problems, even though this would be invaluable information to those of us who develop computer graphics technology.

To address this need, the CG&A editorial board decided to institute a regular Applications department, guaranteeing that every issue would contain at least one bona fide applications article. In so doing, the board decided to run the Applications department with different editorial policies and practices than the usual fare.

A key emphasis of the department is in on directed articles. About a third of our articles are author submitted, but two thirds are written by professional writers with topic selection and content development under the department editor's direction. We decided early on that if we relied exclusively on submitted articles, we couldn't ensure that topics would cover the emerging areas of interest we wanted to highlight.

Also, to feature more current and timely topics, we needed to work closer to publication deadlines, more like a few months in advance than a year or more for regular articles. As a consequence, we decided that Applications department articles would not go through the regular refereeing process, but rather would be reviewed and accepted by the department editor alone.

Over the years, we have gained a sense of how authors can maximize the likelihood of creating an Applications department article that will make the grade. These guidelines apply not only to the Applications department, but to CG&A applications articles generally.

Solve a real-world (non-computer graphics) problem. There are plenty of opportunities to publish articles that tell us about new computer graphics techniques. But we are not so much interested in how you solved a computer graphics problem or built a graphics system as we are in the real-world problem you started with. The proverbial "solution in search of a problem" is not what we want, with us the problem comes first.

Apply computer graphics in a new area. The best applications articles occur when new technologies and equipment allow a new problem domain to benefit from a graphics-based solution. And even in areas with a history of using computer graphics, finding a new technique or efficiency can give traditional applications new reach.

Teach us about a new problem domain. Since your audience is largely computer graphics professionals, your problem domain is probably not known to most of them. Tell us about your area. What are the problems? What are the conventional approaches? What are the limitations and frustrations of current users? Teach us about what do people do today, what can't they do, and what caused you to select computer graphics as a means for solving your real problem.

Actually solve one problem. We get submissions from people developing a computer graphics technique, system, or product who emphasize how it can solve a whole range of problems. Fine, but readers are often less interested in the 100 problems your system can solve than in hearing about just one problem you did solve.

Get a result. The easiest way to get a result is to solve a previously unsolved problem or discover something new. Or maybe with your system people can now do something they previously couldn't do or do as easily. Tell us why this solution works, what others were tried, and why this was better. Would any solution have worked or was yours just the right one for this task? A result is anything new you learned from actually doing something, so draw conclusions from what you did.

Tell us about your data. It's particularly important to tell us about your data. What does it look like? What are its characteristics, size, speed, accuracy, and artifacts? Show the data and images from your domain so readers can imagine what a solution would entail. Real-world data is easily distinguished from "toy" data, in that it's messy, and you have to take it as it comes. As the visualization people have discovered, real data is best.

Tell us what you did. Tell us how your solution works and how someone could reproduce it. Readers particularly like to hear interesting, nonobvious technical details, facts, and figures. This includes configurations, models, even prices, as these are all part of real-world solutions. Also tell us how many lines of code you have, how long it took, and how many people were involved. Armed with this knowledge, the readers might see areas for improvement and opportunities for different approaches.

But don't just tell us what you did. A good Applications article isn't just about what you did as an end in itself. Your work might be interesting as computer graphics technology, but we want to know what you did with it, where it got you, and what your actual solution to the problem was. Often prospective authors place too much emphasis on "here's how we built our system to solve problems" rather than "here's how we solved this particular problem."

Tell us what went wrong. It's axiomatic that if you are working on an interesting real-world problem, it won't go like you expected. There will be things that don't work, unexpected twists and turns, and things you still can't do. If you aren't failing about half the time, you aren't trying hard enough. It's unconvincing if your article is nothing but positive accomplishments, as this suggests that you selected the problem to suit your solution rather than vice versa. Many product promotional application notes, which might otherwise be good candidates for a story, fail this test. Companies hate to admit that there is anything their product can't do, that developing the product was anything but a straight line to success, and that they have anything but a "yes" answer to all questions. But the best companies recognize that their claims are vastly more credible if they tell both capabilities and limitations.

Tell us the story with beginning, middle, and end. If it's a real-world problem, then there ought to be a story about how you came to recognize the problem, how you went about solving it, what went wrong along the way, what finally worked, what the result was, and what you still can't do. If these things are missing, it probably isn't a real problem or hasn't gotten past the toy problem stage.

Tell us about real users. What actually happened when real people (not just you) used your solution? How did you improve your system based on experience? Too often we see articles where graphics researchers develop a technique that purports to be useful in a given problem domain, but there is little evidence people in that field actually used the system.

As fields mature, they naturally transition to working in applications areas and at the boundaries with other fields. When graphics was new, much of the energy focused on getting graphics itself to work. But once we had 1,000 useful graphics algorithms, developing the 1,001st wasn't as important as the problems we could now solve with our existing, proven techniques.

Indeed, over the 10-year existence of the Applications department, the pages of CG&A devoted to practical content have steadily increased. One reason is the growth of the other CG&A departments, all of which strive to feature real-world fare. Another reason is CG&A's emphasis on theme issues, whose guest editors generally solicit their content and often seek out work by people at the interface of new techniques and their application. The Applications department might have started as a special initiative designed to plug a recognized hole, but is now just one avenue for featuring practical, real-world content. Table 1 lists all the Applications department articles published over the past 10 years.

We have one last rule: If the story is interesting enough and something we'd like to learn more about, all the other rules can be bent. I hope that over the years, these pages have given you something new to think about as you pursue your areas of interest. If so, please also think about sharing your own stories with us. If you are doing something new with computer graphics, we want to hear about it!