[Marble-devel] [Mockup] Configurable Route Profiles

Torsten Rahn tackat at t-online.de
Sat Aug 7 12:09:00 CEST 2010


Hi Niko,

First I'd like to say that I really like your recent involvement with Marble!  
Your routino patch rocks! :-)

In Marble we are very open to new features and new suggestions. But we want to 
avoid feature creep and a cluttered UI. So we have to trade that openness for 
spending much time of the development on making up our thoughts on how to create 
a really good UI and how to provide the feature in a way that 

* it doesn't get in the way of a casual user 
* it is easy to understand and easy to use. 

So you've already described a use case and the kind of target users.

I guess we agree that

* the feature only benefits a very small group of advanced power users (those who 
are not satisfied with the automatically provided sane defaults that marble is 
supposed to deliver).
* the UI provided for this use case is pretty heavy (It's a bit of a cockpit).
* we'd still like to have this feature :-)

A) So where should this kind of functionality be put?

We have kind of this unwritten policy for adding features to the UI:

* application toolbar: contains features that are used very often by the main 
target users (should address the needs of most people). Each toolbar button is 
used many times either to frequently enter an often used work flow (e.g. opening 
a file, printing) or to frequently change the state of a certain important 
feature.
 
* application menu: contains the whole set of those features which needs to be 
easily accessible by the target users while working with Marble.

* application settings dialog: Contains options which usually just get changed a 
single time by some target users.

* plugin settings dialog (e.g. the wikipedia/weather plugin dialog) This is 
Marble's machine room. The plugin settings typically go way beyond what most 
users would want to change. The normal user shouldn't have to mess with features 
provided here. The plugin dialog is usually just accessible through the 
application settings dialog via the plugin tab. The stuff presented there is just 
for power-users.

* task based settings dialog (e.g. the sun control dialog): This is a settings 
dialog that addresses a certain important task. The dialog is often enough used 
for interactive use (and hence non-modal). The dialog can either be triggered 
via the menu or via a button or context menu entry that is spacially closely 
associated with the feature.


So where should your dialog be put? Usually in terms of policies it would rather 
be a case for the plugin settings dialogs imho. But as you mentioned the dialog 
affects functionality provided across several plugins. So the plugin settings 
dialogs wouldn't be a good choice. 

I guess "task based settings dialog" would come close. It could be maybe 
accessible via a toolbar button or an (RMB?) menu in the routing tab.
Any thoughts?

B) Dialog layout

I also like the "mit-list-checkboxen-ohne-tabs.ui" best. Tab's are always to be 
used with care (to avoid tabs-within tabs).

Problem with this dialog is the dependency of widgets on each other in the 
dialogs: There are three parts:

i. the routing profile list 
ii. the plugin list with checkboxes
iii. the plugin settings (which I guess is provided individually via the 
plugin).

ii. depends on whatever is selected in i. . And iii. depends on whatever is 
provided in ii. 
I think it already requires quite some deep understanding of a typical user to 
understand this long dependency queue. So visually this dependency needs to be 
made very, very clear. We need to make sure that the user understands 
immediately 

* that it matters where he clicks first
* that he intuitively knows where he has got to click first (namely on the 
listview) 

And where to click next (the plugin list). And that any change of those will 
affect the selection of the plugin settings.

Some thoughts:

I think the listview on the left should get a title (like "Routing profiles").

I also think that the full right pane needs to be grouped/separated from the 
left pane. It needs to be very clear that the right pane resembles the settings 
for the profile chosen on the left. One way to accomplish this would be putting a 
groupbox around (Title e.g. "Selected profile"). But then the problem would be 
that there would be groupboxes within groupboxes since the "Settings" (iii.) are 
provided in a groupbox already. And using groupboxes within groupboxes is not 
considered good design.
Also I guess that the "Settings" group box title would usually hold the plugin 
name instead?


Of course a completely different solution would be to put the whole right pane 
into a wizard or a separate dialog window for creating profiles. That however 
might lead to the situation where a (modal?) dialog window is launched from a 
(modal?) dialog window. That is also something that is usually avoided.


That's all the initial thoughts I have regarding this tough complex topic :-)

Hope it provides some food for thought.

Torsten










 






On Friday 06 August 2010 19:26:00 you wrote:
> Hello,
> 
> > Could you describe a bit more in detail which use cases you are trying to
> > address? Who is the target user of these kinds of settings?
> > Shouldn't the routing plugin already indicate what capabilities there
> > are?
> 
> Ok, my plan is to use marble for planning bicycle routes. The route depends
> on the used bike (MTB vs. Race) and on other preferences (cycle routes
> preferred vs.
> fastest way). With the current Bicycle profile this is not possible.
> Using routino it is possible to define custom transports and profiles
> in an xml file - but
> there is currently no way to choose between those in marble.
> 
> The issue with the current UI is that it can only provide options that
> exist in all
> routing plugins. OpenRouteService and YOURS both have a range of
> different profiles
> and options that are currently not usable from within marble. With
> such an configuration
> dialog advanced users can create custom profiles giving access to all
> features.
> 
> Other use for an router configuration is various settings for the
> offline routers (paths to
> data files etc). Although that could be implemented in a simpler UI as
> well.
> 
> Another way would be per-router-plugin options in the routing tab. But
> that would make
> the UI much more complicated for the average user.
> 
> > In Marble we always try to avoid configurability just for the sake of
> > making it configurable. Therefore we should discuss/review this concept
> > a bit.
> 
> yeah, that's why Marble is so easy to use...
> 
> > Also it would be nice if you could send the .ui file in addition to the
> > screenshot (I assume there exists one).
> 
> attached. (three versions, my best one "mit-list-checkboxen-ohne-tabs.ui")
> 
> Niko


More information about the Marble-devel mailing list