Who are you writing beans for? Like most bean developers, you probably think your customer is someone just like you, a Java programmer. You design your beans with yourself in mind, adding features that would help you as a programmer. Seems reasonable. But what if you could reach a wider audience?
Programmers are only a small slice of the computer-user population. If any computer user could pick up your bean and wire it into an application without programming, imagine the increased potential for selling your bean, and for Java programming in general. This article looks first at how visual programming is poised to bring Java to a larger audience, then tells you how to make your beans more appealing to a wider market.
Why Design Your Beans
for Visual Programming?
Remember a time before spreadsheets? Well some of us can anyway.... If you wanted a computer to perform a calculation on a set of data (say, a 10% price hike), you got a programmer to write a COBOL program to process your request. When spreadsheets came along, they hid all the complexity from the user, and suddenly anyone could do all sorts of complex calculations. Most people don't consider working with spreadsheets to be programming, yet they're providing all the instructions the computer needs to do what they want it to.
Spreadsheets don't do everything users want. In fact, few programs ever exactly match the end user's specifications because they're designed for a wide audience. So what would happen if users could design their own apps? If they had the right components and could easily assemble them, they might be able to build these apps themselves.
Beans... They're Not Just
for Programmers Anymore
Beans (when used with the right visual builders) have the potential to change how applications get created and who creates them. Visual builder tools could tap into a larger customer base, but they need your help. To lure nonprogrammers into the world of Java and visual programming, we need more beans that anyone can pick up and use. To design them, you need to consider a new and different type of user, a nonprogrammer who shies away from writing code.
Most people can follow instructions for wiring a keyboard to a computer, connecting a stereo, or assembling a child's toy. These instructions invariably use diagrams - visual representations of the assembly - rather than textual instructions. So why give computers textual instructions?
Many people can assemble physical components without any instructions at all, because they can see how the parts fit together (see Figure 1). Well-designed components fit together only in ways that work (the plug for the keyboard doesn't fit the socket for the printer), or they provide visual clues for assembly (icons on the plug and socket, or matching colors).
What Makes Java Special?
I risk preaching to the converted here. You know Java is special, not only because it's cross-platform but because of how well beans work as pluggable components. But what you may have forgotten is that Sun's JavaBean component model was specifically designed with visual builders in mind.
But You Have to Code Java...
Still resisting this line of reasoning? You're probably imagining why nonprogrammers can't use beans:
You can do interesting stuff only in methods, not with beans.
Not if your beans are designed right. For example, take some of the complex, yet easy-to-use beans on the IBM alphaWorks (ibm.com/alphaworks) and
VisualAge Developer Domain (ibm.com/software/vadd) Web sites:
- JMF player: video and sound media player that lets you play multiple media clips
- Gauges: visual devices that display a single value that can vary continually within a range, such as LED displays, counters, and sliders
- SmartMarkers: A palette of color "markers" that highlight patterns and trends in data tables
- VisualScheduler: Project management bean suite that lets you visually schedule a set of tasks
- XML beans: Beans for manipulating XML content, such as viewing, searching, editing, or processing XML documents
If your bean successfully encapsulates a particular task that a lot of people want to do, you can provide the methods for the most common functions. The programmers can add their own methods.
You can't really make beans interact well without code.
Again, the magic is in the design (and in the visual builders). You have to put some thought into how these beans will connect with other beans, and do lots of usability testing. You might also need some helper beans to replace some coding techniques, like a Step bean that lets you specify the order in which events get fired.
Using the visual interface is too limiting.
It doesn't have to be. Since beans were originally intended for visual builders, the JavaBeans specification gives you a good start on how to expose all your bean's functions visually. The JavaBeans Guidelines at VisualAge Developer Domain pick up where the JavaBeans spec leaves off, giving you more tips on how to design your bean.
The tools aren't good enough.
You're right. many of the tools around today are still designed mainly for programmers. They provide lots of extra function that nonprogrammers don't need. They're improving but we need better visual tools such as debuggers and ways to visually encapsulate function - visual subroutines to help manage the clutter on the workspace. But some current visual composition editors are intuitive enough for nonprogrammers to use. Have you checked out VisualAge for Java lately?
Java is better suited for server-side programming than UI design.
Java is becoming very popular for server-side programming, but JSPs still need beans to encapsulate rich presentation function. JSPs make it more important than ever to encapsulate the complex function and easy customization into beans so that visual designers have all the tools they need to concentrate on visual design rather than coding.
Who are these people anyway?
The first thing you need is an introduction to your new audience. Members could be your nontechnical manager who wants a tool to track your project but doesn't want to spend money or programming time to get it. Or your Uncle Fred who wants to connect his computer to his barn's thermostat so it wakes him up when it's too cold for his cows. A COBOL programmer who doesn't know Java but wants to put a Web front-end on his or her legacy application. A Web site designer who needs beans to add dynamic elements to Web pages. Anyone who doesn't know how to code Java.
How Do you know what they want?
The thing is, nonprogrammers know what they want their computers to do, but they don't especially know what beans they want or how they should perform. There are two keys to making good beans that will make them more appealing to programmers and nonprogrammers alike:
- Encapsulate some complex, really useful function that can be used in many applications: The world has enough UI widgets for now in all sorts of styles. Beans need to combine lower-level functions so that the bean really hides complexity from the user. Programmers are good at providing complex function to users but not so good at hiding the complexity. You must carefully analyze what most users will do with your bean and cater to them.
- Make sure the bean is easy to use in visual builders: This is easier said than done, especially with the wide range of builders on the market. It includes everything from providing good short names and BeanInfo classes to more complex issues, like serialization and customizers.
The real promise of beans is not write once, run anywhere, but write once, reuse everywhere.
Making your beans easy
for nonprogrammers to use
So what makes beans easy for nonprogrammers to use? In this section we'll run through a bean that plays nicely in visual builders.
- What's in a name? The most basic usability improvement is good naming. This includes everything from the bean name, to package naming conventions, to names and descriptions of properties and methods. As with good interface design, if you give objects intuitive, simple names, even nonprogrammers can often use them without assistance.
- Provide BeanInfo files: A BeanInfo
file is a Java class that implements
the BeanInfo interface, named to
correspond to the bean it describes. (For example, a BeanInfo file for a LessThan bean would be called "Less ThanInfo"). You must provide a BeanInfo file if you don't follow the bean naming rules laid out in Sun's Java- Beans specification. These rules allow bean tools to gather information about your bean using introspection. You should follow the naming conventions and provide BeanInfo files to distinguish between "preferred" and "expert" features and provide property descriptions. VisualAge for Java (and other visual builders) can automatically generate BeanInfo files for you. Nonprogrammers can also use the BeanInfo tab in VisualAge for Java to get valuable information about your bean.
- Mark commonly used features "preferred": Preferred features show up in visual builders at a higher level than nonpreferred ones. For example, in VisualAge for Java, preferred properties appear in the selection menu when wiring an application (see Figure 2). You have to select nonpreferred features from a dialog after selecting the Connectable Features option (see Figure 3).
- Use bound properties where appropriate: Bound properties notify other components when their value changes. This lets other components do some action based on that changed value. So when nonprogrammers wire bound components together, the components actually perform an action when run. Bound components help nonprogrammers make the bean do its work. For example, a LessThan bean would compare the two values and report the result as soon as it receives two input values rather than waiting for some notification. From the perspective of nonprogrammers, when they wire un- bound properties, their bean doesn't do anything when it receives all the necessary data. Bean users have to write their own code to find out when a property changes.
On the other hand, unbound properties are more efficient than bound ones, so you should make a property bound only when another bean might need to know when that bean changes. In general, input variables don't need to be bound because their value doesn't change by itself (and the end user doesn't change it); it gets changed only by the underlying application.
- Be easy to listen to: Events generally indicate that a component in a program has reached a certain state or that an externally generated action has taken place. Event listeners are responsible for registering their interest in an event with the source of the event. When the event occurs, the event source informs all listeners, who can then act on the event according to their own needs. When designing your beans, think how nonprogrammers will use the final bean and program in any events they'll probably need. For example, a bean that performs file I/O would fire events at key points, such as after it reads a new line or when an I/O error occurs. Nonprogrammers can then wire appropriate responses to these events in their apps, like issuing a message when an error occurs.
- Provide state-of-the-art visual design and visual customization: Users will buy beans only if the visual design is professional and matches the look and feel of the rest of their system. In most cases this means using Swing for your visual elements and taking advantage of its look-and-feel customization.
Try to get a professional graphic designer involved; many powerful beans today suffer from a poor visual design. For an example of combining powerful visual design with functionality, check out the SmartMarker and Gauge beans at the VisualAge Developer Domain Web site.
- Give in-your-face documentation: The last thing a power programmer wants to think about is documentation, yet your bean will never sell if no one can figure out how to use it. With today's visual builders you needn't limit yourself to narrative how-tos and Javadocs. Try to provide creative, yet simple help for your beans, such as the "About this bean" property used on IBM alphaWorks Web site. You can provide visual help for using your beans (including wiring examples) right in the property editor for the bean. For example, Figure 4 shows visual help for a LessThan bean. (Once again, enlist a professional graphic designer to help out.)
- Use common design patterns: Design patterns are another tool to help nonprogrammers learn how to use beans quickly. They also help other component developers understand and maintain your code. Design patterns are templates for creating applications. They provide a set of rules and naming conventions that help you create and maintain your applications. If you're developing a set of related beans, you should provide a common interface for them to make it easier for your customers to understand the structure and usage of your beans and easier for you (or someone else) to upgrade them. Design patterns provide a way for you to describe this structure and usage.
- Create your own customizers and property editors: Really useful beans with complex functionality often have complex property sheets. You can help nonprogrammers navigate property sets by providing property editors and bean customizers. A property editor is a tool for customizing a particular property type. You should consider creating your own property editor when you have a property that doesn't fit the standard editors (such as a Swing look-and-feel editor). On the other hand, use customizers when property editors seem too primitive to customize a particular bean. A property editor is associated with a property; a customizer is associated with a bean. Customizers provide more advanced customization of the bean and let you completely replace the IDE's standard property sheet for that bean.
- Cope well with errors: A bean that plays nicely in visual builders also does rigorous error handling. Nonprogrammers don't know much about handling errors, so provide cues for error handling in your bean's features. To appeal to nonprogrammers, make information about all possible error conditions available in ways that are easy to program visually.
You can provide information about error events either through exception events or properties. In general, properties are easier for nonprogrammers to work with, but they're not always suitable for all beans (for example, when the property can't access information about an event). You need to carefully consider the situation where errors might arise in your beans before designing your error-handling techniques.
- Deliver the whole package: An article on selling beans wouldn't be complete without a word on packaging. You should follow standards for Java package-naming guidelines, Javadoc formats, and icons. One last task for your visual designer is to create a recognizable, snazzy image that represents your bean (no easy job!). VisualAge for Java helps with this process by providing wizards that walk you through the export process, and version control to help you keep track of your packages.
Where to learn more
These tips for writing beans for visual programming are expanded on in a set of tutorials on IBM's VisualAge Developer Domain site. These tutorials walk you through creating beans in VisualAge for Java, and along the way teach techniques for making your beans easy to use in visual builders.
The growing popularity of online bean brokerages shows there's a market to sell your beans. We have the right tools, the right technology, and the right markets in place to greatly expand the audience for the beans we develop. What we don't have are the broad scope of beans needed to really develop apps without programming.... What useful bean is lurking in your grounds?
- JavaBeans Guidelines: www.ibm.com /software/vadd/Data/Document2398?OpenDocument&p=1&BCT=1&Footer=1
- Visual Programming with Beans tutorials: www.ibm.com/software/vadd/Data/Document3328?OpenDocument&p=1
- Designing Beans for Visual Programming tutorials: www.ibm.com/software/vadd/Data/Document3436?OpenDocument&p=1
- alphaWorks: www.ibm.com/alphaWorks
- VisualAge Developer Domain, complimentary downloads of VisualAge
for Java, Entry Edition: www.ibm.com/software/vadd/
Many thanks to Dave Pullin for the initial idea, and Tatjana Apine, Colette Burrus, Tatjana Lukovnikova, Juris Krikis, and Pavels Nikolajevs for all their hard work on the visual programming tutorials.
Stephanie Parkin is the managing editor of IBM's VisualAge Developer Domain and WebSphere Developer Domain Web sites. She coauthored the visual programming
tutorial series, and is
currently turning the series into a book.