Andrew Woods Seattle Web Developer

Application Architecture on Localhost

You’re ready to begin development on your project. Now what? Since you are a professional, you need to setup your environment not just a for a single project, but the many projects to come. Sure you could just create a folder on your desktop, and start hacking together an html file from scratch. but I’m gonna show you a better way. The solution I’m going to show you will use a local webserver. I’m using Apache, and you should be too. If you’re using PHP at all, you have to use a web server.

Filesystem Setup

It should be easy to get to, and easy to manage. Lets start by going to root of your filesystem either in Finder or the Terminal, and create a directory ‘www’. This will contain everything web related. In the ‘/www’ is where you begin to organize. I suggest by type first. Think for a minute about the kinds of things you’ll need – websites, log files, software from third parties like jQuery, Smarty, BluePrint – are a few of the basics. Create a directory to hold each of these type of information. ‘libs’ for the 3rd party libraries, ’sites’ to contain each of your client web projects, and ‘logs’ to hold the log files that are associated with each of your websites. So your structure should look like the following:
  • www
    • libs
      • php
      • js
      • css
      • sql
    • logs
    • sites
In the libs directory I suggest one more level of organization – language name. That way your PHP, Javascript, Ruby, and CSS all separate. Then the only other thing to do is to make sure you include the version number of any libraries you extract into here. e.g. /www/libs/{lang}/{software-1.0} Now you have one place on your system to store all your software libraries. When you create your website projects , copy the desired libraries to your /www/sites/{project} directory. In my ‘/www/sites’ directory, I use project names, which is typically the domain name minus the top-level domain. Generically it looks like ‘/www/sites/{projectname}’. So my Mastodon Labs project is in the directory ‘/www/sites/mastodonlabs’, which lives on the internet at mastodonlabs.com. If you know that you’ll have a client where you work on multiple projects, you could use the client name as a level of organization e.g. /www/sites/{clientname}/{projectname}. Now that your structure to for organizing projects is intact, what should go into the project? a folder for documentation, one for sql scripts, one for the website root, and one for your framework (if you use one). I use CodeIgniter
  • /www/sites/foobar
    • ci_system
    • docs
    • site
    • sql
You may be wondering why the directory ‘foobar’ isn’t the site root. There are multiple reasons. Most importantly, it’s a best practice not to have any config files in the document root of your website. This helps keep your website secure by design. Every framework has at least one, usually containing database information. So a user should never be able to visit a URL like http://foobar.com/system/config/database.ini.  While there are techniques to hide such directories, it’s just best not to put them in the document root. ‘docs’ is a good place to keep notes about the project, a list of things to do for the current project, special instructions, list of notes for the specific versions of the site. For projects that require a database, it’s also good to have a set of SQL scripts that build/modify your database structure. For that purpose, you use the ’sql’ directory. Since all these directories are contained in one project directory, it’ll be easy to manage them all in a version control system. We’ll talk about that in the next post, but for now, let’s focus on your Apachefgv configuration setup.

Apache Configuration

When Apache starts up, it parses it’s config file httpd.conf. On my mac (OS X 10.4), this is located at /etc/httpd/httpd.conf. While it’s possible to have all your configuration in one big file, I use a second file called vhosts.conf which is read in with an include statement. 
Include /etc/httpd/vhosts.conf
This file holds all the virtual hosts (read: websites) configurations on your machine. At its most basic, this file is responsible for mapping the url of the website to the corresponding directory in the filesystem. There’s a lot it you can put here, but for a simple websites this is all you need. When you’re doing your local development, you only need to worry about one hostname – localhost. You’re probably wondering “but how do we access more than one website?”. The answer is ports. By default, websites are served on Port 80. It’s possible to have your web server listen to more ports for requests.  If you want to listen to port 3000, you would put this statement in httpd.conf 
Listen 3000
This gets to you have way there. Now apache will listen to requests on that port. When it gets a request, what should happen? First add the following to your httpd.conf, if its not already in there. 
NameVirtualHost *
Now you need to tell it which virtual host you want to receive it. go to your vhosts.conf file and add the following lines: 
<VirtualHost *:3000>
    DocumentRoot /www/sites/foobar/site
    ErrorLog /www/logs/foobar/error.log
    CustomLog /www/logs/foobar/access.log common
</VirtualHost>
Now you just stop/start apache so that it reloads with your new configuration. Be aware that the /www/logs/foobar directory needs to exist before you restart Apache, otherwise Apache will not restart successfully and it will fail silently (you wont see an error message). Apache will create the log files if they don’t already exist. On my system, I use /usr/sbin/apachectl stop to shutdown the server, and use /usr/sbin/apachectl start to start it up. Thats it. Now  you see your website in your browser when you load http://localhost:3000 Happy Computing!

Accessibility Affects Everyone

“An accessible web page makes all content available to any human user who wants it regardless of browsing technology.” – WebAxe In your browsing experience on the web, you may have heard the word ‘accessibility’ mentioned. If you did a quick web search, you saw that it was to help people who are disabled access the web.  That is true and it’s still a primary driver, but the benefits of accessibility affect everyone. One example is phone numbers. Marketing people like to use words, substituting letters for digits, in their phone numbers. So you might see “1 800-your-mom” instead of  “1 800 968-7666″.  They do this for 2 reasons. First, people are better remembering words than numbers. Second, it helps with their branding.  The convention is based on the original rotary phones, and then touch tone phones.  It was useful in years past, but its quickly becoming an outdated strategy. As more people use mobile devices with full QWERTY keyboards, the letters no longer matchup with the digits, and the solution becomes inaccessible.

Everybody needs access

I agree that disabled people have been treated as second class citizens on the web. Sometimes, not considered at all. There has been some forward progress thanks to the web standards crowd through the use of alternate stylesheets, semantic markup, and considering whether someone could use their design with a screen reader.  With that said, to sell accessibility as a way to assist disabled people sometimes does more harm than good for the cause (increasing adoption of accessible design). Most people don’t identify with the disabled community, unless they happen to know someone. In fact, its not even on the radar for most businesses. So when it comes to their company website, accessibility is not considered during the website design process. But if it were, it wouldn’t cost that much to add it. Adding it afterward, just like security, is always a more expensive process. If you discuss accessibility in terms of the non-disabled users, it’s likely businesses will see the value more readily. As a result, the disabled users get what they need.

Data from a U.S. Census Press Release

In a press release titled “More Than 50 Million Americans Report Some Level of Disability” released May 12, 2006, The U.S. Census Bureau provided a number of important statistics. Below is a quote from that report. “About 18 percent of Americans in 2002 said they had a disability, and 12 percent had a severe disability, according to a report released today by the U.S. Census Bureau. Among people with disabilities, more than half of those 21 to 64 years old had a job, more than 4-in-10 of those ages 15 to 64 used a computer at home and a quarter of those age 25 to 64 had a college degree.” Perhaps this will get businesses addressing accessibility as a primary concern, if for no other reason than that it could increase their bottom line. Here’s to hoping.

Mobile Edition

This morning I’ve launched the mobile edition of AndrewWoods.net However, it doesn’t include this blog. That’s for a future time. :) In keeping with the One Web idea, I’m using the same url but a different layout. I chose this method, because it complies with the DRY principle, it made it easier/faster to develop, and its more cost effective since i’m not using a separate hosting account for a mobile site. The difficulty to mobile web development is that you need to test a wide variety of devices. Acquiring such devices can get expensive depending on how many you’re developing for. Some developers, and even companies, make sites to cater to iPhone or Blackberry and call it a day. I’m using a Palm Treo 700p, and limiting my development to Palm Devices would be bad, given the small audience. More importantly though, I want everyone to be able to use my websites. So, I have a request. If you have mobile browser on your phone, could you send me some screenshots of what different pages on AndrewWoods.net look like, in the next day or so? Here’s an example of a screenshot from my hiragana project. I’d greatly appreciate it. If you’re a web developer that makes mobile sites, I’d love to hear any tips you might have.

Mystery In The UK

I’m currently working on a webapp that will allow every country to participate. the content is locally consumed. I’m attempting to build a database to hold all the information, in a structured way. I’m confused by the  country relationships of the UK. I’m in the USA, so I’m not sure what the typical experience is for a UK citizen. There are four countries: England, Wales, Scotland, and North Ireland. These four countries, have formed an entity called “United Kingdom”, or UK for short.  Plain old ‘Ireland’ is a separate country. There is another entity called “Great Britian”, which refers to the countries England, Wales, and Scotland (source: DirectGov).  There’s an organization ISO that maintains global standards. One of the standards is ISO 3166-2, which is a list of country names, and their 2 character abbreviations. Looking at this list of country codes and names, the United Kingdom has the code of ‘GB’. Huh?  More confusingly, the countries England, Wales, Scotland, and North Ireland are all without their own 2 character codes. I guess the real question is “Who’s on first?“. Let’s hold off on that issue for a moment, and look back to my original problem. I’m unclear as to how I should model the relationship between the UK, the individual countries of the UK, and their cities. Let me give you an example. I live the United States, in the state of Washington(WA), in the city of Seattle. So my record would be like this: country=US, state=WA, city=Seattle. Given that, lets do an example for London. Three examples come to mind. The first captures the most information: country=UK, state=England, city=London. This one is appealing as it captures the most information in an existing structure. The second just removes England from the state field: country=UK, state=null, city=London. The third uses England for the country country=England, state=null, city=London. I’m considering this one because I know that England is a country, so it’s technically correct. Do people who live in the UK, look on web forms for UK, then their own specific country? Or do they look for their specific country, then UK? What’s the convention most users expect? Is there another territorial breakdown I’ve missed?  I know of postal codes. I appreciate any feedback you can provide. UPDATE 2009-FEB-21: Everybody’s feedback was very helpful, particularly Gary Gale (@vicchi) who just happens to be Head of UK Engineering at Yahoo Geo Technologies (@yahoogeo). Let’s recap of the things I’ve learned. First ‘United Kingdom’ is what users search for. It’s also the name that appears in the ISO 3166 list. So I can safely use it. Second, people never look for things by their individual country (England, Scotland, etc) – partly because of the previous point, and partly because postcodes are so informative, they can be used to pre-populate other fields like city and county. Third, the ‘county’ is what people typically use to filter things.  There are actually two sets of county information – administrative and postal. The web apps I’m writing are for people and not the government, so I’m going to use the postal counties. In summary, Mr Gale said “if you’re designing a web based mechanism for addresses you’d use the country, the county and the town followed by the street address and our Postal Code, the equivalent of the US ZIP”. Nice! Pragmatic and simple. Thanks again everyone. It’s been illuminating.

Architecting Your Dev Environment

Every web developer has a particular way of working. This can be anything from using particular software applications, to storyboarding with construction paper, to drawing diagrams on paper napkins at their favorite local cafe. Whatever it may be, they learned at some point in their experience as a developer, that their technique works. But if you’re new to the business, you have nothing to draw from. So these next few posts are targeted to the newcomer. However, if you’ve been around for a while, you might learn a trick or two, that you can add to your own tool belt. The following is a list of the upcoming titles in this series
  • Application Architecture on Localhost
  • Source Code Control Architecture
  • Hosting Architecture
Foreach of the items in the list above, I will discuss the technical aspects of setting up your environment. Setting things up the first time will seem like a lot of work. but every additional project will be very easy to set up, once you have the blue print. There are few technical constraints, as most of these concepts apply across environments. I am on a Mac OS X machine, so all command line items will use BSD syntax using the Bash shell. I’m approaching this from the perspective of a LAMP developer. PHP 5 is my language of choice. Application Architecture on Localhost This segment will give you a practical, scalable structure that will keep things organized. Also, you’ll be given some very useful bits for configuring your Apache server, as to how it relates to your day-to-day.  I’ll try to ensure that you get all the essential, plus a couple of cool bits. Source Code Control Architecture If you’re new to web development, you might need an introduction. However, that’s already been covered by many people smarter than myself. What I’ll give you are suggestions/strategies on how you might make the best of organizing your strategies. Hosting Architecture So you’ve got a working a site on your local box. Your next step is to put in on your hosting environment. You’ll need a staging environment, so you can let other people test your code, have clients preview updates that you’ve worked on. the things you learn for the staging environment, can also be applied in your production environment. Stay tuned, as I plan to write a post every few days. NOTE: As each post is written, I’ll update this one to link to it.

Brightkite

I’ve been using Brightkite for a while now. If you’re not familiar with it, Brightkite is a location-based mobile social networking site. What does that mean? you ask. It’s like Twitter, but it keeps track of where you posted from. If you haven’t tried it yet, I suggest you try it. I’d love to hear your thoughts. For now, I’ll give you mine. The great thing about Brightkite is that you can meet people based on where you are. Someone that you might have never met is now within reach just because you both use the same service. This is the advantage is has over Twitter. However, the userbase needs to be increased dramatically to enhance the interestingness. If they can accomplish this, then you’ll meet others who are currently checked in nearby, as opposed to a few days later. This happens to me quite a bit – where I’ll see someone of interest who posted, but the post is dated from several days ago. The folks at BrightKite have done some great things with their web application .
  1. Map view of your friends. They display where your friends are checked in on a google map. This is great when you don’t recognize the street names and when you want to get a quick sense of where they are in relation to each other.
  2. Privacy Control. You may not want everyone on the internet to know where you are all the time. Brightkite has built-in some controls to manage your privacy. They let you mark which friends are trusted. Those are the people who can see your exact location all the time. There are also just normal friends. Below your menu, is a privacy switch. When set to public, everyone can see your location and posts at full accuracy. When set to private, strangers see your checkins at the city level but no posts, your normal friends can see your checkins and posts at the city level, and your trusted friends get to see your checkins and posts at full accuracy.
  3. Sharing with other sites. Under “Account Settings” there is a sharing tab. It identifies other sites that you can send your brightkite information to. Currently they support Twitter and Fire Eagle. I’ve never looked at Fire Eagle, but I’m actively using the Twitter sharing. Brightkite sends my info to Twitter when I post a note or photo. I did for a while also send my check-ins but that has zero value to a Twitter user, imho.
There are some things that I would change. Lets call them opportunities for improvement.
  1. Email interface for photo uploads. Brightkite assigns a unique email address to you. They instruct you to send your photo to that unique address. A simple as email is , sending photos to brightkite doesn’t work for me. the mobile version of gmail doesn’t allow you to send attachments. It’s just not available. You can make the argument that this is a gmail problem. Never the less, I’m still not able to post photos from my mobile. If Brightkite had a file upload on their site for uploading photos, this would be a non-issue.
  2. Placemark names not utilized fully. Placemarks are used to identify places that you go to often, and allows you to assign a nickname to it. The nick names are not used when you check into a place that doesn’t already have a name, like an intersection. For example I might have an address of “9th & Pine, Seattle, WA, 98101″ with a nickname of “Bus stop at Paramount”. When I write a post from that location you will only see the address. I think it would improve the user experience to use the nickname as well.
  3. Streamline the interface. Do a place search and enter a business name. If you want to check in at one of the places, you need to click the name. On the new page click the “Check In Here” button. It would be great though if I were able to click “check in here” from the search result. The “visited places” and “place marks” both have that functionality. So why I cant I have it here too. Another thing that bugs me is all have very different looking listings. If they could bring them in line with one another, it’d reduce the time it takes the learn the web app.
  4. Symbols. One symbol that you see alot of brightkite is an orange circle icon with a white ‘X’ in the middle. Other applications, outside of brightkite, have taught us that an ‘X’ in a icon means close or delete. So when I see that icon in the placemarks listing, I’m thinking that I can delete the item by clicking the orange circle icon. It will actually bring you to the place stream for the location. That’s confusing to me, and probably to others too. I’d like to see brightkite use the lime green trapezoid in their logo, as that is the placemark icon. It would have a couple of benefits – the ‘kite’ icon doesn’t have any external meanings like the ‘circle with an x’ icon, and it strengthen the association of your location with BrightKite.
  5. Editing Placemarks. There is no way to edit a placemark. Many placemark redisplay the address as the name. So, when you checkin and post a note from that location, the address is written out twice. People like names, computers like addresses. That’s a lesson we’ve already learned with DNS. So, I’d like to be able edit the placemark name so that everybody can benefit from it. Also, people make mistakes and there’s no way on brightkite currently to correct them. This alone should be enough to add in the ability to edit.
I’d love to hear what you think.

Chromed Site Menu

One aspect of website development that has been redesigned over and over again is navigation. As time has progressed, web designers have battled multiple issues – usability, accessbility, client preferences (I want it look just like Amazon’s), tradition (other sites do it “this way”), cool factors. But what if you the designer never had to design another navigation? How cool would that be? Very, you say?! That’s what I thought. In short, my idea is to put your website menu in the browser chrome. The browser chrome, as defined by Urban Dictionary, is “a euphemism for the graphic control elements of your browser interface.” It would work like this: The webdesigner would create an XML file in the root of the website called ’sitemenu.xml’. The browser knows to where to look for the sitemenu.xml. It finds the xml file, parses it, and generates the nodes in the toolbar menu under ‘Site’. The toolbar menu is the same one that has File, Edit, and Bookmarks. So this means that the contents of the Site menu are dependent upon the website in the browser window. Why would we want to do that? you might ask. Well, there are several reasons:
  1. Web Designers would spend their valuable time on other aspects of the site
  2. Accessibility would become a non-issue:
    • Anyone using a screen reader already knows how to use there application menus.
    • Usability is increased since the user doesn’t need to relearn the navigation style for that website
  3. There’s now more room for the content without the navigation consuming space on the page.
    • Reduced Page Size – A good thing for the mobile environment, since currently subscribers have to pay for the data charges.
    • Can be cached for browsing multiple pages on the same site.
  4. It would work identically on your mobile browser as it does on your desktop
Can this actually work, you say? Sure! Why not? All the pieces are available. Google already uses a similar idea for crawling your site. Browsers are already doing something similar with a favicon (the image that shows up when you bookmark a site). There are challenges ahead, to be sure. The biggest one is browser adoption. Theoretically, I could create the optimal XML file and associated DTD, give it to Opera and Mozilla, and they’d have it implemented in a fortnight or two. However, Microsoft would probably get around to it with IE9 because between this day and that, they would create a slightly different implementation that they would force upon the development community. Then there’s the mobile browser manufacturers. The fragmentation in the mobile community is great. With the numerous mobile browser manufacturers out there , It could take years for them all to catch up. Like I said before – there are challenges ahead. However, I still think it can work.

Email Standards

I came across a site promoting “Email Standards”. It sounded like a good idea so I checked it out. What they are actually talking about is applying Web Standards to email, which is something entirely different. Web standards is about making web content available to everyone in a consistent way. This is partially achieved by writing well-formed valid (x)html documents to deliver the content, and keeping presentation separate by using CSS. So this group wants to bring this methodology that has rendered benefits to developers and users alike to the email experience. If the web development community is interested in using the existing email standards, they would see their work is already done. “Really? Tell me more!“, you say. Think about the word document you sent to your boss, or the photos you sent your friends. That was made possible by a technology called MIME, that every email client understands. Now imagine that file is an HTML document that you’ve designed using web standards, complete with unobstrusive javascript and CSS. Your customer clicks on it, and it opens in their favorite web browser. It displays perfectly. But what about displaying my HTML page in the message of the email? The fact that it works at all is amazing, and not in a good way. The incompatibility issue is not a small one. Lets say its 2017 (10 years from now), and the email vendors got on board with the whole “email standards” campaign of injecting HTML into email messages, and its been completed successfully. What does that get you? Not much. Because to move forward, all the email vendors standardized on xhtml 1.1 (the current standard of 2007), but in 2017 the standard is xhtml 5.3. If MIME is used to deliver the HTML content, this becomes a non-issue. So instead of campaigning to inject web standards into email, lets push for keeping the web standards on the web.

One document to rule them all ?

Some say that its best to have one document to serve all audiences. Jeffrey Zeldman wrote about this idea in his book “Designing with Web Standards” While it’s a nice thought, and simplifies things for developers, it doesn’t work all the time. Now I’m not trying to go head-to-head with the Big Z, but rather I’m trying to my best to provide an optimal experience for a mobile user. Think about a news site like CNN. It’s not uncommon to see a related video or some large images on a page, next to the story. If I went to that same site on my Palm Treo, I’d download all that media because it’s part of the markup. That’s unfair to the mobile user, since most cant view it. That’s especially true for those who pay for the data beyond what their wireless service contracts allow. I’ve tried changing the setting on my treo to not download images. But what really happens is they seem to get downloaded anyway, but not displayed. Now I’m not complaining (well maybe just a little), but I think that it’s currently not feasible at the moment. As I mentioned in my post for the Engadget to Palm blog entry, the mobile stylesheet doesn’t work on my treo when a screen style sheet is available. But lets pretend it did work. Would doing tricks like display:none in a style sheet be enough for mobile users. From what I’ve read lately some screen readers don’t respect display:none. Another approach is to serve a separate set of files. Each of the sites in my top 5, use this approach and it works well for them. We the users get a better experience because of it. I’m sure the developers of these sites are reusing most of their code from the main website. Sure, it’s a little extra work to maintain, but nowhere close to building another full scale website. So what’s the harm?

Figuring out the Mobile Web

I rediscovered a blog posting from Cameron Moll about the development of the Mobile web. Its from 2005, but it still makes sense. As a few people mentioned, the U.S. is far behind in the mobile web development from. So this blog posting will likely be ironically timely for us in the U.S. BTW, he just wrote a book on mobile web development.I’d like to start my contribution by listing my top 5 best mobile sites. The list contains the sites that give me the best experience on my Palm Treo 700p. The links in this list point to the mobile sites and should be viewed on your PDA
  1. Fandango – a movie listing site
  2. The Weather channel – Provides local weather (and so much more) information based on your zipcode.
  3. ABC news - A major US television network
  4. GMail – Mobile version of Google’s Mail client.
  5. The Onion – A satirical news site.
As part of my education for mobile development, I’ve added a mobile style sheet to my personal website.  Mobile development is more than just adding a style sheet. It’s also about using the markup effectively. One idea that was very useful was the Leahy/Landridge image replacement technique. This allowed me to use the heading tags so all clients can access that markup. I then applied the technique in my css file for desktop users, and used simple styling for the mobile users. This way, the mobile user still gets a nice experience without the extra download. I’m interested in what techniques have worked for you. So if you have one you’d like to share, let me know.