ACME WildCachers

If you are careful in how you apply highlights, you can exclude any already highlighted caches before applying a different color to prevent accidentally changing colors. I have started doing this myself.

Those red pins are actually the default style in the Apple Maps framework. We saw this some during beta testing of 5.0, but it was hard to pin down causes. I know of at least one workflow that will cause this, but anything you can remember about what you did before this happened would help Nic to track it down.

7 hours ago, AnyMules said:

The workaround I use for this is to copy the text from the cache descrition and paste it in to the cache note - then I can just edit and add the extra info where I need to without needing to swap back and forth.

I do the same, but this approach falls short when photos are an important part of the puzzle since they can't be added to the cache note.

3 minutes ago, Twinklekitkat said:

Not trying to be obstinate but I do not get the options shown in the screen shot by @rragan.  Must be iOS version related.  I have an iPhone 7 running iOS 11.4.1 and DO NOT get these options.  I did in previous versions.  I am able to have links in e-mails open in geocaching.com but it is not "sticky".  Cachly always opens the app with no way to change it.  So as not to beat a dead horse I will drop it and just learn to live with it I guess.  @Bolling what version iOS are you running?

For what it's worth, I am running the same version of iOS that you are (though on an iPhone X), so I don't think OS version is the issue. Something else must be going on. Try uninstalling the Geocaching app temporarily. Cachly can't launch it if it's not on your phone. You can reinstall it later, but maybe that will allow you to reset this behavior.

OK, I think I may be able to finish connecting the dots. Cachly's View on Geocaching.com option will match the global iOS behavior for handling geocaching.com or coord.info links. I'm pretty sure when you initially install the Geocaching app, it makes itself the handler of those links because they have the power to do that as owners of those domains (or maybe there's an option right afterward that no one remembers). But I was able to change my preference between Safari or the Geocaching app by long pressing on a hyperlink like @rragan showed in the previous post and then choosing to open in Safari. For me, that option is sticky and iOS uses whatever I last selected globally (including in Cachly when using View on Geocaching.com). Before I started playing around today, my cache links would always open in Safari. After going to an email and then choosing to open in Geocaching app, Cachly started launching the app instead of Safari. And I was able to change it back the same way. Hopefully this works for you, too.

This sounds similar to an issue I've had. My typically weekly PQ is 1000 caches and I typically download it first thing on Friday morning before doing anything else that would use API calls. Two of the last three weeks I've gotten the pause banner at the end of the PQ download. I did not get it last week.

I think it would be a nice feature to be able to jump to my own logs for a cache from the cache details screen, but I would not want the button in the upper left to be the way to do that. I think it would be more confusing if that button suddenly changed to something other than the mechanism to post a log since that's what it has always been.

I have recently been thinking about submitting a very similar request for a mode to make it easier to work on field puzzles. The key to improving this would be the ability to quickly flip back and forth between the cache description and cache note without losing position in either. I was thinking this could be applied as an enhancement to the cache note screen that would keep the description loaded in a collapsed panel that could easily be pulled open and closed. On an iPad there should be enough screen real estate to have both the note and description visible at the same time (maybe even larger screen phones).

Could be related to something I reported a while back.

On 5/28/2018 at 7:03 PM, Nic Hubbard said:

A wiki is a wiki, that is just how they work. If we want to restructure or rebuild how it functions that is one thing, but changing how wiki's work in general isn't something we should do.

Completely agree. We won't be able to please everyone. If the very nature of a wiki is unintuitive to someone, there's not much we can do.

On 5/29/2018 at 6:06 AM, rragan said:

Specifics on what subjects he had trouble finding would help. 

I did actually push a little harder to understand the struggle and this is what I got back.

Quote

It’s just the general organization. It’ll mention to go to a menu, but there’s no link and it won’t be on the page. You have to go all the way out to the main menu, and click until you find it. When I noticed it, I was learning about offline lists, pq, and bookmarks. I was trying to find along the route info, but I found that on gs website.

 

I think this is potentially valid criticism. I haven't been browsing the wiki recently so maybe we are already doing a relatively good job of this, but cross-linking between pages is an easy win and something we should remain conscious of when making edits. A good rule of thumb is that the first mention of another topic that has content on a separate page should be a link to that other page or a section of the page.

Someone on the Facebook user group indicated the wiki was difficult to navigate, so I asked for specifics. I haven't given this much thought yet, but wanted to pass along the reply:

Hyperlink the reference. Or have the full menu in a drop down. Going back to the main page, I forget what I’m looking for. It only shows what’s in the section you’re lookin at, but other menus are mentioned and someone that doesn’t know the app/premium features well, it’s frustrating to have to try and remember what you’re looking for on the main page.

11 hours ago, Bolling said:

I personally like seeing the waypoints even if I pick one.

I agree, I don't see a reason to hide the other waypoints even if you specifically chose one from the waypoint list. I've been frustrated by this in the past because I'm in the habit of going through the waypoint list to pick a non-final waypoint rather than using Navigate and changing the target. I would prefer a consistent approach that shows all waypoints for the current cache, regardless of how you started navigation.

I interpreted that page to mean that Wikipedia uses Extension:MobileFrontend. The desktop version still looks like most wikis I've seen, but it also has a mobile-optimized view. Maybe that page is misleading.

2 minutes ago, Nic Hubbard said:

If anyone wants to look into the skins for mobile you are welcome.

I did one Google search and came across this page.

https://www.mediawiki.org/wiki/Manual:Mobiles,_tablets_and_responsive_design

Perhaps an extension would allow you to keep the typical desktop look and also get something better on mobile?

Went with text and no mailto link for now.

Just now, Nic Hubbard said:

Looks great to me. I am wondering if the support email address is going to get spammed though. 

Did consider that. I've seen some sites type the address out without a link like "support at cach dot ly." Harder for a bot to interpret and no link to follow.

10 minutes ago, rragan said:

If the user has narrowed their screen or is on a mobile device, the side-by-side screens will likely end up one above the other.

I definitely did not consider this, but it's an excellent point. Maybe the adjacent screenshots should just be broken apart and placed in between paragraphs? I think each screen has enough accompanying text that we could avoid the issue altogether that way.

I made several tweaks to the language on the page, primarily adding clarification and some links to more detailed pages of the wiki. It's really coming together!

Oxford comma? Please?

I also do not think app should be capitalized even when it is preceded by Cachly. 

1 hour ago, Nic Hubbard said:

We can ask for volunteers but they will need to be committed to helping translate each release. 

Done. Feel free to update if you don't like the way I presented it.

On 3/16/2018 at 11:54 AM, Nic Hubbard said:

Cachly is also localized in the following languages:

English, Dutch, French, German, Icelandic, Italian, Japanese, Polish, Portuguese, Swedish

Maybe this has been discussed before, but I'm wondering who actually did the non-English translations? Did you use a service or work with Cachly users? I was thinking about putting a note to contact you if wiki readers are interested in helping with new localizations but didnt want to overstep. 

There is an existing filter option for Last Found Date, but the user entry must be an absolute date. This is OK, but I found myself wondering if there was a way to filter my largest list based on caches recently found (within the last week). I can use Last Found Date with a date that's a week back, but this date must be manually updated each time I want to apply my "found in the last week" filter. I would like to have an option for Days Since Last Found that would be dynamic based on when the filter was applied and wouldn't need to be updated over time.

On 3/21/2018 at 10:49 PM, rragan said:

I modified the invitation to edit at the beginning of the Wiki indicating moderation will occur.

I inadvertantly added a duplicate comment about moderation. I missed yours because it wasn't in the same paragraph as the registration link. I rearranged this intro slightly and removed my duplicate comment.

Bummer. I added a note about moderation on the main page. Maybe it will cut down on confusion for new users who don't see their edits right away.

Hopefully spam won't be an issue. But if it is, moderation for unknown users seems reasonable to me. If you do end up turning it back on, I wonder if there is a way to make it more apparent to the user what is going on. What I experienced this morning was quite jarring. After saving a change, I was taken back to the page with no sign of my change, and there was no message anywhere indicating the submission requires review before it will be published. I've got plenty of experience with unmoderated wikis from an editer's perspective, but I'm not sure what sort of control the installation package gives you over the messaging for a user who is being moderated.