Talk:User Interface Improvements

Problems with current UI (moved from main page)

(These are just gathered from comments on the forums, and ones I've heard from helping new users) -- —The preceding unsigned comment was added by Benjamin Linden

• User interface is rendered as part of the standard frame render cycle. Thus it does not use recognisable OS-standard components and lags whenever the sim does. Could seperate this to use a general platform-independant kit (wxWidgets?) - although a lot of work!

• Users confused by a plethora of options that aren't related to their current situation. A user with no interest in content creation still has to deal with a huge number of related options on the pull-down menus. "Build" button on bottom toolbar is the only thing there related to building.

• Too many valuable items are on the client debug menu. I've seen several Live Help calls in which users are sent to these menus! If they are needed for solving technical problems encountered by regular users, they shouldn't really be part of an "easter egg".

• Mac OX X complaint: Mac OS X implements right-clicking with Control-click. The Mac OS X SL client implements right-clicking with cmd-click.

Advantages of the current UI

• User interface is rendered as part of the standard frame render cycle. This allows for innovative gui components not present in the OS such as the pie menu, which is much easier to navigate than OS-standard context menus. This should be leveraged to design gui components for a virtual world, rather than going backwards with 2d OS controls Kaworu Jun 13:30, 15 August 2007 (PDT)

That is a disadvantage as well. On the Mac, at least, lag in the viewer makes the UI completely unusable at times. In fact, it seems to make the UI of the rest of the Mac unusable as well. 15:51, 15 August 2007 (PDT)

• Current user interface is easier to deal with for building than a more videogame-like interface would be, since elements like editing and inventory windows can be freely moved, duplicated, and resized. On the other hand, since these *are* windows, many of these UI elements could be rendered in the native GUI toolkit in separate OS-level windows rather than in the UI. which would allow them to be positioned around the SL window in multi-window mode. Argent Stonecutter 18:38, 15 August 2007 (PDT)
• Current user interface is largely consistent, though this has wavered at times. Designing a new consistent UI is likely to lead to more of the kinds of problems that have caused so much protest over the past year. Argent Stonecutter 18:38, 15 August 2007 (PDT)
• One of the major advantages of the current UI is immersion. The UI has been tailored to the needs of a virtual experience. There are innovative things like the pie menus, the UI interface is usually designed to be visually lean (slim window titles, slim tabs, etc. ... for example a window title is about half has high as a standard Windows window title). Nicholaz 06:48, 18 August 2007 (PDT)
• On an intuitive level, it generates a separation between out of world and in world. Having OS dialogs float on top of the window or even outside the window, especially for operations which are related to in-world, would have the tendency to reduce the experience to a mere animated wallpaper for a fancy chat client. (The only dialog where I could imagine an UI dialog are preferences, because these happen on a meta-level anyway). Nicholaz 06:48, 18 August 2007 (PDT)
• Another benefit is that it leads to a consistent experience across platforms. Nicholaz 06:48, 18 August 2007 (PDT)
• Yet another benefit is that window clipping leads to performance reduction. Simply run a windowed viewer and watch the FPS by partially covering it with native windows. Nicholaz 06:48, 18 August 2007 (PDT)

Considerations for the proposed UI

• Many of the existing floaters, particularly the building ones, should not be radically changed other than possibly making them first class OS level windows. Don't abandon the parts of the user interface that currently work. Argent Stonecutter 08:13, 16 August 2007 (PDT)
• Users are generally used to Menus so removing the Menu entirely may not be recommended given that it may not be possible to reproduce all the functionality there. However a better reorganisation of the menu, and possibly having the menu contextual and hidable would improve things. May even take some ideas from the MS Office Ribbon bar. Matthew Dowd

I was with you up to the point of the ribbon bar. Having a universal menu that contains all options and operations should not be discarded... particularly not in the name of making things easier for new users. Argent Stonecutter 18:48, 15 August 2007 (PDT)

• Alternate possibility, keep and expand the pie menu, so that right click (or whatever click or key combination the user selects for menus) brings up a menu (pie, pacman, etc) that includes every option in the menu bar. Argent Stonecutter 08:09, 16 August 2007 (PDT)
• Alternate possibility, sweeping the mouse above the top of the screen drops a menu bar down.

• The idea of regions needs careful thought - users could get annoyed if they go to click on something in world which is in a corner of the viewer only for a part of the UI to suddently popup in the way! Matthew Dowd

Agreed, you should probably have to click on an actual docked icon to open the element. The Mac dock is visually appealing, but restricted... perhaps make the docked objects recognizably 3d icons, but draggable anywhere around the edges of the screen that you want, so that when you click on them they pop in or up or down. Argent Stonecutter 18:48, 15 August 2007 (PDT)

• Consideration of how these regions would interact with HUD's attached to that position in the viewer needs careful thought to avoid the UI interfering with existing (and future) HUDs. Matthew Dowd
  • Making the HUD anchor points (or new ones... say "Dock 1", "Dock 2", ...) dockable and draggable, with the same show/hide behavior, would help a lot. Argent Stonecutter 18:48, 15 August 2007 (PDT)
• The ability to dock floaters/regions in os-native windows that can be placed on another monitor would unclutter the view while keeping that information visible (and will not cover the view while they are in use!). Kaworu Jun 13:30, 15 August 2007 (PDT)

GUI and (eventually) client scripting

Whatever design we come up with, ease-of-scripting (or at least the ability to script at all), should be part of the design-parameters.

As I've mentioned before, the WoW client paradigm would be a good one to examine and emulate--at least the overall concept of making virtually everything in the GUI scriptable. http://www.wowwiki.com/Widget_API http://www.wowwiki.com/World_of_Warcraft_API

Saijanai 15:08, 15 August 2007 (PDT)

Largely agree, and the scripting language should probably be Javascript using the Spidermonkey component in Gecko, since it can be run independently of the HTML browser and is already in there. Argent Stonecutter 18:50, 15 August 2007 (PDT)

The wave of the future is apparently mono, even on the client side. This could allow extremely powerful hybrid in-world/external tools to be devised. {{Saijanai Kuhn} Saijanai 18:02, 16 August 2007 (PDT)

Interaction between in-world and out-of-world scripting

To avoid hitting people with too many changes at once, we should look at what changes in the communications between the client and server would make things easier and to allow maximum compatibility with existing content.

• Allowing objects on the client to register listens in the game, so that you can have gui components do things like respond to high channel chat from scripts, should be possible.

Whether the chat comes in as a simple line or encapsulated in XML or whatever is less critical.

This could be tested in the existing client by allowing applications outside the client to connect to a socket and hook into chat. Connect to localhost:1337 and send "<listen channel=42/> <send channel=42>flight status</send>" would lead to getting messages like "<chat source=UUID channel=42>flight enable</chat>".

Argent Stonecutter 08:19, 16 August 2007 (PDT)

IN the long run, this would allow for external tools to act like in-world tools. If a tool allows you to keep chatting with friends, or ask/answer questions in IM, it becomes at least somewhat part of hte game. 17:58, 16 August 2007 (PDT)

• Allow HUDs to evoke widgets on the client side sot that a HUD could define sliders, dials and other interesting objects where the client's GUI does the mouse-tracking and other GUI updating, and sends the updated info to the HUD for further processing. Saijanai 15:24, 17 August 2007 (PDT)

Factor the GUI framework into a usable separate library

That is frankly, probably the single most important step that can be taken to get these concepts working. The SLGF (Second LIfe GUI Framework) isn't the best ever devised, but it is frozen in place and nothing else can be built on it, due to poor documentation and the existence of the kitchen-sink class, llview.

Until we can discuss the weaknesses of SLGF separately from the weaknesses of the GUI and the rest of the client, not much can be done to correct any of them, save at the emergency-mode bug-fix level. Saijanai 12:19, 30 August 2007 (PDT)

That should be the classes defined in view.cpp. llView and other framework classes may or may not need work but its the classes that implement the viewer that are hopelessly tangled. Saijanai 10:07, 7 September 2007 (PDT)