User talk:Esbee Linden/Office Hours/2010-09-08
From Second Life Wiki
Feedback from reading the transcript
- Firstly, congratulations on an excellent meeting that made great progress! :-)
- UI layouts must not be confused with user profiles (as was done at [08:30]), because the relationship between user profiles and users is 1:1, while the relationship between UI layouts and users is X:Y --- they're disjoint sets. A given user/avatar can select any number of layouts throughout a single login session to suit the tasks being performed (1:X), while a given layout can be used by any number of avatars or users (1:Y). User profiles and layouts are inherently different concepts and shouldn't be mixed up. This is also the reason why user or avatar information should not be stored with the layout information under a preset --- it would make layouts unshareable.
- A note on terminology: although "UI layout" and "preset" are often used interchangeably (and that's fine), there is a conceptual difference --- layouts are STORED TO presets, and RECALLED FROM them. The preset itself is a conceptual named storage box, and could have any number of different implementations, even on the same system. This includes UI buttons, UI menus, the name XXX in a command line such as "/savelayout XXX", directories or folders in the filestore, and other entities.
- Although a given layout may be best suited to only one screen size, it's not a fault condition for one or more windows of a layout to extend outside of the application frame --- indeed, the user can already move the larger part of a window outside of the frame manually. I suggest that no attempt be made to impose a policy on users by bringing windows into the frame or clipping them after selecting a preset. It's easy to imagine that a user might actually want to save a layout in which several windows are in part or almost wholly outside of the application frame, ready to be dragged in when desired. Recalculating the layout and imposing a policy automatically as some suggested would not really convey much benefit, and would deny certain types of use. An extra command for "normalizing" the layout would be fine however.
- The data stored under a preset needs to be stored locally mainly because layouts transcend single worlds. A given user is extremely likely to want to use the same layouts when visiting other worlds, and server-side storage wouldn't work. Hopefully LL is sympathetic to viewer use in other worlds as well, but even if not, notice that Aditi constitutes "another world" --- any presets stored while in Aditi would never appear in Agni if presets were stored server-side only. The data could be stored server-side IN ADDITION to client-side, no harm in that, but no extra work is needed server-side since we already have notecards. There is precedent for this in TPVs like Imprudence, which recognize notecards carrying Windlight information by notecard name suffix. As others have said though, server-side support is just asking for delay. I suggest that this be left to viewer-side alone.
- Some windows can be opened only in the context of a particular asset or target, such as a script or someone's profile. In such cases, the layout data stored under a preset doesn't cause the window to pop up, it just stores where the window(s) of this type WILL pop up in future. Eg. for the script editor, if you open up several scripts, size and position their editor windows where you want them, and then save the layout to a preset, then future editor windows would pop up in the same places in the same order under this preset only when such windows are opened manually. (Perhaps it should be a panel property, the choice of whether selecting a preset causes that panel to appear or not --- some panels like vicinity chat usually require it while others like group profile never require it.)
- Finally, .... both AW Groupies and the UXIG group have been advocating configurable UI layouts and the multiple presets idea for some years, and UXIG in particular focused wholly on ideas for the user interface after LL pulled out of its User Experience OH. At least a nod in that direction as attribution would be nice: this work should be positioned as resulting from collaboration between residents and the Lab. :-)
Well done to all participants! More technical meetings like this are needed. :-) Morgaine Dinova 10:33, 10 September 2010 (UTC)
UI layout beyond panel positioning
- Although this OH dealt primarily with whole-panel sizing and positioning, note that the concept of storing layout sets under presets is far broader than this. Jira VWR-22781 applies this idea to every GUI element that can be displayed in the viewer without exception --- panels, tabs, buttons, sliders, checkboxes, display areas, etc, as well as to hierarchical groupings of such elements.
- We should start simple, but keep in mind that the possibilities are far greater! :-) Morgaine Dinova 11:00, 10 September 2010 (UTC)