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 
You’re going down the correct path by focusing on actual use cases and personas. No one ‘needs’ to use the build floater. They want to complete various tasks. If you can come up with good basic types of users – including some that won’t use any of the needed functionality (or very rarely) – then it will be less confusing to incorporate new features as they appear from Linden. I think I can say that a fair amount of work was done on a “casual, consumer” persona within Linden, with attendant user flows and a great design. We often referred to it as ‘couch-pusher’. I wonder if they would be willing to release those designs to help y’all?
Your comment about how subjective more experienced users get is right on target. People often assign positive qualities to otherwise inefficient habits/muscle-memory. You might have more success by defining a persona to contain them and focus on a persona for someone who’s new, but wishes to start doing complex tasks.
Btw, talking about ‘tools’ at this level will short-circuit the process. Talk about what they want/need to ‘do’. Ex: Users don’t need a manip, they need a way to move and place objects in the world.
Obviously I could go on and on, I’ve been doing this exact sort of thing for similar types of users for years and years. I did believe that this was an important part of helping Second Life grow and was working on it. Best of luck.
LikeLike
Hey, Charlie!
The focus on use-cases is very clear in the discussion transcripts, and I agree that’s where the focus needs to lay.
Muscle-memory is a very worth-while mention as well: it’s perhaps the biggest factor in the great V1 / V3 UI divide – which I’ve always felt has been less about the actually “usability” (or otherwise) of the V3 UI and more about people wanting to remain in the comfort zone of only using familiar habits, efficient or otherwise. And I know that even as I write that, someone, somewhere is liable to be taking aim at me 😉 ).
Personas is an excellent suggestion, particularly as there is still a risk the approach being taken could end up re-focusing on “tools” rather than “needs”.
LikeLike
Thanks Charlie boy!
LikeLike
This work will be invaluable for an entirely different reason eventually. Sooner or later LL will have to address the problem of “low end systems”. Part of developing a lite viewer or cloud viewer will be deciding which build functions are really necessary. My opinion is Rez, Move and Stretch (all sides). With those 3 you can position furniture, etc. and adjust clothing and hair.
LikeLike
I’m all for a reassessment of the current build tools. After using them for five years, I’m pretty used to them. Happily I’m one of those users who feel change can be good.
I suppose my number one concern is that they stay out of the way of one’s view of the world while building. Although the current build floater is a bit crammed full’o’stuff, it does have the virtue of being relatively easy to tuck into a corner of the viewer window. That said, some stuff could definitely be pulled out into a separate floater, like the terraforming and parcel tools. I don’t think I’ve ever clicked on the Focus and Move buttons at the top of the build floater, as I tend to use keyboard shortcuts for those tasks. But then, my workflow definitely isn’t going to be universal (and I’m one of those whackos who think Blender is quite usable).
I’m also slightly skeptical of the value of simpler build tools. I’m not against them by any means; I think there’s real value there. The cynic in me simply doubts that many casual users are willing to put in the effort to do more than grab a handle to move those couches about.
LikeLike
I hope the remember 1 thing if the do something new. Make sure you need as less mouseclicks as possible to access all functions in the build floater. In that case the V1 build floater is not bad, agree in the years its a bit of seeking sometimes between viewers. Further i dont hope the go make the same mistake as what the did with the change from V1 to V2 GUI. dont pull to much at muscle memory.
A basic build floater, with a pull down for advanced options (that stay open when you did that once)
is not a bad idea. But dont make it to difficult to access the normal build tools.
Agree with marcus, if you dont show novice people there’s more then only moveing a prim. the possible never use the otehr functions.
LikeLike
Marcus already said pretty much all I could say about the Tools floater. Focus and Move: Never used. Terraforming: Should have its own floater.
For the rest, altho I find things relatively simple (I’m a Blender user too…), I wouldn’t be allergic to some changes as long as it doesn’t involve accordions. (That’s the worst thing that ever appeared in the viewer’s UI. Too much space wasted for the controls and not enough left for the contents.) I’d like nothing more to see the radio buttons corresponding to meta-keys disappear to see more useful information instead, like number of prims/object weights and number of faces, etc. And the Tools floater must stay vertical because that’s what wastes the least space on nowadays screens. (Just like Blender’s default UI.) Last and least, the OCD people in my head would like the Tools not to touch to the camera at all. I don’t remember when I disabled the option to re-focus the camera when entering edit mode but all the viewers I’ve used for over 5 years all still give a kick in the camera any way.
As for the casual users, instead of trying to make the Tools floater fit every usage, I was thinking of another floater with just 5 tabs: Move, Rotate, Resize, Colors/Textures and Contents.
On top of the tabs, some controls to choose in between the whole object or a child prim/mesh.
Geometry changes let appropriate handles appear around the object/prim and the least clutter as possible in the floater itself, especially nothing to change the prim shape.
Textures/Colors tab should use UI controls to select one or several faces. Preferably, color and texture selection should happen in the same floater instead of a separate one. Drag and drop should be possible to copy color/texture from one face to another. (Drag and drop doesn’t require much explanations… in general.) The maximum possible number of faces on a prim is 9. Only 8 for a mesh. That should fit in a not oversized floater.
Contents tab could stay pretty much the same. I don’t see much which could be removed. I would just add a very handy button to open/close the inventory. (I’d like very much to see the contents of all the child prims/meshes as a tree but that may be too much to ask.)
Even as a poweruser, I’d might use just that to do some quick changes, as long as all the mouse driven selection options remain available.
And in the end, I’d just take this new floater, merge the Move, Rotate and Resize tabs, add new tabs for the perms, the prim shapes and to rez, plus all the options that were left aside from the original Tools floater. That would be the new Tools floater.
Any way, right now, the major problem of the Tools floater is that it is too much hardcoded in the viewer itself and you can’t experiment much without having to re-compile the whole thing. Even a simple skin job isn’t that simple because (last time I checked) the Tools floater is a real… hmmm… labyrinth. Fixing this situation would be already a great improvement so that more people could play with re-skinning instead of a very few able to dig in the viewer code.
LikeLike
Well, After I read this post I had an idea. I’m going to lay it here, since it’s currently beyond my skills and because the more people knows about it, the faster it may happen. The only thing I ask is this one:
If you use my idea, GIVE PROPER CREDITS. Thank you.
So here’s the idea:
What I think is that the build floater shows too much, and all the time, regardless of the task we want to do.
There are ways to do pretty transitions in the UI interface, as Nirans Viewer shown it.
What could be done is that depending on what type of item we are editing, the details and controls shown in the floater would change. Example: When editing a mesh object, only show mesh-related details and controls and hide the ones we can not use and aren’t related (aka, cut, taper, skew change shape,) instead of simply graying them. The reverse situation too: If we are editing a simple prim, do not show mesh parameters that can not be applied on a prim. And for sculpties, well, pretty much the same as mesh; do not show skew,taper, etc.
This could make the buld floater smaller and more task-oriented.
To go further with it, we could even hide the prim editing options automatically when we go into the “move” move”, and maybe spawn a child/sub floater for the position parameters when going into edit mode, because we use it as well when editing. I’m thinking about this kind of modular floater. we could even add a “texture” mode beside the “move”, etc, buttons to do the same thing instead of having a tab. The idea would be to keep a minimal floater, a bit like v1/Firestorm did, but push it further by “expanding” and spawning child floater as we need them according to what we want to do instead of this bloatload if grayed details.
Phew. Sorry for the brick ^_^
In hope that I give enough ideas for things to change..
Miguael Liamano/Tarnix.
LikeLike
MHm, I’m sorry if there’s too much similarity with Riisu’s post, I in fact did not read it before I posted, to avoid involuntary plagiarism.
LikeLike
One last thing that popped in my head when I woke up: The possibility to grab the Tools floater and move it around is my number one on the list of the useless features. Half of the times when I want to select the contents of an edit field, I end up dragging the floater instead. I’ve never needed this feature. My Tools floater is pushed against the left edge of the screen and I waste a lot of time pushing it back there. Am I the only OCD builder around or should I create a group? 😉
LikeLike
in the past 1-2 weeks i´ve already announced to redesign the build floater completely again , which will most likely have a top-to-down layout again however , it will be moved , categorized and generally cleaned up, it will hopefully provide a way cleaner look , more space to fit everything in it , faster controls over stuff and most importantly it wont stay in your way which i think is the worst thing about the build floater, theres simply no place where to put it , its always in my way , no matter if its vertical or horizontal , minimized or not.
LikeLike
LikeLike