Jump to content

[FEATURE] Enhance Instant Notification Setup


frinklabs
Followers 5

Recommended Posts

Looks good to me. "Cache types to watch:" obviously, and "Log types to watch:" instead of "Events to watch:", since "event" means something else in geocaching.

 

And there's a bug in your page: you left out the log types for events. I point this out because I think this omission underscores why the existing interface isn't like this: the existing interface tries hard to avoid allowing you to select log types that don't apply to the cache type, and my guess is that's why each cache type has to be entered individually. I recommend abandoning that approach, happily allowing someone to click "found" and "attended" for traditional caches even though there are never any "attended" logs on traditional caches. Once you've decided that's OK, then the combined form of the type you've shown works fine and would be just what most people would want.

 

Although one thing you've left out is the range. That occurs to me because one thing that works out nicely about the existing approach is that you are compelled to select a range for each cache type, something that led me to realize that I'm only interested in new traditional caches that are relatively close, but I like to see new puzzle caches even if they're quite a distance away.

Link to comment

Looks good to me. "Cache types to watch:" obviously, and "Log types to watch:" instead of "Events to watch:", since "event" means something else in geocaching.

 

And there's a bug in your page: you left out the log types for events. I point this out because I think this omission underscores why the existing interface isn't like this: the existing interface tries hard to avoid allowing you to select log types that don't apply to the cache type, and my guess is that's why each cache type has to be entered individually. I recommend abandoning that approach, happily allowing someone to click "found" and "attended" for traditional caches even though there are never any "attended" logs on traditional caches. Once you've decided that's OK, then the combined form of the type you've shown works fine and would be just what most people would want.

 

Although one thing you've left out is the range. That occurs to me because one thing that works out nicely about the existing approach is that you are compelled to select a range for each cache type, something that led me to realize that I'm only interested in new traditional caches that are relatively close, but I like to see new puzzle caches even if they're quite a distance away.

 

Excellent input -- thanks!

 

I am guessing that if they have a PQ selection screen that allows you to simultaneously select "Caches I Found" and "Caches I Haven't Found" then having checkboxes for log types on caches that don't support them won't break anything.

 

Below are the changes you described, except for the "range" part. This is omitted because it, and everything below the section I have mocked up, would stay the same as-is.

 

Have a great weekend!

 

a46772cf-0f81-4868-8f10-4f7073f0d860.png

Link to comment

Looks good to me. "Cache types to watch:" obviously, and "Log types to watch:" instead of "Events to watch:", since "event" means something else in geocaching.

 

I was going to make exactly the same suggestion.

 

And there's a bug in your page: you left out the log types for events. I point this out because I think this omission underscores why the existing interface isn't like this: the existing interface tries hard to avoid allowing you to select log types that don't apply to the cache type, and my guess is that's why each cache type has to be entered individually. I recommend abandoning that approach, happily allowing someone to click "found" and "attended" for traditional caches even though there are never any "attended" logs on traditional caches. Once you've decided that's OK, then the combined form of the type you've shown works fine and would be just what most people would want.

 

That's the beauty of using this sort of approach to development. Using a mockup of what the screens might look like, users can identify bugs in the design *before* it's implemented.

 

Although one thing you've left out is the range. That occurs to me because one thing that works out nicely about the existing approach is that you are compelled to select a range for each cache type, something that led me to realize that I'm only interested in new traditional caches that are relatively close, but I like to see new puzzle caches even if they're quite a distance away.

 

Rather than include a range, another approach would be to first select a location and radius, then create the notification criteria for each location. For example, I might want notifications of all cache types within 50 miles of my home location, and also create a notification with just traditional, multis, and events for some other location I might be visiting.

Link to comment

If we're designing the ideal notification system, then what I'd love to see is the ability to choose a geopolitical region in addition to a range.

As an example, here's where I live in far-southwestern Canada:

map-bc.jpg

Literally everything south or east of the city is the United States (Washington state), separated from me by bodies of water. My home notifications frequently pick up caches over in the US, which I don't really care about (the ferries aren't cheap!). If I could limit the notifications to my province of British Columbia in the same way that I can with PQs, I wouldn't get these unwanted notifications anymore. I suspect there are many other cachers with situations where they want to restrict their notifications to a province/state/country.

Link to comment

Yes, this would be nice. I always wondered why the system only allowed us to pick one cache type under each notification.

 

Hopefully we'll get a response from gc.com letting us know if it can or can't be initiated.

 

You've also got Took Photo based on webcam caches.

 

Given "took photo" and "attended" mean the same as Found where a physical cache is concerned the interface might as well state that Attended and Took Photo will be treated as Find logs for the purpose of notification. The only other possible issue is Will Attend.

 

That said if you say you want to receive an email every time someone logs Attended on a traditional cache or Took Photo on an event cache you'll get that. There just won't be very many of them.

Link to comment

If we're designing the ideal notification system, then what I'd love to see is the ability to choose a geopolitical region in addition to a range.

As an example, here's where I live in far-southwestern Canada:

map-bc.jpg

Literally everything south or east of the city is the United States (Washington state), separated from me by bodies of water. My home notifications frequently pick up caches over in the US, which I don't really care about (the ferries aren't cheap!). If I could limit the notifications to my province of British Columbia in the same way that I can with PQs, I wouldn't get these unwanted notifications anymore. I suspect there are many other cachers with situations where they want to restrict their notifications to a province/state/country.

 

Not necessarily even a province. I live to the south-west of London so the only "obstacle" (if it can be called that) is a very dense urban area.

 

A cache 20 miles west of me is an easy proposition by bicycle. A cache 15 miles northeast means going through central London, which I have very little interest in doing.

 

By car I can get 20 miles SW in around 20 minutes. 20 miles NE would take me a couple of hours, maybe more. 20 miles NE would probably be quicker by bicycle than by car.

Link to comment

7 years later and we still have no improvement on how one sets up notifications?  I would like to be notified of ALL new caches/events/etc. in my local area, and it appears that one must still set up a cache-type by cache-type notification. 

  • Funny 1
  • Surprised 1
Link to comment
7 hours ago, Keystone said:

Yes, that's correct.  One reason for this is the different log types available for certain cache types (Attended, Will Attend, Webcam Photo Taken).

Not a very convincing reason.

A rather trivial front-end code extension would allow multi-selection in the "Cache Type" list, and then display all those log types, which are common to all selected types (e.g. "Published", which is probably by far the most used log type in notifications). When clicking "Create Notification", the code could still send individual notification settings to the back-end. No back-end change needed, and much better UX, when setting up publish notifications in a new area.

  • Upvote 1
  • Helpful 1
Link to comment
8 hours ago, Keystone said:

Yes, that's correct.  One reason for this is the different log types available for certain cache types (Attended, Will Attend, Webcam Photo Taken).

Like baer2006 said not convincing reason. Just put a watch on those events and webcam cache.

 

It's 2021 now a big upgrade of Notification System is required it's dumb to require to put a new notifications for each different type of cache to get the new published.

Edited by Lynx Humble
Link to comment
6 minutes ago, Lynx Humble said:

It's 2021 now a big upgrade of Notification System is required it's dumb to require to put a new notifications for each different type of cache to get the new published.

 

We've seen how much functionality is removed and how many things get inadvertently broken with other "big upgrades" recently. Yes, the present system is clunky but it's functional and pretty flexible and is something most cachers wouldn't be constantly changing, it's just go through the process of setting it all up the way you like it and that's it. If it ain't broke, don't break it.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Followers 5
×
×
  • Create New...