ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

Web 1.0: What We Can Learn From Butt-Ugly Websites of the 1990s

Updated on August 30, 2014

A Web 1.0 Website, 1994

It looks ghastly, it uses an image map, and there's almost no info, just navigation. But computer screens were tiny, homepages had to be "above the fold," and websites worked differently then. We can still learn from this godawful design.
It looks ghastly, it uses an image map, and there's almost no info, just navigation. But computer screens were tiny, homepages had to be "above the fold," and websites worked differently then. We can still learn from this godawful design. | Source

When Content Was King

The web has changed profoundly, and few websites from the early days have survived. The remnants of the web's early years exist in forgotten backwaters seldom visited by web users who arrived in the last 5-10 years.

Sometimes, it's good to look back and remind ourselves how the web used to be. In most respects, it has vastly improved. But there are also methods that worked, sites that presented their content effectively, and successful techniques that we have lost in the shift from Web 1.0 to Web 2.0.

This article is dedicated to the memory of Geocities (1994-2006), the free webhost used by millions to host our hand-built websites.

The Shift from Static to Interactive: Web 2.0

The terms "Web 1.0" and "Web 2.0" come from Darcy DiNucci's prescient article "Fragmented Future" in 1999. Tellingly, this article was published in Print magazine. We were still reading our tech blogging in printed magazines, because there weren't tech blogs or online news sources in those days.

At the time, webpages were "static," hand-coded from top to bottom. The content was self-contained. There were no reader submissions or comment boxes, no "votes" or "share" buttons. Pages did not change or incorporate new content, like ads or "related articles" in the sidebar. Websites, too, were static: an author or group of people would build them from the ground up, like a DIY carpenter building her own custom house to suit her needs, instead of a modular house with all the standard features (dishwasher, fridge, microwave, specific rooms) that houses are expected to have.

DiNucci's predictions were spot-on. In the 2000s, we started incorporating more kinds of content: videos, photos, sound, and pieces of content from other websites, everything from YouTube videos to Amazon products and prices. We implemented user interaction such as polls and comment/feedback. Instead of building our own websites, we migrated to popular, well-trafficked third-party platforms to publish our content -- anything from Twitter to Blogger -- and we started publishing articles on sites like Hubpages.

Web 2.0, the interactive, script-driven and social web, changed what kind of content we could easily share, and therefore the kind of content we tend to share.

The Web 1.0 Model of a "Homepage and Subpages"

Nowadays, few people build websites except for businesses. Instead, we post the bulk of our content on online publishing sites. Apart from Tweets and status updates, our content usually takes the form of single-page articles and posts, tightly focused on one topic.

Whereas in Web 1.0, the standard way to present content was to have a homepage, which consisted of an introduction to the topic plus navigation links, and subpages covering aspects of the topic in more detail. Here's a few examples:

In all these examples— humble and clumsy as they are— the "homepage plus subpages" model allowed the author to share richer, more detailed, and more in-depth information on each subpage. In Web 2.0, instead, the basic unit is a post, which only allows us to skirt the surface. It's harder to give expert-level information in Web 2.0.

Takeaway Lesson: I suggest that we may at times want to adapt the web 1.0 "homepage plus subpages" model in order to present more useful, richer, and more in-depth content. Blogs will let you do something similar, but the basic structure of blogs is to group posts chronologically, not by topic; you need to choose well-thought-out categories. (My Mom, who has a web 1.0 mindset, used Wordpress to create an educational website using only categories and static pages, not blog entries – that's going a bit too far, but it shows what's possible.)

Expert (or Informed Amateur) Information

In the early days of the web, it was illegal to earn money on the internet (a government-funded research tool). Instead, the goal of web pioneers was to create websites of useful or interesting information. For the first time we could share our expertise, hobbies, interests and passions with more people than we knew, in a different way than we could with printed books. We hoped that if we all built and contributed something to the web, we would then be able to enjoy and benefit from everyone else's contributions.

That meant our sites were in-depth, dedicated to their topic, and designed from the ground up for that topic, rather than using modular "publish anything" tools like Hubpages. For example, see the search tools of the Perseus Library on which I worked from 1993-1996. The tools are tailored to the content found on that website, and are made for students and researchers studying that particular kind of content.

Takeaway lesson: Nowadays, we mostly write brief articles and link out to Wikipedia or other expert sites for "more information," lest our content outgrow our web 2.0 readers' short attention spans. But sometimes, we should be the experts who create the expert sites with more in-depth, detailed, and rich information and/or tools best suited to that topic. The site doesn't have to be professional or scholarly. It could be for knitting wool socks, or any other topic you can imagine. An in-depth site draws visitors because its content exists nowhere else on the web.

Creating Websites Without Readers in Mind

Wait, what? Why would we want to design webpages withou considering our readers? Surely, readers were the reason for publishing, even in Web 1.0?

Well, yes. However, for the first ten or so years of the web, apart from the occasional guest counter or guestbook, we knew nothing about our readers. We had no idea who was reading our websites, or even how many visitors we had. We didn't have Google's search query data to tell us why people had come to our website and what phrases (keywords) they were looking for.

Instead, we simply built websites to cover the topic. We didn't take into account reader feedback, whether a topic was likely to attract readers, or what the popular searches were on our topic. We created content, and designed our websites, with one directive, one goal, one purpose, one driving principle: the topic itself. It, not readers, determined what content we included, how we organized our website, and every aspect of our online work.

Takeaway Lesson: Obviously, now that we can hear back from our readers, we should pay attention to them. We should consider user experience. But let's not forget: our goal isn't simply to attract visitors and satisfy them. Our goal is to cover a topic well. How we go about doing that depends on our topic, not only our readers.

working

This website uses cookies

As a user in the EEA, your approval is needed on a few things. To provide a better website experience, hubpages.com uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at: https://corp.maven.io/privacy-policy

Show Details
Necessary
HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
LoginThis is necessary to sign in to the HubPages Service.
Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
AkismetThis is used to detect comment spam. (Privacy Policy)
HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the googleapis.com or gstatic.com domains, for performance and efficiency reasons. (Privacy Policy)
Features
Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
MavenThis supports the Maven widget and search functionality. (Privacy Policy)
Marketing
Google AdSenseThis is an ad network. (Privacy Policy)
Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
Index ExchangeThis is an ad network. (Privacy Policy)
SovrnThis is an ad network. (Privacy Policy)
Facebook AdsThis is an ad network. (Privacy Policy)
Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
AppNexusThis is an ad network. (Privacy Policy)
OpenxThis is an ad network. (Privacy Policy)
Rubicon ProjectThis is an ad network. (Privacy Policy)
TripleLiftThis is an ad network. (Privacy Policy)
Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
Statistics
Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)
ClickscoThis is a data management platform studying reader behavior (Privacy Policy)