Suggestions for UI improvements

[Mollymawk]

I recently raised a pull request adding to OpenCPN's barren OS X menu bar the "Preferences", "About", and "Help" menu items which are standard for every app on OS X, and also suggesting the empty menu bar be populated with useful items which would enhance usability and make OCPN look more native and more user-friendly.
Dave argued against my suggestion, saying that it is OpenCPN policy firstly not to have menus, and secondly to maintain UI parity across every platform. A few people disagreed and said that menus are important on OS X, but I can certainly see Dave's point too.



Anyway, thinking about this gave me some ideas which I think would very much improve the OpenCPN interface across all platforms.

I would like to describe these ideas here not as a final concept I would like to see implemented, necessarily, but rather with the goal of starting a discussion on making OCPN more user-friendly, removing some clutter and UI inconsistencies, and revealing features which are currently "hidden" by only being accessible through keyboard shortcuts.



I believe the following goals are desirable:

* Reveal in the UI features which are only accessible by keyboard shortcuts, such as fullscreen, ENC detail visibility of various types of item, ENC detail slider, screen dimming, etc.

* Reduce the number of items in the context menu (right-click menu). The context menu should only contain items relevant to the point clicked, not general options such as north/course up toggle, AIS target list, etc.

* Allow toolbar items (or even the whole toolbar) to be hidden without entirely losing access to the functionality of those items.

* Greater UI consistency. Why is the AIS visibility toggle in the toolbar, but the AIS target list in the context menu? Why is the measure tool in the context menu, but the route tool in the toolbar? Why aren't the route tool and the waypoint dialog button side by side in the toolbar?

* Avoid heavy reliance on fiddly interface items like normal menus, which - as Dave pointed out - could be hard to click accurately with a touchpad in a seaway on some vessels, and which are hard to use on a touchscreen device.

I'm sure there are other improvements I haven't thought of right now.



Thinking about how to achieve these goals, and iterating through a few ideas in my mind, I have come up with the following as one way to go, which I believe would work well.

- Certain toolbar items should have drop down menus rather than toggling a single setting. To aid touchability / clickability at sea, the menu items should be *large* - each line as tall as the toolbar buttons are. There should be no more than a few items in each menu.
For example, AIS menu could have the target visibility toggle, an alarm on/off toggle, and an entry to open the target list.
ENC menu could have the current ENC text toggle, plus the toggles which are currently only accessible by keyboard shortcuts such as soundings, light sectors, etc, and the CM93 detail slider.

- At the left side of the toolbar, should be another menu (also large items), with the "three stripes" menu icon as used in web browsers and mobile apps. This should contain items which need menu options, but which don't deserve a place in the main toolbar. Some of the context menu items could move here. So could the "about" button. (In Android parlance, this is the "overflow menu".)

- Ideally, the user should be able to move items between the toolbar and the menu mentioned above, like in Firefox's new UI. This would be optimal but I don't know how easy it would be to code.

- I think Mac needs menus in the menu bar. Just my opinion, but it seems others share it. Look at Firefox again, it doesn't have menus on other platforms anymore but it still has them on Mac.
Maybe they could also be optional on other platforms, or they could appear when you press Alt like in many Windows apps.
That said, for me this is not a big priority, though I am willing to implement it if it is wanted.

I have other minor ideas, like perhaps the chart group selector should be in the chart bar at the bottom, but the above is the bulk of what I am envisaging.


What does anyone else think?
Am I on the right track? Or do people think the interface is perfect as is? Is this type of feedback / discussion welcome? Or am I stepping on someone's toes? :-)
Etc...

[CarCode]

Mollymawk,
I second your suggestions.
However the goal of the developers seems to be other things like support for systems like Raspberry Pi, Android etc. They spend already a year to make optimizations for small computers.
As I have learned there is no democratic way to vote for anything here, I have made my own version of OCPN with things I like to have. Because it is only for me and other german people with Macs it is only in german language.
Gerhard

[Mollymawk]

Gerhard,

Originally Posted by CarCode

the goal of the developers seems to be other things like support for systems like Raspberry Pi, Android etc. They spend already a year to make optimizations for small computers.

I happen to agree that support for small devices is important. As it happens, I think my suggestions (or other changes of this type, if others have any ideas) would help that effort, as less UI clutter is better on small screens and my ideas expressly allow for "touchability" with Android etc in mind.

Originally Posted by CarCode

As I have learned there is no democratic way to vote for anything here, I have made my own version of OCPN with things I like to have. Because it is only for me and other german people with Macs it is only in german language.

I see that you are frustrated, but I would say you are wrong to complain about the excellent work the core developers are doing and have done. OpenCPN is not yet perfect (hence my suggestions) but it is a truly outstanding piece of software already, better than many of the commercial offerings, and an inspiring example of what the open source movement stands for and can achieve.
Further, I think Dave & co are right to prioritise functionality and compatibility over UI enhancements, at least in the short term.

As for "no democratic way to vote for anything", that's hardly a surprise, most projects work like that. The project leader (Dave) will always be the one who steers the project and ultimately the one who decide what gets done and what doesn't. That doesn't mean he won't listen to community input, I'm sure.
Also, there are only a few core devs, we can't expect them to put a lot of time into working on things they don't think are worthwhile.

I don't think forking OpenCPN, just for a few minor UI changes, is a sustainable or desirable thing to do - much better to all work together to produce one great product - but of course, if you do want to maintain your own fork for personal use, that's entirely up to you.

Let's all try and collaborate amicably and without being so provocative!

Cheers,
Caesar

[nohal]

Gerhard...
Talking about democracy, voting etc. Could you link to one (really, any) pull request you ever sent and was refused?

Many thanks in advance as usually.

Pavel

[CarCode]

Originally Posted by nohal

Gerhard...
Talking about democracy, voting etc. Could you link to one (really, any) pull request you ever sent and was refused?

Many thanks in advance as usually.

Pavel

I don't think we need to warm that and all your insultes...
Gerhard

[Mollymawk]

Crikey, I only wanted to start a constructive discussion about some ideas for the UI, do we have to descend into name-calling?

[seandepagnier]

I agree with improving the ui.

I personally would like to be able to customize actions (like buttons on the toolbar) so the user can map them to:

1) toolbar icon (can arrange them as desired in rows etc...)
2) context menu (set position submenus etc)
3) keyboard shortcut (customizable key)
4) network interface (allow external applications to control opencpn in this way)

Maybe this seems complex, but would basically be hidden from most users, and set in the configuration file, or maybe through a special setup dialog.


As for menus... I use them in several plugins so that I don't need lots of buttons. Not sure if it makes sense for opencpn or not.

[Mollymawk]

To be clear, the type of "menu" I am proposing is not little fiddly items like normal system menus, but more like the menu in Firefox (see attached).

Like you mention, the user should be able to move the toolbar buttons around, and between the main toolbar and the "overflow menu".

I agree that users should be able to modify keyboard shortcuts. Also, *everything* should have a keyboard shortcut, and *everything* should also be accessible via the UI, without *having* to know the keyboard shortcut.

I think your idea of other networked devices controlling opencpn is very interesting, but possibly very complicated and more a "behind the scenes" thing than part of the visible UI.

[bdbcat]

Folks...

I am definitely interested in improving the OCPN UI, even in radical ways. We can learn a lot from modern Web design practices intended for small screens and fat fingers. And really, that was the original concept of O. Usable at sea for real-live navigation.

And, of course, there are lots of places in OCPN that have inconsistent interfaces. That's the nature of evolution. But we don't have to live with them forever. We just need to focus on them.

Regarding traditional menus: The Mac community is important to me, despite occasional appearances. And it seems clear that Mac users feel "naked" without a menu bar. OK, then lets give them some clothes, and have a menu bar, for Mac at least. We can start minimally, and enhance it as we decide on the UI elements that make sense here.

But now we come to the nub of the issue: dev resources are, and always will be, slim on the ground. And UI development is slow, tedious work.

I suspect the other devs are experiencing something like I am; fully 80% of my time is devoted to cross-platform compatibility and functionality issues. O has gotten complex, internally. And much of that complexity is a consequence of the broad base of platforms we target.

As always, our first priority is and will be to make all existing features work reliably and smoothly across all platforms.

And that leaves little dev bandwidth left over for new code. So we learn to live on less sleep.

Anyway, what can move us forward here is two things:

1) Reasonably detailed screen prototypes of target new interface elements. These can be crafted from other apps as examples, marked-up screenshots of current OCPN, etc.

2) For those able and willing, specific pull requests to the github code base. Although it may take a few weeks, pulls always get processed, in one way or another.

Please carry on with this discussion

Thanks
Dave

[Mollymawk]

Dave,

Many thanks for taking the time to explain your stance on this and letting us know you're willing to make big changes to the UI.

I fully understand why you and the other core devs aren't able to dedicate a massive amount of time to UI work, and I certainly appreciate the important work you do to keep OCPN stable and operational across different platforms.
Less sleep is the way forward! :-D

Anyway, I don't have a lot of time to dedicate to this type of thing at the moment, but I am willing to put in a bit of work to improve the OCPN UI.
(And I'd like to note, though I have talked about the menu bar which is specific to OS X, and though my primary development platform is a Mac, my primary navigation system is a Windows laptop, and I also use Linux Mint, so I'm equally interested in UI improvements across all platforms.)

I will try to convert some of what I have talked about above to code, and send you some more pull requests.
I'll also try to post screenshots of what I do here, so we can get feedback from the community of OCPN users rather than just those who know how to compile it themselves.

One question: what prevents the use of latest development wxWidgets, which is in fact much more stable on OS X, at least, than the latest 'stable' version? Is this just a policy to only use 'stable'/released software? Is there any way forward on this other than to wait until wxWidgets 3.2 is released in a year or more?

I would like feedback on my specific ideas above, re toolbar drop down menus and 'overflow menu', from devs and from the wider community of users.
Perhaps my descriptions are not clear enough for real discussion - I will try to either code something and take a screenshot, or make a mockup.

I hope others will participate in this discussion and contribute their own ideas.

Cheers!
Caesar

Sent from my Nexus 7 using Cruisers Sailing Forum mobile app

[nohal]

Caesar...
Your ideas about the GUI are good - if you go through the tracker, most of them are already there, worked out to certain level. Unfortunately the tracking ticket for the first toolbar rework a couple of years ago, containing some good concept pictures for expandable buttons seems to have disappeared. But I didn't look for it very hard so maybe you will have better luck.

Originally Posted by Mollymawk

One question: what prevents the use of latest development wxWidgets, which is in fact much more stable on OS X, at least, than the latest 'stable' version? Is this just a policy to only use 'stable'/released software? Is there any way forward on this other than to wait until wxWidgets 3.2 is released in a year or more?

The reason is simple. ABI compatibility. There is nothing like that (guaranteed) between the nightly builds of wxWidgets master branch. Maybe it does not matter to you or other devs, but it does matter to a normal user, tester and plugin packager.
If it is really needed, we of course can use a *carefully selected and tested* snapshot and it will not turn into a total disaster, but the question, and I really mean it, is: Why?
Could you back the "much more stable than the latest stable version" with something that obviously works in wx master, obviously does not in in 3.0 and is breaking OpenCPN? And I don't think the reason to use the wx master nightlies is that two line commit fixing the font selector exceptions on Yosemite, that one is backported to stable.

Pavel

[yardie]

Caesar, goodluck. I've started my own, internal, OSX fork to see if there is anything I can do with the OCPN code. There appear to be a lot of UI bugs that only happen on the Mac. My old Vista laptop has better performance than my almost new MBP. And it barfs all over the Mac HIG.

There is plenty of optimizations that can be done. And I look forward to contributing. But at the moment I'm living from a suitcase.

[Mollymawk]

Originally Posted by nohal

Caesar...
Your ideas about the GUI are good - if you go through the tracker, most of them are already there, worked out to certain level. Unfortunately the tracking ticket for the first toolbar rework a couple of years ago, containing some good concept pictures for expandable buttons seems to have disappeared. But I didn't look for it very hard so maybe you will have better luck.

Thanks Pavel.
I hadn't come across many UI improvement tickets on the tracker, but I hadn't looked very hard, it's true. I had seen a couple of minor requests, like a different order for the toolbar items, and customisable keyboard shortcuts.
More generally, I thought a discussion here involving users as well as developers would be a good idea.

The reason is simple. ABI compatibility. There is nothing like that (guaranteed) between the nightly builds of wxWidgets master branch. Maybe it does not matter to you or other devs, but it does matter to a normal user, tester and plugin packager.

Thanks for confirming this; I assumed that was the case but Gerhard told me it wasn't...

If it is really needed, we of course can use a *carefully selected and tested* snapshot and it will not turn into a total disaster, but the question, and I really mean it, is: Why?
Could you back the "much more stable than the latest stable version" with something that obviously works in wx master, obviously does not in in 3.0 and is breaking OpenCPN? And I don't think the reason to use the wx master nightlies is that two line commit fixing the font selector exceptions on Yosemite, that one is backported to stable.

Perhaps "much more stable" is an exaggeration, but it is indeed more "native" on OS X - for example, it supports the native full screen API which is now some five years old... (This is rather important for an app like OCPN which will very often be used in full screen mode most of the time.)

[Mollymawk]

Originally Posted by yardie

Caesar, goodluck. I've started my own, internal, OSX fork to see if there is anything I can do with the OCPN code. There appear to be a lot of UI bugs that only happen on the Mac. My old Vista laptop has better performance than my almost new MBP. And it barfs all over the Mac HIG.

There is plenty of optimizations that can be done. And I look forward to contributing. But at the moment I'm living from a suitcase.

Thanks yardie.

Yes, there are a lot of OS X HIG violations, and UI bugs. Thankfully some of these have been fixed (though others are getting worse...)
The fact that none of the devs work primarily on a Mac is obviously part of the issue, so anything we Mac users can do to help is important.

I do hope you will send pull requests for anything you fix - as soon as you fix them is best, rather than a lot of things as once, so others don't duplicate your work.

I'm new to wxWidgets and to C++, so we'll see how I go, but I'm certainly planning to contribute as much as I can.

[CarCode]

If there is someone of the Mac users here who knows to work with Xcode for compiling OCPN, then please use the analyzer in Xcode.
After that please come back for further discussions...

Gerhard