Jump to content

paleolith

+Premium Members
  • Posts

    952
  • Joined

  • Last visited

Everything posted by paleolith

  1. m = meters mi = miles 3GDs was talking about cachers making multiple trips to find a group of caches which are 1/10 mile (161 meters) from each other. Edward
  2. The world moves on, without my consent or permission, or yours. As long as you are happy inside a sealed room, not communicating with anyone or anything outside, you can keep on running what software you want ... until the hardware breaks. But if you want anything from outside, you have to move on to continue communicating. There's a lot of it I don't like either. As others have pointed out, the latest Firefox still runs on old OSs. But as for the OS, I might tolerate Win7, but I've looked at Win8 and read about Win10, and I'm thinking my next OS might be Linux ... or some combination of OSs using VMware. I don't like the choices, but the world is moving on. Edward
  3. Ye gods. That is a good argument for a permanent moratorium. A total perversion of challenges. GS acted slowly, gently, appropriately. If I wanted to fault them at this point, it would be for not stopping such idiocy sooner. Thank you, GS, for stopping it now. Edward
  4. No, not in any way. And I have not gotten the impression that any reviewer requires more. I wrote more in the case I cited, but then I almost always write more than most. (I have dropped to #39 in Found It log length, but that's because there are more cachers writing long logs -- despite the complaints seen here about one-word logs, the ranks of those writing long logs remains robust.) Yes, I think you're right about that too. Archiving one's own cache is not a happy thing. Asking for someone else's to be archived isn't happy either. I've done both, and didn't like it. I don't imagine that any reviewer likes doing it either. Edward
  5. I fear struldbrug caches, so I basically support reviewer action. I do think reviewers should take equally strong action to keep caches going when viable. I do not think lack of CO response should be sufficient to archive a cache if it's otherwise viable. In particular, when other caches visit the cache and proclaim it in good shape (whether by examination only, or by maintenance), that should be accepted. That has not been an issue in the caches cited in this thread, but I have see it in other cases, which I cannot cite at the moment. My point is that based on current guidelines, CO should only be absolutely required when the cache needs the response. And I'll add that I've seen reviewers go out of their way to help. I'm watching a cache now that needs to be replaced. The CO is still around though not caching. He should have replaced the cache months ago. The reviewer is letting it string along because the cache is an Old One and the CO has generally been a good participant. One of my caches had to be disabled because of construction in the park. The reviewer allowed me to string it along for two and a half years, posting monthly reports on the progress. Eventually he asked me to archive it. And as it turned out, the renovated park is so neatly groomed and popular that I decided I could not place a Traditional, and recently published instead a multi with no physical presence in the park. Still, do I detect a hint of Make Fun of the Handicapped Week? Do we discriminate against those who dislike reading and writing, perhaps because they don't do those things well? By definition, those posting here enjoy reading and writing. Should we so discriminate, since owning a cache does require communication skills? That's a difficult one. But if we are going to require COs to communicate well, perhaps the publication process needs to be adjusted so that the CO has to show more communication capability prior to publication. More subtly, many people just don't like talking back. A reviewer's note can be totally conciliatory, can explain all the ways the CO can handle the situation, and some people will just react (at a gut level, not intellectually) that it's a power situation and will just back away. I don't know if anything can be done about that without excluding many people from the hiding side of the game. Edward
  6. I just noticed that my profile photo is missing. I didn't delete it. Anyone else have the same problem? Any idea why? I can re-upload it of course, but it's weird that it's missing. Edward
  7. Yeah, I hardly recognize it. I hardly recognize geocaching on it. In fact, I don't recognize geocaching on it at all. "Watch this video to find out what geocaching is." (Apparently the gc.com staff has forgotten how to write. Or thinks nobody reads. Even though there's a lot of guidelines you need to read. Or are all the guidelines being converted to video?) "Download this app to find out what geocaching is." "There are 247 geocaches within 5 miles of where you aren't." "Sign and date the log book. Don't bother writing anything about your experience, either there or in your unmentioned online log." This sort of misdirection -- direction by fashion -- is the reason all the caches I own are now PMO. The one good thing is that apparently the "create your free account" form requires an email address. Whether the email address is verified before account creation, I did not test. Edward
  8. Well, that would have delayed the publication of both of my challenge caches by over a year. Several other cachers completed each of them before I did, with much appreciation. The second was being requested by other cachers even before I published it. Both are still popular over five years after publication, and another challenge cache in the same area -- somewhat modeled after mine -- is also popular. I just see any point in requiring the CO to attain the challenge pre-publication. Sure, it's important that the CO has done the research to make sure it's an attainable challenge. And like any cache, the CO *should* make sure it's an interesting cache, though we all know that doesn't always happen. But attain in advance? No point. Edward
  9. For the past half hour or more, online API access has been throwing errors, claiming invalid request. Multiple GSAK users are reporting this. Edward
  10. Technically true, but I find that in practice, if I email a user who has a verified email address and has been active recently, I usually get a reply. If they haven't been active in, say, the past year, a reply is much less likely. If they don't have a verified email address ... well, who knows? Perhaps those same people would have used a throwaway address or stopped reading email immediately, but if verification isn't required, we'll never know. I agree with those who say it does not have to be email in the strict sense, RFC822 and all that. It just has to be a way to contact the person online. However, I'd say it needs to be more permanent than a free intro app which might get deleted tomorrow. We already see lots of problems because people change email addresses, but at least most people tend to keep email addresses for some time. Edward
  11. I have to disagree on a couple of points. First, having found thousands of caches does not automatically translate into seeing things as a customer does. Being an insider changes the perspective enormously. And finding thousands of caches makes someone very different from the average cacher, who generally has found tens or hundreds (my impression, since AFAIK no stats are public). Second, people vary enormously in their needs and preferences. This is obvious in everyday life, and it's just as true online. Meeting the needs of users requires providing options and flexibility. This is a difficult trade-off, since options also create complexity. It's clear to me that people who actually use the system did approve "those changes", and there are probably many users who think the changes are just fine and so haven't come here to complain. So the problem is not that experts weren't consulted. It's that too small a sample of users was consulted. Edward
  12. This article just published by the Nielsen Norman Group, the pre-eminent user experience (UX) experts: UX Without User Research Is Not UX Summary: UX teams are responsible for creating desirable experiences for users. Yet many organizations fail to include users in the development process. Without customer input, organizations risk creating interfaces that fail. Edward
  13. I just noticed this and was going to post it, but you beat me to it. I can however expand. Sometimes small fish can learn from big fish. Jakob Nielsen often points out that Amazon leads the way in user-friendly interfaces, even though not all of what they do would work for smaller fish. Old eBay subject: New items that match: dutrieux/dutrieu New eBay subject: 1 NEW (dutrieux, dutrieu) 1) The old subject was much longer due to the superfluous words "items that match", and those superfluous words came before the identification of the search, making the emails harder to scan by eye. 2) The new subject contains the count of items found, a very useful bit of information. 3) The change in the search ID is subtle in this case. The old search ID "dutrieux/dutrieu" was a name I entered -- very similar to the actual search terms (which are "dutrieux OR dutrieu"). This required that I enter a meaningful name even though it was generally duplicate information, and I'm sure this confused a lot of people. eBay probably got a lot of complaints that users had trouble identifying the search emails. The new search ID "(dutrieux, dutrieu)" is simply the search terms (comma meaning OR and parens for grouping). As we all know, Groundspeak reverted the subject line changes. However, some of the discussion here has been on the possibility of improving the subject lines. I think most of us would be willing to change our filters and other methods for a real improvement. But making a real improvement requires a lot of hard design work and usability testing, not someone sitting down and saying "oh snap, I think I'd like this". I've been in IT (formerly DP, same thing, new name) for 45 years, and one thing I learned very early is that the way I like things isn't always (or even usually) the way other people like things. As a professional in the field, it's been my responsibility to provide for others, not for myself. On top of eBay's actually improving the subject lines, guess what -- eBay still offers the option of plain text or HTML email. I just now switched my preference from plain text to HTML so that I can evaluate the quality of the HTML notifications and will report back when I've seen one. For eBay, there's an obvious, very real advantage to HTML email in that it can display photos of items within the email so that users need not go to the eBay page to see the items. (This is mostly useless for my searches, but I still see the value.) Groundspeak has not come up with any added value for their HTML notifications: the information is identical to what would be in the plain text notification. Even the formatting is not significantly changed, except for the major reduction in text/background contrast that makes the emails much harder to read. (The cache owner ID, a useful addition, was added at the same time as the forced change to HTML notifications, but the owner ID is completely independent and could have been added to the old format notifications.) Edward
  14. I'm glad you appreciate our feedback. Unfortunately we at the other end see precious little evidence that GS as a whole appreciates it. The changes in email notifications were not even posted to the User Insights forum that GS set up just a few months ago for exactly this purpose. Does no one at GS understand how heavily the notification emails are used? Surely you know how many are sent. As I posted at great length yesterday in the thread on last week's release, for most of us HTML isn't really the issue. "HTML" has become a label for multiple problems with the new emails: wretched formatting, excessive size, and missing information. (Originally "HTML" was also a label for the mangled subject lines, but that got fixed.) If GS won't offer an option for plain text emails, what solution does GS propose for the problems which have been discussed here at such length? Does GS really not care hard difficult it is for us to read the emails? Edward
  15. I love the HTML emails. With HTML, it's possible to expand BBcode used in log text so that I can actually read logs from people who use lots of BBcode, which tend to be the most interesting logs. And it's great that Groundspeak recently set up a User Insights forum, so that they were able to gather users' ideas prior to implementation. Oh wait ... GS didn't use the User Insights forum. And they aren't expanding the BBcode. Well, that's awfully strange, since that was really the only possible argument at all for using HTML! And weighed against that missing improvement, we have these major degradations: Poor contrast of text vs background! Pastel on pastel is hard to read. That may be difficult for many of the 20-somethings on the design team to recognize, but a lot of cachers are retirement age. Eyes do develop deficits over the years. (I've had five eye surgeries in the past year and a half, and I feel lucky. Fifty years ago, the doctors would have said "you're going blind, deal with it".) Note to design team: Read Jakob Nielsen on usability! Very closely related, the code forces the use of Helvetica or Arial if they are available on the system. Though common, these are poor choices for reading on screen. I choose Verdana, which was specifically designed for legibility on screen. It's very rude of GS to override my choice, especially when they overrode my choice with a less legible one. Awful HTML. It uses table-based formatting, which screams 1998. Modern? No, not with this crufty trash in the HTML code. Excessive formatting. Coders gone wild. People would be complaining far less if the HTML were only used to provide necessary formatting. Instead, the design team has fallen into the common trap of using formatting capabilities just because they can. Wasted characters. The HTML in a typical message contains almost 3000 spaces at the beginning of lines, which is of no use except to those who read the HTML code that underlies the messages. (How many, even of the complainers, have done that?) Total typical message size (excluding headers) has increased from about 600 bytes to about 10,200 bytes. Of this increase, about 3,000 bytes is the line-leading spaces mentioned above, and about 5,500 is HTML tags, most of which are unneeded. Some tags are needed just to use HTML, but I'd guess that a nicely formatted HTML message needs at most 2,000 bytes. To make it worse, I cannot override the choices. When I'm viewing cache pages in a web browser, I can set up my own style sheet to adapt to gc.com's poor choices. That possibility is not available to me when I'm reading email. I'm glad to see that the subject lines have mostly been fixed. And a couple of issues brought up are not valid complaints about the recent changes: Images in the messages: the actual images are not included in the messages, only the links. Those with data-limited accounts may still have a valid complaint, since the images will be downloaded when they view the message -- but the image will probably be cached and only downloaded once. At any rate, the mail storage is not being bloated with multiple copies of the images. Base64 bloating: GS has been base64-encoding emails for a long time, even with plain text messages. There was actually a point to it with plain text, because plain text email does not handle most characters not used in English, even simple accented characters, and base64 is part of the solution to this problem. But this is not necessary in HTML, which has a much defter method of handling this and does not need the blunt club of base64. GS is to blame for leaving the base64 in place for HTML emails, but this is a sin of omission, not a sin of commission. Finally, I wish GS would standardize on a single subject line tag, perhaps [GC]. This would simplify my filters, since I would not have to juggle [GEO] and [LOG]. But as others have pointed out, omitting the tags would make my caching life much harder. Edward
  16. As a pretty serious hiker, I'd rate it 2.0 -- 1.5 for the short rail-trail and add a half for the ditch. But if this rail-trail mostly attracts urban walkers out for a stroll and 5mph bicyclists, I'd consider bumping it by a half or even one. Terrain ratings are relative to the audience. Edward
  17. I hope GC fixes this, but I decided not to wait any longer. Though I'm not aware of any case where I've been unable to contact someone, I've seen a number of logs on my caches where the user is "not validated", and that bothers me. Most of my caches are now PMO. I'm saddened that I felt I had to take this step. When I first signed up, before I paid, I was offended at what I perceived as an attitude of "you can't see this even though you are a member". Partly my issue was that "always free" was a big talking point. (Haven't looked to see if it's still there.) If someone wanted, they could dredge up my posts on the matter. In most cases, I don't care if someone has paid. I don't really care if they've validated an email address. But I want to be able to contact them, however that's done. Edward
  18. So how long do we have to wait for the permanent band-aid? I'm surprised there hasn't been more outcry about this. I just searched for a cache I'd visited recently and had trouble finding it because I forgot the name had "The" at the beginning. I've been programming since 1967, and I totally understand the performance issue of doing a full string search on all titles. However, I also understand database indexing, in particular what used to be called an "inverted file". A true keyword search would mean "find names which contain words that start with all of the keywords in the search". Although this sounds more complex, it's easy to do with indexing, and the site performance would be excellent. Databases did this very well forty years ago with less processing power than my wristwatch has today. Please raise the priority of this. Removing capabilities that we (premium members!) used is very unfriendly. Edward
  19. While this is true, many of the cachers with consistently long logs do write interesting stories with no multi-paste (or use of GSAK insertion features etc). I am currently #38 for log length on mygeocachingprofile.com. In the past (though not recently), I've looked at some of those with longer average logs than mine, wondering if they were "cheating" with multi-paste etc. I did not find any such. The cachers with the longest average logs were really writing them, no shortcuts, and generally interesting logs. Edward
  20. I'll give you a quick answer applicable to this situation, but note that when you publish the cache, you will have to mark a checkbox saying you've read the guidelines. So, you might as well go ahead and read them now. I have a cache where, after several finders took a short bushwhack instead of the longer, easy walk, I decided to try to "force the route" as you put it. It was already a mystery cache, albeit at the published coordinates (a challenge cache). I moved the coordinates to an "entry point" to the easy walk and gave the heading to the cache but only a general idea of the distance. Nothing more is needed for this cache. It's seldom found, so I can't say how well this is working, but I'm pretty sure it will avoid the problem. You could do something similar by publishing the coordinates of the entry to the path and saying "walk up the path until you reach a bench". This could be done as a multi, mystery, or letterbox cache. (There are very few letterbox caches around, so this would be a welcome variation.) It's true, as others have said, that there are various ways people might try to shortcut it anyway. However, I think you will eliminate 90%-99% of the problems by doing it as a multi, either as I described or as others have described. Edward
  21. Excluding events, 73 of my 648 finds (since mid 2007) have been archived, 11%. Perhaps this fairly low percentage reflects the fact that I prefer backwoods hides, and among the non-backwoods ones is a well-maintained series of almost 50 caches. (It's definitely NOT a power trail.) Carrying this further, I wondered if high-terrain caches would have survived better, but I found that of my finds with terrain 3 or higher, 29 of 283, or 10%, have been archived, basically the same as for all my finds. Edward
  22. Five minutes? A person can do a lot of damage in five minutes. The limit should be five seconds. Better yet, if you can't see the cache or the SPOR from the car, just throw the new one from the window. Have a lot of them prepared. If you see a whole pile of film cans, just log the find. Ooh, still better: don't even bother stamping the log with your group stamp. Just hit the SPOR with a paint gun from the car window. Mix a little of your blood with the paint so that your find can be verified by DNA analysis. Edward
  23. Yeah, I think the other opinions have convinced me that the o-ring isn't worth pursuing. It was sort of an old idea still rattling around in my head that needed closure. Interesting idea about rubber bands. But also decons are now far more expensive than the Therapak containers linked in another thread. Edward
×
×
  • Create New...