Jump to content

PQ's Days being unchecked after processing


TeamWalri

Recommended Posts

I was checking out my PQ's on Wednesday 9/20 and noticed in the totals at the bottom that there were 0 for Wednesday. That was unusual as I have 2-3 different PQ's each day. Well I noticed that there were 3 that did run that day but for some reason the Wednesday box was unchecked after it created and mailed the PQ. Each of my PQ's are checked to "Run this query every week on the days checked" and it should not uncheck it.

 

I noticed again today (Thursday) that the same thing happened.

 

Just thought I woudl bring it up.

Link to comment

From reading the UK forums this is a permanent "feature."

 

So much for "automation." I personally don't understand the need to go to this as even today--being a Friday--the latest PQ for us ran before 9 AM.

 

Must be getting ready to offload some server time to Waymarking PQs. As if that's anything I'm interested in. I paid to geocache and was never consulted about extending my money out to something I'm not interested in and get reduced service in the stuff I am interested in.

 

EDIT: I was looking at the wrong date. It seems all of a sudden the PQ have ground to a crawl. Yesterday's last PQ for us was 12:40:44 PM and the one I thought had run before 9 am hasn't even ran yet at all--that time for a run earlier in the week. Prior to that most have ran fairly early, some as early as before 1 am and most well before 4 am.

Edited by CoyoteRed
Link to comment

I paid to geocache and was never consulted about extending my money out to something I'm not interested in and get reduced service in the stuff I am interested in.

 

We generally reside at opposite ends of the spectrum on almost every issue, but as much as I hate to say it, but I agree completely with CR. TPTB might want to sit up and take notice, that if they have done something that CR and I agree was a bad move, I bet there are a lot of poeple in the middle who feel the same way.

Link to comment

I paid to geocache and was never consulted about extending my money out to something I'm not interested in and get reduced service in the stuff I am interested in.

 

We generally reside at opposite ends of the spectrum on almost every issue, but as much as I hate to say it, but I agree completely with CR. TPTB might want to sit up and take notice, that if they have done something that CR and I agree was a bad move, I bet there are a lot of poeple in the middle who feel the same way.

 

CR is just speculating that this PQ cleanup has something to do with PQs for Waymarking. He is probably way off base as PQ for Waymarking would proabably be scheduled on a different machine than geocaching PQs. The clearing of the automatic days to run has been used before to control the load on the PQ server. Too many people schedule PQs to run everday of the week even though they don't use them everyday. I suspect that if they got rid of the days to run and you always had to submit PQs to be queued to run once like we do with the My Finds query, you would find that you would usually get your PQ in a few minutes and never more that a hour or two.

Link to comment

I won't speculate on the reason it was done.

 

I do consider the unannounced change of something from recurring to limited shelf-life to be naughty. Users not reading the forum but with even just weekly PQs delivered will likely only notice the change when they realize they're hunting with old data - something the site is normally reluctant to promote.

Link to comment

I do consider the unannounced change of something from recurring to limited shelf-life to be naughty.

I feel the same way. The TOS says:
Groundspeak may change, suspend, or discontinue any portion of the Site, or any service offered on the Site, at any time, including but not limited to any feature, database, application, or content. Groundspeak may also impose limits on certain features offered on the Site with or without notice.
So he can change it without notice, but I think it would have been more polite to do it with notice.
Link to comment

While I have no idea why it has happened, I was expressing displeasure with having a feature taken away. I can live with only having one recurring pq, but taking away the automation is frustrating. In my opinion, premium member features should make participating in a hobby easier, not more convoluted.

Link to comment

I just noticed this message in the body of my latest PQ's:

 

It has been 30 days since you last edited this query. To continue receiving this query next week you will need to reselect the days for it to run. This is an automatic housekeeping rule to speed up Pockey Query generation for everyone.

 

As most people never read the emails, I don't think this was the appropriate way to announce the change. An announcement in the forums, while still not reaching most geocachers, would probably have been read by more.

Link to comment

I just noticed this message in the body of my latest PQ's:

 

It has been 30 days since you last edited this query. To continue receiving this query next week you will need to reselect the days for it to run. This is an automatic housekeeping rule to speed up Pockey Query generation for everyone.

 

There probably could not have been a worse way to do this. A solid number of people never even look at these emails and depend on other programs, scripts, etc to pull these emails and pull the .gpx files out of them.

 

Are TPTP listening here?? It would have been more appropriate to send an email to the primary account (yes, I have my PQ's going to another unmonitored account that gsak checks). PQ emails are NOT the place for communication, as they are (from everyone I know) mostly unmonitored.

Link to comment

But a general message does not affect everyone. TPTB sent the e-mail to the people that get the Pocket Queries. It's their fault that the people don't read the e-mail?

Actually, NO, its not... I expect a PQ email to be just that, a PQ. IF TPTB want to send me an email, they should send it seperate to my primary email address. There is no reason the PQ generator couldn't send two emails, one for the PQ (and thats it), and a 2nd for the message. PQ's are very often automated. I would suspect (no stats) that there are more people that use programs/macros/whatever to pick up the PQ emails than people that dont. If true, that means the majority of people for which the message was intended did NOT see it. Watching the forums supports that. Many people complained about the PQ's getting unchecked before a single individual several days later noticed the message.

 

If TPTB @ GC wish to send a message, it needs to be seperate. I do not believe the PQ emails are the place for that, even if they involve PQ's. The messages WILL be missed.

Link to comment

Until someone doesn't get a pocket query and goes back and reads the e-mails that say if they don't update the PQ...

 

GC.com did not create the automated process to grab the e-mails and macros to pump the information into GSAK or whatever software. They sent an e-mail message that stated what everyone needed to do.

 

I'm sorry - we're all grown up responsible people here. If you choose to not read e-mails that come along with a pocket queries, I don't see why GC.com has to send another SEPARATE message to say "Did you read the e-mail we sent? Here it is again."

 

Some of the the same people that have an automated system of macros to capture PQs also have special e-mail accounts for the PQs, and would NEVER read the e-mail that was sent the same way.

 

They could have spoon-fed everyone and sent 40 e-mails - one every day up to the change. Seems kind of redundant.

 

I guess I just disagree: I don't think that something like this is completely GC.com's fault.

Link to comment

I'm sorry - we're all grown up responsible people here. If you choose to not read e-mails that come along with a pocket queries, I don't see why GC.com has to send another SEPARATE message to say "Did you read the e-mail we sent? Here it is again."

I DO choose to read every single email that is sent to the email address that I supplied to gc.com for communicating with me. I have separate emails for PQ's myself, and thats all that should go to that email address. No where did I even come close to indicating to gc.com that I wished to receive any other communication to that email address except for PQ's.

Some of the the same people that have an automated system of macros to capture PQs also have special e-mail accounts for the PQs, and would NEVER read the e-mail that was sent the same way.

Which is why gc.com needs to communicate to the email address that I supplied for that purpose, not to an email address that I clearly indicate is only for sending a PQ to.

Link to comment

We are set up exactly the same way as Potato Finder. We do read all the emails that come to the address we set up for geocaching communications, but the PQ account is reserved just for PQ's.

 

It probably would have been better to send an email to the address we supplied for communicating with Groundspeak rather than the PQ account. I probably would have not detected the change for a few weeks when PQ's stopped coming in, but at least the forums brought it to my attention sooner.

 

edited for clarity

Edited by jon & miki
Link to comment

I agree with the two posts above me.

 

I, too, have a special email box just for PQs. After processing the only thing that is left is the zipped GPX files, nothing else.

 

TPTB are fully aware of the fact that folks do this. It's either that or they so happen to not read this forum which would be odd to say the least considering it is for discussing this site.

 

I do have the box checked in our profile that says, "Inform me of new features and changes to the web site." Why not use it?

 

Yes, we are responsible adults, but we are also consumers of a business website for which we've paid a yearly subscription. I'd think we'd be treated better than this. I mean it's not as if this wasn't discussed last time.

Link to comment

Hold the phone. This is the text of my PQ email that I received yesterday:

 

Here are the Pocket Query search results in the formats you requested.

 

49380.gpx: GPX is an extended GPS exchange format that can be read by both EasyGPS and ExpertGPS, as well as various other software applications. The latest version of EasyGPS for Groundspeak can be downloaded from the links section of Geocaching.com. You will need the latest version to read this format.

49380-wpts.gpx: This additional GPX file contains supporting waypoints for your Pocket Query.

 

No mention of the 30 day expiration date. I created the PQ over a year ago and it's parameters don't change as it's for the general area near my home. It runs only twice a week. Now I have to make a random change just to keep it running every month?

 

[edit for typo]

Edited by Rebel
Link to comment

There are LOTS of people that don't read the 700K zip files or a 3MB XML file when they arrive. Expecting users to do so is just unrealistic. There are also lots of users that, because of the large nature of these things, redirect them to alternate accounts that are never read by a human.

 

There is a place in the forum for announcements that is almost never used for htis kind of thing.

 

There is a "notify me of changes" mailing list that wasn't used.

 

There is a weekly emailing that wasn't used.

 

Yes, the TOS allow it; legality isn't in question. Even though the change itself is insanely annoying, I'm not even fussing about that right now. Sticking a notice in a megabyte zip file that's directed to an email address that isn't read by humans (you know, the only place the site uses an alternate email address becuase they know they're using it to send megabyte zip files that aren't likely to be read by humans...) is simply not a good way to announce the change. Then again, email is simply the wrong way to distribute multi-megabyte data but let's stay focused here.

 

It seems that you only get the email when it expires, too, so until you notice that the recurring subscription stops, you will be hunting with old PQs in this case. A user that gets one PQ a week will see it disable itself after just four deliveries. That's bad, Markwell. Nobody in this thread asked for 40 announcements.

 

If PC magazine subscription decided that I had to call a fone number monthly in order to get the next issue and announced that in a paragraph in the "gamers" section (I don't do games) I'd be similarly annoyed.

Link to comment

I'm sure everyone has different requirements and methods for using PQ's. In my case however, I use PQ's so I can have as complete and up-to-date information as possible about a cache on hand when I go to hunt it. We travel for a variety of reasons (not just caching) and do not typically plan out our hunts in advance - weather, proximity, mood, energy levels, available time & daylight all play a role in selecting the caches we go for and most of of that information isn't available until we're in the area. (I should add that we usually don't have web or wap access while we're travelling, we rely on Cachemate for a static picture of the available caches)

 

I do understand the need to somehow cull out PQ's that are not being used. No matter how big the server(s), an ever-increasing load can eventually overcome any conceivable upgrades.

 

I for one would be willing to give up scheduled PQ's entirely if I could have a single query with the following caches included in the results file:

  1. all caches that had their description changed since the last time the query was run
  2. all caches that had their coordinates updated since the last time the query was run
  3. all caches that have been logged since the last time the query was run along with the "new" logs entered since the last time the query was run (not limited to 5 or 20 logs. If a cacher wants to have the logs in hand for a new cache in our area, they pretty much have to run a "new caches" query daily; with a 5 log limit, they may still miss some logs that would have been invaluable for finding the cache.)
  4. no 500 cache limit (perhaps a file size limit of <10mb might be applied though or limit results to a couple of states could be used to prevent hijacking the master database)
  5. only the cache GC# plus an archived flag for all caches that have been archived since the last time the query was run

To my thinking, the complete cache information should be included for caches under criteria 1-4 and only minimal information provided for archived caches (no coordinates, description, logs etc).

 

Since older caches get logged/changed/updated much less frequently, I believe the results file size might actually get smaller with this sort of query. If scheduled queries could be superceded this way, the whole issue of "deadwood" queries could be made to go away. And the number of queries needed to cover an area (like the UK or one's normal hunting range) would be reduced as well, with the side effect of removing duplicate results before they are sent out as PQ files.

 

With this kind of query, I could simply ask for the results when I'm getting ready to travel or go on a hunt. In my case anyway, we would no longer need scheduled queries at all, we'd just ask for the updated results whenever we were ready to go on a hunt. If we were travelling, I would do what I do today, schedule a one-shot PQ for the area or route we plan to hunt along.

Edited by jon & miki
Link to comment

Yet another approach, one I at least would find a little more user-friendly, would be to put a limit on the number of times queries could be run instead of using a time limit.

 

That limit could be applied on a per query basis or against the total number of query runs made.

 

On a per query basis, allowing 26 runs (for example) before the PQ had to be re-ticked would allow the folks who run a weekly query to go 6 months or so before rescheduling while making folks who generate higher loads reschedule on roughly a monthly basis.

 

If the limit was set up to be based on how many runs could be made for ALL pocket queries before rescheduling, the effect would be to favor those who did not overload the system with pocket queries. With say 300 runs allowed, someone running 10 pocket queries on a daily basis would have to reschedule monthly while someone running just one a week would probably never have to reschedule. This approach in effect allows each cacher a limited amount of server usage before rescheduling rather than setting an arbitrary time limit.

 

I hope gc.com will consider these proposals along with any offered by others as a better long term strategy than the currently implemented one.

Edited by jon & miki
Link to comment
I created the PQ over a year ago and it's parameters don't change as it's for the general area near my home. It runs only twice a week. Now I have to make a random change just to keep it running every month?

Just enable it to run on whatever day. That is all the "change" that is needed to keep it running for another 30 days.

Link to comment

I just noticed this message in the body of my latest PQ's:

 

It has been 30 days since you last edited this query. To continue receiving this query next week you will need to reselect the days for it to run. This is an automatic housekeeping rule to speed up Pockey Query generation for everyone.

 

As most people never read the emails, I don't think this was the appropriate way to announce the change. An announcement in the forums, while still not reaching most geocachers, would probably have been read by more.

 

I admit that it wasn't necessarily the absolute best way to notify users, but it does give you 7 days notice to make the change to your query. Since I can't even hazard a guess as to whether you read your PQ emails or not (and you should), it's kind of the point that you should be reading them.

 

We'll add a way for you to bump your query date on the PQ page in the future, and show the "age" of your query so you know you may need to bump it. I don't have any issues with suspending this necessary evil until we add some additional ways to "ping" your queries so we know a human being is out there using them.

 

Inferring that the change is due to Waymarking Pocket Queries is weird. I tried to follow the trail to that conclusion but got lost along the way.

Edited by Jeremy
Link to comment

These unannounced changes sure seem to happen a lot. Stripping scripts from the profile page with no notice, changing the html format on cache pages with no notice, now this with the PQs.

 

How about a creating a section on every cacher's profile page where changes like these can be announced? Or even a separate Announcement page. Something... anything?

Link to comment

Of course it was frustrating to not be getting my PQ's, but at least after finding this thread, I now know why. I'm not happy, but I guess it is the prerogative of the owners of geocaching.com to decide what features will be provided for the price of membership. That's my complaint. :lol: Now here's my question....

 

I have six PQ's that run once a week to keep my offline GSAK database current.

 

I am not clear on whether I can go to my PQ list once a month and recheck these to run for another month? Or to get them to work again, do I actually need to make some small change to the PQ itself and then recheck the day of the week in the list?

 

on edit: ---After re-reading Jeremy's post, I THINK I understand the issue is the same one that was a problem a while ago. Namely that after a while many PQ's are being generated for accounts that are not active. By clearing the system, this streamlines the PQ que for those that are using them. If that is correct, how about this solution?

 

Once I get a good PQ, I may use it for months without having to edit it. So instead of unchecking the day of the week based on the last time a PQ was edited, can TPTB make it dependent upon your last visit to the website? If an account has not logged into the website for a month, then uncheck their PQ's. If that is too hard to program, how about an separate email warning us that the PQ's will be unchecked in, say 48 hours. A link in the email could take us to a spot on the website to check a box indicating that we are using and want to keep receiving the PQ's. There may be other solutions that are also better than forcing a once a month purge and editing of all recurring PQ's.

Edited by Cheminer Will
Link to comment

I admit that it wasn't necessarily the absolute best way to notify users, but it does give you 7 days notice to make the change to your query. Since I can't even hazard a guess as to whether you read your PQ emails or not (and you should), it's kind of the point that you should be reading them

 

We'll add a way for you to bump your query date on the PQ page in the future, and show the "age" of your query so you know you may need to bump it. I don't have any issues with suspending this necessary evil until we add some additional ways to "ping" your queries so we know a human being is out there using them.

 

I agree with you - it wasn't the best way to notify users. And it still isn't notifying many users. I found out about it in the GSAK forum.

 

I personally think that it is a good idea, but every 30 days is a bit too much - 90 days would be more acceptable.

 

There must be other ways though of lowering the overhead on your PQ system than by doing this though, and you're paying to money (I assume) for programmers and system engineers. Several good suggestions have been made above, and should be seriously considered - but here's my bit...

 

I live in West Australia. Like most cachers over here, I run two queries per day to keep my GSAK database up to date though from time to time (as now) I keep tabs on just a little more.

 

A single PQ containing all updated records for say 14 days, could be run and sent to every cacher (premium members only of course) in West Aust who requests it, on a daily/weekly/fortnightly basis, saving perhaps 50 PQ's per day from running. Not much of a saving, but looking at it from a global position, there would have to be a considerable reduction in the number of PQ's run on a daily basis.

 

There would have to be a PQ option to select an unlimited number of caches with recent updates within a pre set period (e.g. all logs for the last 7 or 14 days), for a specified state or country, and would override any/all other selected options. This type of PQ would be run first each day (top priority) and the resulting GPX file would be distributed to everyone selecting it for that state. The PQ would only run once, with your mail server handling the distribution task.

 

The end result is that you could give us as customers more (caching logs) for less (system PQ machine overhead). e.g. If I wanted to keep a database on all of Australia, I could keep it up to date with the data from a run once PQ for all of Australia that includes me in it's distribution list.

 

Just my thoughts :) - Wayne

Link to comment

Just so I understand, let's do a quick recap.

  • Some PQs that haven't been altered in a while are going to be deselected so they no longer run automatically (unless the member reselects them). The purpose of this change is to stop unused PQs from running so the rest of us get ours quicker (or at all).
  • A week before the change went into effect, a notification message was sent in the email which delivered the affected PQ.
  • Since this change does not affect everyone, there would be no point to send a broadcast email to everyone.
  • Since many people deselct the option to get a million emails from Groundspeak, the broadcast email approach would fail to reach many of it's intended targets.

I don't understand what makes this issue whine-worthy.

Link to comment
The purpose of this change is to stop unused PQs from running so the rest of us get ours quicker (or at all).

Huh...

 

I've not had the first bit of trouble in getting PQ's since that last burp. Most have been fairly early, too. If you need to move those up even earlier then start the process earlier.

 

Inferring that the change is due to Waymarking Pocket Queries is weird. I tried to follow the trail to that conclusion but got lost along the way.

Eh, if I had a PQ server just sitting there idle because I've "optimized" its workload, that's probably what I'd do--put it to work.

Link to comment
The purpose of this change is to stop unused PQs from running so the rest of us get ours quicker (or at all).
Huh...

 

I've not had the first bit of trouble in getting PQ's since that last burp. Most have been fairly early, too. If you need to move those up even earlier then start the process earlier.

If you are not having trouble, why did you post the following comment a few days ago?
... It seems all of a sudden the PQ have ground to a crawl. Yesterday's last PQ for us was 12:40:44 PM and the one I thought had run before 9 am hasn't even ran yet at all--that time for a run earlier in the week. Prior to that most have ran fairly early, some as early as before 1 am and most well before 4 am.

Regardless of whether the great and powerful CR has problems, we still see occasional posts by others who experience difficulty. Either way, the decision was made to take action and everyone affected was notified.

Link to comment

There are arguments to be made for however you do or do not use PQ's. The issue that TPTB are trying to address is valid. PQ's are sometimes slow etc. It is just that there may be a better way to fix the problems than a blanket unchecking of all PQ's.

 

Maybe some of you experts have ideas. I suggested the following, but of course I have no idea if any of my ideas could be programmed.

 

"Instead of unchecking the day of the week based on the last time a PQ was edited, can TPTB make it dependent upon your last visit to the website? If an account has not logged into the website for a month, then uncheck their PQ's. If that is too hard to program, how about a separate email warning us that the PQ's will be unchecked in, say 48 hours. A link in the email could take us to a spot on the website to check a box indicating that we are using and want to keep receiving the PQ's. There may be other solutions that are also better than forcing a once a month purge and editing of all recurring PQ's."

Edited by Cheminer Will
Link to comment
There are arguments to be made for however you do or do not use PQ's. The issue that TPTB are trying to address is valid. PQ's are sometimes slow etc. It is just that there may be a better way to fix the problems than a blanket unchecking of all PQ's.

I think that this is what they tried to do. Everyone's PQs are not affected by this plan. Only those that haven't been edited in the last month. By chance, I made an edit to mine last week, so mine are safe.

Link to comment

There are arguments to be made for however you do or do not use PQ's. The issue that TPTB are trying to address is valid. PQ's are sometimes slow etc. It is just that there may be a better way to fix the problems than a blanket unchecking of all PQ's.

 

Maybe some of you experts have ideas. I suggested the following, but of course I have no idea if any of my ideas could be programmed.

 

"Instead of unchecking the day of the week based on the last time a PQ was edited, can TPTB make it dependent upon your last visit to the website? "

 

This was one of the first ideas. It turns out that the login date has no real correlation to whether the pocket queries are being used or not.

 

If that is too hard to program, how about a separate email warning us that the PQ's will be unchecked in, say 48 hours.

 

Seems like a lot of nagging. I'd prefer changing the pocket query generator page so the list shows the age of your pocket query. If it is too old it will let you know there.

 

We'll implement this when we add sorting to the page and the priority bump feature - which moves your query to the top of the queue for the day.

Link to comment

 

Seems like a lot of nagging. I'd prefer changing the pocket query generator page so the list shows the age of your pocket query. If it is too old it will let you know there.

 

We'll implement this when we add sorting to the page and the priority bump feature - which moves your query to the top of the queue for the day.

 

I guess I agree with the nagging part.

 

If you do it by showing the age of the PQ's on the generator page, could you also include a button on each PQ line that we can just click to refresh each PQ as it approaches the time limit? That would make it easy to check every couple of weeks, and refresh the PQ's we want to keep coming.

 

Thanks!

Edited by Cheminer Will
Link to comment

 

Seems like a lot of nagging. I'd prefer changing the pocket query generator page so the list shows the age of your pocket query. If it is too old it will let you know there.

 

We'll implement this when we add sorting to the page and the priority bump feature - which moves your query to the top of the queue for the day.

 

If you do it by showing the age of the PQ's on the generator page, could you also include a button on each PQ line that we can just click to refresh each PQ as it approaches the time limit? That would make it easy to check every couple of weeks, and refresh the PQ's we want to keep coming.

 

 

That's exactly the idea. The other idea of the bump button is like one of those buttons you whack to change the street lights so you can cross. It *won't actually do anything but it'll make you feel better when you smack it.

 

*(actually it will do something. Your tax dollars at work)

Link to comment

It has been months since I have visited the forums, I see not much has changed.

 

I find it very wrong to just switch off the running of my PQ. It does not matter if I am using it or not I should not have to come back to say I want to keep getting it.

 

I have paid a subscription. Let's say I pay to get the paper delivered to my house everyday. It is of no concern to the newspaper if I am reading it or not. And I don't have to keep going back to the newspaper to tell them that I wish to continue to get the paper delivered, other than I need to keep paying my bill.

 

Maybe I throw the paper away everyday without looking at it. But from time to time perhaps I do want to update my knowledgebase on current events. That is my business. I have paid for it I get to use it or not use it how I see fit. If the newpaper can't deliver my paper in a timely manner it is their problem to fix. Get more newspaper boys, get faster presses, stop taking subscriptions to get to the level of what they are able to deliver. But they don't get to slip an article in the sports section that says I have to call the office to tell them I want to continue to get my paper delivered while at the same time they keep sending me a bill.

Edited by GrizzlyJohn
Link to comment

It has been months since I have visited the forums, I see not much has changed.

 

I find it very wrong to just switch off the running of my PQ. It does not matter if I am using it or not I should not have to come back to say I want to keep getting it.

 

I have paid a subscription. Let's say I pay to get the paper delivered to my house everyday. It is of no concern to the newspaper if I am reading it or not. And I don't have to keep going back to the newspaper to tell them that I wish to continue to get the paper delivered, other than I need to keep paying my bill.

 

Maybe I throw the paper away everyday without looking at it. But from time to time perhaps I do want to update my knowledgebase on current events. That is my business. I have paid for it I get to use it or not use it how I see fit. If the newpaper can't deliver my paper in a timely manner it is their problem to fix. Get more newspaper boys, get faster presses, stop taking subscriptions to get to the level of what they are able to deliver. But they don't get to slip an article in the sports section that says I have to call the office to tell them I want to continue to get my paper delivered while at the same time they keep sending me a bill.

 

That is a very good analogy...but is anybody listening? Doubtful.

Link to comment

I think that it's time for a moratorium on all changes to the site other than maintenance.

 

It appears that TPTB have fallen victim to the siren song of motivational speakers and authors, most of whom exist only to sound good and collect checks.

 

I don't mind change but it looks like there isn't a plan. Figure out where you want to go and go there. The patchwork quilt method just is not working. PQs aren't working efficently? Make them work as they are formatted now. Who knows how they'll work after all these "change for change sake" changes are made.

 

I'll put up with it. I don't like it, but I'll put up with it.

Link to comment

The whole reason behind the PQ is to have them processed automatically. An XML file is not for displaying information, but for processing it.

 

Whether the email which contains the PQ is for human eyes or not read at all is another issue all together.

Allmost nobody I speak about this is reading the PQ email.

The program I use gets them from the email account, and process them. Because of mailbox limitations, I delete the PQ email after processing it.

However, since there are some people out there that read those emails, keep the expiry text in the email.

 

Displaying the age of the PQ in the PQ page is a step in the right direction, however I for one almost never come to the PQ pages, other than (in my case) GSAK notifies me that a PQ has more than 500 items in it. Then I go to the PQ page and change my PQs accordingly.

 

I would strongly suggest to put the expiry date of the PQ into the XML files. That way you can have the programs which process those PQs handle the expiration of the PQ and can generated messages, reports etc.

Link to comment

"Instead of unchecking the day of the week based on the last time a PQ was edited, can TPTB make it dependent upon your last visit to the website? "

 

This was one of the first ideas. It turns out that the login date has no real correlation to whether the pocket queries are being used or not.

Maybe not, but neither does the fact that I haven't edited my PQ in a month mean that I am NOT using it. I'd say the first proposition is much more realistic than the second.

 

I realize we don't pay much for PQs, but we do pay for them. I'd pay more, probably quite a bit more, but I don't expect to have to keep asking for something I'm automatically being charged for every month.

Link to comment

I would strongly suggest to put the expiry date of the PQ into the XML files. That way you can have the programs which process those PQs handle the expiration of the PQ and can generated messages, reports etc.

Also, the LongID of the PQ should be in the XML file to make the process fully automatic. Edited by team_wolfje
Link to comment

How about a countdown next to the PQ name then?

 

Days remaining or active till date.

PQ's are made for automatic processing. The filename is not the place for storing this information.

An XML tag should be the correct place for it:

 

Header PQ:

  <name>New Caches</name>
 <desc>Geocache file generated by Groundspeak</desc>
 <author>Groundspeak</author>
 <email>contact@Groundspeak.com</email>
 <time>2006-09-27T03:57:05.7800628-07:00</time>
 <keywords>cache, geocache, Groundspeak</keywords>

Should be expanded with:

  <expires>2006-10-14T00:00:00.7800628-07:00</expires>
 <id>fd9bba82-63d2-4a07-a1da-e55375037992</id>

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...