[APP] - version 3.30.+ ( 15. 3. 2018 )

[Menion]

@Condor
hmm, I also think that this solution is complicated. But is there any possible better solution how to log trackables during logging a cache?

I'm aware of your one-click solution, but it is made for "Logs manager" ... select X logs and upload them together with logging a trackables. What I need is an option to really log a trackable during logging a cache.

So the only solution: change it to "online log" only as before?

@lor74cas
"stop" intent, in this case, makes sense, but most common scenario will be request without defined "profile". Ok ... solution ... "name" defined = only apply if this profile is active, otherwise stop always.

Support for Live tracking is planned.

[Condor]

@Menion
TB log at one cache, essentially as it was for years. The only requirement was to preset (or remember the last state) than the one visited. Whether it is on the old card or down on the main one is one. No offline storage! Just like sending in one batch with a cache. No gray records.

This "card" TB is similarly used in FNM for the whole dose. Follow sequence, synchro as detailed in it.

Really simple and no problems ;-)

[Menion]

Offline logs looked so promising, damn.
Oki, for now, I'll downgrade it to the previous system when the only online log of trackables directly with a cache will be possible. Thanks

[Condor]

Offline record of TB is really unnecessary and especially unrealizable.It is assumption of many variations of problems that can not be solved.
Real use? Nothing reasonable did not think. More importance to save offline log TB is the reason for its later use (send) For this purpose this activity is unnecessary. This action is only done when sending. And it does not matter whether it is a one cache or a lot of cache.
Everything is about saving time, doing unnecessary tasks, automating the process, minimizing errors.

We all want to make Locus the best.

[locus.sv@heime.org]

The way Condor describes offline logging of TB's was the way Maaloo Geocaching for Windows Phone worked and it worked OK for me, but there was issues.

For instance, a TB you have with you is logged as visited on cache A,B and C and then dropped at D. And you continue logging cache E and F without the TB.

How is this supposed to work in offline mode if you don't log anything about this while offline?
This will work if you send it to the API in chronologically order while sending the cache visits. I think the RC version would work as intended, but these points needs to be done:

1. Rename the LOAD button so that it is completely clear that this will also upload TB logs. (But I would prefer this button only load TB's)
2. Make sure all TB logs for cache A is deleted when any visit, attended, note or anything else is deleted for cache A.
3. Don't create duplicate visits, drops or anything else for a TB on a given cache. (I think we can live with that deleting a visit on a cache completely and create a new one must be done when you realize a TB is logged wrong. If your intent was to log a drop, but you logged a visit, then delete the local fieldnote and log it once again)

[Condor]

I do not know how to comment and explain the context properly.
The basic question is:
What do we want it to happen?
There is a need for this answer. We want to write TB to a specific cache log. Yes.

So this is what I want and the solution offered is complex and without complications. It is easy to apply for bulk enrollment.

Once again, I emphasize. Any storage of the offline TB log is unnecessary, it does not matter is the source of the problem. It does not require any subsequent action.

Any work with TB is only needed when you send it online. Just how it worked so far. We want automatic setup to be visited. This is the first phase and requirement.

The second is to apply this principle to the bulk log exactly in the same way automatically for all caches in a batch.

[locus.sv@heime.org]

How do you solve this use case with your solution?

"a TB you have with you is logged as visited on cache A,B and C and then dropped at D. And you continue logging cache E and F without the TB."

[Menion]

That's the common use case that complicates Condor's one-click solution and it's the reason, why I prefer log of trackables in the same screen, where you log a cache - so in the same moment.
Or did we miss something @Condor?

[Condor]

locus.sv@heime.org

Simple log single cache option:
exactly as it works until now. (required manually for each set visited or drop off)

Variant bulk log:
mark A, B, C click send. Cache D send individually, visited, drop off, grab. Mark E, F, G .... or all and send.

Individual unique decisions drop off, grab, pick up can not be automated. It is an action after a specific decision or action. It's not a repeat activity.
95% of work with TB is visited (own inventory). This activity takes up daily for a 50-100 cache of 1-3 hours. I want to spend 3 hours on nature or sleep or whatever. I want to save 3 hours of mobile phone battery.

[Condor]

The solution retains the principle of maintaining the status quo and the ability to send caches individually as now. Benefit would be to remember the setting you have visited.

New option (in FNM) to mark the range or everything, set TB as the visited and one click. Equipped. Each action is unambiguous and user-driven. No action makes any hits in a different cache or offline record.

[locus.sv@heime.org]

I understand your way of doing this and I was used to do this when I was on Windows Phone and Maaloo Geocaching. But it was always a hassle to remember everthing. It starts to get complicated when you have 5 or more TBs, drop them in different caches and visit tens or more caches. You have to write down what you do and be sure to do the right thing when home.

I think Menion's approach is good, but a few bugs have to be sorted out.

[locus.sv@heime.org]

That's the common use case that complicates Condor's one-click solution and it's the reason, why I prefer log of trackables in the same screen, where you log a cache - so in the same moment.
Or did we miss something @Condor?

This is how GSAK is doing it. You edit your logs, tell what to do with each and every TB and at a later stage in time, you send it to groundspeak. It works like a charm.

[Condor]

***  3.31.0 RC2   ***

The first and only click on the online log and this has happened.
Below TB records continue.


The magnifying glass is now great!

Line spirit! Some bugs ...
Appears when POI notifications are running

[Michal]

3.31.0 RC

My opinion on the setting dialogues:
1. An unnecessary complication of the structure of the settings. Why these additional levels, are there still a lot of settings to it?

2. The German translation has become worse, has Google translated?

Hi Frank,

Locus settings are very complex, we all know that, and for many (especially new) users, they were too complicated. In order to make them more intuitive we restructured them. Not on a base of our whims - its new structure comes out of an extensive testing, experimenting and thorough user survey. And as @menion has written, we struggled to rework it on behalf of logic and best possible UX for as many people as possible.

As for the German translations - Locus is translated by users voluteering in Crowdin translation project. If you are sure you could contribute and improve Greman translation, you can participate in it as well.

[lor74cas]

@lor74cas
"stop" intent, in this case, makes sense, but most common scenario will be request without defined "profile". Ok ... solution ... "name" defined = only apply if this profile is active, otherwise stop always.

Support for Live tracking is planned.

Hello, tested intent on last version:
Example:
track rec started with profile geo
intent sent pause geo, paused current geo recording profile OK

track rec started with profile car
intent sent pause geo, paused current car recording profile NOT OK