Hi Thorsten, I think we've gone beyond what can be done for the upcoming release, but comments below.
On Sun, Jul 10, 2011 at 7:30 AM,thorsten.i.renk wrote: >> 2) As it stands, it's very difficult for a new user to understand the >> difference between Local Weather and Global Weather. let alone how >> they inter-relate. Enabling the Local Weather package requires >> setting "Enabled local weather module" from the Local Weather Settings >> menu, yet the rest of the settings a user is likely to want are in the >> Local Weather dialog. As a first step to sorting this out, I'd like >> to do the following: >> 2a) Move the "Enable local weather module" checkbox to the Local Weather >> dialog. > > In my opinion, a clean solution would be to introduce a new master weather > dialog on which the user can specify > > * is live weather to be used or an offline solution > * which weather system (local or global) is supposed to render the weather > information (and supply the offline solution if applicable) Yes, a unified dialog for high level weather setting would be a very good idea, This would undo some of the work that (Torsten?) did to amalgamate the various global weather dialogs some time ago, but I think splitting off the METAR/scenario section at the bottom of the dialog makes a lot of sense given that in most "modes" the various detailed configuration options are read-only anyway. I also wonder if the terms "global" and "local" are really applicable. Would "static weather modeling" and "dynamic weather modeling be better terms, or how about simple/complex? >> 2b) Move "Local Weather Settings" to the Debug menu, on the >> assumption that more users will never need to modify the settings >> there (Thorsten R. - is this true?) > > No - quite the contrary. The design philosophy is (not strictly true, but > mostly): > > * Local Weather (i.e. what used to be Local Weather Tiles) is a launcher - > everything you select here is parsed only at startup of the weather > system, but cannot be modified runtime I think this "launcher" aspect is something that we want to hide from the end-user. Most people just want to be able to change the weather system and then press Apply or OK. Having to press "Stop" first is very different from the rest of the UI. I think we'll want to make this implicit, so the user can press (say) Apply, and the underlying weather system stops and then is started under the covers with the new parameters. Apart from the stop/start time (which could be handled by a "please wait" message), is there any reason we couldn't do this? > * Local Weather Settings contains all options which can be modified > runtime. The main purpose is to get a handle on performance - for instance > you might start out on relatively clear skies, so you can render clouds > out to 55 km without large framerate impact - but then as you go on, you > come into overcast skies, and the framerate drops like a rock - this menu > allows you to choose runtime that you'd like to see clouds only to 20 km > and get the framerate back > > So in my view, this should not appear in debug (for reference - I use the > 'Settings' menu maybe 3-4 times per hour of flight or so). I think 90% of users are going to struggle to understand what most of these settings mean. Is there one particular setting that you are changing regularly? Perhaps we could extract it alone and give it a easier to understand name? Alternatively, could we use some arbitrary Performance/Quality slider that is mapped to these settings? -Stuart ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
