Re-thinking the whole database / visible elements part

[zsero]

Its not a clear feature request, but a suggestion for re-thinking some things which are now based on old concepts. I know there have been different requests about for example making the tracks into categories, just like the points, what I would strongly support, as when you import say 100 tracks there is absolutely no way to delete them, except to try to figure out which one was imported, one by one. The way it's done with points is the proper way to go in my opinion.

But for this whishlist, I just want to mention, that the whole database part is extremely segmented now, and is really really difficult to oversee once you really start using Locus. At the moment, all these functions behave in a slightly different way:
- database - tracks
- database - points
- maps - map elements
- temporary elements
- MyMaps export (why is it not called import???)
- categories for track
- categories for points
- startup phase for loading some elements (like in the database)
- startup phase for loosing others (like in maps - elements)
All these things are actually connected to what elements are visible in the screen, but they are scattered in a million places and all behave a bit differently.

What I'd like to ask is to make a clear new idea / design / architecture for all the database elements. I think as a general idea there should be a clean screen, giving us all the options we ever do with elements, and would consist of a clean design with only 3 tabs:
1. Points - with categories
2. Track - with categories
3. External elements
    -> here goes all elements, what are not static in the database but are from datasources
      A. from files / directories, like elements now
      B. from MyMaps
      C. from any other online or virtual data source

The points and tracks would have the same tree-like structure, with folder level and element level selection. All selection would be just a simple tick-box! No more change category, select all, change category, deselect all.
The temporary elements could be just one category for points and tracks.
The external elements would remember the state on startup. For example you'd have a folder on your SD card called: points, caches, tracks, etc. When you make a checkbox to a specific folder or file, Locus would load it up on startup. It might require some caching and looking at file size / file date change, but it's perfectly possible / not very complicated.
MyMaps elements would also load on startup, if there is network connection. If not they would just be using a cached version.
Exporting would work by clicking on any data element, or folder. Importing would have a button. The 4 button screen at the database now is very inefficient, import export doesn't need to be there and we need one more click just to do something.

This is my idea about how to make the database part better in Locus. I believe I'm an experienced Locus user and I find Locus to be more and more complicated to use with such a scattered database structure.

Here is my idea about a simplified, folder structured database screen.

[zsero]

OK, I think it was quite complicated when I wrote it. What I basically would like to say is that in my opinion, a better Locus experience would be much more simplified.
In my opinion, there would be 3 main areas where the whole experience should be concentrated: Main - Data - Map

1. Main screen - perfect as it is now. The UI in this area has really evolved into a close to perfect experience. Seriously, Garmin couldn't achieve with almost 3 billion of dollars under years and years what Locus did in such a short time!

2. Data manager screen - this is what my idea is about. This part would unify all points, tracks, and now scattered external data sources functionality. 3 tabs, one for points, one for tabs and one for external data sources. Points and tracks would be like now, but they would have the same category structure. For example if you import something.gpx with 100 points and 10 tracks, then these objects could be in a similarly named "something.gpx" category both in points and tracks. This way you could turn them off easily or delete them quickly.

External data sources would have to be well thought out and designed, but for a start you could just move Map Items and Google MyMaps elements here. Here, what is a category in points and track would be a data source. Actually, Map Items is a very ambiguous name, it should be renamed something like "file/directory loader". So instead of adding a category, you could add a new MyMaps item. Or a new file-directory item.

Finally, Import and export wouldn't have to be bigger then the small icons like "download map" in the map screen now. Definitely no need to take half the screen. Actually, export should go to an item and category option button.

3. Map screen - perfect as it is now. Except that the map items have nothing to do there. As well as the "delete temporary items". Crazy place for them.

Tell me what do you think about it. I think the idea is to simplify the basics to a very clean main - data - map workflow. And re-think the data part. And in the future, you can make the data - main split screen UI for tablets. Actually, at this point Locus would be in market for professional GIS guys.

[menion]

hmm I have this post in tab in firefox as one of TODO, but as you wrote "it was quite complicated" ...

firstly the easy onces ...
1. thanks, nice
3. items are required because it's main purpose is for GroundOverlay items (Network links, Screen overlays and others are supported) so these are more maps then points/tracks

2. this is worst and I have one "bad" message for. I'll not change Data Manager at no cost, because ... https://getsatisfaction.com/locus/topic ... s_and_data (read mainly my last post)

[zsero]

OK, then in this case I'd recommend the following:
1. Actually, it's quite close to what I was saying, starting by ditching the import export buttons. But instead of tabs you use the 3x3 grid, almost the same.
2. In this case I'd still recommend moving all advanced functionality, ground overlays, network links, file-directory sources (now part of map items), MyMaps, and possibly a lot of things in the future into an external data sources button (or make some friendly name for it, like). As Lotus evolves, all these things will be just scattered around in the craziest places. I think they all belong to the same place. This way you could actually use a lot of common function for these, like update button, checkboxes for each, import option, caching etc., will help you manage them in the future, as well as all users would much better understand what's going on.

The most important thing I want to say is that try to think about that the usage model of Locus and make it as simplified as possible. I believe it is about
1. main screen
2. maps
3. points-tracks
+bonus advanced functionality for experts

I believe everything could be built on top of these 3 + 1!

[menion]

if you look on locus evolution in last months, you may notice that more then adding new features, I work quite a lot on improved design and usability. So thank you for you comments and suggestions, I mostly agree with them. I just cannot be so "speedy". Because in nature of people is to speak more about negative stuff and changes, then about positive. Almost every change in GUI, have some (less or more) negative impact on rating, because people who don't like it, shout . Next update will be my death, I know it ) so then I'll have to take some break before next big changes like merging "map items" together with other stuff into separate screen (btw. I'm not much sure about it - My Maps is deprecated and no extra stuff is currently not planned - we'll see).

[zsero]

if you look on locus evolution in last months, you may notice that more then adding new features, I work quite a lot on improved design and usability. So thank you for you comments and suggestions, I mostly agree with them. I just cannot be so "speedy". Because in nature of people is to speak more about negative stuff and changes, then about positive. Almost every change in GUI, have some (less or more) negative impact on rating, because people who don't like it, shout . Next update will be my death, I know it ) so then I'll have to take some break before next big changes like merging "map items" together with other stuff into separate screen (btw. I'm not much sure about it - My Maps is deprecated and no extra stuff is currently not planned - we'll see).

Then always combine it with something extra :-) Like it has been rearranged a bit, but now you can do X. But yes, I perfectly know what you are saying, usually a product evolves linearly with a growing user base and then there is no way to correct for decisions what were made long long time ago when everything was so different. So it's a sensitive question, but extremely important. In my opinion this is the biggest problem with some open source projects, that they develop linearly, into bigger and bigger and finally huge monsters, because no one wants to take anything out, and then finally they end up with something what only the expert users can use (and really enjoy using it, because they know everything about it). And all the newcomers are left out, not understanding what's this huge mess and how to use it. I just want to strongly recommend sticking to some vision and following it / making surveys, even if it means cutting features. Actually, even Google cuts 3-4 products every year in "spring cleaning".

A quote from REWORK, an amazing book btw! Actually I truly recommend you to buy/read it.
http://www.scribd.com/doc/54730060/29/T ... he-problem

Throw less at the problem

Watch chef Gordon Ramsay's Kitchen Nightmares and you'll see a pattern. The menus at failing restaurants offer too many dishes. The owners think making every dish under the sun will broaden the appeal of the restaurant. Instead it makes for crappy food (and creates inventory headaches).
That's why Ramsay's first step is nearly always to trim the menu, usually from thirty-plus dishes to around ten. Think about that. Improving the current menu doesn't come first. Trimming it down comes first. Then he polishes what's left.
When things aren't working, the natural inclination is to throw more at the problem. More people, time, and money. All that ends up doing is making the problem bigger. The right way to go is the opposite direction: Cut back.
So do less. Your project won't suffer nearly as much as you fear. In fact, there's a good chance it'll end up even better. You'll be forced to make tough calls and sort out what truly matters.
If you start pushing back deadlines and increasing your budget, you'll never stop.

edit
menion, I'm in love!!! 2.6.0 :-)))

The only feature what is missing now is a better import. Let me explain what I think is a very common usage scenario:
1. At home, on a desktop you prepare a GPX file what contains with all the waypoints and tracks/routes you'll need on a trip. This GPX file contains everything you need.
2. In Locus you'd like to import all the file's contents into it's own category. This is the most important step. One trip, one file, one category!
3. Once you've finished the trip, you'd like to hide or delete the tracks/points.

I strongly believe it's a very common scenario for Locus users! Here are the following changes what you'd need to make it work.
1. Track categories, just like for points! Please, there is no alternative!
2. On the import dialog, make a choice for new category. By default, name the category after the GPX file's name, don't ask to enter it again.
3. The import would put the points in the points/new category and the tracks in the tracks/new category.
4. For each category, to show-hide it would be nice to have a checkbox with 3 choices: yes, no, some(grey checked). I think it is the natural way of handling categories, showing-hiding them with a single click! Also, you could see the state of each category, something not possible now!

Keep up the good work! Locus is amazing!


edit
I'd like to update on this. The new track categories and import is a nice change! I'd still prefer custom category names, just like for tracks, as well as the option to import a GPX/KML file into points/<filename> and tracks/<filename> category. This way you can easily switch on-off or delete a category. But thanks for the implementation, it's already a nice way forward!

[menion]

as I read our previous conversation, seems that major part is already completed. Mainly with current test versions, nice ...

about this automatic creating of categories by name of files. I'm not a big fan of such feature, so if you think it may be useful, I may recommend to post it on GetSatisfaction site

[zsero]

Posted it on get. Btw, from current most recent 5 wish-list threads, 2 of them could be solved this way
https://getsatisfaction.com/locus/topic ... zip_folder