Is it a conflict of interest to publish a blog about proper web design techniques in blogger? I can't deal with this theme anymore. I'm off to hack up Typo to do what I want...hope to be back soon, most likely at http://www.ericdelabar.com/
I recently finished a "Members" section of a website for a local non-profit. The primary user base was small, (less than 100) so I didn't spend a lot of time on building a robust user management system. Basically, a user would access the site, request a login by entering a username, password, confirm password, first name, last name, phone number, and email. After which an admin user (i.e. yours truly) would be notified, log in to the site and approve the account if they knew the user.
Here's where it gets interesting. Of the 10 users that have signed up so far, 5 of them have used a space character in their username. Is it a problem? No, not in this instance, but I found it to be interesting user behavior. I personally have not tried to use a space in a username in as long as I can remember, but I can't tell you why. I would assume that a long time ago when I created my first online account, (an AOL screenname if I remember correctly) a space was simply not allowed.
So what's the point? Simple; users do things you may not expect, and you may not expect things for not-so-valid reasons. (Face it, how AOL did things in the mid 90's is probably not a best practice.)
On a related note, 3 of the 5 members who used a space character in their name have already "forgotten" their username; they actually didn't forget it, they just misunderstood the username field to be a full name field, and simply entered their full name on the registration form, and then didn't know what to enter in the login form. So, the next build of this site will feature much more descriptive, cork'd-like forms, in hopes of solving these problems in the future.
While there's no substitute for learning something by first making all of the mistakes, it doesn't hurt to learn from somebody else's. In today's issue, we're going to talk about absolute positioning.
absolute
Eric A. Meyer. Cascading Style Sheets 2.0 Programmer's Reference.
The element's box is laid out in relation to its containing block, and is entirely removed from the normal flow of the document. The containing block of the absolutely positioned element is the nearest ancestor element with apositionother thanstatic. If no such ancestor exists, then the containing block is the root element of the document.California: Osborne/McGraw-Hill, 2001.
In truth, the solution was in front of my face the entire time, I just never understood it! (Or possibly I just skimmed the paragraph and only read the first sentence, but that's a different issue altogether!) The problem I was seeing was that my absolutely positioned (position: absolute; top: 0; left: 0;) element was appearing in the upper left of the viewport, not the upper left of its containing element.
The simple solution was just to set the position property of my containing element to relative. This is a valid solution because a relatively positioned element behaves exactly like a statically positioned element, except that the position properties (top, right, bottom, and left) are used to offset the element by the specified amount. So, as long as the position properties are left with their default values, to make a container element, all you need is position: relative.
Continuing our thread on tools, we're now going to have a look at setting up a simple test server environment.
As I explained last time, I typically develop on a Windows and Linux, so I prefer a tool that works well on both platforms. Coming from a Java development background, there is one tool that meets this requirement, and more; and as you may or may not know, works with more than just Java. That tool is of course, the Eclipse Framework, a Java-based development platform.
Out of the box, Eclipse provides the hooks necessary to support helpful features such as syntax highlighting and code-completion; with the help of a variety of plug-ins you can very easily enable these features for Ruby, PHP, Perl, C, or pretty much whatever language you prefer to develop in. For this tutorial, we're just going to get the basic HTML, CSS, and JavaScript editors installed and configured.
Start off by downloading the latest version of the Eclipse Framework, at the time of this writing, that was 3.2.2. To install it, simply unzip it to your hard drive; to make your life easier, drop it in the root of a drive (i.e. c:\). (Make sure you have a JDK/JRE installed, if you don't, grab the latest from Sun.) Once installed, start it up by running eclipse.exe (just press OK at the Workspace Launcher prompt for now) and go directly to the Help > Software Updates > Find and Install... menu. Select the Search for new features to install radio button and press Next >. Check the box to search the Callisto Discovery Site and press Finished. On the next screen, expand the Callisto Discovery Site node, and then expand the Web and J2EE Development node. Check the box for the following nodes:
Read and accept the license agreements and press Next >. Press the Finish button, and let it do its thing. If you receive a Verification window, press the Install All button. When prompted to restart Eclipse, select cancel, and close Eclipse. Congratulations, Eclipse is installed and now we're ready to install Apache HTTP Server.
You may be wondering why it's necessary to install an HTTP server when you can open an HTML file directly from the file system in most browsers. The simple answer is because this is a development environment and the code you produce locally should run on the server without modification. With some site file system layouts, paths, such as those to images or stylesheets, may be different on the server compared to your local machine, especially if using URL rewriting techniques. As a benefit for more advanced users, you can also configure apache to run PHP, Perl, or the server side language of your choice. Now, back to our tutorial.
First, download the latest version of Apache. (We're assuming you're on Windows here, if you're using an alternative OS, this exercise is left to you...) At the time of this writing, the best version is 2.2.4 and Win32 Binary (MSI Installer) is probably the easiest to deal with. After it's downloaded, run the installer. The install process is pretty standard; for server information you probably want to use localhost for your Network Domain, unless your desktop has a fully qualified domain name, and your machine name for Server Name, on the Server Information screen. From that point, the Typical install will probably do just fine. When it's finished, Apache will be conveniently started, and you'll be ready to move on. To test your result, load up a browser and check out: http://localhost/; if it worked, your browser will display an oh-so-descriptive page stating "It works!" Now that you have a working web server, let's create a convenient shortcut to open Eclipse in the htdocs directory of Apache.
Browse to your Eclipse install directory (probably something like: c:\eclipse) and right-click on eclipse.exe. Choose Create Shortcut from the context menu. Rename it to "Apache HTTP Server Workspace" and drag it someplace convenient (like your desktop.) Right click on the Shortcut and change the Target field to look something like this: C:\eclipse\eclipse.exe -data "C:\Program Files\Apache Software Foundation\Apache2.2\htdocs", where the italic text is replaced by your Eclipse install directory and Apache install directory respectively. Press OK to save your changes. Now start up Eclipse by running your new shortcut, and you should not be prompted to choose a Workspace. Congratulations, Eclipse is now configured, now let's get a project setup and give a quick tour of the Eclipse functionality.
To clear the Welcome screen, press the "X" on the Welcome tab at the top of the screen. By default, you'll be setup in the Jave Perspective, this won't be of much help unless you're a Java developer, so choose the Window > Open Perspective > Other... menu. Choose the Resource perspective from the list and press OK. The screen layout will change and should now show the Navigator, Outline, and Tasks views (counter-clockwise from upper left.) Right click on the Navigator view, and select New > Project... from the context menu. From the Wizards tree, expand Web, and select Static Web Project and press the Next > button. In the project name box, type an appropriate name for your current project, in this example we'll use demo, and press Finish. A new folder will appear in the Navigator view and inside of it will be a variety of folders and files, don't worry too much about any of them, but you can get rid of the "WebContent" directory. This directory is now a subdirectory off of your localhost root directory (i.e. http://localhost/demo/.) Just to verify, create a new HTML document named index.html (Hint: try the New context menu off of the "demo" folder in the Navigator view view again) and paste the HTML from my second article into that file. Next, load it up and the server and inspect your handy work! (Try: http://localhost/demo/, it's an oh-so-exciting blank page with a title. Hooray!)
That's it! In my next article, I'll take a look at setting up a simple directory structure and making more than just an empty web page.
After my last post, we have a nice, clean starting point for our website. Which is great, but in order to take it to the next level, we should probably get a nice development environment up and running.
First, we'll start with the client side. At Trifecta, we develop entirely on Windows. In my spare time, I have a Gentoo (soon to be Ubuntu) Linux box at home. Because of these factors, my tools of choice tend to be cross platform. As far as browsers go, I develop strictly in Firefox due to its ease of debugging with tons of useful plug-ins (Firebug, Web Developer Toolbar, DOM Inspector) and cross-platform availability. I of course have IE at work; where I've switched totally to IE 7, and I run the free IE 6 VM provided by Microsoft for testing in IE 6. I also have access to a Mac running Safari, a variety of Windows Mobile smart phones, and a few versions of Opera, including the Wii Beta version. Do I cover all of my bases? Probably not, but I'm at least over 95% of the user base.
What I really want to talk about are the Firefox plug-ins I mentioned earlier; if these tools are used correctly, a properly coded site that works in Firefox works just about everywhere else as well. To start off, make sure that when you first install Firefox, the DOM Inspector is installed. To do this, on the "Setup Type" screen, choose Custom, and on the "Choose Optional Components" screen, make sure the "DOM Inspector" check box is checked:
Ok, now we're ready for plugins! My current must haves are as follows:
If you're still stuck in IE land, there's still hope, Microsoft has released a half-decent copycat Web Developer Toolbar, and there's hope for their (Java)Script debugger. If you have a Genuine Advantage copy of Windows it won't hurt to try them out.
That's it! Get those installed, play with them, and tune in next time for part 2, where we setup Eclipse and Apache as a test web server on Windows.
Alright, in the beginning there wasn't DOCTYPE, it didn't come along until about the time XHTML was released; however, if you want to do the Web 2.0 thing right, it helps to start on a solid base.
My goal here is to get a brand-new HTML document up and running as a good base for designing a Web 2.0 application. Today, we'll look at the parts of a document that the typical user doesn't actually see, but play a huge role in how a user finds your site and how it's actually rendered on their screen.
First things first; make your DOCTYPE the first line of the file. That's right, line number one, no XML definition, no spaces, no server-side code, the first line of the file. This ensures that you don't end up in quirks mode accidentally. Now, as far as DOCTYPE's go, I really only see two options, HTML 4.01 Strict and XHTML 1.0 Strict. There are theoretically valid arguments for not using XHTML, most of which have to do with the simple fact that most web servers don't serve it as XML and most browsers don't read it as XML, but that's a different article for a different day. Today, we're using XHTML 1.0 Strict because the client insists that we use the latest technology regardless of whether or not it's appropriate; so this is what the DOCTYPE definition for XHTML 1.0 Strict looks like:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"">
Remember, that's the very first line of your file!
Next, let's get the basic xhtml in there:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8"/>
</head>
<body>
</body>
</html>
Next, let's get some very basic SEO framework in there and add some meta elements. Meta elements are sometimes called meta tags, but since we're working in an XHTML document we'll use the XML terminology. We'll use description and keywords, and throw author in the for good taste.
<meta name="keywords"
content="page, site, title, keyword, doctype"/>
<meta name="author"
content="Eric DeLabar"/>
<meta name="description"
content="A short description of the page content."/>
Great, now there's a place for keywords and a description, but why do we need them? Keywords are old-school, I don't even know if modern crawlers still look at them, but I do know that like all meta elements they should be specific for the page you're writing them for. So, as a means of guiding my SEO, I usually choose the 5-10 keywords that I want to apply to my current page, then make sure that as I'm writing the page copy I use those keywords.
The description meta element is slightly different, because it's visibly used. It is displayed by some search engines as a description of your page when it occurs as a result. As a guide to writing a description, keep it short, around 128-256 characters. Keep in mind that if it's too long it will most likely by truncated, so just write a sentence describing the current page.
Now, we'll have a look at the page title:
<title> Descriptive Page Title - EricDeLabar.com</title>
Like the meta description, the title element is displayed as part of a search result list, so a descriptive title can be very helpful for drawing users into your site. Some SEO experts also believe that keywords in your title are more heavily weighted in search rankings. Keep the title shorter than your description, and maybe consider including your branding at the end. I like the branding at the end because if it does get truncated by the search engine more of my more important descriptive title is displayed.
Finally, let's add the stylesheets:
<link rel="stylesheet" type="text/css"
href="/style/screen.css" media="screen"/>
<!-- [if lte IE 6]>
<link rel="stylesheet" type="text/css"
href="/style/iefix_screen.css" media="screen"/>
<![endif]-->
Now I'm a bit of a purist, and I'll have a later post describing my process for styling a page, but notice for now, I usually have a minimum of two stylesheets. The first being a clean stylesheet (as in NO Hacks/Filters/Whatever you like to call them) that handles all of the (mostly) standards complaint browsers, then an Internet Explorer conditional comment for handling older versions of IE. In this case, my iefix stylesheet is for lte IE 6 which translates to Less than or equal to Internet Explorer 6.
Notice that the iefix stylesheet comes after the other stylesheet(s), this is so that any rules in the iefix stylesheet with equal or greater CSS specificity will overwrite the rules in the standard stylesheet. (More on specificity in a later post.)
That's it! Congratulations, you have a nice, clean base to start your web 2.0 website on! If you're curious, the finished product looks something like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8"/>
<meta name="keywords"
content="page, site, title, keyword, doctype"/>
<meta name="author"
content="Eric DeLabar"/>
<meta name="description"
content="A short description of the page content."/>
<title> Descriptive Page Title - EricDeLabar.com</title>
<link rel="stylesheet" type="text/css"
href="/style/screen.css" media="screen"/>
<!-- [if lte IE 6]>
<link rel="stylesheet" type="text/css"
href="/style/iefix_screen.css" media="screen"/>
<![endif]-->
</head>
<body>
</body>
</html>
First, a separation of church and state. I did not coin the term Web 2.0, and I have no particular feelings towards it (either for or against.) What I do feel is that the idea of Web 2.0 has put a few very important issues onto the map.
This blog aims to discuss these issues and more from a technical aspect. I hope to provided tutorials, insights, and best practices for front-end development; but where necessary, back-end code will be provided in either Ruby-on-Rails or Java.
So that's it, let's see where it goes from here!
