<br><br><div class="gmail_quote">On Fri Jan 16 2015 at 9:04:15 AM Blumentrath, Stefan <<a href="mailto:Stefan.Blumentrath@nina.no">Stefan.Blumentrath@nina.no</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear all,<br>
<br>
>From a user-perspective, I would like to say that one of the big plusses of GRASS is it`s consistency over time (also in the GUI). The transition from TclTK to WXPython went so smoothly for me, because principles stood the same. Do not get me wrong, I am not against changes/improvements but I would advise to make only subtle changes, so users do not have to acquaint themselves with the software after each GUI change (like the poor fellas who had to re-learn their proprietary GIS when it went from 3.2/3.3 to 8.something and then again when 10.something came...) .<br>
<br>
In addition, for amateur-python/shell-script-<u></u>writers like me the simplicity of creating a GUI for a new module is also a big advantage of GRASS. This simplicity should be maintained, regardless what new features are added to the GUI.<br></blockquote><div><br></div><div>+1 This is really one of the great features of GRASS GIS.  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Finally, from my point of view the authors of the WXPython GUI did a really great job, I can see nothing confusing or scary in it, so I do not see urgent needs for changes in in the GUI in principle.<br></blockquote><div><br></div><div>+1 To illustrate how useful the GUI of many functions are: I also fairly often refer back to the GUI. Not really to use it (most I do is on the command line) but as a reference to remember certain options or parameter names. In other words. In other words, for me it serves as an alternative more visual help. And I asked a beginning user, and she used it the same way (start with the GUI, and copy the syntax to use in scripts), as she finds it also easier to have a quick grasp of the options than the help file.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
That`s said, the advantage of avoiding tabs would probably be that users need less clicks to fill in all information to run a module. However, having all options in one window (without tabs) may generate a high window, with probably the need to scroll down (or un-collapse the optional choices (if they were collapsed)). So for such modules the less-clicks-advantage is not that big...<br></blockquote><div><br></div><div>I actually like the ability to group major function into tabs, especially if there are many options (and I agree with the above, one should avoid the need for scrolling). For me the main advantage of grouping of options in one tab is the earlier mentioned option to group options that require one single explanation line, and perhaps more important, to group options from which the user need to fill in only one, at least one, etc. (some good solutions were already suggested I think)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers<br>
Stefan<br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:grass-dev-bounces@lists.osgeo.org" target="_blank">grass-dev-bounces@lists.osgeo.<u></u>org</a> [mailto:<a href="mailto:grass-dev-bounces@lists.osgeo.org" target="_blank">grass-dev-bounces@<u></u>lists.osgeo.org</a>] On Behalf Of Nikos Alexandris<br>
Sent: 15. januar 2015 23:05<br>
To: Moritz Lennert<br>
Cc: Paulo van Breugel; GRASS-dev<br>
Subject: Re: [GRASS-dev] module header definitions add: text/multiline and latex support?<br>
<br>
On 15/01/15 13:34, Nikos Alexandris wrote:<br>
<br>
>> Just a very quick mockup, all-in-one page:<br>
>> <<a href="http://imgbin.org/index.php?page=image&id=21809" target="_blank">http://imgbin.org/index.php?<u></u>page=image&id=21809</a>>.  Note, the "Help"<br>
>> button and the "Manual" are duplicates, if I am not wrong. This adds<br>
>> up in overloading the interface.<br>
<br>
On 15.01.2015 14:55, Moritz Lennert wrote:<br>
<br>
> Interesting, but I have to admit that I do not see what the advantage<br>
> of this is compared to the tabs...<br>
<br>
Just an idea, it is.  It would be possible to have the optional stuff collapsible.<br>
<br>
Anyhow, the point is:  a GUI needs a designer's touch.  This is going to make the interface readable, and not confusing  or  scary (as my quick mockup is too, of course).  The same is valid for the Wiki, for which I failed, in the past, to get past the message "let's make our Wiki beautiful" up to the point where we could say "we do have a beautiful Wiki".<br>
<br>
I've had a nice course on interactive programming with Python, back in September.  And I do have a sense for what it takes to program a GUI.<br>
My understanding is that big changes are probably way out of the project's manpower.  And we can surely live with that.  Yet, if there are changes to happen, let them be step-wise and adhere to modern UI principles.<br>
<br>
Nikos<br>
<br>
______________________________<u></u>_________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/grass-dev</a><br>
</blockquote></div>