Vision

The main aim behind developing swooplet is to improve the user experience (UX) for configuration tools in Second Life®. As we work to achieve this, our commitment remains unwavering in preserving the complete privacy of all swooplet users.

Higher Standards

In Second Life®, we prefer products with abundant features and customization options. We value the ease of personalizing our experiences and appreciate visually appealing configuration tools. Additionally, we prioritize speed over sluggish and unresponsive products.

The HUD-making Challenge

Crafting a user-friendly interface in Second Life® requires significant effort and skill. Despite our best endeavors, the interface falls short of commonly recognized standards for user interfaces due to the absence of fundamental features such as hover-over reaction or scrolling response.

As we strive to enhance the user interface (UI) in Second Life®, the cost of improvement becomes increasingly apparent. We have to split the code into more and more scripts (mini-programs confined to 64KB of main memory). The more scripts we add, the more challenges arise as we deal with asynchronous execution. Eventually, the maintenance and refactoring of the HUD's code becomes harder and harder. The lack of built-in testing capability means ensuring that nothing is broken after a small change in the code is only possible through a tedious manual testing of every HUD feature.

Also, to make the HUD load resources on demand is practically impossible. If the HUD is made with mesh, every piece of it needs to be loaded fully. The loading of the texture resources can be postponed until needed, but then assets show blurry while loading or even get stuck in partially loaded state. Cached textures allow to display them instantly, but then users receive a notification indicating that a particular HUD exceeds the expected memory usage.

The Product Updates Challenge

Another challenge that developers in Second Life® face is the overall lack of mechanisms for the seamless replacement of scripts and mesh, which are the fundamental building blocks of HUD-based user interfaces in Second Life®. Without those mechanisms, delivery of bug fixes and the addition of new features can be significantly delayed. How many times have you postponed accepting a new version of a product, fearing that all your settings would be lost?
In contrast, web technologies help ensure that the latest version is always in use. Occasional upgrades to the main product might still be necessary, but the process of iterating between UI feature changes and bug fixes requires no effort from the end user.

Examples of Hot Fixes

There is a growing list of UI improvements and bug fixes. It is available separately on the Changelog page.

Additionally, here is a list of data-related modifications that can be made after the product is released and delivered to the customer:

  • Adding new texture choices with automatic notifications regarding the availability of new items.
  • Ability to provide tags and labels to choices or fix them.
  • Ability to add uniquely purchased items.
  • Enhancements to the logic of the randomizer.
  • Hot fixes of errors in textures such as accidental inclusion of a temporary texture, forgotten material maps.
  • Improvements in the overall look of the textures and initial settings, hot fixes of alpha layer glitches.
  • Prevention of modifications that can break the product.
  • Separation of left and right side customization (provided the mesh was built for such possibility in mind).
  • Automatic notification of a new product version with a note of changes.
  • Keeping the store locations up-to-date. Maintaining the 'events' list.