What was old (and forgotten) is new again (and scaring everyone, again)

I’ve come across half a dozen site in the past month that seem to be concerned with a little JavaScript that will provide information about the user’s surfing. The idea is that some site can access this history and make certain assumptions about the user of the browser. As if this will be any good information. Though one site did mention the scenario where one site may check the browser history to see if the use came from some competitor. In this case the site would or would not provide information to the user. This is all speculation on the scenario.

The sites that present this as something new and frightening need to get a clue. This is not new! The JavaScript to access the browser has been available for some time. But I’m guessing the use of this JavaScript functionality will be something like the new AJAX functions that have been available for years but not ‘discovered’ until recently.

AJAX Server File Browser

I was reading a book from SitePoint.com, DHTML Utopia: Modern Web Design Using JavaScript & DOM. Way in the back of this book is a section in interactions with the server via client-side JavaScript. The author, Stuart Langridge, covers an application that allows the user to a) view a tree of folders on the server and b) move a file from one folder to a next via drag and drop. Wow.

My first thought on this was “With all the AJAX development going on, why has no one developed a tree view control?” This may seem like a strange question but remember in the dark ages of Web development (the days before AJAX and Web 2.0) when we are developers attempted to emulate rich desktop applications. During that time we would have a need for a tree-view. This is where the user can click the ‘+’ to expand the display and view children similar to Windows Explorer.

One of the major burdens of building this type of rich control before the days of AJAX was this. The developer would come to a fork in the road of his/her development. This fork would make the developer chose one of two paths of implementation. Path ‘a’ is to send all content to the client browser that will ever be needed for the tree-view control. Realize this could be hundreds of items. Most of which the user would never see because the child nodes would remain hidden. The second path ‘b’ of the fork would be to only provide enough information to the client to build the first level tree now. Then when the user selected a node to view (expand) this would force a call to the server and a page refresh to display the contents of that node. This of course goes against the AJAX process in that the entire client web page must be resent from the server.

So this is how I arrived building an AJAX tree-view control. It’s is pretty basic as it stands. Some things I’m working on adding are:

  • Detail view control – On the right-side view is the details of the folder content. If have a desire to make this be something like Windows Explorer in that you can change the view from detail to thumb to whatever.
  • Column expand/drag – This is something I’ve seen on other (before AJAX) controls where you can actually expand the column display.
  • Search for nodes – This should allow the user to search the left-view tree for nodes. Should not be hard to implement.

I’ve put together an initial beta release. It’s not much on cool functionality. But it dows work and the folder tree is dynamic. Download the initial beta version here. Also feel free to test out the tool here.

Feel free to leave a comment below or check out other projects I’m working on here.

Better printed page links

This is in a word…FANTASTIC!

I was hunting around for some print style sheet tweaks for a client. Seems they have a very wide horizontal table that of course when printed cuts off the right side. No Duh! so I’m surfing around checking various leads on Google or whatever search engine and I come across this article

http://www.alistapart.com/articles/improvingprint

I’m sure you’ve all printed a web page that contains links. You get the link text that is shown on the web page but not the actual URL. Since this is a printed document you can’t really hover over the link text to see the URL href or anything. So basically you’re screwed! The first iteration of a solution was to move the links inline. Well as is mentioned in the article it makes the text you are printed very unreadable.

So the solution is to put footnotes next to the link text that reference the URL at the bottom of the printed page.

I’m totally blown away. Thanks Aaron