[opensource-dev] from debug to prefences

Hitomi Tiponi hitomi.tiponi at yahoo.co.uk
Tue Jan 25 03:14:37 PST 2011


I have been struggling with this on StarLight as well.  My design approach was 
to incorporate many of the debug settings that people seemed to like while also 
keeping a fairly simple approach.  The skill seems to be in allocating them into 
a sensible form - so in the end I settled for sub-tabs based on KirstenLee's 
approach - with the main options separated from additional, specific options.  
And can we please ditch ('can' for the Americans) the 'Advanced' tab - it is 
just there for stuff that didn't fit in the other tabs and is hardly 'advanced' 
- much better to give the option in sub-tabs for those that care to explore 
more.  Many of the debug settings don't work anymore so maybe it would be a good 
idea to ditch those first.
Hitomi


>one of the things that oz and q have been grousing (to use oz's word) about 
>lately is that there are LOTS of preferences in the debug menu that really don't 
>have debug functions but are preferences.  Both oz and q feel that the 
>>preferences bar is already kind of full though many users want to see more 
>preferences.
>What I propose is kind of a compromise.
>Here's how it would work. We take the existing advanced preferences tab and turn 
>it into a floater activated if you click on where the advanced tab is now. we 
>then bump many of the preferences that are in the debug over.  we >can do it in 
>kinda a category form as the sketch here shows or break it up into tabs.  
>
>This would give the ui more of an mmo like presences control which would not 
>necessarily be a bad thing and give faster, very easy and intuitive access to 
>the more advanced features for those that want them and yet also >allow us to 
>keep both the preferences and debug consoles "clean."  with some careful 
>monitoring and feedback from the users we could then possibly narrow down what 
>settings are not really needed and eliminate them off >this panel and conversely 
>have a space to add new preferences as well.
>I'm sure someone is going to argue that this would just make things more 
>complicated both in the short term and long term. I'm going to attempt to answer 
>those as follows. 
>
>As far as the short term, yes it would. I'm sure it would involve quite a bit of 
>code reworking and discussion and stuff. It would also take users a bit of time 
>to adjust to the changes. 
>
>In the long term, I think it would actually be simpler this way and add to the 
>new user experience. by setting up things this way we could add ui hints and/or 
>tool tips that explain what these preferences do, and if this one >panel gets 
>crowded, i don't think that most users will mind.  in fact those used to mmo's 
>will be kind of expecting it.  in the mean time it gives us a place to part 
>lesser used preferences from the prefences control, and clears >up the debug 
>menu while also making it easier to both move more used features back into the 
>preferences menu and setting up for eventually allowing us to pick and choose 
>what preferences we want where.  
>


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110125/ea6b2d03/attachment.htm 


More information about the opensource-dev mailing list