Customizable User Interface (Proposal)

If we can rebind keyboard input, we can effectively support additional devices if someone is able to convert their input to keyboard sequences (often this is provided as part of a device driver anyway). I'd be happy with this as a start. But eventually I'd still like to see better support for additional devices. I guess I'd better keep my vote on that proposal!

neko

Great, thanks Cienna! The fewer separate proposals the better, as a single generic solution is always better than a restricted one that can only be extended with the help of explosives.

And Neko, my guess would be that the extended device handling which you require would fall out quite naturally from a generalized UI of the type that we have been discussing here.

If a user-programmed client-side language can activate LL-defined API actions then it can also obtain input from or be triggered by independent local devices. And if mouse and keyboard events can be dynamically reassigned from their LL defaults, then there is no reason in principle why these standard input devices cannot control other subsystems instead, or conversely, why other input devices cannot take their place as inputs to SL.

The key paradigm that is needed to make any of this work is that everything on the client box is under arbitrary programmed player control, while everything on the server is under LL's control and we can only get at it through tightly restricted APIs.

That client/server and player/LL split is the only one that makes sense anyway, especially for an unrestricted world like SL. The attitude of some content providers that the machine we have paid for is merely a closed delivery platform for their financial benefit is, erm, well, clueless.

I hate to be the first voice of dissension (wait, no I don't!), but I would much rather LL overhauled the interface, improving its usability, visual appeal and OS-standards compliancy as opposed to letting anyone write their own "skin."

While I personally would have fun with this feature and probably would toy around with a few of my own, I firmly believe LL is in the position to do it better than I could. A good interface designer with full access to the development team could do wonders for the user experience.

Handing this ability over to the users will result in a few good interfaces, and a lot of bad ones. New users will download the ones that are popular or have the most colorful/Photoshoppy buttons, and end up with usability and/or reliability problems, giving them a bad impression of SL as a whole. Even if the good ones get popular, they won't necessarily match the ones shown in official SL documentation/training (we will have that someday, right?).

I fully agree with Cienna that there are limitations, particularly having to rely on chat. But could you imagine the confusion of implementing different methods for different users? I can see the product ads now: "Super Retro Stereo, plays all music streams! Warning: you must have slskin003.skn installed, version 0.38b or higher." Or how about when you try to show a new user how to get the box off their head? "Okay, click the Remove Box button. Oh, you don't have that? You must be using the default interface. Okay, listen carefully..."

Nothing personal against anyone who supports this idea. It really does sound like it could be fun to customize the experience, and could make things better on an individual level. But on the whole it's up to LL to do the work, and improve our UI experience, while maintaining compatibility with all current and future features.

I think it's important to state that this proposal does not cover merely "skinning" the UI, but essentially would mean open sourcing the UI component of the SL client. Everything from simple skins to entirely new behaviors would be possible.


You're pretty much right on here, yes there will be a lot of new complexity. To draw on the WoW comparaison again, this is exactly what has happened. There are a few packages, a single set of modifications designed, tested, and supported by a team of individuals who just happen to not work for Blizzard. Most people start out with one of these, be it Cosmos or another. Other people like myself strike out on their own and build their own set of usable modifications and handle their own support.

One (sad) thing that would probably need to be taken as a policy would be one of "provided, but unsupported". That is, one of the suggestions by LL customer service would be to remove all UI mods to see if that fixes the problem.

One brilliant idea to help alleviate some confusion is having modifications exist in-world, and the Super Retro Stereo could offer you its custom UI elements the first time you use it (and handle upgrades as well, much like many script writers do already). The support question is valid as well, and should be dealt with. Presumably one should assume that the other users is dealing with the default interface, and work from there.

I don't think it would be in LL's best interest to completely hand UI development over to residents. As I mentioned earlier it could be thought of as an open sourcing of the UI layer; in all likelyhood you may see some residents changes and fixes to the base UI folded into the Linden supplied one. This is no small proposal, of course but I think it is somewhat vital. When you think about it, as a resident you can do anything you want within the limits of the world, anything you want outside the world, but the missing piece of the puzzle is doing anything you want with the client, within reason.

It's actually not as complex as it sounds, Lora.

Every client system takes inputs from its user control devices and then generates outputs from those inputs to send to server-side. The first step in creating a customizable UI is simply to break the direct, predefined link from inputs to outputs, and turn it instead into a 3-part linkage from inputs to actions to outputs. The links are made explicit, defined in a modifiable form.

Doing so then allows inputs to trigger user-defined actions as well as the default ones, so that the expanded set of actions can now trigger the outputs defined by the API in more ways than previously available.

Add to that a client-side programmable language to extend further the way in which inputs are handled and actions are generated, and the sky becomes the limit.

And yet Lora, there would be no additional complexity visible to those who wish to avoid it, because by default those original inputs would be coupled through to their original outputs in the XML forms, so the unambitious user need see no difference at all, in principle.

It's good for new users and the more advanced ones alike. And it can even reduce the dev burden on LL's shoulders, because calls for UI changes would become far fewer when the UI is not hardwired by LL.

Thanks for the responses Cienna and Morgaine.

The problem isn't technical, it's centered around user confusion and Linden support. If someone comes up with a brilliant solution to a UI problem, it doesn't matter if it's not in the standard, shipping client UI.

I'm not dead-set against the idea. It could work, but only work if LL incorporated the good changes into the default UI, while still controlling the overall experience, especially for new users and people who just want to have a good out-of-the-box experience.

Although I've not seen this done anywhere, it's interesting to note that one of the things that become possible with customizeable and switchable GUIs is to switch in a noobie helper GUI to make all actions plain and simple through direct menu selection and wizards for everything. It wouldn't give a fast method of interaction, but it could flatten the learning curve immensely.

Taking this even further, a diagnostic assistance GUI could be provided as well, in which an LL support person could interact with the client's GUI via a control or instructor's channel, either for explaining how things are done or for problem diagnosis.

Just about anything is possible given client-side programmability.

Cory talked about this a fair amount at the town hall last night.

Hiro Pendragon: When can we expect an API for the GUI so that we can customize it?
Cory Linden: Not in 1.7 but hopefully for 2.0 . . . very high on our list of new features once we are on top of bugs.
...
Cory Linden: Building that API is a lot of work, but I would agree that in the medium to long term it is critical that we better leverage the enormous talents of our residents.
...
Icon Serpentine: Is an expanded keyboard control interface in the development plans between now and 2.0?
Cory Linden: yes, but on the 2.0 side of "between now and 2.0"
...
Catherine Omega: Are there plans to expand the XML control over the UI, and if so, what would it take to get a simple way to create a toolbar that would allow us to llSay text on a given channel? It'd be great for games and the like.
Cory Linden: The UI overhaul (2.0 timeframe) is very much focused on these changes. We want objects and experiences to be able to customize the UI as needed.
...
Cory Linden: there are downsides to making eveyrthing an options, but the more flexible we make the UI the more likely that someone will be able to make it an option if they want to

Thanks to Kex for posting the transcript.

neko

I would like to state for the record that I fully support this idea and so should you!

Everyone's needs are different, and giving us the ability to customise things to our own needs makes things more productive. I, for one, would like to have the ability to rez a box and sit on it with a single click/mouse gesture/hotkey... Why? just because! I want to be able to change my GUI so it's just as ugly as the beta GUI... ;0 and I want tiny little widgets that make fart sounds arayed along the side that I may click to my hearts conent..

Not only do I support this proposal, but I think it is essential to make this happen if SL is ever to become a worldwide used tool.

Is the current date for 2.0 any closer, or is it still at the end of the rainbow?

This proposal still needs your support ;0 !!!