Jump to content

Decrypting Hints. . .


BigWhiteTruck

Recommended Posts

I am just wondering why we are doing a full page refresh to decrypt hints when it would be very easy to just have the hint swapped with javascript. I think having the decrypt button be a link to the unencrypted version of the page is a bit silly, very 1990's, not to mention that it puts undue stress on the servers. Also, clicking on the link, waiting for the page to reload and then scrolling back down to the hint is very annoying.

Anyway, I think this simple change would really make a difference in server load and also make the user's experience better

 

I hope I don't sound too critical, I tend to just lay things out there.

Link to comment

This was suggested long ago. I remember even writing a prototype of it to show how it could work. It's not hard to implement and I do agree it'd give both a better user experience and a lighter load as there'd be fewer pages to deliver.

 

[ edit ]

Aha. What I can't find with a forum search, I can find on my own system. http://www.mtgc.org/tmp/xxx/xxx.html was the prototype I did.

 

The code is, uuuh, underambitious (I'd totally do it just by putting it in a div and modifying the DOM now that I'm older and wiser) but it shows it's not hard to do.

Edited by robertlipe
Link to comment

I think the reason why it hasn't been changed is that the site was supposed to work on all flavors of mediums.. so javascript was shy'd away from. one day maybe we'll put some browser detection in and fix it.. or just put it decoded below using white font and just select it to see :laughing:

Link to comment

Thanks Raine. The use of JavaScript has been limited for this reason. In this "new" world of AJAX it seems that JavaScript is becoming more acceptable, but adding features that break current features makes me hesitate from implementing them.

 

Since the pages are temporarily stored in memory the added click to decrypt the text isn't a huge hit on the machine anyway.

Link to comment

Javascript was a big nono "back in the old days" but those days have passed. The current site itself depends on Javascript. Disable javascript and then try to step through the pages of a 'nearest caches' or the pages of a PQ to convince yourself that's true.

 

Printing just renders the page. Try printing my example above either encrypted or decrypted. The img links are hosed, but that's because I was lazy when I hijacked it and didn't rebase all the site-relative links when I rehosted it. My example (which I'm offering as a proof of concept and certainly not an implementation poster child) would need to walk the argument list and set the value of the toggle based on the incoming URL for those that have build external links but that's not hard, either.

 

I don't care much either way. I prefer pulling the pages in a PQ and manipulating locally as it's crazy fast. But I think the printing thing and the javascript acceptance thing are both non-issues. If it's a technical problem and you want help solving it, let me know.

 

Also, Jeremy, it might not be a hit on the database, but your network statck and hosting service still has to deliver the page again.

Link to comment
Javascript was a big nono "back in the old days" but those days have passed. The current site itself depends on Javascript. Disable javascript and then try to step through the pages of a 'nearest caches' or the pages of a PQ to convince yourself that's true.

 

Printing just renders the page. Try printing my example above either encrypted or decrypted. The img links are hosed, but that's because I was lazy when I hijacked it and didn't rebase all the site-relative links when I rehosted it. My example (which I'm offering as a proof of concept and certainly not an implementation poster child) would need to walk the argument list and set the value of the toggle based on the incoming URL for those that have build external links but that's not hard, either.

 

I don't care much either way. I prefer pulling the pages in a PQ and manipulating locally as it's crazy fast. But I think the printing thing and the javascript acceptance thing are both non-issues. If it's a technical problem and you want help solving it, let me know.

 

Also, Jeremy, it might not be a hit on the database, but your network statck and hosting service still has to deliver the page again.

For those of us that regularly look at the site from our PPC I thank you. Java-stuff makes the IPAQ throw up and its messy to clean all thoses pixels off the floor.

Link to comment
Javascript was a big nono "back in the old days" but those days have passed. The current site itself depends on Javascript. Disable javascript and then try to step through the pages of a 'nearest caches' or the pages of a PQ to convince yourself that's true.

I'm definitely aware of the nearest cache page but you can still go through the first page which would be enough for just an average geocacher.

 

I don't object to doing it. I'm just offering some reasoning behind us not implementing it earlier. There are plenty of javascript Rot13 decryption scripts to choose from.

 

The way to do this is to allow it to work regardless of whether javascript was enabled. One such way would be to provide the link and an onclick event. I think that would work.

 

(I agree with some folks about decrypting it at the cache site. The reality is most people print it before they head out)

Link to comment
(I agree with some folks about decrypting it at the cache site. The reality is most people print it before they head out)

I find that puzzle cache hints are the only ones I end up decrypting on the site (for obvious reasons). The rest are in Cachemate and can be decrypted at the touch of a button when I need them at the GZ.

Link to comment
Javascript was a big nono "back in the old days" but those days have passed.

 

For who?

 

Disable javascript and then try to step through the pages of a 'nearest caches' or the pages of a PQ to convince yourself that's true.

 

Yes, that was a really lousy change and continues to be a real pain in the you know what...

 

To get to the second page:

 

1. Cycle through and close all other browser windows (I usually have 3-4 open)

2. Enable JS

3. Wait for page to reload

4. Wait for javascript to load (negligable here)

5. Click link

6. Wait for new page to load

7. Wait for it's script to load

8. Don't forget to disable script before calling up other sites!!

 

Needless to say, I don't go to other pages often, it became too slow/painful...

 

Enjoy,

 

Randy

Link to comment

I'm prepping for a trip, so I can't prototype this, but you can have the best of both worlds. You definitely have the right idea, Jeremy. I think the syntax is something like:

 

<A HREF="thispage.html&decrypt=y" onClick="decryptthingy();return false">Decrypt</A>

 

If you have javascript enabled, you get the newfangled stuff. Let the JS walk the DOM for the hints div, rot13 it, and write it back. If you don't, you get the linky link and the page reload just like you always did.

Link to comment

I would say: keep it simple. The issues presented by the OP are not compelling and to me dosn't seem o improve anything. A full page reload is not a relevant issue because virtually all the data are cached on the local PC. The amount of data transferred is the same with a script or without (is there anyone that does not have a browser cache working?). The browser still has to redraw the page if a script messes with the text. The fact that the OP suggests that scrolling down to the hint is a bother can be overcome with html bookmarks in the html code.

Link to comment

Ummm... It's a different page so it isn't cached. All of the images are (should) be cached, but the text is different.

 

Additionally, if I'm understanding the mechanism correctly a proper DIV switch via JS will not re-render the page, only change what needs changing. That's the beauty.

Link to comment
I thought that RJFerret would be lurking around somewhere

 

Hahaha!!!

 

OK, cool, just 'cause I keep my mouth shut from now on though doesn't mean the legacy users I represent are no longer here... (Or I'm any less interested in "giving back"/contributing...)

 

I love site improvements (in one of the best designed websites around) and am delighted with the level of care taken consistently.

 

(Nevermind with a great sense of humor!)

 

Sincerely Jeremy et. al., thank you,

 

Randy

 

PS: You don't know, especially now that snow has returned, how much I appreciate cache attributes--probably every third hunt!

Link to comment
I'm prepping for a trip, so I can't prototype this, but you can have the best of both worlds. You definitely have the right idea, Jeremy. I think the syntax is something like:

 

<A HREF="thispage.html&decrypt=y" onClick="decryptthingy();return false">Decrypt</A>

 

If you have javascript enabled, you get the newfangled stuff. Let the JS walk the DOM for the hints div, rot13 it, and write it back. If you don't, you get the linky link and the page reload just like you always did.

Exactly what I was thinking. It would work fine for those of us who have javascript enabled, and would work the same as before for those of us who have disabled javascript (for who-knows what reason).

 

Git-r-done, Jeremy!

Link to comment

Ummm...

 

Forgive me for asking, as I know very little HTML and stuff like that but here goes.

 

Why can't you add a new button thingy that when clicked it will open a new mini window that only contains the hint decripted?

 

I know that some kind of 'shell' must be used for the Cache pages since they all have the new PDF feature.

 

Disregard if this is not even close to realistic.

 

:P The Blue Quasar

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