A fundamental part of interfaces today is displaying text on the screen. We were shocked that PLG does not currently have any functionality for displaying text. Fortunately, we received some sample code from the PLG forum to allow us to render fonts onto bitmaps, and places these bitmaps on polygons to float in the scene. While this solution did work, it was far from what we needed.
For one, the fonts placed on textures simply do not look very good. They are fuzzy and unclear at many resolutions. This caused us to make the interface larger on the screen than normally would have been necessary. This method for displaying fonts is also terribly inefficient. Not only does it take a fair amount of time to create the bitmaped texture, but displaying fonts all the time creates many memory-intensive objects that must be cleaned up at some point, slowing down the Java virtual machine.
Sharp, fast, flexible text rendering is an essential part of an interface toolkit. Until PLG has a way to display text in a reasonable manner, we suggest application developers look for another toolkit to develop with.
The PLG toolkit provided only uniform scaling. That is, we could not apply a non-uniform scale that could stretch an object. We needed this functionality to implement folded-scrolling. So, we had to go into the PLG toolkit and make changes to the source to allow for non-uniform scaling. When building large projects, it is important to avoid leaving broken windows around. This is just one example of a broken window we found in the source. Changing this functionality earlier would have been easier, but once all parts of the PLG toolkit start relying on the broken window, it becomes much harder to fix a simple problem.
The cursor used in PLG has a very nonstandard appearance. While we like the idea of the cursor being more dynamic, care must be taken in the process since the cursor is a UI element that can affect the usability of the entire system. The current cursor is a grey color, that is 20% transparent. Because of this, it has an extremely low contrast with the background image. Most cursors are black, with a white border to ensure that they are visible on all kinds of backgrounds. We found that users often got confused with the current cursor, and clicked with the center of the glyph, rather than the pointed end. We suggest orienting the cursor so that it points to the upper left portion of the screen. We also suggest using placing a border around the cursor, and using a high contrast ratio between the cursor color, and the border.
We often had complaints from users and critique group members that the moving backgrounds in PLG created a feeling of motion sickness. In reality, this experience is known as "simulator sickness" and happens when the motion observed through the visual channel does not match up with the orientation detected in the inner ear. We like the use of motion-paralax to give some depth clues. However, if users feel sick, or are disturbed, then the feature becomes a distraction.
In order to mitigate these difficulties, we recommend that the amount of motion-paralax be reduced. We need only a few pixels of change from one side to the other to detect motion parallax in an image. The current implementation may be giving too many depth cues to users.
Also, we suggest PLG tighten up the response time of between the mouse motion and the background changes. Since the head moves slightly to follow the eyes, and eyes generally move to follow the mouse, the position of the mouse on the screen can be though of as a very rough analog to the position of the head. In order to reduce the amount of simulator sickness experienced, we recommend reducing the amount of lag between the head position and the motion on the screen.
Project Looking Glass is Sun Microsystems' open-source exploration of a 3D desktop environment. The toolkit is Java based, and supports legacy 2D interfaces as well as new 3D applications. Project Looking Glass's framework includes, among other things, a client-server model for scenes and execution, an event system, and a 3D layout manager.
In general the project had very little documentation. It was common for the developers on this project to have to go to the Looking Glass source code to understand the toolkit functionality. Not only were the JavaDocs for PLG slim, we also saw very little code documentation within the toolkit.
PLG allows for objects to be translated, scaled and rotated immediately. But, often times in our interface we needed to have several objects move at the same time. We needed the ability to have one animation start after another had finished, or to delay the start of an animation. There was presently no way to do animation scheduling in the PLG toolkit. So, we developed a simple AnimationPlan component that allows us to schedule animations to our needs.
Part of our charter was to look at ways to integrate transparency capabilities into the desktop interface. However, we quickly found that transparency in the PLG toolkit simply did not work. At first, components drawn to the screen would flip in front of and behind one another. Every trick and workaround we tried did not help to alleviate this problem. So, in order to have our prototype function correctly, we went into the source of PLG toolkit and hacked it to turn off transparency altogether. We were still able to use a limited amount of functionality on our "glue" or "spread" elements, since the transparency was applied as a style.
Although many of our initial designs involved rounded interface elements, we quickly found that the PLG toolkit provided no functionality to help us draw curves. Even a simple Bezier curve interpolator would have been dramatically helpful to drawing shapes and lines in the interface. Because we needed curves for our "Fold" visual element, we implemented a very simple curving interpolators which use a simple Sin to produce a smooth transition.
The PLG toolkit currently uses NaturalMotionAnimation components to dictate how Component3D objects move from one place to another. However, we were unable to find a simple Linear motion component. This was quite frustrating since we assumed that a linear motion animation would be one of the first things a developer would implement. We needed objects to move together, so it was important for us to either use a linear interpolator, or an ease-in/ease-out interpolator. While the NaturalMotionAnimation did provided some visual ease-in/ease-out, it did not do so in a consistent manner that allowed us to use it to coordinate the motion of adjacent objects in the scene graph.
Most 2D interface toolkits implement some form of clipping. This feature is useful in so many ways. We needed it in our prototype to show only a portion of the contents of a list. There are many times in an interface where you want to show a portal into another world, and this simply cannot be done easily without clipping. Since PLG did not have clipping implemented, we had to do a fair amount of hacking to get the appearance that we wanted. We suggest clipping be implemented (to the pixel level) as soon as possible.