Hmm, I think we’re getting close here. I see what you mean about the segment editor workflow having value, but cleanup is still of dubious use there? If you start with the segment editor and use that to confirm enough individual segments, eventually Arc will split the segment into more correct segments where users can further confirm or continue to split. I can see cleanup providing some value there, but it definitely shouldn’t be the primary action on the previous page as it is now because that’s not where it is most contextually relevant.
Yeah, I agree. In that workflow Cleanup doesn’t provide much. I think Cleanup best fits in the opposite workflow.
I’m trying to recall my own workflows in more detail, because how the app is now tends to fit very well with those - I’ve basically designed the buttons and flows to match my personal preferences. So if I can document those (instead of them just being implicit muscle memory) that’ll be clarifying. Not to say “my way is right” but to understand more clearly the different workflows.
Sometimes I do frequently is tap into the details view for an item and tap the Cleanup button. Especially for Visit items, but also often for Trip items. I do that as a first casual step, while browsing the timeline data, before getting into “I need to start confirming/correcting the timeline data”.
For Visit items I think that workflow isn’t really in contention. Cleanup does a job that doesn’t have a competing workflow.
For Trip items, I think there’s two kinds of cases: 1) I know the trip was all one activity type, eg all walking, or 2) I know the trip had a mixture of activities, and I want those separations preserved.
For the first case, that’ll be where I tap Cleanup on item details view frequently. It has zero risk of undoing any potential manual work I’d done previously - it won’t overwrite already confirmed type assignments. It’ll only change/confirm the type of samples that don’t yet have a confirmed type. So it efficiently serves that quick cleanup task.
Like, let’s say I know the whole trip was walking, but there was some 30 second stationary period, and I’ve already confirmed that segment as stationary. If I used the item edit view to confirm/correct the item’s type, that’d wipe out that segment level work. It’d convert all samples to walking. But the Cleanup button will just clean up around the manual work I’ve done.
That’s I think what I made that button for in the first place. That sense of: There’s some new samples here, their types aren’t exactly right. If I confirm/correct the entire item I’ll wipe out some sample/segment level changes I’ve already done. If I go into segments view to clean up piece by piece in there that’ll be tedious. Solution: the Cleanup button.
2 Likes
Ok I tried it again for a longer period and have some more feedback
- The new model is very good at determining type, it’s very bad at determining when to split. So often if I have a mixed car/walk route it will correctly determine the segments but then not parse them out as two separate segments so I can’t auto confirm
- I really don’t like when you confirm locations it doesn’t automatically clean up as stationary, it’s a large change from The current version of arc and not my preferred behavior
- When trying to select a location, the map is way too close. I often don’t know where it is so it’s hard to correctly choose a place without manually zooming out
- The availability of the clean up icon is kind of annoying, I wish it was available on all screens. Sometimes I want to use it and have to dig into a menu
1 Like
Oh I totally agree on your first point. When I have a mixed train/walking trip, it’s tedious to go into the individual segments view and re-confirm some as walking others as train.
I’d like to make the case (again?) for a multi-select or batch editing feature. Yesterday I took a long train trip. And this is how the timeline view looks like:
This continues hundreds of times. There are a total of 125 uncertain items. It is tedious to edit them one by one manually.
What I want is to be able to tell Arc Editor to select all segments between 3:50pm and 9:50pm and clean them up into a single train trip. I’m thinking of a simple UI where the user specified the start time, end time, the segment type, the app highlights the selected segments, and then the user taps Confirm to make a change.
Interesting! I haven’t noticed this difference in behaviour myself. I’ll keep an eye out for it, and see if I can figure out what’s happening differently.
I’m confused on that one. If you confirm a Place assignment for a Visit the behaviour is the same in both apps. In both cases all it does is set a `confirmedPlace` flag on the Visit, without making any changes to the samples within the Visit. In both apps if you want the samples cleaned up inside the Visit you still have to tap the Cleanup button separately.
Noted! I’ll have a look at the zoom levels and tweak a bit. Those are super fiddly to get “feeling right” in various different situations. I’ve probably tweaked it differently in Arc Editor and not done as well as before.
The Cleanup button is available on Item Details view, Item Edit view, and Item Segments view, same as in old Arc Timeline. In the old app it was sometimes in a menu, but in Arc Editor it’s always on the toolbar.
Perhaps what you’re noticing there is sometimes the button isn’t present, because there’s no samples available to clean up. In iOS 26 it’s not possible to “disable” a toolbar button. You can’t have the button present but greyed out / disabled. So in those cases where the action can’t do anything I’ve had to leave the button out completely. So probably what you’re seeing is a case where there’s no suitable samples for cleanup and the button is missing.
Though that can change quickly. Like, a new sample might come in (if you’re looking at the current item) and then there’s something available for cleanup, so the button will reappear at that point.
Heh. And as always I’ll push back, saying that that kind of UI is a failure on the part of the developer. If you have to add UI to make it easier for the user to clean up after your own mistakes, you’re not doing your job properly as a developer.
The correct solution is to figure out why LocoKit2 recorded that mess, and fix that. Or if the recording can’t be fixed, then figure out why it didn’t automatically clean it up itself in processing, and fix that.
Basically there should never be a case where you have to multi select to clean up a mess. If there is such a case, the app hasn’t done its job properly and there’s a bug (or few) to fix. If I make UI so that you can clean it up yourself more efficiently, that reduces the pressure on me to fix the actual cause of the problem. Which … yeah, that would be me failing at my job.
Which means… I need to debug your screenshot! It looks like the stationary state detection periodically incorrectly concluded “stationary” while the train was moving. So the question there is: why. Was it low accuracy location data? Could be, if tunnels, or sometimes if it’s a high speed train or passing through built up city areas - anything that would make it difficult for the phone to maintain reliable line of sight to enough satellites.
Though in those situations I think the stationary state detection is meant to fall back to “unknown”, not “stationary”. To conclude stationary it has to have enough data to be confident. So this looks to me like some weakness in that algorithm, for it to be concluding stationary in a situation where that’s not a plausible answer, and it believes it’s got enough data to make that conclusion.
Oh, following on from that screenshot debugging… I think also what I’m seeing there is the timeline processing not finishing its job. It’s not allowed to leave behind zero second Visits. Those don’t meet the “keeper” threshold and must be merged.
So it looks to me like the timeline processing only did part of its job, and didn’t diligently finish up. And it’s also likely that if you came back later it would at that point get the job done. This is a known bug at the moment - something I’m noticing every day at the moment while working on workout importing. (The workout importer triggers that timeline processing laziness, for various reasons).
I’m going to try to get that fixed up in either the next build or the one after. Probably not the next build, because I want to get workout importing shipped in the next few days. But once that’s shipped I want to figure out why timeline processing is sometimes being lazy and giving up before it’s finished the job.
It does eventually finish the job, when it comes back to processing that data at some later point. So it does know how to do it properly, it just should do it properly the first time!
Yup the location accuracy is low. During the trip Arc was reporting an accuracy of about 1 mi. I think however that it’s probably an underestimate. The train probably just had certain types of coated windows that prevented good GPS reception.
Yes I’m now inclined to believe it’s the processing engine not finishing its job. I think previously the Arc app is pretty good at finishing processing. Let me know if you need any more information from me to debug this.
Also if it was a high speed train those can have the problem of making it more difficult for the phone to settle on some consistent satellites to get signal from. Throw in the occasional tunnel and sometimes the phone never gets enough time to settle into a clear fix before it loses it again.
I see that happening in Japan quite often, sometimes even without tunnels, and from what I’ve seen it’s also quite common in Europe on high speed rail. In a weird way it’s sometimes worse than the airplanes situation.
Anyway I’ll sort out that processing engine laziness shortly! From everything I’m seeing, it does know how to do the job properly, and does get there in the end. It just … decides to not finish it sometimes? It’ll no doubt be some dumb little one liner mistake I’ve made somewhere.
Forgot if specific issues were mentioned..
Total visits view in timeline always goes to today. Seems so.
When viewing map points in that view, it shows duration and time. Date would help too.
Trying to fix some in a long list it is easier to find incorrect ones on the map. You had said view in timeline is available in list yet a tap and hold menu from tapping on the map I think would help. When there are many visits and some need reassignment, trying to match found visit on map with one in list, to select view in timeline is cumbersome.
1 Like
I think I’ve seen this happen once, but can’t make it happen today. Not sure what’s different. I’ll keep trying. Maybe I’ll catch it in the act. Or have a clever idea for why it might be happening.
Is that for the tooltips that appear when you tap on things on the map? If so, yeah I see what you mean. The rest of the views say date as well as time, but those ones don’t. I’ll add it there too 
Aah good point. Yeah from the map taps in All Visits view those don’t offer “View in timeline”. There should be a way to get to that. Otherwise you have to guess which one it is in the list.
1 Like
Thank you matt.
Trying to fix such visits from visits list, perhaps as one selects visits and then returns to list to continue fixing, table scroll position could be preserved? Would be great and sure would help.
1 Like