[mapguide-users] Usability of Redline, Query, Theme, Measure, Buffer, FeatureInfo
Jackie Ng
jumpinjackie at gmail.com
Wed Mar 20 03:32:13 PDT 2013
Hi All,
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.
The problem is a minor segway from this thread:
http://osgeo-org.1560.n6.nabble.com/MG-2-4-final-MG-2-5-Beta-1-problems-errors-ect-td5036500.html
I've outed these particular widgets as per the subject line because they
all have the following in common:
- Their UIs are either popups or Task Pane resident content
- They are also mutually exclusive widgets, meaning they take over the
active widget state.
It is the second point that I will argue is completely unnecessary and
causes UI/UX confusion.
Consider this situation:
1. I invoke the Measure widget
2. The Measure widget UI loads in the Task Pane
3. The Measure widget is the active widget
4. 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.
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).
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.
Going back to the above example, I should be able to continue measuring
even if the active widget is not Measure because:
1. Measure should not even be a mutually exclusive widget.
2. The Measure widget UI should be able to operate on its own regardless
of what the active widget is.
Other widgets in question may not have the exact same set of UX problems,
but they do share one or two problems in common.
What I propose as a solution is the following:
- 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.
- Tweak the respective widget UIs to be independent from the rest of the
Fusion system, regardless of active widget state. To be specific:
- 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.
- FeatureInfo: Add a button/link to refresh the layer list dropdown
- Query: Make use of the MapMessage component to relay digitization
prompts for tracing the spatial filter geometry. Add a button to manually
stop digitization.
- Theme: No changes
- Buffer: No changes
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.
Thoughts?
- Jackie
Note: This is directed to multiple lists (MapGuide and Fusion). Not sure
how nabble handles replies across different lists.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapguide-users/attachments/20130320/de7fcf3d/attachment.html>
More information about the mapguide-users
mailing list