[Marble-devel] [Mockup] Configurable Route Profiles

Sat Aug 7 15:32:26 CEST 2010

Hi,

thanks everyone for bringing up this topic :-)

I tried to combine both requirements -- simple UI and advanced 
configurability -- into a new mockup (see attachment). The main 
simplification is that it is not possible to configure all profiles at 
once, but only one. This should make the dialog easier to use for 
first-time users. To get that working, I changed the current "Options" 
inline widget to only let the user choose one of the configured 
profiles. This is another simplification which in my opinion is sane. 
The disadvantage of this approach is that you have a fixed number of 
profiles instead of a dynamic one. I do believe however that this won't 
bother most people; the number of profiles to use could be another 
setting as well.

Regards,
Dennis

On 07.08.2010 12:09, Torsten Rahn wrote:
> 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
>>      
> _______________________________________________
> Marble-devel mailing list
> Marble-devel at kde.org
> https://mail.kde.org/mailman/listinfo/marble-devel
>
>    

-------------- next part --------------
A non-text attachment was scrubbed...
Name: marble-settings-mockup.png
Type: image/png
Size: 95310 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/marble-devel/attachments/20100807/a13342d1/attachment-0001.png 