Inside the Server Side Navigation Bar
SSNB or jsNAVBAR
What IS the SSNB?
The Server Side Navigation Bar is the replacement for the old Web-Ring "HTML code fragment".
The code fragment contained the web-ring "navigation" links to the next link (web site) in the chain, a link to the ring home and to a list of the all the sites on the ring.
Code fragments were often personalized or contained custom graphics becoming a billboard advertising "the ring".
Some remained simple text while others became high tech pieces of HTML programming including Javascripts and image maps.
(Samples at anvilfire.com web-ring nexus)
The SSNB replaces all that with a simple, boring, corporate grey bar.
However, the important feature of the SSNB is that it is served from the ring host's computer, not from the ring member's computer.
This gives the host and the ringmaster the ability to change the content of the SSNB at any time.
Ring members do not have to update the code when there are changes.
There is also no code they CAN edit so the SSNB are always uniform (supposedly).
One of the important uses of the SSNB is to determine if a member site has the linking code installed.
IF it is installed then any time the page is loaded the host can tell when and by whom since they are supplying part of the page.
It replaces the "Ring Checker" that was launched earlier this year.
The problem with the original ring checker was it operated on the "spider" principal.
It downloaded the text of a page and then looked for key pieces of code.
The problem was reliability. Often pages timed out or couldn't be read by the spider.
The HTML code fragments were customized by the Ringmasters and then often individualized by the ring members.
Errors were rampant.
All the automatic features designed into the system had to be disabled by the Ringmasters or ring members that had good code installed would be sent warning letters or taken off the ring by the robotic checker.
The robot machine had no tact and was wrong too often.
With the SSNB you don't have to spider a site. All you have to do is look at the SSNB access log.
IF it has been called the page is active.
If the page isn't active in some minimum time period then call the page and watch the SSNB log.
If it shows the SSNB was loaded then the page is good. If not, the page is missing the SSNB code.
By looking at the access records and not checking sites that have active SSNB accesses then a huge amount of server time and bandwidth is avoided PLUS
it is extreamely accurate. Server records have the calling page recorded so there is no need to ever "spider" sites.
NOTE: These are my suppositions based on the way the system appears to work from the outside.
Hopefully I am not giving the yahoos engineering ideas they didn't already think of. . .
How does the SSNB work?
On the members page there is a simple Javascript statement calling a piece of source code. Example:
<SCRIPT LANGUAGE= "JavaScript" SRC="http://www.hostsite.net/navbar.js"></SCRIPT>
The code this calls is very simple Javascript containing nothing but a list of "document write" statements. Example:
document.write ('<A HREF="http://ahostsite.net/prev.pl?ring=Name;ID=123">Prev</A> ');
document.write ('<A HREF="http://ahostsite.net/rand.pl?ring=Name;ID=123">Rand</A> ');
document.write ('<A HREF="http://ahostsite.net/next.pl?ring=Name;ID=123">Next</A>');
The code could be this simple or it can be very complex.
It could contain Javascript functions (like browser detection), rollovers, image maps, animation or sound.
Anything that could be done from an HTML web page. Below is the result of the above code.
The Yahoo SSNB is fairly simple having two nested tables, fonts and a single graphic.
The Yahoo SSNB is generated dynamically from a program running on their server and is keyed to the serial number in the call.
This integrates into their Web-Rings database and generates the custom code as needed.
In all probability the database is updated every time the SSNB is called (See note about suppositions above).
We came up with a much simpler system using only two lines of Javascript.
The first script has the members site ID (or name/email. . .).
This variable is used in the second script with the document write lines to create a customized jsNAVBAR without a complicated CGI system.
<SCRIPT LANGUAGE= "JavaScript"> var RingNameSiteID='123'</SCRIPT>
<SCRIPT LANGUAGE= "JavaScript" SRC="http://www.ringhostsite.com/navbar.js"></SCRIPT>
This means there is no need for a tricky dynamic CGI system coupled to a database.
The code either serves or it doesn't.
This works with any webring system such as Gunnar's Ringlink and David Levitan's eSitesurf or on any host that give Ringmasters the freedom to design their own ring code.
It also means that versions could be designed that serve the code from the host but the graphics from the member site.
OR the entire block of Javascript could be served from the member site.
Then updates would not require the member to edit their page but just copy a new file to their server.
Those experienced in HTML could further customize the Javascript for their site if they were so inclined.
- Demonstration NAVBAR pages:
- Our original test page
- NAV BAR ERROR Demo
-
NOTE: If you accessed this page through Rings @ anvilfire.com, all our nav bars on that page were served via jsNAVBAR code. Oct. 4, 2000
Why are WE using a jsNAVBAR?
Ever since Webring.org announced the server side navbar I was excited about the possibilities the idea presented.
I had just adopted two web rings and had just gone through trying to get everyone to change their code.
And here we are doing it AGAIN! Changes have become the biggest problem area for maintaining the rings.
The Blacksmith's Ring needed a new logo/navbar and the announcement that the new system would serve the NAVBAR sounded like an ideal time to make the change.
So, I had been planning on a change for a long time and had announced on the ring's home page that we were planning a new logo that would probably be much smaller than the original.
The plan was for a standard banner size (468 x 60).
I had also been thinking about how the system would need to work and had a head start on what Yahoo finally released.
They COULD have served all the funky customized HTML fragments designed by the tens of thousands of Ringmasters and still gotten most of the advantages of collecting data and replacing the spider ring checker.
But they did not. Instead they produced the "grey bar" which after all their effort has some significant design and implimentation problems.
Not the least of which is the (80,000) Ringmasters almost all hate it.
Our jsNAVBAR's were designed to be easy to install and easy for me to maintain.
The current design of the Blacksmiths Ring nav bar is one made up under pressure to get the new Ringlink system under operation.
It has some problems and will be redesigned as a single graphic with an image map.
This will be much simpler (and smaller) code and it will not be suseptible to problems created by pages with style sheets or incompetent HTML editing.
The AMAZING thing about this change is that the ring members do nothing and may not even notice the change!
Many other systems work similarly. Most banner programs now serve "rich content".
That means actual clickable items on banners rather than the fake scroll bars and search boxes.
Its done using exactly the same techniques as above.
This is all part of the ever changing technology of the World Wide Web.
It is also a technology that is not limited to big corporate run systems.
Any Ringmaster or Webmaster that understands HTML and a little Javascript can create and maintain a jsNAVBAR or rich content system.
Jock Dempsey
webmaster@anvilfire.com
October 3, 2000
<SCRIPT><NOSCRIPT>
Java or not to Java. . . Many argue that Javascript is an evil nuisance on the web.
A short time ago "frames" were looked at the same way and before that fonts.
However, Javascript is mearly a programmable extension to HTML.
It is here to stay and more and more web sites are using it.
Virtualy all web capable browsers accept it going back 3 years.
Recent discussions of the subject have focused on the fact that browsers for the sight empaired do not support Javascript.
This is a problem of the lack of keeping up with current technology, not a lack of support for sight empaired browsers.
However, like any web related technology Javascript must be used with ample consideration.
There is nothing worse than a web page requiring the absolute latest technology to view it.
The vast majority of the world is always a couple years behind the latest developments in web technology.
This includes monitor size, browser version, sufficient memory. . . .
On the other hand, many web sites are written and maintained by individuals working alone and they have to decide what level of technology they wish to support.
Most HTML references immediately jump to using Javascript to detect the browser in use so that a compatible page can be served.
If the browser is non-Java capable the pages served are expected to be for that level of technology.
The problem with this "solution" is that is works for individual pages and small web sites but it doesn't work when there are thousands of pages invloved.
Its not a matter of Java/no Java, its a matter of IE 3.0 vs NS 3.2 vs IE 4.5 vs NS 4.04. . . . How many versions of the same site can anyone maintain.
The biggest problem has always been the differences between Microsoft and Netscape browsers.
When Netscape was THE standard and dominated the web, Microsoft's newest releases always were short of support for features already implemented on many websites.
This included Javascript support.
Today the differences are less but those that exist are more subtle and hard to test for.
Style sheet support differences are the greatest despite the touting that this was the solution to pages displaying differently on the competing browsers.
Simple HTML definitions like page margins still require "double tagging" to produce uniform results.
Javascript differences are much more subtle. . . little buggy things like not being able to call a script in a different frame using IE. . .
Those writing Javascript often make the mistake of using much too late a code version for the installed base of browsers.
They then fail to test on any other platform other than the one they regularly use.
Currently the world standard is 4.0 browsers even though there are much newer browsers on the market.
However, I still test on my old 486 running Win3.1 and Netscape 3.2 using a 640x480 monitor.
But soon I will have to abandon this personal "standard" and move on. Progress waits for no one.
Rev. 10-18-2000 Fixed err in sample code, added sample output.
