Basically there is this internal web site that I must use, and I need some stats as to how many total pages I must visit to achieve a task.

Something as simple as a counter that watches for a site name xxx.com and increments every time a page from xxx.com is opened.

there's a firefox extension 'pageaddict' https://addons.mozilla.org/firefox/3685/ that might do the job.

hth

Close, But...

I know that yesterday, I spent a Full 8 hours beating on the site in question. I'd like to know how many pages I viewed in total.

That 8 hrs was spent pushing 32 drawings into the release control system, and I haven't actually gotten them released yet. So far it's cost ~15min/per.

To put that into context It's been a week since I started the task to release a set of 63 drawings.

You might be able to Firefox's history pane sorted by date and site. You'd have to count manually, and I'm not sure if it would show the same page visited multiple times or not, but it's already there.

I can't help feeling that if this intranet application is so misdesigned that someone's taking the time to document how many pointless pages it takes you to, then it's somehow unlikely to even work in Firefox...

Peter

Oh Peter, How did you know? It's Matrixone. (www.matrixone.com) Edit: was Ematrix

There isn't a single drop down chooser any where in the app. Any field that has to be revised brings up some kind of page. Usually a search tool where you type in what you wish to enter, hit find, then from the results, usually a list of one item, choose, then accept. After which you need to refresh the page where you started so that it actually shows the change.

Frack!

Save the page to an html file on your comp. Edit the "action" field in the page's form so that it posts to a simple cgi script on your web server. The cgi script will take note of the request for counting purposes and will then redirect you to the proper url.

Code:

---

#! /usr/bin/tclsh

set token [open counter.txt a+]
set count [gets $token]
close $token

if { $count == "" } {
  set count 0
}
incr count

set token [open counter.txt w]
puts $token $count
close $token

puts "Location: http://therealurl.com/script.cgi\n"

---

It might work...

If he had access to the server, he could just look at the web server's logs.

He doesn't need access to that server, just any server. A web server installed locally should work, too.

And he's going to do that for every page he accesses? And then figure out a way to munge the links on each of those pages so that it redirects to the local web server? If you're going to go that route, it would make more sense to just install a proxy server through which all traffic flows and then read its logs.

Well if it's just one page/form that he's using then it wouldn't be a problem.

Setting up a proxy server would probably be the easiest solution though.

If he's submitting forms, which he said he is, then it's either posting to itself or to another page. In either case (not to mention the case of simply clicking on links) he'd have to change the link on the page his browser is viewing to reference your CGI script. If he's able to do that, either he's got access to the server itself (and, even then, it would be far more difficult than just changing some links) or he can change the page on the fly in he browser, in which case he has enough capability to have the browser itself count, and the other script and web server wouldn't be needed.

The only way your idea will work is if the only way he ever gets to any page he's interested in is by typing it into his URL bar (or selecting a bookmark), but never by clicking on a link or submitting a form.

Nope, you're wrong, Bitt. All he has to do is save the html file locally and edit the url/link, and then view the html page from his computer.

It will work fine for a plain-jane form, but if it's some complex "web 2.0" online application then that's a different story.

Okay, he saves "the" remote page to his local computer. He modifies it to reference your script as the form action.

Then he opens the formerly remote page. That's one hit. It has not been recorded anywhere.

He submits the form. It hits your script, which updates its counter. It then "redirects" to the real page. (How this is accomplished I'm not sure, as a redirect will not post the data again. But let's assume it does, somehow, or was just a regular link.)

Then the page that's now displaying on the browser has been generated by the real web server. Now he needs to click on another link or submit another form. Since that page was not affected by your script nor in any other way updated to reference your script, it only references the original set of pages, not either your script or the original page that was downloaded. So he clicks or submits and gets a new page without interacting with your script, so no counter is updated.

From this point on, the only way to get back to your script is to enter the URL for the downloaded and manually edited page or for the script itself.

Even if you save a modified copy of each page that he was to access, only that first manually modified page will ever reference your script because all of the pages the browser renders after that first one will be the original pages that reference the original web site.

Sorry I haven't been keeping up. Too busy running in circles. Read pushing more pages thru the local bit bucket.

Once upon a time I looked at the url's and page sources. Bizarre!

I'm sure it makes sense at some level but why would anyone program a web app to generate url's that contain random numbers. Truth! I traced a link thru the javascript and it had a random number generator that created a portion of the URL.

Thru the simple expedient of counting the pages visited for one task and multiplying by the number of tasks, I hit well over 1200 pages over a 4 hour period.

What is truly sad about this is that every field I had to fill was redundant info. Every bit of todays work could be automatic.

I'm particularly disgusted with having to use a find dialog just to get my own userid into one field. In another page of the app I can type in a userid and it essentially spell checks it against the acceptable userid's. Yet even in that location the necessary uid is already known to the app and I don't need to be keying it again.

Not helpful, but old Netscape 4.7x History file would track extensive information. URL, page name, first view date, last view days, number of times viewed, etc, etc. Sortable by any of those fields. Able to retain for "999 days".

Is there any such plugin for Firefox? It's sad to see FF 1.5 using IE's pathetic History after Netscape had such a robust one.

All that data seems to still be there.

There is an extension to access it: Enhanced History Manager

Interesting I'll see what falls out with this though FF has some problems with a few functions of the site... Looking at the empeg site counts - Hmm no tally for the entire site.

I take it that the only way to reset is to wipe the history.