Hi All,<div><br></div><div>I was hoping to get this discussion started before I put out the MGOS 2.5 RC, but better to raise this now than to have this problem not fixed for the final release and having to wait for another release cycle for the fix to land.</div>
<div><br></div><div>The problem is a minor segway from this thread: <a href="http://osgeo-org.1560.n6.nabble.com/MG-2-4-final-MG-2-5-Beta-1-problems-errors-ect-td5036500.html">http://osgeo-org.1560.n6.nabble.com/MG-2-4-final-MG-2-5-Beta-1-problems-errors-ect-td5036500.html</a>
</div><div><br></div><div>I've outed these particular widgets as per the subject line because they all have the following in common:</div><div><ul><li>Their UIs are either popups or Task Pane resident content</li><li>
They are also mutually exclusive widgets, meaning they take over the active widget state.</li></ul><div>It is the second point that I will argue is completely unnecessary and causes UI/UX confusion.</div></div><div><br></div>
<div>Consider this situation:</div><div><ol><li>I invoke the Measure widget</li><li>The Measure widget UI loads in the Task Pane</li><li>The Measure widget is the active widget</li><li>I invoke the Pan widget, that is now the active widget. However, the Measure UI is still there in the Task Pane but no longer does anything. I now have in my Task Pane a user interface for a widget that is no longer active.</li>
</ol><div>Such widgets whose UI load in a popup window or Task Pane should be autonomous from the rest of the application regardless of the application UI state. Invoke Script and Invoke URL widgets already carry these assumptions (or I hope anyone building such custom commands/widgets assume this). </div>
<div><br></div><div>The widgets I have mentioned are basically glorified Invoke URL widgets anyway, having such widgets tie into active widget state is completely unnecessary. Invoke URL widgets don't do this and neither should these aforementioned widgets. They should be independent of active widget state. </div>
<div><br></div><div>Going back to the above example, I should be able to continue measuring even if the active widget is not Measure because:</div></div><div><ol><li>Measure should not even be a mutually exclusive widget.</li>
<li>The Measure widget UI should be able to operate on its own regardless of what the active widget is.</li></ol><div>Other widgets in question may not have the exact same set of UX problems, but they do share one or two problems in common.</div>
</div><div><br></div><div>What I propose as a solution is the following:</div><div><ul><li>Make the aforementioned widgets *not* mutually exclusive (ie. isExclusive is false). There is no concept of enabled/disabled for these widgets. If you can see their UI, they're active.</li>
<li>Tweak the respective widget UIs to be independent from the rest of the Fusion system, regardless of active widget state. To be specific:</li><ul><li>Measure: Modify it to be more like its AJAX viewer counterpart. Have buttons to explicitly start/stop the measuring process instead of auto-start on widget activation.</li>
<li>FeatureInfo: Add a button/link to refresh the layer list dropdown</li><li>Query: Make use of the MapMessage component to relay digitization prompts for tracing the spatial filter geometry. Add a button to manually stop digitization.</li>
<li>Theme: No changes</li><li>Buffer: No changes</li></ul></ul><div>With these changes, the UX should be much more bullet-proof. No longer will you have situations like panning with an active dangling geometry digitizer, tracing shapes as you're panning as a result. Such situations are all to easy to trigger under the current behaviour of these widgets.</div>
</div><div><br></div><div>Thoughts?</div><div><br></div><div>- Jackie</div><div><br></div><div>Note: This is directed to multiple lists (MapGuide and Fusion). Not sure how nabble handles replies across different lists.</div>