[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-look
Subject:    Re: Idea for tool preview on mouseover...
From:       Sean Pecor <sean () digitalspinner ! com>
Date:       2002-03-07 2:18:01
[Download RAW message or body]

On Wednesday 06 March 2002 15:44, Dave Leigh wrote:
> This is actually where it begins to fall apart for me. I find that when I'm
> using my browser I'm rarely AT idle in the sense that's useful for this
> technique. 

Same here. With that said, I can still see applications where I'm at rest for 
long periods of time - especially as I use more and more ASP based services. 
For example, I use Clicktime.com for time tracking. I'll keep a Clicktime.com 
control panel open for long durations. It might be neat to roll over a client 
link and see how many unbilled hours I have for that client. There are other 
ways to accomplish this from a UI standpoint, but something like mouseover 
http head/get functionality may be worthwhile. Maybe not :)

> Then I might spent a significant amount of time on that
> page, but I'm not likely to use links out of it. The point is, I VERY
> rarely "browse"... rather I "search" or "read." My useage is possibly
> highly unusual, but I rather doubt it.

Not really. However, I can see particular scenarios where the cacheing can be 
beneficial. Say you're looking at http://www.lwn.net/daily, and while you 
open up STORY A in a new window to read, the other browser window is reading 
in the links for the next 'N' stories. So, when you get back to the daily 
page, clicking on subsequent stories renders the page instantaneously. Sure, 
we eat up some bandwidth, but bandwidth is cheap isn't it? Grin. Our time 
isn't.

> Hmm. True to an extent, but again, I don't think it's terribly useful at
> second glance. You would very likely transfer the HTML, but you're not
> likely to transfer all of the graphics and applets, etc. associated with
> the page. (Imagine the hit on a portal!!) 

What I am suggesting would require that the software pull in everything 
required to render the page (otherwise it would be impossible to do a 
thumbnail). Most portals tend to reuse graphics from page to page. So you'd 
be cacheing the graphics on that first page, and most of the secondary pages 
requested in the background would be quickly retrieved because most graphics 
are already cached.

> I see what you're getting at, though I think the example's a bit stretched
> (It's poor page design to hide the salary on a page displaying job links,
> IMHO).  

It depends. If you're looking at hundreds of job listings, the initial summary 
view might contain only pertinent data. Maybe the salary is presented in 
summary but the relocation requirements aren't, so that and less pertinent 
information appears in the rollover caption.

> It turns out to be something much more than a minor patch.

Well yeah sure but thats the fun part isn't it? :)

> Now that is a benefit, the best I've seen so far. But by itself it's not
> convincing due to the problem of false hits. It would be nice if we had
> something like a "page ping" that isn't a GET and isn't a POST... just an
> "is it there?" request that doesn't count as a hit. But we don't have it.

Yes we do. We have an HTTP HEAD request. The http server response contains 
valuable information like:

HTTP/1.1 200 OK
Date: Thu, 07 Mar 2002 02:14:17 GMT
Server: Apache/1.3.12 (Unix) PHP/4.0.4pl1
X-Powered-By: PHP/4.0.4pl1
Last-Modified: Thu, 07 Mar 2002 02:14:18 GMT
Content-Type: text/html

I'm not sure if this would trigger a hit in logs (I think HEAD is treated 
differently than GET/POST in traffic reports).

Sean.

-- 
Digital Spinner, Inc.
Cutting edge web design and applications development.
sean@digitalspinner.com
http://www.digitalspinner.com
Phone: 802.948.2020
Fax: 802.948.2749

[prev in list] [next in list] [prev in thread] [next in thread]