Please have a look at the main page of my site here:
Note the bothersome message that appears in red. Our legal advisor wanted that message placed on our website to bring more attention to our patent in light of the fact that some of our competitors in Japan are infringing upon it. The main problem is that red box appears each and every time you visit the main page, even if you’ve already visited before.
What I want to do is show that obtrusive message only ONCE, the first time someone visits. Then if they browse the site and return to the top page multiple times, that message won’t show multiple times.
My guess is this could be accomplished with a Cookie. I’ve read through the following thread, but honestly, it’s a bit beyond me:
Sorry this isn’t an answer - but I’d be really interested in this too, as I need to show a message just once on the home page which the user can click to clear. Ironically, it’s a ‘cookie’ warning
I think the solution in my case would be very tricky because I don’t see how any solution would work unless it either hacked the Action I am using or replace the functionality of the Action.
I’m a creative designer more than I am a coder. I know how to copy code and then paste it in the right place only when an experienced coder tells me where to paste it!
More specifically, how does one use the knowledge given on that web page you linked for me, such that the Timed Spawn New Window Action I am using is altered appropriately and then displays the content ONLY THE FIRST TIME a visitor comes to the web page?
That’s what this thread is about. I want to cough up content ONLY THE FIRST TIME someone visits the top page of my site. I don’t want to keep blasting them with the same message over and over because that pisses people off.
I’m also rather surprised no one else has had this need before. Perhaps they have, but I just didn’t search this site well enough.
In any case, I look forward to some coder hand-holding!
Okay, maybe it would stimulate some replies if I also mention that I am a little flexible on this. A cookie solution would seem to be ideal, but if that’s impossible, how about displaying my Timed Spawn New Window content “once per browsing session”?
The main reason I am so desperate to find a solution is because the content I am spawning on our top page keeps hitting you in the face every single time you reload the page or come back to it. It’s just too much.
Any hand-holding style help to find a solution quickly would be greatly appreciated.
You would need to use something besides TSNW for this, as I can’t see a way to hook the event handler that the Action makes and force it to look into the cookie to see if you’ve already shown it to the visitor.
So remove all the Actions, apply Protaculous to the page and choose prototype-packed from the Library picker, if it isn’t there already.
Use the External JavaScript Action to attach the cookiejar.js file to the page in the After Head section. Be sure to add the Actions to your page in this order, otherwise cookiejar will be loaded before Prototype, and neither will work correctly. Download here: https://gist.github.com/3795796
Note the value in the Title field of the Inspector while you have your message box selected in the design view. Replace item42 in the script below with the value of that attribute (case-sensitive!). Paste the modified code into the top Function Body dialog in Protaculous. The message box will appear when the page loads, and will disappear when you click on it, never to return during the current browser session. If you want to change the duration of the cookie, you can do so where indicated in the script. Setting the duration to nothing makes it last as long as the session.
Walter
On Sep 27, 2012, at 2:08 AM, JDW wrote:
Okay, maybe it would stimulate some replies if I also mention that I am a little flexible on this. A cookie solution would seem to be ideal, but if that’s impossible, how about displaying my Timed Spawn New Window content “once per browsing session”?
The main reason I am so desperate to find a solution is because the content I am spawning on our top page keeps hitting you in the face every single time you reload the page or come back to it. It’s just too much.
Any hand-holding style help to find a solution quickly would be greatly appreciated.
I don’t know much about cookies. But why not keep the home page as is with the legal (index.html) then use a duplicate “home” page without the legal (home.html). Once you enter the site or return to the site, you get the legal home page and once you go to other pages on the site the “home” button links to the page without the legal popup. This would work, unless you use the back button on the visitors browser.
Kim, your method actually involves more work because a lot of links will need to be relinked. I will resort to it only if I cannot get Walter’s solution to work as I desire.
Walter, thank you for the excellent advice. I’m getting your solution to work fine in FireFox and Safari on the Mac. I even confirmed that when I click the HTML item it remains hidden, and then it comes back again when I quit and relaunch my browser. That’s great. But it won’t hide in Chrome, almost as if the cookie is being ignored in Chrome for some reason. Each time I click the HTML box to hide it and then reload my page in Chrome, it reloads the HTML box. Chrome prefs are set to the defaults to accept Cookies, and I am running the latest version of Chrome on the latest version of OS X. I also don’t have cookie woes in Chrome with other sites. Chrome is my main browser. Thoughts?
Second Problem…
Although “it works,” it is a far cry from the look-and-feel Timed Spawn New Window gave me. There is no half-transparent white backdrop covering the entire contents of the browser window, resting behind my HTML box. And gone is the drop shadow behind my HTML box too. I could use a partially transparent White PNG to simulate the white backdrop I suppose, but I’d rather not use a PNG. What is the Action using to work its magic, and how do I go about simulating that magic in way that will play well with the Protaculous code?
Did you try the Chrome problem on a live server? I think this may be related to it running from a file:/// URL if you are doing that. I get the same problem here.
As for the look of the overlay, you can make that if you like. This solution does not encompass the overlay layout that SNW makes for you, it just allows you to set something to be shown once and dismissed by the user. To make an overlay, you’ll need to make a layer that has the following attributes:
position: fixed in window
top: 0
left: 0
width: 100%
height: 100%
Give that element a graphic background set to 40% opacity white, and then insert your message element inline within it and use margin on the inline element (never try to use padding on the overlay) to center it.
Walter
On Sep 27, 2012, at 10:55 PM, JDW wrote:
Walter, since a picture is worth a thousand words, here are 3000 words:
Thank you for the help, Walter. I was able to get it to work with 80% opacity (which matches the opacity level of the semi-transparent white background of TSNW).
The main bother with this scheme versus the use of an Action is that you have a huge page-sized object covering up the entire page in Freeway. So what I did was make the Pasteboard huge, apply the Layer Positioning Action to my page-sized box, and then I threw that box into the PasteBoard, freeing me to tweak my page design without intrusion.
Oh, and you were right about Chrome. Once I uploaded it to the server, it displayed once in Chrome and then it doesn’t come back again (in the same session).
Just one tiny “display glitch” caveat, for those of you reading this thread and following in my footsteps. When I tested in IE7 on a slow WindowsXP box, and then also when I tested in IE9 running on Win7 in Virtual Box, I noticed that my red inline box appears briefly each time I reload the page, then vanishes. It says on all of 0.2s, so it’s hard to see, but it is noticeable nonetheless. I’ve not noticed that when testing on my 3GHz iMac in Mac browsers, perhaps because of the sheer page loading speed.
Some other minor gripes, relative to my old TSNW Action implementation are:
The semi-transparent background overlay fills the height and width of my page, but it doesn’t fill the entire browser window.
There is no drop shadow behind the main content box in the middle.
Most often, the main content box in the middle will appear first, followed by the white background overlay.
I had to add a line of text (show in Japanese at bottom right inside my red content box) to inform the user how to clear off that content and get to the main page. In the case of the TSNW Action, there was a more intuitive Closebox in the upper left of the content box.
But the improvement made by the cookie is so great I can live with the minor annoyances.
What’ you’re seeing here (the flash of content before the JavaScript kicks in) is directly related to the amount of content on your page – and its overall file size. Here’s another way of handling this effect which should help you get where you want to go. I’ll comment more on it inline below.
On Sep 28, 2012, at 2:20 AM, JDW wrote:
Just one tiny “display glitch” caveat, for those of you reading this thread and following in my footsteps. When I tested in IE7 on a slow WindowsXP box, and then also when I tested in IE9 running on Win7 in Virtual Box, I noticed that my red inline box appears briefly each time I reload the page, then vanishes. It says on all of 0.2s, so it’s hard to see, but it is noticeable nonetheless. I’ve not noticed that when testing on my 3GHz iMac in Mac browsers, perhaps because of the sheer page loading speed.
You got it in one. The effect doesn’t fire until the entire DOM is present in the browser’s memory. Larger pages take so long that the browser starts to paint the stuff it does know about, then fills in the rest as it arrives.
To use this new script, you will need to set the overlay to be initially hidden in a particular manner. Click once on the overlay box (off on your pasteboard) and use the Item / Extended dialog (DIV Style segment) to add the following name/value pair:
Name: display
Value: none
Now that overlay box will be hidden all the time, and shown by JavaScript when needed. This removes the timing sensitivity in older browsers.
Some other minor gripes, relative to my old TSNW Action implementation are:
The semi-transparent background overlay fills the height and width of my page, but it doesn’t fill the entire browser window.
First and second line of the new script fixes that. The overlay is removed from the PageDiv and inserted as the last element of the body of the page. It should vault over everything from that vantage point.
There is no drop shadow behind the main content box in the middle.
As I noted earlier, it is up to you to create your message box the way you want it to appear. I recommend the CSS3 Shadow Action, or you may use the built in graphic shadow effect in the Style tab of the Inspector.
Most often, the main content box in the middle will appear first, followed by the white background overlay.
This is due to the order in which these elements are read in by the server. If you wanted to force the overlay to appear before anything else, and you weren’t worried about showing it briefly to everyone all the time, you’d need to combine the two scripts I’ve posted. Use the structure of the first, don’t add the display:none to the overlay, and also move the overlay to the top of the page with this (modified) line from the second script:
That (along with the z-index line above it) would move the overlay to the top of the layer order, and allow it to be visible until the browser gets around to asking the cookie question.
I had to add a line of text (show in Japanese at bottom right inside my red content box) to inform the user how to clear off that content and get to the main page. In the case of the TSNW Action, there was a more intuitive Closebox in the upper left of the content box.
You could add a button to your message box yourself. It won’t matter if they click on it – or somewhere else on the page – the entire thing will close. So if you want to have that visual hint of how to get rid of it, just make a little graphic with an X in it, and apply an empty link to it (just link to #) so it will have the cursor change to indicate a link. I removed the link style from the overlay in this second version of the script.
But the improvement made by the cookie is so great I can live with the minor annoyances.
Walter I am at the office now, toying with all of the excellent advice you so kindly provided in your last post. I must say, I now am even more impressed!
I only have one last question. Earlier in our discussion you wrote, “use margin on the inline element (never try to use padding on the overlay) to center it.” But now that I have the overlay filling the entire browser window (a good thing), there is no “safe” value for Margin that will perpetually Center the child box within the parent “Overlay” box. Therefore, my question is, is there an alternate way to center the child item such that it will perpetually center in the Overlay parent? (I must assume there is a way, seeing that the Timed Spawn New Window Action accomplishes that feat just fine.)
Thank you again, Walter. And I must say I am truly humbled by your sheer brilliance at web design!
Walter, I’ve been trying to solve the “centering” problem on my own. After experimenting, I’ve got some Good News and some Bad News.
The Good News - centering
I set Margin to “Auto.” And I then clicked my text cursor inside the Parent Overlay box, Selected All, and then chose “Center” in the “Character and Paragraph Settings” tab of the Inspector. Not sure if that’s the best way to do it, but it seems to keep it Horizontally Centered in the browsers I’ve tried. I then added a few carriage returns above the item to keep it reasonably centered vertically (to my satisfaction anyway).
The Bad News - After page RELOAD, Overlay appears again & won’t close
I went to Protaculous and completely replaced your first script with your second. I then changed your “item42” to the name of my Parent box. I then set the Extended attributes of the Parent box, exactly as you directed. The Parent item now fills the browser window (sort of, the height is only the page height, not the browser window height). But the main problem is that when you click RELOAD in the browser, the Overlay appears again. Even more troubling is that the user then can never click-to-close anymore after that. I confirmed this in all Mac & Windows browsers, except Chrome.
Being too impatient a man to wait for answers, I continue to fiddle. By combining parts of your old script with your new, I found one that works, albeit without the feature of the new code that keeps the content from flashing on and off. Here it is:
var message_box = $('legaleze').setStyle('z-index: 1000');
$$('body').first().insert(message_box.remove());
var jar = new CookieJar({expires: ''});
//you can also set expires to any number of seconds
if(!!jar.get('hide_message')){
$(message_box).hide();
}else{
jar.put('hide_message',true);
$(message_box).observe(
'click',
function(evt){
this.hide();
}
).setStyle('cursor:pointer');
};
I’ve uploaded it to my server here:
(If it’s not visible, relaunch your browser to clear the cookie.)
As you can see, there is a lot of great things here, thanks to your help, Walter. I added a close button and drop shadow, and you can see it is horizontally centered too, and the semi-transparent overlay is now happily spanning the width of the browser window now.
The only two caveats are:
I don’t know what bug afflicts your new code, but I couldn’t fix it. Hence, the red box content still flickers on/off when you RELOAD the page.
The height of the Overlay is the Page Height, not the browser window height (except on IE7, where it is “the current browser window height”). So if you make the browser window taller than the page (or just a tad taller in IE7), then you will see a portion at the bottom that is not covered. If there is a way to specify the height to be 150% of the page height, that would solve the problem, because you’d be hard pressed to make the window height that much taller than my page.
But the result is exactly the same as what I reported before in IE7 – if you load the page and then make the browser window taller, the part you bring into view will not be covered by the Overlay.
Another issue is that my red box and the text inside it also becomes transparent. If I boost transparency to 90%, the text is readable, but I couldn’t figure out how to make the box inside the parent Overlay to be completely opaque. I added some CSS for that red box too, but it didn’t work. I guess that means the Opacity of the Overlay box overrides whatever transparency you separately set for child items inside it.
Try making it position: fixed instead. That will work in IE 8 and above, not sure there’s any help/hope for IE 7. Those people have to grow up one day, and even Microsoft’s site doesn’t support them any more.
Walter
On Oct 1, 2012, at 4:57 AM, JDW wrote:
I’m still experimenting with a fix for the Overlay Height problem. I tried adding the following CSS to Page Markup:
But the result is exactly the same as what I reported before in IE7 – if you load the page and then make the browser window taller, the part you bring into view will not be covered by the Overlay.
Another issue is that my red box and the text inside it also becomes transparent. If I boost transparency to 90%, the text is readable, but I couldn’t figure out how to make the box inside the parent Overlay to be completely opaque. I added some CSS for that red box too, but it didn’t work. I guess that means the Opacity of the Overlay box overrides whatever transparency you separately set for child items inside it.
