UI Forum Transcript

Summary of discussion about Viewer UI Thursday 12 July 2007

Welcome and Overview of UI Plans

Glenn Linden: Hello and welcome everyone. Thank you for joining us today. We've got Benjamin, Steve, and Stephany here from our Viewer UI team to get your input into the UI.

Steve Linden: So, first off, I am planning to discuss what we are working on with the User Interface in general and would prefer not to get into specific interfaces like inventory or the build tools (which are also a special case and merit an entire discussion to themselves) I was hoping to have a wiki page available for this, but have been busy orgainizing projects internally and have not yet put it together, but I will have something this week and we will announce that to the list.

To summarize what will be on there:

• Our objectives are:
  • Improve the customizability of the user interface for 3rd parties and for individuals
  • Provide a frramework for lightweight clients
  • Improve our ability to make the user interface easier to use, more attractive, and generally better

Steve Linden: The projects that we will be tackling intially will be:

• Clean up our UI components and the XUI (XML UI) interface
• Document XUI
• Make "skinning" (customizing images, etc) easier
• Allow changes to be preserved across updates, i.e. provide package and individual directories for UI customization

Steve Linden: Questions so far?

Customizability

Franko Corleone: when you say "customizability" for 3rd parties... does this mean for example custom keyboard layouts for specific uses etc.

Steve Linden: Yes.

Franko Corleone: and would it be possible to secure those layouts across sessions

Preferences

Eloise Pasteur: Will that include good preferences, like for window colour, text colour in IM history, chat history etc, as well as the XUI ones?

Steve Linden: Yes.

Saving sets of profiles

Franko Corleone: and would it be possible to..as example...save a limited No. of such profiles..perhaps attached to group or similar?

Steve Linden: Anything that can be easily made data driven, or is currently data driven, will be, and the data will be "layered" so that we provide defaults which can be changed by a 3rd party "package" and again overridden by individual preferences. There will be an XML file that specifies a load order for XUI files which can be customized

Simplicity vs Improvements

Cezary Fish: You know, I am really worried about "improvements" cuz what makes SL so special is its simplicity so far......

Stephany Linden: We hope it will help localization - and prevent overwrites

Franko Corleone: yes thats the sort of thing im thinking of

Localization Profiles

Franko Corleone: localization profiles

Steve Linden: So by default we will load skins/xu/en-us, then the local language files, then any installed package files, then the per-user files. However that order will itself be customizable. The only caviat is that in the near term, all settings will be machine local, so your UI customizations will not exist if you log in from a different machine

Eloise Pasteur: ok

Franko Corleone: thats fine

Cezary Fish: Mabe I am just a simple mason, but I prefer that you make the things work the way they should instead of OVERRIDING, XML-ing, and WHATEVER-ing them :)

Steve Linden: Now this does not mean that we will not continue to fix clear bugs

Mac GUI Guidelines=

Eloise Pasteur: And any chance of the Mac client meeting the mac GUI guidelines?

Steve Linden: Eloise: we will probably not make mac specific improvements right away

Languages

Franko Corleone: so a specific language file could in fact then be released individulaly rather than across an entire update for example using this model;

Steve Linden: So our intent is to allow external developers to provide options

Franko Corleone: fr example...if i had a thai language graphic/l;ang file to use

Consistentcy

Cezary Fish: The idea is simple, they should work the way they were intended to....

Steve Linden: But as to "the way they were intended" that is not always obvious, even internally.

Cezary Fish: I would like to be able to find any texture no mater what number the client has, this is my dream for now :)

Steve Linden: Our intent is to fix inconsistancies and make the behaviors explicit so that they can be tweaked and tuned by both our internal designers and by external groups, i.e. not just programmers

Sitearm Madonna: Steve, yes another question, "will it come in any other color than "black"?" (obscure henry ford joke sorry)

Steve Linden: Franko: yes, part of the plan is to be able to have external localizations, including graphics. etc.

UI Improvement and configuration

Steve Linden: But actually, we have designers like Benjamin here who are choming at the bit to improve how our UI looks. So you can bet that shortly following our intial cleanup stage we will be pushing out a new improved look pretty quickly after that

Franko Corleone: i thinkits time the user should be able to change the background color of the communicate dialog box

Steve Linden: And we hope to also see external "skins" much like you see for programs like winamp, mozilla, etc

Benjamin Linden: I'm a big fan of clean and simple

Franko Corleone: skins for the communicate box would be cool in the voice ui

OK, looking a bit further ahead...

Steve Linden: After skinning, we are going to be looking to actively engage the development community to help with a more involved project, but one that will lead us towards what many folks have been asking for. which is a better way to create a custom client or customize this one

Steve Linden: The first step in this process I am calling "Data Driven User Interface". The idea here is that not just the layout, but the actual functionality of the UI comes from the XUI files. So for example, the "Search" button on the overlay bar (bar on the bottom of the screen) will have no code associated with it ; the data itself will tell the client to "open the search window". That is a simple example, and we will tackle those first, but eventually everything the UI does will call into a well defined API

Profiles

Franko Corleone: given that model, certain tools etc could be...by default in this model as a profile...be loaded at login

Franko Corleone: and such setups could be changed as a "profile"; am i right?

Steve Linden: Correct. Anything that the UI can do will also be possible from a console in the client and from a batch file that gets loaded at login, or whenever

Eloise Pasteur: So I could force logging in with my edit window open to the contents tab and in the right place?

Steve Linden: yep.

Franko Corleone: Exxxcellent!

Eloise Pasteur: Can I have two to go please?!

Scripting the UI

team23 Mascot: I'm not sure if anyone requested the same thing, but when editing a script can ctrl + f bring up the word search(for the script editor) instead of the gobal search?

Franko Corleone: this is a definite advantage in a number of ways for educational use

Eloise Pasteur: Yes, absolutely

Steve Linden: Now, initally this will be limited to one line commands, like "openWindow(""search", "people_tab")" (or whatever, we haven't defined the syntax)

Steve Linden: Actual scripting with logic like if (optionSet("search tab") == "people" then openWindow ... ) would come later

Franko Corleone: openwindow("search","people_tab","USERNAME"). i like it

Steve Linden: Sure. In fact, it should also be possible to get arguments from other UI components pretty early on in the development process. So openWindow("search", "people_tab", field("person_picker"))

Franko Corleone: what about position of overlay bar top bottom left right ? or components thereof

Steve Linden: Sure. The overlay bar could be bigger, have as many buttons as you like, show up on the side of the screen, whatever

Eloise Pasteur: I know you're still working out the details, but positions of the windows would be nice to have in the calls

Steve Linden: Eloise: sure. The syntax will proabbly be pretty flexible, where you could call openWindow("name=search", "layout=10,10,200,300"), etc

Franko Corleone: location by xyz too easy loveit

Steve Linden: And there could be more than one (although the one on the bottom may be a special case since volume controls, etc are attached to it). At least for a while

Franko Corleone: yup, the concept we have, is a UI with the selectables for specific calls to educational examinations, so the UI is loaded spefically for an examination; each layout having specific buttons etc for the relevant exam being undertaken

Future Possibilitiles

Steve Linden: So, here's where it gets interesting... After we get that out the door, we start letting the UI communicate with external elements, for example, an LSL script. So a LSL script could create a window, provide the XML for the layout, and communicate with the components. At this point we are talking Q4 at best, depending largely on how well we are able to engage outside resources to help with the conversion of our existing UI to use the new architecture. But at this point, the possibilites start to get very interesting.

Franko Corleone: will it need a base graphics engine change to implement this? or will it reside in the existing architecture as an addon / update?

So how can developers help with this?

Steve Linden: The first couple of projects, cleanup and skinning, require a lot of familiarity with our client code, so we are not expecting to be able to leverage a lot of outside resources on it. However, once we write the foundation for the data-driven model, there will be a lot of work converting all of our existing UI to use the new system. At that point I hope to leverage a significant amount of help from the OS community. For now, mostly we will be asking for feedback along the lines of "Is this the right set of priorities" and "What else should we be working on *now* before tackinging some of these valuable but complicated projects". So I will be putting up a public wiki page soon with this plan outlined. We will announce that to the group and solicit feedback, then keep you up to date on the inital internal projects. Maybe try to put together some smaller projects fopr the OS community based on feedback, and then actively engage the community for contributions once we get past the cleanup stage.

Franko Corleone: i can see this being a long term bonus with a long term development path, but extremely worthwhile to many groups

team23 Mascot: ;)

Steve Linden: Any more questions before I give my fingers a rest? :)

Glenn Linden: Great, Steve, you've given us a wonderful overview of the direction.