View Full Version : Visitor Progress Bar Javascript

09-11-2012, 06:40 PM
Visitor Progress Bar compiles results and displays them in a handy website progress bar, providing visitors with instant feedback of how much of the website they have visited so far.

Recently we spent some time developing a special tool for the MysteryPile website that tells visitors their progress throughout our available articles. The visitor progress bar (now working in the footer area of the www.MysteryPile.com (http://www.mysterypile.com) website) uses a client cookie to track exactly which pages have been visited, storing the value, which is then returned to determine a percentage of visited articles based on the total number of articles available.

09-11-2012, 07:42 PM
This information would be very inaccurate due to the way cookies work. Doing this serverside (preferably with a user login) would be easier to implement and probably more accurate.

As a very basic feature on the site, for someone who can't use serverside code, I can see this working. But it seems more like a simplified/toy version than the real solution for this problem.

I'm just being honest here-- there's no better solution using Javascript, probably.

09-12-2012, 02:15 PM
If the results were inaccurate/incorrect, I would not be using the script. Try it out.

Feedback to the visitor is correct. As cookies work, visiting 1 or more pages will send the cookie along with headers. The script works and has been tested for accuracy to the 100% ratio on pages visited, through several browsers. If you analyze the cookies through the process, you'll find the correct information is being stored and received from init to current state, including the right delimiters.

This site does not have a user login for access, and the script was made specifically as a solution without a user system.

09-12-2012, 03:48 PM
I understand, and I'm not suggesting the script isn't well-written. But I am saying it won't be particularly accurate in wider contexts.
Cookies are not reliable (assuming them work in the first place-- and they do almost always these days) because they can be deleted at any time.

Generally speaking this script should be reliable for a while (a day? an hour? 4 months?) but it could easily not be reliable during a longer time so it could be confusing to a visitor.

Certainly this may be exactly what your site needs at the moment, and thanks for sharing it. But my constructive feedback is simply that the situations for using this kind of script are limited because of the inherent limitations in the cookie method.

09-12-2012, 07:08 PM
I do agree with you in the sense of applying this script to wider context, especially as you point out, the fragility of cookies. Eventhough an expire time is set on the cookie (1 year in this case), that won't prevent it from being deleted if someone clears their cache or browses in private modes. Ultimately it may be necessary to use serverside IP session tracking, store it in a DB, and run matches upon each visit, given the lack of user login. That too has limitations, namely to those browsing via dynamic IP. It's possible that I could write a PHP version that interfaces with the site backend to achieve something like this.

Any suggestions to bypass the cookie method for this concept, without taking advantage of a login system?

Thanks for your feedback, I sincerely do appreciate it.

09-12-2012, 10:35 PM
Eventhough an expire time is set on the cookie (1 year in this case), that won't prevent it from being deleted if someone clears their cache or browses in private modes.Right. The only thing that does is that it doesn't ask for the cookie to be deleted earlier. (Browsers could actually ignore that as well and keep it longer than a year, but I don't know of any context when that would happen, except for a user manipulating their cookies intentionally by hand.)

Any suggestions to bypass the cookie method for this concept, without taking advantage of a login system?No, not really. Using the IP is the next best thing, but it's not really very good at all. Something like a session (as in PHP) would allow you to do this completely accurately (and be certain that it will work) for exactly one visit to the website. But there's no reliable way to associate individual users with anonymous guests on the website. And obviously a login system isn't appropriate for all websites-- I'm not suggesting it is.

The reason you might want to use something like a server-side session method is that it would be consistent always. If you use cookies, then some users might be able to track progress over months of using the site, while others might only get it for a day.

The extra reason for using logins is that it would transfer from one computer to another, so that the user wouldn't be confused by seeing "20%" on one device and "50%" on the other. But obviously that depends on the kind of site you have.

Personally, I'd probably suggest just using sessions. A slightly improved method would be by IP with a fast reset (eg, 24 hours) so that the visitor who returns that same day would still have the same info, not just losing it after ending a single session on the website. But that method wouldn't last for years.

Another option here is to extend the server-side method using cookies. Just give out random strings/numbers as pseudo-logins and proceed using the session method, but allow them to "log back in" based on that cookie, if it exists.

In short, there isn't a great answer for this. What you've done is the best I can think of purely client-side, and any server-side methods will have other kinds of complications (like requiring logins, or only working for a short time).