Any New Problems from the New Features?
Adding new features to the existing graphical objects can cause some conflicts—the same types of problems that occur when adding new buildings into a populated urban area. The screen real estate of most existing applications is already well populated; there are a limited number of available mouse-generated events—and often, each event is already strongly linked with an expected reaction. Adding something new into this organized universe can certainly cause conflicts.
You can eliminate or minimize these conflicts by carefully designing contours and by shrinking the area of new commands to the proposed system of nodes and connections. However, there are other ways of solving such conflicts. Here are some of the rules that I tried not to break while building moveable and resizable solutions, along with some thoughts for and against my decisions:
- I use a left-button press to start forward movement of the objects or to reconfigure them, and a right-button press to start rotation.
- Use a left button press for forward movement of an object only in the sensitive area of any connection. While it's no problem to start this movement by pressing anywhere inside the object, left-button clicks are already widely used, primarily to change the z-order of objects to bring the selected object to the top. I found it very useful to be able to grab and slightly move a plot to see more information without having to bring it to the top and alter the entire view of the form. If starting forward movement will affect the entire area of the object, then the object in motion will be automatically brought to the top position. That is exactly what Windows typically does now, so it's definitely a consideration, but I still think that providing users with the possibility of moving an object on the lower layer without disturbing the whole hierarchy is very useful.
- Object rotation is usually started by a right button press inside a node. Again, it's fairly easy to start rotation by clicking any point inside the graphical object. For example, the TuneableGraphics application uses arbitrary polygons, and you can start the rotation of those polygons by clicking any point inside the object. From the user's point of view, starting the rotation by right-clicking anywhere inside the object would be much easier. But the reason behind not implementing this technique for PieChart, Ring, and so on is simple—I am not sure that it would be correct. Usually, the right-mouse click pops up a context menu. I don't like the idea of starting two different processes with the same mouse click (although with the polygons that's exactly what I'm doing). Also, expanding the start of rotation to the whole object's area while restricting the start of forward movement to the connections is awkward.
Finally, the idea of moveable and resizable graphics will spread quickly (the advantages of such graphics is impossible to overestimate), but the development of applications for such graphics will require some setting of commonly used rules of interaction for moving and rotating the objects. It will be much better for users if all applications implement movement and resizing based on the same system of commands.
Contours, described in Part 1, make objects moveable and resizable. Here's a summary of how the whole moving/resizing process is organized:
- To make any graphical object moveable/resizable, you must derive it from GraphicalObject.
- You can include controls into moving/resizing operations just as they are.
- To organize a moving/resizing process, you need a Mover instance:
Mover Movers = new Mover();
- Mover supervises the moving/resizing process for graphical objects and controls that are included in its inner List<>:
Movers .Add (...);
Movers .Insert (...);
- Users perform moving and resizing operations with a mouse organized through the three standard mouse events: MouseDown, MouseMove, and MouseUp.
- MouseDown starts moving/resizing by grabbing either the whole object (moving) or a single node (resizing). The only mandatory line of code in this method is:
- MouseUp ends moving/resizing by releasing any objects that could be involved in the process. The only mandatory line of code in this method is:
- MouseMove moves either the entire object or a single node. There is one mandatory line of code in this method; to render movement you must call the Paint method:
if (Movers .MoverCaught)
- If contours must be visible, use one of the drawing methods, for example:
Final Remarks and Some Ideas
- If needed, you can use several Mover objects to organize moving and resizing. Each Mover deals only with the objects from its own List<>.
Moveable/resizable graphics are a powerful tool. By adding these features to the objects inside your program, you get the same flexibility on the inner level that Windows provides on the upper level. It's not surprising at all that the result is very similar to what you have on the upper level. The upper level includes all windows in the Z-order; the last one to be called is shown on top of all previous windows. When you click any window the system changes the Z-order and moves the selected window to the top. Now you have a tool to do exactly the same at the inner level; the only difference is that the system doesn't handle it for you behind the scenes; you, as a designer, have to do it explicitly. This article gives you the tools (methods) to do it easily.
The idea of moveable/resizable graphics is not simply new; it is so revolutionary that it's difficult to add it as a basic part of your design work in a week or even a month. I've been using moveable/resizable graphics in applications for a year and a half, and I still find myself solving problems in an ordinary way from time to time. Only later do I understand that with the help of moveable/resizable elements I could achieve a much better solution.
It's very difficult to predict what moveable/resizable graphics can bring into most existing applications. Look back and try to imagine the PC world with Windows stripped of its flexibility? Can you imagine a version of Windows where the system (instead of you) decides what and where to show each window? That's what you have now on the inner level. I'm absolutely sure that after the idea of moveable/resizable graphics catches on, modern-day fixed applications will appear as ancient as DOS applications do today.
application shows the details of this new technique of turning static graphical objects (and controls) into moveable and resizable ones. To make things absolutely clear, I tried to keep all sample classes and all forms for demonstration as simple as possible—that's why each form works with only one particular moveable/resizable class of objects. However, in real applications you would often like to use different moveable objects together. To show that it is no problem to do so, Form_Main.cs
contains objects of completely different types. It's very strange to see standard scientific plotting y(x), houses, sets of colored rings, and a couple of colored polygons in one form. They have nothing in common except that their design is based on the same described algorithm. Even so, they can all coexist in the same space (form) without any conflicts.
To gain a better understand of what these techniques allow, look into the TuneableGraphics
application, which includes a lot of different samples. The idea of that application was not to develop something extraordinary for one particular area; the main idea was to demonstrate the possibility of amazing results for absolutely different objects and areas.
Perhaps the area that can benefit most from moveable/resizable graphics is "financial" graphics. Millions of people analyze financial data and the effectiveness of their analysis greatly depends on how close the view of the numerous plots is to their expectation of the best and the most informative view. Nothing could be better than a system that allows everyone to view plots using the best personal arrangement. When you analyze a lot of information on the screen, the best system is the one that lets you size and organize the entire view at any time, without stopping the application or going somewhere else for extra tuning.
Scientific and engineering applications, which triggered my work on moveable/resizable graphics, can also gain from this new type of plotting. Using this new plotting, programmers can redesign the most complex systems, turning them from designer-driven into user-driven applications, and bring analysis of the most difficult engineering and scientific problems to another level. Instead of developing tiny details within several scenarios for calculations, programmers will design tools that allow any possible scenario or variant of research work in one or another particular engineering/scientific area.
Several documents and programs exist that can help you to understand and use moveable/resizable graphics effectively. You can find these www.SourceForge.net
in the MoveableGraphics project.
Many thanks to those who for years helped discuss the design of scientific plotting. Special thanks to Dr. Stanislav Shabunya from the Heat and Mass Transfer Institute. My work on tuneable graphics was triggered by a mutual project years ago, and his remarks during the fall of 2007 caused some significant improvements in clarity.