Anatomy and Deployment of Links ·
Index · Part 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · Expand · Web Feed
Before you create pages, navigation elements etc., and before you develop the very first link, go to the white board and think about Web site structures. Developers tend to think geeky, they create logical, non-redundant structures. Bear in mind, that Web site visitors usually have no idea of abstraction, encapsulation, inheritance and normalization.
They go to a search engine and seek for a particular information or product, for example green widgets. On your landing page they expect to find the whole story. To get general information on (colored) widgets, most likely they won't trail your path to the root from a subsidiary page expressing a widget variant's attributes and behavior, but omitting a description of widgets. Instead they hit the back button and click on the next search result. You must provide all related information on the landing page for the search term 'green widgets', that is you must include a short paragraph of text on widgets and colored widgets as well. Sounds pretty easy, but it's a dilemma, because fulfilling the visitors expectations leads to content duplication, which is a bad thing with regard to SEO (solvable with clever linkage and snippet management - read on, also check out this method).
The point I want to bring home is, that there should be a few linkage layers extending the (technically conditioned) hierarchical structure of a Web site with topic-oriented navigation elements and themed interlinking within the body text as well. This requirement often results in a geeky structure (black lines), obscured by different topical connections (green and red lines):
Looking at the picture it becomes obvious, that technically driven structures cannot fit the confused user's needs, nor will they ever be suitable to represent any site's theme (especially not on multi-themed sites). Why? Because the first hierarchy level is superfluous and prohibits theming. There is no valid reason to put all news under news, all tutorials under tutorials, all products under shop etc. etc. - it's done at so many places caused by lazyness, geeky thinking, and villainous planning. Even 'unexpected growth' of formerly tiny sites to large resources is no excuse for a poor or shortsighted design. By the way, geeky structures confuse the hell out of search engines and dilute a site's authority status.
Is there a way to do all themed interlinking by changing the established Web site structure? No. At least not yet. But we can improve the old fashioned hierarchical structure with universal nodes and topical connectivity. Both concepts are not that new, but many webmasters (especially technically unschooled former publishers or salesmen) coming from the static side of Web development can't adopt them completely. At work they fall back a paradigm or two, and develop dynamic sites emulating restrictions which belong to the stone age of the Internet. Another weakness is the usage of various 3rd party scripts for particular tasks (shop, publishing, directory, web log, link exchanges ...), because those will seldom interact as seamless as necessary.
Define node: A node is an information unit containing information about a single topic, linked to at most one parent node, and none to many child nodes. Nodes without children are called leaf nodes. The topmost node of a hierarchy is the root node, it has no parent node. All nodes in a structure under a root node, including the root node itself, build a tree.
Define Universal Node: A universal node is sort of an instance of the superclass nodes. It has an unextended set of attributes (ID, parentID, name, title, description, sort order, anchors, type). That is a universal node has no more attributes than necessary to build and represent a tree structure. The attribute anchors contains a set of link attributes. The attribute type is a pointer to an instance of a node-subclass.
Other than well known nodes like folders in a directory tree, universal nodes don't act as a shelter containing objects having attributes and behaviour which aren't (necessarily) transparent to the container. Universal nodes transform the contained object to a node, that is they infold the objects and make them a part of the tree structure. Looking at a hierarchy of universal nodes, one can see only nodes of different appearances, but not a single container loaded with cargo.
Logically, a universal node is an instance of a subclass, which inherits the attributes and methods necessary to build and represent a tree structure from its parent class.
Physically, a universal node is a conglomerate of at least three objects (node, anchors, and type specific data and behavior) for two major reasons.
First, it makes sense to change a node's type dynamically, for example a one-pager can mutate to a complex structured document during its life cycle. That can't be done by changing data in a given structure, it must be done by replacing the outdated object by the new object, where the new object is an instance of a different subclass, while other values of the universal node's instance variables are not necessarily subject of changes. Since those changes occur frequently in production systems running 24/7/365, changing the type pointer is the best maintenance procedure.
Second, the majority of accesses to persistent nodes data is caused by navigational requests. To create menus, listings on (category) index pages and alike, only few values are needed. Dealing with the overhead of complex database tables to fetch 3-4 values per tuple is a no-no on systems where high performance is almost everything.
Summarizing, with regard to system transparency and useability, the best solution is the segmentation of complex subclasses into separate entities. Publishers, editors and webmasters handling SQL queries will not understand atomized database structures created by object2table wrappers or persistence frameworks.
In a Web site's structure a node-subclass can represent a single Web page (primitive node), or a set of homogeneous data belonging together (complex node), which are visualized on multiple Web pages of the same micro structure (and which may be indexed in a node specific table of contents, and which may have complex attributes like glossaries, appendixes etc.). Alias nodes are 'empty' primitive nodes, pointing to a primitive or complex node, thereby overwriting one or more attributes of the wrapped node, for example title and description.
Examples of primitive nodes: home page, category index page (one-pager), articles (one-pager), feed previews. Important (outgoing) links can be handled as primitive nodes, regardless whether they are described on a separate page, or just appear on their parent node's (index) page.
Examples of complex nodes: image or movie galleries, multi-page category indexes, structured product information, structured documents like huge articles, news pages aggregating related feeds in variable orders.
Example of a tree structure built with universal nodes:
In a tree of universal nodes every node type can be parent or child of any other node type. A universal node (and a node's structure with all children, grandchildren...) can be moved under another parent node by simply changing the parentID attribute. Because the dynamic navigation 'knows' only nodeIDs, all links stay valid, the navigation elements simply regard the new parent(s) throughout all levels.
This picture shows a simplified example of a partitioned Web page created by a universal node. All peripheral areas and CI components (on white background) are controlled by the generic functionality of the universal node. The navigation links represent a part of the tree from the node's perspective, probably extended by or intermeshed with topical connectors. In the header the path to the root is put as linked bread crumbs, using the data gathered in the left handed navigation element's recursive loop. Other topical connectors and type specific or generic site wide links, for example a 'most popular' or 'featured products' box or so, are placed below the navigation. The block of further leading options like 'related products' or 'related articles' above the footer's generic first level navigation bar is created from topical connectors of the type 'related links', which may or may not appear in navigation elements too.
The page's body area (on gray background) is controlled by the universal node's type specific functionality. That includes inner navigation and advertising within the content.
Deeper segmentation and other layouts are possible and easy to accomplish, for example the type specific functionality can control segments of the peripheral area (e.g. inner navigation blocks, targeted ads or even the page title etc.).
Define Topical Connector: A topical connector is a themed link from one universal node to another universal node, where the nodes are not connected in the tree structure. A topical link has (possibly complex) properties and behaviour, for example purpose, qualification, conditional in-/exclusions, and node-like attributes like title, description and anchors, which allow the intermixed use of universal nodes and topical connectors in structured Web page elements like menus.
Topical connectors extend the tree to a webbed structure, which is a (possibly on multiple layers) intermeshed network of nodes. In comparision with the geeky structure, the topical layers consist of way less non-hierarchical connections, because most (if not all) topical affiliations are (implemented as structural links between universal nodes) part of the tree structure.
Alias nodes are a comprehensive form of topical connectors.
Although it's feasible to handle complex structures as described above dynamically, it may be a good idea to implement denormalized flat helpers for performance reasons. That is editorial users (authors, publishers, webmasters ...) work with the normalized structures, while Web site visitors get the pages created based on merged and sorted node sequences extracted from (parts of) the tree plus all related topical connectors. Such a flat helper is a persistent sequence of nodeIDs plus level numbers in a particular order, which gets joined with the nodes table on nodeID to fetch attributes like anchor text, tooltip, and URI.
Different outputs need different denormalized extracts, which may overlap with other flat helpers. On structure changes a node's update trigger should regenerate all flat helpers belonging to the changed nodeID or containing the changed nodeID or it's parent, as long as the flat helpers are needed to create important pages.
To generate hierarchical site maps, article or white paper indexes and alike (on the fly), it makes sense to have some large flat helpers, including flat helpers covering the whole site's structure. Those batch jobs should be started by cron jobs in low traffic maintenance windows, because heavy batch processes can slow down a server, and the actuality of site maps etc. is not that crucial.
Amplification of Internal Linkage by Inbound Links
From a search engine's point of view, a well structured, user friendly (and content rich) Web site is more likely considered an authority on its overall theme. The organization of related content under one universal node per topic is considered a network of topical hubs. Each internal hub becomes an authority on its topic, and all hubs together form an authority on an overall theme.
Larger internal hubs attract way more deep unidirectional inbound links than a couple of pages on the same topic, which are (structurally) scattered all over a site. Supplementally, each internal hub should be subject of its own link building campaign. Clever themed internal interlinking provided, the power of incoming links gets perfectly distributed to all related nodes (content pages). That's not so much an issue with link popularity, respectively PageRank™ (but an issue with regard to topical PageRank™). Good inbound links (pay attention to anchor text variations!) contribute to the hub's (=index node's) topic (~keyword) relevancy and authority. The hub has only few upward connections (navigational links to upper levels), so the inbound link's authority contribution gets funneled to the right content pages. All on-the-page optimization being equal, pages loaded with authority do rank higher on the SERPs.
A side note on the hub vs. authority myth:
Not every page loaded with more links than textual content is a hub. Not every page loaded with useful content and few outgoing links becomes an authority when many related pages link to it. Consider a link and its surrounding text content. The assignment of a (weighted) hub- respectively authority-status to a Web page by search engines is not mutual exclusive across the boards. A Web page classified as hub can be considered a topic authority and vice versa. An authority hub is a Web page providing on-topic content and valuable connections to related content, regardless where the content is hosted. A web page's cluster (that is a group of closely related documents providing content and related connections) can form an authority hub as well.
A Universal Node's Anchors and their Link Attributes
The Components of a Link [HTML Element: LINK]
Anatomy and Deployment of Links ·
Index · Part 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · Expand · Web Feed
Last Update: September/7/2005 [1st DRAFT] Web Feed