Customizable User Interface (Proposal)

I'll start out with the short version:
Copy the interface system of World of Warcraft as completely as possible.

Long version:
World of Warcraft (WoW) has an extremely customizable user interface. It is built on a combination of 3 things:

1. XML Layout Definition - Simply a set of XML files defining the core of the interface. These follow object-oriented inheritance to allow for predefined UI elements. In the XML definition you define the layout, art assets, and behaviors through a robust set of tags. These are loaded when the game starts, or anytime a scripting language call is executed.
   
2. Lua Scripting - Since the XML definitions are static, dynamic behavior is introduced through a Lua scripting runtime. With a combination of Lua builtins and Blizzard provided libraries the client UI can perform some fairly amazing feats. Of course, in this sort of MMO environment things are heavily sandboxed, and interaction outside of sanctioned methods is minimal.
   
3. Assets - Art assets, font assets, sound assets, etc. Simple enough.
   

The beauty of this is that when you install WoW, you are installing along with it the complete source code to the default UI. Modification is easy, accessible, and most of all encouraged. The AddOn system allows for modular expansion of functionality, instead of forcing users to manage conflicting modifications to the core UI files, which would optimally remain unchanged.

How would this relate to SL? To put it simply, user interfaces inworld suck. The most efficient is a chat-based UI; for example my glasses change color by using the supplied gesture to parse "/sg color blue". This is great for simple things, but as you try to scale to more complex interfaces you quickly run into the limits of the system. The end result is either arcane /commands, a system of many prims to handle touch events, or the very limited llDialog—which is essentially a slightly prettier front end for arcane /commands.

Giving us the ability to add on to the client UI would allow much better experiences for inworld objects and items. Being able to extend the default UI and change behaviors would allow for things which the Lindens may not have though of, or do not wish to implement. Imagine being able to modify the events listing so that you never see another Tringo event again (with a user-made filter). Imagine taking control of your friends list and only seeing online notifications for certain people (by suppressing the client's display of people you don't like). The possibilities are endless.

To close I'd like to point out an example of a WoW UI addon, to show off the ingenuity of a userbase when give this kind of power. This is one I use a lot, it's called simply Gatherer. With this addon installed, whenever your character collects from a resource node, it remembers where you did that. But then, via being able to extend the Blizzard-supplied UI screens, it shows you on your radar/minimap, as well as your overhead large map, where those resource nodes are. While we don't have resource nodes to mine in SL, there are still many things that can be done to improve the UI we'd be given.

This can be found in the voting system as Proposition 120

What do you think of my proposition to create user interfaces? The experience could be much more immersive.

/54/21/42870/1.html

I support this product and or service
----------------------------------------

But I have some additional ideas related to it. We live in a live, streaming environment, right? Why not have the interface modules transportable in world, and activatable like clothing or gestures? This would allow people to ship control panels for their product along with it. While I can see the downsides like malicious coding and overcharging for Interface modifications, I think the benifit of being able to trade UI peices would be worth it in the end.

~ le-stamp! ~

Personally I want to get as far away from LSL as possible. Client side prims don't handle modification of the base UI either.

Exactly my thoughts as well. The first time you attach something it could offer you a UI bundle that would get installed locally (after confirmation, of course).

To avoid problems with malicious code, etc just leave the files open and viewable. While not anyone has the capability to review the code, there are enough crusaders out there that would inspect every UI addon they come across, and let us know vocally what they think of it.

Would your super flexible and powerful customizing system enable me to eliminate mouse glows when the cursor is over control objects, and allow one to seamlessy integrate and external text editor such as Scitez (with it knowing about where syntax errors occured)?

Would we be able to affect the name tag display( i suspect not) ?

More concrete examples might garner your idea more support.

In theory yes, it could. It all depends on what is exposed for customization. I suspect some things may be tough, such as the editor integration. You wouldn't want to do that entirely in the UI scripting language; it would be more suitable for a client API for lower level integration. However the other two examples would likely be in the realm of possibility. Again, it all depends on how much control we are given with a system like this and how much is 'hardcoded' outside the UI framework.

all ten of my votes are already dedicated to this proposal.

OK, I voted for #120 too. I hope it does well!

Cienna, I'm extremely interested in UI improvements --- all 3 of my sig links are in some way related to that. However, because my interest stems largely from wanting SL to become more interactive to host sports and other rapid activities, I would like the improvements to cover not just windows, panels and other visible objects, but right down to every single mouse and keyboard press and release.

In effect, I want the user to be able to define her interaction environment wholly, still restricted to the in-game actions that the world designers allow, but activating them in whatever way the user wants rather than only in the way the designers specified and no other.

One such area that needs major improvements is binding of keyboard and mouse actions --- our existing interface is basically useful for building and not much else.

For example, I want to be able to disable the existing right-click and left-click actions when I enter some game or sports zone, and replace them with more appropriate UI actions. This might include chorded actions like, for example, "Hold down right-mouse to activate Mouselook, and while it's held down, hold down left or middle button to Move Forward". Although it's just an example, it will be familiar to many as the mouse-only full navigation mode in two major MMOGs. If people want to set up their gaming interface to use keyboard/mouse controls which are second-nature to them, they should be allowed to do so.

My long-standing General Mousebutton API proposal allows that kind of setup to be configured trivially, and also provides a very flexible and extensible hook system for interacting with world objects in arbitrary programmable ways. Does the WoW-style interface which you have proposed allow this too?

If so, this would be terrific. If not, can we merge the two ideas?

They could easily be made to modify the base UI, if they ran client-side scripts.

LSL is a perfectly usable language in this context and pretty much everyone in SL is already familiar with it to a lesser or greater extent. I would prefer Lua by a mile of course, as it's enormously faster, hugely more flexible, extremely easy to embed and sandbox, and very readable. But LSL would do, if LL don't want to bring in a new language for UI control.

As for the Javascript mentioned in your proposal entry, I can cope with any language, but this is one I'd rather leave behind in the world of web pages and not see here. If LL admit a new language, let's make it Lua --- which is used in a huge number of other games, and even in our beloved Open Source Metaverse Project. It certainly is the future of embedded languages for game scripting.

Here's a link to the main Lua site for those not acquainted with this beautiful little language.

I voted for this. I, too, hope the general mousebutton API, or preferably, support for a wider variety of local input devices (joysticks, steering wheels, and of course, my favorite, biometric devices) can be integrated with this proposal.

I'd like to say, though, that while I'm fine with Javascript, it's not as stable or standardized as I would like. ECMAscript would work, I suppose, but I'd just as soon have Perl.

But any externally supported language that would let me test compiles while offline would be great.

neko

I don't think that LSL would be appropriate without massive extensions and better performance; it is simply not a general purpose language, but a domain-specific (SL objects) scripting language. It doesn't have the qualities of Lua you mention. For performance, running full out on the client without having to share a sim with other scripts might help.

As for client side prims, I think that gets down into a semantic for packaging. One of the obvious strengths would be what Chibi mentioned here, being able to load UI extensions into the client from the world, as opposed to directing the user to an external webpage. "This object would like to offer you an interface modification, do you accept? Yes/No" sort of thing.


Ignoring the fact that Javascript (ECMAscript, standardised) is a completely misunderstood language due to bad browser implementations, I don't mind Lua either honestly. They both get the same job done in very similar manners. I suggest Javascript(ECMAscript) since it follows the C style syntax, is just as flexible as Lua, and much of it would be familiar to anyone who has done web pages. Without having to deal with multiple implementations as you would between IE/Moz/etc it is a thousand times 'better'.

From another thread:



The reason for the comparaison with WoW is twofold. First, it is the best implementation of this sort of customizability and extensibility in a game-type environment that I have personally seen and used. Second, the game itself is exceedingly popular, and within the WoW community UI addons are used and embraced by a large number of people. Thus more people here are likely to identify with it than if I had just said "An XML defined, script driven UI with hooks to the SL world for communication and manipulation".

Plus every time I bug a Linden about this I say "clone WoW's UI"

As a side note, it may help to explain my personal vision of this sort of thing as a triangular system. You have 3 points: inworld objects with LSL, clientside UI definitions with ECMAScript/Lua, and outside entities. Ideally all three of these would be able to communicate with the other two, allowing the developer to leverage only what is needed. Some things may be best served by only a client/world interaction, such as robust preference setting or control of scripted objects without the need for listens. Others may only need world/3rd-party interaction (what we have now), such as MetaAdverse signs or (gasp) land scanners. And still more may want require all 3 working in concert.

I thought of this after I posted last night, and this was the conclusion I came to, as well. It's widely known and fairly flexible. We just need to work out how it will save and read files, presumably on the client side, without violating privacy or security. But that would be an issue regardless of language. Actually, it might be better to have all the data storage on the server after all, so that you get the same UI modifications if you log in from somewhere else....

neko

There would definately have to be sandboxing done. To return to the WoW example, they provide you with only one method of persistant data storage via saved variables. At no time while the game runs can a UI script write to disk, it simply registers variables to be saved which are written to disk when the user logs out or reloads the UI layer.

Within the SL world I think there is less concern of functionality limitations than in the WoW world since it is (I would hope) a less directly competitive environment. I mean there is no place for a limitation such as "spells may only be cast in response to a button press, and there may be only one spell cast per button press". But obviously something like "the client cannot query the position of another user on the grid if you don't have them as a friend" would make sense.

Cienna, you answered my side-points about the embedded language, but not the far more important one that I raised in the preceding post.

A customizeable UI that didn't deal with interactivity via input devices (especially flexible and dynamic mouse and keyboard bindings, including mouse chording) would be cool but wouldn't get us very far in an environment where so many people (including Philip) want to see hugely diverse and immersive interactivity.

That's simply an API issue. LL will simply provide an API of commands which can be activated via fields in visible XML-defined panels or directly through the client-side scripting language. While it's up to us to decide how and when to activate those commands, it's up to LL to define what they do and don't do.

It'll be quite different to WoW even if it "clones the WoW interface", because as far as I know WoW doesn't have user-defined prims which run scripts. We'll certainly be wanting our set of XML-UI API commands to include messaging to our in-game objects --- the number one requirement being to talk to our attachments of course.

I don't see any reason why it couldn't encompass a wide range of input devices. I think it would likely make sense to begin as an XMLified version of what we have right now, i.e. keyboard/mouse only, the same look and feel for the interface, etc.

Right. Like I mentioned to neko the WoW example is one easily accessible as the type of interface to have, an exact clone of what they give wouldn't make sense. The needs of the two environments are going to be different. Perhaps it would be better to say "come up with a World of Warcraft style customizable interface" rather than just "clone it". ;)

I give you 2 votes ;0 Be happy!

I stamp this three times, twice in my name and once again in Baba's.

I approve Oz to stamp any topic in my name, as long as it is also stamped by himself.

I was hoping for a stronger position on this, like perhaps "Yes, an XML'ified UI must include means to dynamically rebind mouse and keyboard inputs through the XML interface, since those are a fundamental part of any UI".

Obviously the default bindings would provide the same functionality we have today.

Oh, I apologize. I misread what you had stated (and never followed through on linked discussion) thus assumed you were speaking of a generalized input API for more than mouse/keyboard devices. Now that I understand; yes, an XML'ified UI must include an extensible means to dynamically rebind mouse and keyboard inputs to whatever the user would wish, whether it be UI elements from the base UI or user-created addons. This would be a fundimental part of any UI but especially important for a user-extensible one.