User Data Management in BaseCamp

Former Member over 14 years ago

Note: this information is deprecated as of version 3.2.

You will notice a few changes in the lower bottom half of BaseCamp after updating to version 3.1.1. We've received a lot of feedback on this forum on adding more data management features to BaseCamp that many of our MapSource users were accustomed to. Here are some pointers to get you started on using these new features. Note that all screenshots are of BaseCamp 3.1.1

Searching
As you start typing the name of a data item you want to retrieve, the search box will suggest items that match the name you are typing. You can press Enter or choose it from the suggestions to select the item.

Filtering
In the screenshot I have 89 data items, including multiple routes and waypoints. If i want to filter my list to show only routes. I would click on the button with the route icon to filter my list to show only routes.

Sorting
In the screenshot, I have a page full of tracks and I want to find the track with the most number of track points. I would first filter my list to show just the tracks. This adds a few track specific columns to the list. I would then click on the column heading 'Points' to sort my tracks by the number of track points.

Browsing
In the screenshot, I have a few tracks and I want to visually browse through the elevation profiles of these tracks. I would first bring up the elevation profile of one of the tracks in my list of tracks and then I can click on the Next or Previous button to switch to the elevation profile of other tracks.

0 Former Member over 13 years ago

Libraries and My Collection areas

I'm fairly new to Base Camp and using libraries (which seems like an unconventional name). Anyway, when I move items into a library "folder", I would expect it to disappear from under the root "My Collection" are, but it appears in both. If I delete it from one or the other, it deletes it from both. Is there logic behind not having a true hierarchy of "folders"? Am I missing something here?

0 Former Member over 13 years ago

While the developers claim there is some useful logic and rationale to the Basecamp model, there are many of us who argue differently. The developers claim that it makes it easier for users, especially non-technical folks, to use it. The jury is still out on that. Questions like yours would seem to put their claim into question.
[/end hissy fit]

Here's the scoop:

1. The "folders" are called Lists.

2. Lists don't ever contain anything but names.

3. The things (waypoints, tracks, routes, etc) you place in Basecamp's Library (there is only one) stay there, in the Collection. They never, ever, go anywhere else.

4. When you place something into a List, you don't. All you place there is a copy of the name and Basecamp makes a pointer that points the name back to the real thing which only ever lives in the Collection.

5. Since there is only one of anything and it only lives in the Collection, when you delete that thing, waypoint, track, whatever) from the collection, Basecamp then must go through all the lists that point to that thing and remove all those pointers because the thing they point to no longer exists.

I hope that is some help in understanding what you are seeing. Can you see the logic in it yet? :D

...ken...

0 Former Member over 13 years ago

Not to be argumentative, but, yes I do see the logic in that. That's the basic premise of a database and it is a very efficient way to manage and manipulate information. A pointer (name) takes much less storage and memory, not to mention much less CPU, to effect any particular operation on that data (pointer).

The problem that I'm seeing is that the BaseCamp folks made this leap from flat-file (MapSource) to database without educating the user community first. So folks are trying to apply a flat-file workflow to a database and it just doesn't work. A good database application design should never require the user to understand "how" a database works. So far that is not the case with BaseCamp.

There are currently a significant lack of user "tools" for manipulating and "viewing" how/where data is being used - which is very important in hiding the complexities of how the database works while still visualizing your data in a "logical" way. Hopefully v3.3 will bring some needed functions.

Maybe the video tutorials that they are working on will provide some "new user" education on this topic as well without trying to teach everyone how databases work.

Cheers,

0 Former Member over 13 years ago

After a long discussion in the german garmin forum about Data/Map View I found this thread explaining the thoughts behind the two different views. To make it short: In my opinion this was a fundamentally wrong design decision! In fact I'm astonished to learn here, that the design used to be "The right way" in previous versions of BC.

There is not one good reason for this splitting of views, so I want to answer to every of your arguments:

* the list will loose 3 rows of vertical space because of the column, the filter, and a horizontal scroll bar due to the columns not fully visible. It makes the list really hard to use especially if you have a small (laptop) screen.

No problem with this! By now you already have reintroduced the filter option again in 3.3.0

* the column is not useful unless you scroll to the right or adjust the splitter to make the list wider. If you did make it wider, isn't that similar to the user data oriented layout?

I don't need to see all columns. I need Name, Distance, Point, Color that's all and it perfectly fits into the left part of the screen without scrolling and plenty of space for the map. I definitly neew this informations during Trackdesign and for the general overview.
Make hide/unhide of columns useful in the Headings context menu of the list, save the visible state on program shutdown, that's all! Every user will find his/her preferred view style!

* the data filter may not be fully visible, which may lead to confusion of missing data because the selected filter is not directly visible.

Design the data filters as "Tabs" (they are Tabs!) which are horizontally scrollable (everyone knows how to do it in Firefox etc.) 99 % Percent of users need max. 3 filter categories and scroll for the rest if needed. No problem at all and you see your selected filter all the time.

Personally, I found the user data oriented layout really awkward when I first saw it.

I gave it a try and I think like you did: The Data oriented layout is !"$*$%$*"!'

So P*L*E*A*S*E think about it: Trash this "Data View" nonsense and make a versatile single Map View! You are going in the wrong direction with this View style switching. A lot of users simply don't know about this "Data View", It's layout is merely useless because of the minimized map and the list of the Map view looses it's information content Definitely a wrong design decision!

0 Former Member over 13 years ago

So P*L*E*A*S*E think about it: Trash this "Data View" nonsense and make a versatile single Map View! You are going in the wrong direction with this View style switching. A lot of users simply don't know about this "Data View", It's layout is merely useless because of the minimized map and the list of the Map view looses it's information content Definitely a wrong design decision!

Yes. +1 And, yes, I know this is piling on but I make no apologies.

It would make life so much easier if there was no Data View VERSUS Map View choice to be aware of. No forced compromises to choose between. Fewer things to understand about using Basecamp effectively.

Just make ALL the necessary features/functions available all the time. Then, if a person wants to change how things look they can simply drag a pane larger or smaller as needed.

This is another paradigm you had right in Mapsource ... all the filters and tabs and data columns, and the tools to manage them, are in the data pane. So all I need to do is drag it wider to see more, if I want to. One easily changed multifunctional view with everything there to be easily discovered and used as I need it. Elegantly simple and complete.

In Basecamp I can already drag the data panes larger if I want to see more. So why the extra complexity of leaving out necessary data and tools that I can only get access to by switching to some other arbitrary view. And which then causes me to similarly lose functions of the other "view" when I do it. And which remain hidden to me if I am not already aware of this whole "view" thing.

If I can already drag panes larger and smaller in any combination I need, why the extra complexity of the two "views"? If I need more vertical display space I can easily turn toolbar elements on and off.

Why not put your efforts for the visual interface into something useful like allowing me to unpin a pane and park it outside the Basecamp window or at least drag it to a new location inside the Basecamp window? And otherwise make all the tools and data available all the time and let me decide how wide and where I want things to appear??

...ken...

0 Former Member over 13 years ago

Yes. +1 And, yes, I know this is piling on but I make no apologies.

It would make life so much easier if there was no Data View VERSUS Map View choice to be aware of. No forced compromises to choose between. Fewer things to understand about using Basecamp effectively.

Just make ALL the necessary features/functions available all the time. Then, if a person wants to change how things look they can simply drag a pane larger or smaller as needed.

This is another paradigm you had right in Mapsource ... all the filters and tabs and data columns, and the tools to manage them, are in the data pane. So all I need to do is drag it wider to see more, if I want to. One easily changed multifunctional view with everything there to be easily discovered and used as I need it. Elegantly simple and complete.

In Basecamp I can already drag the data panes larger if I want to see more. So why the extra complexity of leaving out necessary data and tools that I can only get access to by switching to some other arbitrary view. And which then causes me to similarly lose functions of the other "view" when I do it. And which remain hidden to me if I am not already aware of this whole "view" thing.

If I can already drag panes larger and smaller in any combination I need, why the extra complexity of the two "views"? If I need more vertical display space I can easily turn toolbar elements on and off.

Why not put your efforts for the visual interface into something useful like allowing me to unpin a pane and park it outside the Basecamp window or at least drag it to a new location inside the Basecamp window? And otherwise make all the tools and data available all the time and let me decide how wide and where I want things to appear??

...ken...

Thanks for your support! I think we totally agree on this topic :)
I would like to sign every single sentence of your in deep analysis! And thanks for putting it into more elaborate language :o

Garmin, make BC a better version of Mapsource. There is definitely a long way to go! And the first step would be: Turn back!