Alpha testers wanted

[RBEmerson]

Originally Posted by brak

Could you elaborate on the "charts are here" and thumbnail options? Were you able to load multiple chart cells? What was the display like if you did that?
[...]

"charts are here" = default root folder for chart (for example D:/Charts/ENC_Root)

As to thumbnails, the idea is to go to any given chart file and see a thumbnail (very reduced image) of the chart in the file. It's part of the "have I picked the right chart?" process.

As to multiple charts, I'm a bit confused here. I'm working from the ENC's in the bulk download that NOAA uses. That is, the root folder is called "ENC_Root" and there are 676 folders with just short of 8000 files in them. However, the folders I've tried so far only have one file each. I see no way to open even two adjacent charts (e.g., US5MD11M and US5MD12M).

[brak]

David,

Nothing is set in stone We'll see how things go - if it becomes evident that toolbar is necessary, one will be created.

Originally Posted by DavidGC

I would re-think the tool bar.
I would rather give up a narrow strip of chart space -- even if it was just small icons, the function of which was labeled when I rolled over them with a mouse -- than to have to memorize keystroke shortcuts. What I (and other old guys like me with lousy memories for which shortcuts go with which program) would end up doing would be going up to the menu every time I want to do something.

You could have the best of both worlds if you made the toolbar something the user could choose to have on or off -- even better if I could choose which functions appeared on the toolbar, so I could customize it to have only the functions I wanted.

DCM

[RBEmerson]

While I like the notion of using gestures and keystrokes in a user interface, in a complex app like a nav program, there are just too many commands and options for a user to memorize. A toolbar is an aide memoire as much as anything; "yes, you can do [task xyz] in this program."

For that matter, using "1" and "2" to zoom in and out is not very intuitive. <CTL-O> for open, however, does fit common user interface practice.

[brak]

Originally Posted by RBEmerson

As to multiple charts, I'm a bit confused here. I'm working from the ENC's in the bulk download that NOAA uses. That is, the root folder is called "ENC_Root" and there are 676 folders with just short of 8000 files in them. However, the folders I've tried so far only have one file each. I see no way to open even two adjacent charts (e.g., US5MD11M and US5MD12M).

To open multiple charts you have to open them one by one at this time. I.e. you first open US5MD11, then select "open chart" and open US5MD12 and so on (and also US2EC03 which acts as a small scale background chart for the entire Chesapeake and Atlantic area all the way to Long Island. If you go to "close chart" dialog, you will see all currently loaded charts in the list and will be able to remove some or all.

[RBEmerson]

Very interesting... opening the East Coast chart followed by the two MD charts works quite nicely (note, however, a seam showed up at least in the SE corner of the US5MD11M - might be NOAA's fault, might not...?). Opening 11 and 12 without the East Coast chart, however, didn't seem to blend the two charts. And then it dawned on me that US5MD11M was zoomed so far out it wasn't being drawn (only a black area filled the chart's space) and that US5EC03 was filling in the background when having three charts were selected. So, in fact, multiple opens does work. As long as all the charts in view are drawn.

[Pblais]

Ideally, there will be very few chart controls except for general preferences.

Perfect! Users can't deal with a laundry list of layer features. Some long years ago I was in the GIS business. All the way back to 1975! It is possible to get this right and make it just not a feature but fully automatic. While I would personally like to tweak it no one else will really be able to deal with it. There is far too much going on in the overall process of navigation to cope with tweaking a display.

It's all what refer to as 747 cockpit syndrome. Too many things to tweak to deal with the real problem. Information overload is the problem.

Toolbars take valuable screen space that is better used for chart information.

That isn't a bad approach but you need tool bars. Go to the smaller icons and run a top and left side set. Make them context sensitive and it's no longer a problem. Consider the new MSoft ribbon. It's all context based.

Consider you will need route and waypoint function to go beyond being just a viewer. If you ever become a view Google earth already has you whipped 6 ways from Sunday. As you move to being more than a viewer you need to think sailor in the cockpit needs to change a plan. Changing plans is the most complex area on the boat. You probably agonized on the plan for a long time and suddenly we need to make a new plan on the fly. How easy will it be to do that. That is really when it gets to be crunch time.

It has to be quick and snappy and you have a lot a of bad things going on and it has to be visually obvious. Under pressure you forget all the details and it has to be very visual and automatic.

Were you able to load more than 3 cells at a time? The very first release on our site was limited to 3 cells by mistake - this is fixed now, limit is 10 cells.

I didn't have time to push the limit. The real limit has to be unlimited. Really! You have to reach that point. You may not be able to deal with spacial indexing now but you do have to do that sooner or later. It's OK to get it off the table for now but the longer you put it off the worse it get. If all I can see is Baltimore Harbor then you lost me at Cape Charles.

I really do hope you have a lot of luck. I've got enough time in this business to know how hard it is and that night and day bleed into one all too often. To maintain a level of excitement to see a project like this through takes a lot. Probably more than you realize.

[brak]

Originally Posted by Pblais

Consider you will need route and waypoint function to go beyond being just a viewer. If you ever become a view Google earth already has you whipped 6 ways from Sunday. As you move to being more than a viewer you need to think sailor in the cockpit needs to change a plan. Changing plans is the most complex area on the boat. You probably agonized on the plan for a long time and suddenly we need to make a new plan on the fly. How easy will it be to do that. That is really when it gets to be crunch time.

It has to be quick and snappy and you have a lot a of bad things going on and it has to be visually obvious. Under pressure you forget all the details and it has to be very visual and automatic.

Good point, we'll definitely need to manage complexity and provide easy plan management, but we are not there yet. Slowly does it.

[RBEmerson]

I think it's very instructive to apply "what would a sailor do here" to the overall design. While I do think access to the ENC options is useful (case in point, my shallow, safe, and deep settings may not be someone else's; our boat's draft [water or air draft] isn't everybody else's draft and vice versa), it's certainly not a primary job task. What is important (past "where are we?") is being able to draw on a chart. That is, drawing routes, drawing LOP's, making notes, etc. With few exceptions, it's almost impossible to do more than drop marks, set waypoints, and draw routes. The ability to draw a range based on landmarks, for example, is a challenge in the programs I've tried. And the ability to mark an area for attention is limited.

There are some tasks computers do well and those capabilities should be used as much as possible. For example, laying out a route and following it is a primary task, of course. But laying out a route with input from predicted tides and currents and producing ETA's along the way is tedious when done by hand; computers do that work without complaint.

I/O flexibility is also crucial. One port for GPS data coming in and one port for autopilot commands going out simply won't cut it. I let the laptop send its data to the autopilot and also forward environmental data (wind, depth, speed) to other equipment in the boat that can also display this data. In addition to GPS data, there's environmental data, AIS data, and both the radar and VHF supply information that should included in the chart display. The radar can pass along the position of MARPA targets as well as EBL's, VRM's, and the cursor position. The VHF accepts position, course, and speed data and sends back information about DSC data received. The point is sophistication in setting up data ports is essential.

[brak]

A significant issue that prevented the viewer from working on many MacOS macines was just fixed. If you had trouble running the application and would like to give it a go again, the new version is now available (0.2.284 and above).

We would love to know if this solves the chart symbol problem!

[brak]

Evening everyone

A new alpha release of PolarView is available and we would appreciate your feedback. A few new features in this release are:

- Chart manager.
- Fully automated quilting.
- World base map built in.
- Opening current information location in Google Maps.

We also implemented numerous small fixes based on your feedback.

Download is available at Polar Navy

The easiest way to add most charts is to download a complete NOAA ENC charts package from ENC Downloads (look for "All available ENCs" link).
Open the charts archive in a location of your choice (i.e. C:\Charts). You should see a subdirectory ENC_ROOT with multiple ENC cells.
Start PolarView and open chart manager by using menu or pressing Ctrl+C (or Mac+C). Use option "Add Directory" and select directory location in which the charts were installed.

[RBEmerson]

The app crashes under WinXP SP3. It launches and shows the world map. Opening the chart manager and pointing to D:\Charts\ENC_ROOT (all NOAA ENC's in release) starts out OK but about a quarter of the way through indexing the charts, the app crashes. This was repeated twice at about the same point in indexing. I'll test this under OS X as soon as I can get the charts downloaded. Launching at least works well.

BTW, CTL-C is committed to Edit -> Copy - using it to open the chart manager runs counter to this. Either CTL-O or SHFT-CTL-O would be consistent with Windows (and OS X) UI conventions.

[brak]

Originally Posted by RBEmerson

The app crashes under WinXP SP3. It launches and shows the world map. Opening the chart manager and pointing to D:\Charts\ENC_ROOT (all NOAA ENC's in release) starts out OK but about a quarter of the way through indexing the charts, the app crashes. This was repeated twice at about the same point in indexing. I'll test this under OS X as soon as I can get the charts downloaded. Launching at least works well.

BTW, CTL-C is committed to Edit -> Copy - using it to open the chart manager runs counter to this. Either CTL-O or SHFT-CTL-O would be consistent with Windows (and OS X) UI conventions.

Did you notice which chart it is indexing when the crash occurs?

[RBEmerson]

Nope - it's obscured by Windows announcing the crash. BTW, under OS X 10.5.4, things loaded up and seem to working as expected with the same chart set (d/l'ed under OS X, of course).

[brak]

Originally Posted by RBEmerson

Nope - it's obscured by Windows announcing the crash.

This is too bad - the crash cannot be reproduced here (as usually is the case ) and knowing the specific chart would be extremely helpful in fixing the problem.

If you do not mind trying one more time, could you move the "progress bar" dialog towards top or bottom of the screen as soon as it appears, so that if/when crash notification re-occurs, cell name would still hopefully be visible?

[RBEmerson]

US3GC02M/US3GC02M.000 seems to be the victim.

I tried opening the error report file but couldn't extract it in plain text.