there goes the neighborhood

Alter width of article: Default / Full width

June, 2000.
By Molly E. Holzschlag. (Link to original article.)

I'm so tired of the terms "venture capital" and "angel investors." What happened to the Web I loved—that strange, diverse place where human expression, information, and global community were as important as commerce?

Once a place for information exchange and personal expression, the Web is now driven by commercial endeavors. While this has been great for technological innovation, which is exciting, human issues have been relegated to the Web's alleys and back roads in the rush to develop Web "properties." In essence, the Web is undergoing gentrification—a virtual urban renewal.

How can the home-page enthusiast make her mark? Where does the small businessperson go? And what on earth does this gentrification process demand of us—an already stressed group of developers—as we seek to advance our technical know-how to keep up with market demands? Underneath the poignant philosophical arguments lies an equally confounding and perhaps alarming trend regarding the technology we use to stake out our Web claim.

The lay of the land

There are some staggering differences between the ways that the first Web settlers used the medium and the methods necessitated by today's Web demands. The fundamental discrepancy lies in ease-of-entry. The early Web was relatively easy to work with and create. Today's Web demands technical know-how that even the most senior developers are struggling to gain or improve. This is clear in several development arenas, including client-side coding, server-side technology, and content.

In 1992, almost anyone with access to the Internet could create a simple informational Web page using HTML and put it up online (see Listing 1). So maybe the page's metaphorical walls weren't covered with pictures, and the furnishings consisted of plain text. There was content, and links to other content. And bear in mind that these pages are as accessible today as they were then—perhaps even more so because at the time there were no cross-browser or cross-platform conflicts!

In 1993 the visual browser caused radical shifts. By 1995 we could hang pictures and add wallpaper to our Web "rooms." We could even make text blink. But things were still pretty simple, and creative people could put together a site that was aesthetically impressive, as well as useful (see Figure 1).

Figure 1. In the Web's early days, creative people could design simple pages that still had visual appeal.

Coding was still straightforward with few cross-browser, cross-platform concerns. We weren't using tables, frames, or JavaScript. We were building with the basics, and while the results were basic, they still worked. They still work today. Some could even argue that they work better because they are highly accessible no matter the client. So maybe they aren't the most aesthetically interesting, but they are functional.

As you probably know, the ensuing years have brought profound and complex changes to client-side code. Resolution issues and cross-browser, cross-platform design headaches are an extension of the rapid growth and competitive nature of browser development. Gone are the days of simple homesteading. In their place are table constructs, frames, style, and scripting (see Figure 2)—a lot of work to achieve something that can be done just as effectively but with less overhead if we only stopped pressing to have more whirligigs and doodads.

Figure 2. Sophisticated look, complicated code.

It takes a vast amount of knowledge to hand build a site in today's Web environment. Web pages aren't produced with stand-alone HTML. Instead, the coder must understand a range of issues such as whether to use dynamic or fixed tables, how to manage frames, and whether to use style sheets and browser-specific code. What's more, many educated coders are familiar with, but not completely aware of, actual HTML 4.0 standards versus how HTML is conventionally used.

Also consider that the World Wide Web Consortium (W3C) and many industry leaders are convinced that XML is the future of client-side coding. They've instituted XHTML as the bridge between HTML and XML. Now we come to the gentrification issue as it applies to code.

Using XHTML or XML requires an adherence to syntax (see Listing 2) that even very good HTML coders have not had to follow! This language shift widens the gap between homesteader sites and Web "renewal" sites, which sweep down and declare that modest HTML home pages are dilapidated structures. All this happens in the name of growth and prosperity.

Coders who want to make good choices about how they code now and into the future should:

Hired help

OK, you say, but what about WYSIWYG software? An individual interested in creating Web pages doesn't have to know how to code to put up a site. He or she can use WYSIWYG development software to design pages and let the software do the coding. That person can even use software not intended specifically for Web design but that contains HTML export options. Just about any Microsoft Office product offers this, as do some Web graphic design programs like Adobe LiveMotion and Macromedia Fireworks.

But WYSIWYG software doesn't provide a real solution. In fact, if the goal is to create a page that everyone can view easily, such software can actually make the job harder.

If you've got some development time under your belt, have studied Web design concerns, and use WYSIWYG software successfully, take an honest inventory of your skills. You probably know an awful lot about the Web and Web browsers, despite the fact that a WYSIWYG program is supposed to do most of that thinking for you.

Some very specific issues with WYSIWYG code that cause concern are:

et's say a person is working with FrontPage or GoLive, as are many newcomers to the Web. He or she opens the program on a computer set to a resolution of 1024x768. Without understanding how to manage resolution for dynamic or fixed table designs (see "Integrated Design" in the October 1999 issue), the designer might go ahead and create a site according to his or her screen resolution. Looks great! Well, not if a visitor is surfing at a lower resolution. Talk about a wide load—suddenly a viewer is confronted with having to navigate a horizontal scrollbar, on top of everything else.

Another example—and I've had more reader questions about this than I care to number—involves using FrontPage components without understanding that the server extensions must be available on your Web server. This can cause enough stress to send an unprepared designer to crisis intervention. Sites developed without prior understanding of this concern can render most of the content unusable—after countless hours of hard work.

nd what of those developers who understand WYSIWYG software, but don't know HTML? I always liken this to driving deserted back roads in Arizona in August. The car breaks down, and you don't know how to fix it. Guess what? You're buzzard food! If a developer doesn't know how to get under the hood of a WYSIWYG program and make repairs, the developer is at a significant disadvantage.

WYSIWYG software does not, by these measures, make access to Web development any easier. As a result, home-page enthusiasts and Web developers alike must seek out more and more resources to survive. This is part of the reason the Web is being gentrified—unless developers have the time, money, and resources to develop their slices of land, they can't or won't because the learning curve and expense are simply too high.

Here are some things that WYSIWYG users can do to mitigate problems inherent in using this software:

While all of this takes time, it reduces the potential for learning unnecessary information.

Energy and security

As if client-side issues weren't enough, the gentrification problem becomes more pronounced when we examine the server side. Having a simple form and linking to it is one thing, but managing advanced server concerns takes a deep understanding of what technologies are available, and how to use them.

Chats, message boards, auctions, games, dynamic generation of pages, globalization, secure transactions, customization processes—all of these demand, at the very least, a breadth of knowledge from the designer or project manager to make decisions about hosting, security, and choosing database-related technologies. Do you go with Perl/CGI, or Cold Fusion? Oracle or MySQL? Microsoft, UNIX, or Linux?

How does a simple guy who wants to set up a small storefront business with online ordering make decisions about which technologies are best for him? He'll either have to study intensely or hire someone to make the decisions for him, and hope that person does it right.

Does this mean he can't create a simple page and make a printable form? Fortunately, no, he can. But unfortunately, many of today's Web-site visitors won't give a simple site without secure transactions a second glance. Most Web users would rather visit a superstore around the virtual corner than deal with an inconvenient and disconcerting unknown entity. Our simple man can't really compete without significant resources to help his little storefront mimic a superstore, complete with all the advanced technology—and its price tag.

Here are some things you can do to learn more about how to choose and deliver appropriate server technologies:

Renters' rights

Some Web companies and communities are well aware of gentrification issues, and are helping the little people get online. While these communities should be applauded for offering wizards (see Figure 3), free Web space, and integrated technologies available with a few clicks of the mouse, there's a sobering problem associated with most of these offerings: control and ownership of content.

Figure 3. Site management tools on MSN.

When you sign up for most of these services, you get a lot of tools to help you. But as you sign in, you're asked to give personal information for demographic purposes. Then, you're told you need to categorize yourself into one of the groups predetermined by the provider. Be sure to read the terms of agreement pages very closely. You may see items like this:

"...reserves the right to remove at any time, without notice, any user-created communication service..."

"Pursuant to our privacy policy, we may disclose to third parties certain aggregate information contained in your registration data ..."

"We reserve the right to reproduce any material posted..."

While undeniably useful to people who need ease-of-entry and want a clean, well-lighted place to live, work, and play, these sites remind me of so-called "planned cities"—contained communities where individuals of common interest fell compelled to reside. Property, privacy, and ownership are vague, and an elusive external governing board makes the judgments.

Bring it on home

For home-page enthusiasts and small businesses, attraction to the Web's resources is being tempered by a raised bar of access. Technologists must develop sites based on commercial rather than personal values. In our rush to embrace and define technology that ultimately belongs to us, we must examine how we're developing our properties—philosophically and technologically.

Do we really need all of this stuff? I'm not saying we don't, but I am saying that before we build our next superstore, let's think about why we're doing it, streamline our code and our work process, and be absolutely sure to read the fine print before making decisions. The home we lose to gentrification may be our own.

All content Copyright © Molly E. Holzschlag. Molly® is a registered trademark of Molly.Com Inc.
Copyright Dunstan Orchard