More fun with JavaScript - HTML Events, HTML5, and AJAX

I talked a lot in my last post about Javascript. Continuing on that idea, I'd like to talk about DOM (Document Object Model) events. DOM events are triggers in HTML documents that allow scripting languages like JavaScript to execute functions when something hapens, such as when a user clicks on a button. User-interactive web pages would not be possible without the use of DOM Events. Not all events center around users though, as there are also DOM events that trigger when the page or an object page loads, unloads, or fails to load.  To get a full list of DOM events, as well as an understanding of the way event models are interpreted in browsers, check out this Wikipedia article.

Click Here for a live demo

My last post used the onKeyUp DOM event to trigger a Javascript function that calculated the cost of a number of items. The code in the picture to the right changes the text inside a textbox when the user selects (highlights) the text inside the box.  Client-side scripts (scripts that execute in the user's browser rather than on the web server) aren't the only use of DOM events though. You can also launch server-side functions by triggering a postback (causing all or part of the page to reload) using the __doPostBack() method.

The issue with using __doPostBack() method is that it causes the page to reload, which interferes with the user's display. AJAX allows us to get around that by doing asynchronous updates, or updates independent of page loads. AJAX is a name that you hear a lot in the development world. It's actually an acronym that means Asynchronous Javascript and XML. It works by using Javascript to access DOM events and the XMLHttpRequest object to access data. While AJAX is often referred to as a single technology, it is actually a combination of HTML, XML, Javascript, CSS, JSON, and other technologies.  You can learn more about AJAX and the underlying technologies it uses in this Wikipedia article.

As someone who develops a lot of data driven applications, I make pretty heavy use of tools developed using AJAX, such as the ASP.NET AJAX Controls Toolkit. I've also supported projects implemented using Telerik RadControls as well as those using Infragistics ASP.NET Controls. All of these tools offer methods to asynchroneously access data and server side functions without reloading entire pages.

In addition to providing key functionality in AJAX, Javascript is one of key components that make new features in HTML 5 and CSS3 possible. In fact, many developers use toolkits developed using Javascript such as modernizr to support older browsers when they implement those features.

I hope you can get a feel from this article about the important role that Javascript plays in web development today. It allows developers like myself, as well as designers to create web sites that are attractive and rich with both data access and user-interactive features. In the eighteen years since its creation in 1995, I would argue that few technologies have had as large of an impact on web development and the internet as a whole as Javascript.

Building a simple javascript calculator

View A live demo

I got a little restless tonight, and put together a pretty simple Javascript calculator as a refresher for myself.  For those that don't know, Javascript is a scripting language used to add some programming functionality to web pages.  It's very useful, and easy to learn. It can be used for anything from simple calculators to replicating HTML5 and CSS3 features on older browsers. While I mainly build applications that rely on server side programming, like asp.net, they still often rely on Ajax controls that require Javascript.

In this case, I built a calculator that multiples a number of items purchased by the cost per item to report the total cost to the consumer.  Simple features like this are easy to build and add to your web site. In fact, one of the very first development projects I worked on was modifying an amortization calculator on a real estate agent's website. That was during an internship in high school almost ten years ago. Calculators are also easy to build using server side languages, but it requires the page to reload, which is an unnecessary annoyance to the user and wastes server resources. This is especially true if you have large pages that take a while to load.

Anyways, here's the code:

The bulk of the work is done in the script section, in a function called total(). A funtion is a section of code that can be called by the script. Splitting code into functions makes it easy to reuse, and in this case, easy to call from one or more html events. The total() function reads the value in the text boxes and converts them to type of number called a float, which is a decimal value. If either value contains non-numeric characters (letters or symbols), the total is returned as $0.

The function is launched using the onKeyUp event in the textbox controls, which is an HTML event that triggers whenever a user releases a key on their keyboard while the HTML object (in this case a textbox) has focus (the mouse cursor is set to the object). This means that anytime the user types into either of the first two textboxes, the page will run the script and automatically change the total as the user types.

If you'd like to learn more about Javascript, checkout the w3c's free tutorial here: http://www.w3schools.com/js/default.asp

Should I buy more domains to help promote my site?

I get asked this quite a bit. The answer depends a lot on what the intended use is.

Usually, the logic I hear goes something like this:

I have one website and one domain name. So Google, only looks at me once. If I had one website and five domains all pointing to the same site, Google would look at me five times, so I'd get five spots on a search page and push some of my competitors further down the list.

The problem with that scenario is that part of your page ranking is how often people actually visit your domain. By default, domain redirects use a 302 (temporary) redirect code, which tells search engines like Google to log the hit for the first domain, but display the domain that it's redirecting to. So, by splitting your site into five domains, you're also splitting your page ranking among those five domains, but not necessarily evenly.

Now when Google indexes your site, they don't see one awesome site with a ton of visitors, they see five awesome sites with a moderate amount of visitors each, and rank all five lower than they would have ranked just the one with all those hits.  You can tell search providers to log all of the hits/visitors for one domain by manually setting the redirects to use a 301 (permanent) redirect. So now all of your visits are in one basket, and that page domain gets ranked higher.  The problem there is that the other domains are virtually ignored, so they aren't going to meet the stated purpose of bumping competitors down.
 
So is it worth the effort?

If your goal was just to bump a competitor down a page or two in search pages, I'd say no. It's not likely to work, and even if it did, it would reflect poorly on you for your customers to see that you basically spammed a search engine.  Not to mention that your competitor could just buy more domains and do the same to you.

There are, however, times when it makes sense to use multiple domains and/or redirects to help build legitimate traffic and boost your rankings. Before I get started, if you're unsure about all the 301 vs 302 talk, it's ok. You can always contact you hosting provider and ask them to set it for you.  I also want to point out that I don't have any affiliation with any of the example domains (real or not) used nor am I attempting to promote them in an way.

• If you recently changed domains
  
  You want all your old visitors to follow you seamlessly, and you want to keep the page rankings you built up with the old domain instead of starting from scratch. Keep your old domain and use a 301 direct to your new site from the old. You'll have to keep paying for the old name until users learn the new site, but it's usually not as expensive as re-marketing to them.


• If the new domain name is something potential visitors are very likely to search for
  
  For instance, if I ran jakeshammers.com, it might make sense to also buy cheaphammers.com (looks like someone actually beat me to it) or awesomehammers.com. I've only seen one or two cases this made sense. Cnet.com for instance also promote themselves as download.com using redirects. Download.com is just such an obvious domain to use that it makes sense. For most people though, this isn't likely to be a huge money maker, so I wouldn't recommend going crazy with a bunch of domains. 301 redirects would probably make more sense here, unless you wanted to promote yourself under the new domains. In that case, you can use a 302 redirect. Just don't expect super high rankings for either domain.


• If you want to protect your brand name
  
  For instance, I might buy jakeshammers.net, jakeshammers.info, jakeshammers.me, etc. to prevent spammers and scammers from posing as me to take advantage of my customers.


• If you want to promote a specific product
  
  Let's say my company is famous for making a product called The Super Awesome Mega Hammer.  I might purchase SuperAwesomeMegaHammer.com to promote it.  Here I could either run a dedicated site just for that hammer, or I could redirect to my site, or to the hammer's page on my site. It just depends on my marketing strategy.  Again, I have the choice of using 301 redirects to promote jakeshammers.com, or 302 redirects to let SuperAwesomeMegaHammer.com build up it's own rankings.  
  
  I can also save a bit of cost on the extra domain here by using a sub domain like superawesomemegahammer.jakeshammers.com. I have all the same options with that domain, but since it's underneath jakeshammers.com, I don't have to pay extra for it. The trade off there is that I'm giving up the brand protection not owning superawesomemegahammer.com but I'm gaining a bit of extra advertising using the sub domain by keeping my regular domain in the name. If it were me, I'd consider doing both and using a 301 redirect to one from the other.

So to sum it up, if you have a legitimate purpose for keeping multiple domains, it's possible. If you're just looking for a quick and easy way to push yourself over a competitor, it's likely to do more harm than good.

I know that information can be a lot to take in, please feel free ask for clarification or add to the discussion in the comments below. 

Should I be using a CMS?

It's a valid question for a lot of small businesses out there. Do you pay someone to develop your site? If you do, do you pay them to make updates to the site, including minor content changes? Or do you roll your own site with your own html editing skills that you picked up along the way?  More people than you might think have web development skills, but many of them, including myself still choose to use content management systems to make the work easier and to save time. With a CMS, I can choose to use a free or paid template or I design my own site, but I don't need to use a wide range of HTML skills to make simple content changes to the site afterward. That let's me take development off the brain and focus on content.... about development.

Right now, I'm typing this post in a simple text editor using blog software called Blogger. There are certainly more flexible CMS systems out there than a simple blog package, but for what I'm doing at the moment, it's sufficient for my needs. It's flexible enough for the time being, works well, and happens to have the benefit of being free and easy to set up. Some day, I may move to Joomla or Umbraco so that I can showcase some of my development skills with custom applications, but for now I'm content with simple posts and spending my available time working with my customers.

What is CMS, and does it save time, money, or (preferably) both?

CMS stands for Content Management System. It's essentially a software package that lets you add, remove or edit content from your web site without directly editing the html files.  Most CMS packages require very little if any knowledge of HTML form the user once they are set up. Most large companies use one type of CMS or another to manage their websites. As the price tag of implementing a CMS package has come down, this once enterprise only solution is increasingly an option for small businesses as well.

When you're selecting a vendor for a new website, one of the questions you need to ask is who is going to be doing the updates for content. Are you going to write all the news articles/item descriptions and then pay them to upload them, or would you like to cut out the middle man and post them yourself.  If you want to post them, do you have web editing skills to build a website? Even if you do, is it worth the time you'd have to invest to format it in HTML? After all, you're not in the business of writing your own web pages, so every second you spend on the site is time you're not spending on you actual services or products.  In the world of small business, that's unfortunately also likely time you're spending after hours, and not spending at home with your family.

So are those the only two options? Pay the specialized worker to do a menial (for him/her) task that essentially duplicates work you've already done, or take away from time you could be working on your products/services? Not exactly. A CMS system lets you type your content into a normal editor that looks a lot like Microsoft Word, or Libre Office Writer, and formats it in html for you. That way you avoid paying someone every time you update content, and stops you from having to learn advanced web design skills for simple changes. In other words, it saves you time and/or money.

Many CMS packages like Drupal, Umbraco, and Joomla have the ability to install extensions, or packages. These are basically addons created by third party developers (like myself). These packages provide you, or your developer, with a way to build on other people's work, again saving time and money.

So what's the catch? 

There's always a catch right? No such thing as a free lunch and all. The cost savings with CMS systems tend to be long term. There is almost always a higher initial cost. It makes sense right? The guy/gal you're paying to develop your new website went to school to be a web developer, but they didn't teach him/her whatever system you want him/her to use on top of that, so it's going to take longer, and s/he's going to charge more. Depending on the features you want, some CMS packages are not free (though many are).  You can downplay some of that cost increase by choosing vendors with experience with popular CMS applications, but it's unlikely to go away completely. Keep in mind that the increase in cost is a direct result of an increase in the time it will take to finish the project.

Depending on the system, you may lose some flexibility. For instance, my blogger account isn't going to let me build my own web forms in asp.net, but I could with Umbraco. Likewise, if I wanted to build my own time entry system for team members to clock in hosted on my website which would then bill my clients after I approve their time (an actual consideration), blogger no longer works, and a "real" CMS system is needed.  At the moment, I don't have a need for that, but I could someday. You need to work with your developer to figure out your needs and select a system that will work with you.

In the early days of CMS, html

So is it worth it?

I think so, but I also stand to make money if you pick me as a vendor.... Ultimately you'll have to decide for yourself.  The bottom line is that it can save you money over the long run if you're willing to spend it now.  Like most things in life, you may be willing to settle for saving the money today and find that you wish you'd have invested it later.  I think now is the part where I shamelessly point out that my company can help you either way.

What makes a software project successful?

It's a question I think about quite a bit. I've worked on quite a few projects, for school, for work, for small businesses in the are, and for myself. What makes my successful projects work, and why did my unsuccessful projects fail? I consider that because I believe it helps me take the best steps going forward to have as many successful projects as possible.

I've always believed that technical knowledge, while obviously important in software development, is not the only key factor in a good software development project.  The remaining key factors, to me, are listening skills and a developed understanding of the organization.  My most successful projects have always been projects in which I have successfully identified key stakeholders and effectively collected and validated their requirements.  That always sounds simple, just ask them what they want and give it to them. It seems so easy that most people waive it off as self explanatory.   But the process of collecting requirements is not always as straight forward as asking someone what they want, but rather looking past what they are asking for to what they actually need, which takes time and certain degree of expertise.

Internal projects, the type of project I work the most with, are often good examples of this. Often I will get an email from an initial stakeholder requesting a project. Let's say the director of HR want's a new benefits page on the company intranet to list out links to PDF files, so he emails me asking me to make one for him.  I can throw together a simple page with some links in no time, but the project may or may not be successful by doing so immediately. If I make the page now, I may find later that the communications team tasked with keeping the page and its links up to date doesn't know how to modify the html or that they don't have write access to the web server to upload new files.  By failing to  identify them as stakeholder early in the project development, I would have failed to collect their requirements, and I'll have lost a good opportunity to finish the project successfully and on time. In most cases, I've merely delayed the project, but in some circumstances, the project may now be deemed too difficult and be scrapped entirely.  Either way, my reputation with the stakeholders will take a hit, however small. With that, they will lose at least a small amount of confidence in me to understand what they need and deliver it to them, which will make not only this project more difficult, but also future projects with the same stakeholders.

So how do I avoid these pitfalls in future projects? By taking the time to ask the right questions before jumping in, even with seemingly simple projects. It's important to not only know what I have to build, but who I'm building it for, who will use it, what their needs are, how they think the system should work, etc.  Often times, when I begin to ask these questions, it becomes apparent that there is a significant amount of requirements gathering needed for even a small project to understand how to provide the appropriate deliverables the first time around.

What do you think are the key factors to a successful project? What processes do you use to gather requirements in your organization? I'd love to hear your feedback.