As I reported a while back, the Content Creation Improvement Informal User Group has started looking into the matter of the Build floater.
Like many things in the viewer, the Build floater has to cover many tasks, some of them quite basic (moving a lounge chair across a room) through to very complex building and texturing activities required by content creators. Over the years, this has led to the Build floater becoming considerably more cramped and complex as options, capabilities and tools have been added to it.
Even redesigns of the UI – as with Viewer 2.x and Viewer 3.x have brought with them issues of their own. Some of these are code-related, some of them are very much impact the usability of the floater, e.g. localisation problems wherein languages other than English don’t readily fit the floater size and layout, etc.
Some TPVs have sought to tackle the issue over the years, but efforts have tended to revolve around working with the constraints defined by the current Build floater, rather than looking what needs to be done in order to make the use of tools traditionally grouped together as “build tools” more task-oriented.
Firestorm and Phoenix, for example, have retained the old V1 capability of being able to show a minimal toolbar (remember the MORE and LESS options on the old, old Build floater?) which can be used to perform basic object movement and rotation tasks without having a plethora of additional information thrown at the novice user.
Niran’s Viewer has also sought to address how information within the Build floater is presented: offering it in a left-to-read format which is potentially more readable for many people as it is easier to visually scan.
However, such approaches suffer their own drawbacks. Niran’s Viewer may present the information in a more logical left-to-right flow, but this is really a cosmetic change rather than a fundamental shift in emphasis in how the tools are presented in terms of user needs as opposed to content creator needs. Similarly, the Firestorm / Phoenix approach retains the minimal information approach from Viewer 1.x, but again, even this potentially contains too much information for, say, someone merely wishing to pull out a sofa and position it in their lounge or who wants to adjust the location of a bracelet attachment on their wrist.
The CCIIUG is therefore looking not so much to redesign the Build floater itself, but what needs to be done to present options and tools more logically, such as through one or more floaters that could eventually replace the Build floater as we know it. As such, the Group has been discussing requirements in terms of use rather than function:
- What tools does the lay user, with no interest in content creation, need to be able to see and access in order to complete the simplest of tasks such as the aforementioned positioning of an in-world object or to resize an object (in-world or attached) to suit their needs?
- How can these be presented in a user-friendly manner that doesn’t swamp the “consumer user” with information superfluous to their needs
- Where does the cut-off come between “basic” tools (as described above) and the more advanced tools generally the preserve of the content creator?
- How should the more advanced tools be presented?
These are actually tough questions to answer as they cover very specialist areas, code design, UI design, etc., as well as a need to clearly understand what “consumer” or “novice” users actually require (itself a tough question for anyone who has been engaged in Second Life for any reasonable length of time, as views naturally become more subjective as time passes). However, the work is potentially pertinent for a number of reasons:
- The Build floater is seeing more and more being pushed into it as functionality within Second Life continues to be enhanced with new tools and features – mesh saw the additional link and pop-up panel; pathfinding has seen the addition of new information panels, etc.
- It is thought that there may well be a further change pushed into the Build floater as a result of “something new” (no specifics available) coming down the line
- Even if any new approach coming out of the CCIIUG isn’t adopted by LL, as it amounts to UI improvements, as so long as it does not impact how the in-world experience is shared between viewers, it does not fall foul of the TPV Policy, and so TPVs will be free to adopt whatever improvements may arise from discussions if they so wish.
A working party within the CCIIUG is being formed to look more closely at the matter, and with a view to putting together mock-ups of ideas as to what a new Build tool UI might look like. As such, input is being welcomed from both TPV developers and from users in general on the matter, with the aim of eventually presenting ideas to Linden Lab at some point in the near future.
If you’d like to be a part of the working party, you can join by attending the weekly CCIIUG meetings, held every Tuesday at 15:00 SLT at the Hippotropolis Auditorium. Information on the Build tools discussions to date, please see the links below.
Inara Pey: Living in a Modemworld 