Archive for the ‘Web Development’ Category

Top 5 Reasons Your Website Sucks

Friday, February 26th, 2010

Over the past few months, I’ve spoken to a number of small business owners about their websites. As a freelance web designer, I’ve been primarily targeting local small businesses because many of them don’t have websites; the few that do often have an amateur design that hasn’t been updated since 1998.

Believe it or not, the sales process has been relatively tricky. Although many small business owners are keenly aware of the benefits of a professional website, many others don’t seem to care. These people often manage their website themselves and are convinced that they don’t need an upgrade.

The sad truth is that your visitors do form an immediate opinion of your business when they see your website. This first impression can be the difference between gaining or losing a customer!

Without further adieu, I give you the five top reasons why your website sucks:

It Gives Me a Seizure

If your website uses more than 3 colors for its text, has animated GIF images, uses scrolling marquees or blinking text… your website sucks!

Let’s be honest here: your visitors are so overwhelmed by color and animation that they don’t know where to look. This isn’t good! If they can’t find the information they’re looking for, they’ll search for your competitors.

Your Website Sucks!

It Uses Frames

If your site uses the HTML tags frame or framesetyour website sucks!

Frames are about the worst thing you could use to build your website. For starters, search engines can’t crawl your content when it’s loaded inside an HTML frame element. Frames aren’t consistently rendered in every browser, so your website might look even worse than it already does. Frames confuse your visitors as the browsers “Back” button now does something different than expected. Frames don’t print as expected. Frames often cause scrollbars to appear. Frames are also a security risk to your browser.

If those weren’t enough reasons to avoid frames, consider this: HTML5 won’t support them.

Browsers Murder It

If your website doesn’t look the same (and work) across all of the Web browsers that (at least) 90% of your visitors use… your website sucks!

This is the hardest thing for do-it-yourself webmasters to understand: building a website is harder than you think. Things that look fine in Internet Explorer often don’t look the same in Firefox, Chrome, Safari or any of the other Web browsers available… and I haven’t even mentioned mobile devices!

It’s important to know what browsers most of your visitors use so that you can test your website and be sure it looks fine. If your customers think your website sucks, what will they think about your business?

It Doesn’t Tell Me Anything

If your website doesn’t give me the information I’m looking for… your website sucks!

Are your business hours listed? What about your address and phone number? What is it your company actually does?

The answers you need to provide may vary, but it’s important to give the public what it wants. Furthermore, your content needs to be well organized so that these answers can be easily found! If your customers can’t find the information they need from you, they’re going to check out your competitors.

It Uses Flash

If your website is heavily reliant on Flash… your website sucks!

Companies often ask about Flash because it looks cool. And it often does… but websites that rely on Flash to display important content have several serious failures.

First of all, many mobile devices can’t display Flash. The iPod and iPhone can’t display Flash at all – a huge problem given how many people use them.

Secondly, Flash isn’t easily indexed by the search engines. Google says it can read text embedded within Flash files, but regular HTML text is far easier for them (and the other search engines) to read and understand.

Lastly, do your visitors actually like having to wait for your Flash animations? Many websites that use Flash go overboard using everything from background music to animated page movements. Your visitors are looking for something specific – do you really want to make them wait for it?

What do you think?

Do you agree or disagree with this list? Did I miss anything?

Ext Scheduler

Monday, February 8th, 2010

A few weeks ago, Mats Bryntse (mankz on the ExtJS forums) asked me if I would be interested in taking a look under the hood of his Ext Scheduler application. There has been a great deal of buzz in the ExtJS community over his tool, so I jumped at the chance to peek into his source code. We’ve never actually met in person, but Mats seems like a good guy and he has a lot of good insight on the ExtJS forums. Apparently Mankz is also a DJ; I did not know that!

Disclaimer: Mats granted me a free license to use the tool in exchange for my review.

After unzipping the source code, I poked through a few of the examples. At first glance I was very impressed! The download came packaged with six demos, each of which utilizes different ExtJS features and gathers data via different sources (eBay, Google Calendar, among others). My only immediate complaint was that the API documentation wasn’t included in the ZIP file. It is however freely available on the Ext Scheduler website here.

Let’s Build Something Fun!

Rather than just saying what the Ext Scheduler does… let’s build something! Since Ext Scheduler’s website already has a handful of examples, I’d like to try building something new — let’s use the Twitter API and map when our tweets are posted.

A quick note: I didn’t realize something important until I was almost done with this application – the Twitter API doesn’t allow you to grab tweets based on a given time frame. You’re only allowed to grab the last X tweets… which I think is pretty lame. Had I know that before starting this application, I would have chosen a better example. *Facepalm!*

My journey through the Ext Scheduler started with a quick look through the API docs. The basis for the entire application is the Sch.SchedulerPanel() class, which is an extension of the Ext.grid.GridPanel(). If you read the API docs for this class, you’ll learn that it depends on two data stores: the first (“Store”) defines the various categories/rows for your application, while the other (“EventStore”) defines the events displayed on our schedule.

For my sample application, the “Store” will consist of a single Twitter user and the “EventStore” will be filled with this user’s 50 most recent Tweets. Thus, my application only has one row on the grid (boring, I know). I chose to display my grid as a 24 hour day so we can see our user’s Twitter activity over the course of a single day. Toolbar buttons allow us to move forward/backward by day. (Since the Twitter API doesn’t take start/end date parameters, this functionality is somewhat pointless.)

Take a moment now and try my sample application. We’ll explore it in more detail below, but see the source code here.

Learning Curve

My only real complaint with the Ext Scheduler code is the fact that there’s a slight learning curve. The examples provided in my ZIP folder are great, but there’s so much going on in each demo that it’s hard to figure out the basics. It took me the better part of a day to get my application working, so be prepared for a little bit of frustration.

Don’t get me wrong – this is an awesome tool, and I had the same complaints about ExtJS when I first started too. As such, I’m hoping this review can be a step-by-step demonstration on how to get started.

Step One: Define Your Categories

The “CategoryStore” is used for our left-hand grid labels – the entities to which the events are associated. In some of the other Ext Scheduler examples, the “Categories” were often people; the “Events” were often meetings or other appointments.

I started my application by prompting the user for their Twitter username. If you open my source file, you’ll see that I take the user’s input and insert it as a new data record into my TwitterApp.Scheduler.categoryStore (an Ext.data.JsonStore()). That was easy!

Next, I call the init() method on my TwitterApp.Scheduler object (a generic literal), which calls a series of other methods. In essence, here’s what they do:

  • Set this.start and this.end (values needed to properly display data in our schedule)
  • Create and load our “EventStore” (we’ll come back to this in a moment)
  • Create the scheduler grid and render it to the UI

Step Two: Define Your Events

As I just mentioned, we need to create and load the event data to display on our schedule. See the following code:

Ext Scheduler Demo

Our “EventStore” is another simple Ext.data.JsonStore() object; however, I’m pulling the data for this store from the Twitter API (based on the supplied username).

Take note of the “start” and “end” base parameters on this store. Although Twitter doesn’t really need them (which is why this example kinda sucks), the Ext Scheduler classes do! If you don’t add these parameters you’ll get an error!

When this store finishes loading (see my LOAD event), I manually set the “EndDate” property for each record because Ext Scheduler needs this information.

Step Three: Create the UI

Once we have our categories and events defined, we have the data we need to display the Ext Scheduler UI.

The Sch.SchedulerPanel() class is an extension of the ExtJS GridPanel(). The only things we really need to be aware of are the autoViews property and the eventTemplate since they’re the two things which really affect the appearance of our tool.

For the autoViews, you have your choice of displaying the grid by days/week, hours/day and a few other options. Since we’re using Twitter, I thought hours/day was most appropriate.

For the eventTemplate, it’s important to create an Ext.Template() object that means something to your users. Looking at the other examples of Ext Scheduler, you might see the name of the event, its start/end times, or other descriptive information. My example isn’t as cool… but you get the idea.

The only other thing I should point out is that your users will probably want a way to change the date range displayed by our scheduler grid. I added “Previous” and “Next” buttons which essentially alter the start/end date and reload our “event” data.

Step Four: Brag about your tool!

As I already pointed out, the Twitter API was a terrible choice for this demo because it doesn’t allow me to search for tweets by a selected date range. It was also a bad example because tweets don’t have start/end dates. Note to self: choose better examples next time!

Overall, my impression is that the Ext Scheduler will be an invaluable tool for most developers working with “events”. It’s easy to work with, offers an impressive set of features and should impress a lot of end-users. I would encourage everyone to check out the other Ext Scheduler examples and see for yourself!

WordPress Automatic Upgrades on GoDaddy

Saturday, January 30th, 2010

It’s been a while since I moved this blog over to WordPress, and my only complaint since the move has been the periodic upgrades needed for WordPress and its plugins.

Why is that a big deal? After all, there’s this prominent link saying “Upgrade” when WordPress (or any of the plugins) detect a new version.

Well… for starters, I’m hosting this blog on a Windows IIS7 machine. To complicate matters, I’m also using GoDaddy. Rather than diving into why either of these factors is complicated (if you’re interested, do yourself a favor and Google it) I’ll simply jump into the solution for automatically updating WordPress on a GoDaddy IIS7 hosting plan.

Step One: Login to GoDaddy

Login to your GoDaddy hosting control center.

See those tabs at the top? Hover over the “Content” tab, then click on the “File Manager” option.

Step Two: Set the Correct Permissions

Using the file manager, find the directory containing your WordPress blog and check the box next to that folder. (For example: if your blog is installed at /(root)/mysite/myblog/, then  navigate to /(root)/mysite/ and click the box next to myblog).

Click the “Permissions” button from the toolbar.

When the dialogue box opens, set the permissions for this folder to “Read/Write”. Be sure to also “reset all children to inherit” these permissions.

Click “OK”.

Step Three: Click the Automatic Upgrade links

Now, login to your WordPress dashboard. Click the “Upgrade” links for WordPress and any plugins which have new versions.

Be sure to properly backup your database and other files as needed!

Step Four: Reset the Permissions

Technically, you probably don’t have to do this — but it’s good practice to never allow applications extra security clearance when they don’t need it.

Simply follow steps 1 and 2 again, only uncheck the “Write” option. Be sure to “reset all children to inherit”.

Any Questions?

This worked perfectly for me, moving from v2.8.6 to v2.9.1. I’d love to know how this works for you!

Book Review: ASP.NET 3.5 Application Architecture and Design

Friday, January 29th, 2010

This review is part of a series of book reviews I have agreed to do for Packt Publishing. I am not being paid for this review, although I did receive a free copy of the book. I do not work for either Packt Publishing or Microsoft.

ASP.NET 3.5 Application Architecture and Design was written by Vivek Thakur and published in 2008.

Who This Book is For

This book is intended for developers who have “basic understanding of the ASP.NET framework, and programming knowledge of either C# or VB.NET”, although it looks to me as if every example is written with C#. The word basic is a relative term, but Vivek seems to use it accurately – you don’t need to know that much about ASP.NET in order to comprehend this book.

Furthermore, Vivek states that “if reading about application architecture usually confuses you or sends you to sleep, then this book will be perfect for you!” He’s not lying. Vivek does an outstanding job explaining complicated concepts using everyday analogies.

Getting Started

Vivek starts the book by introducing the reader to the world of software architecture. He uses the analogy of an automobile company, where mechanical engineers, design engineers and the assembly line staff all have clearly defined roles – roles separated from each other for a variety of reasons. Vivek equates this process to that of the software “project life cycle”, and then moves into a discussion on software tiers and layers.

From there Vivek dives into n-Tier software architecture, giving some great examples along the way. I loved his approach to this topic because he starts at the beginning (a 1 Tier, 1 Layer application) and moves step-by-step towards a fully n-Tier application (his example uses 6 Tiers). The author also sticks to the same example (an order management system, or OMS) which helps the reader easily understand how a 1 Tier application is different from a 4 Tier.

I also really appreciated Vivek’s instruction on how to add new class libraries to Visual Studio. For readers who aren’t well versed in VS, this is definitely something useful.

Lastly, I thought it was a great idea to introduce the concepts of Data Transfer Objects (DTOs), Lazy Loading and distributing assemblies across multiple machines. Vivek’s explanations of each subject were clear and concise – perfect for readers with only “basic understanding of the ASP.NET framework.”

Moving On

About halfway into the book, the author moves into discussions of MVC and SOA design patterns. The only thing I really didn’t like was the introduction of the Windows Communication Foundation (WCF) in chapter 7, and that’s because Vivek only spent 4 pages on the subject. WCF is also the only .NET-specific topic in the entire book; I understand why it was introduced, but it felt rushed and (as someone who isn’t an expert ASP.NET developer) I didn’t get much out of it.

On the other hand, I really enjoyed Chapter 8 (Database Design). Vivek’s conceptualization of the domain model vs. the logical data model is spot-on, and I would recommend that any developer looking to build a database read it. I particularly liked the author’s example on page 197 for data normalization: who knew that the members of Metallica wrote books on ASP.NET? Sweet!

The Final Verdict

I definitely enjoyed reading ASP.NET 3.5 Application Architecture and Design. Overall, I think I would say that anyone interested in software architecture and design (regardless of the language used in development) could get a lot out of this book, minus a handful of exceptions (see my comment on WCF above).

Nice job Vivek!

JavaScript Tabs: ExtCore vs jQuery UI

Thursday, January 21st, 2010

A while back, I built a website for a client using jQuery 1.3 because I needed a slide-show widget for the homepage. More recently I’ve been using ExtCore for small website widgets – mainly because I’m a bigger fan of ExtJS than jQuery. (ExtCore also didn’t exist at the time I built that website).

Long story short, this particular client (a restaurant) asked me to add some new content to their menu. Rather than expecting the user to scroll down a lengthy list of mouthwatering lunch options, I suggested that we add tabs to the menu in order to logically separate the menu items.

Since I already had jQuery 1.3 running the slide-show on this website I simply decided to build the menu tabs in jQuery to maintain consistency. But I was suddenly struck by an idea: why not compare how ExtCore and jQuery UI create tabs from HTML markup!

ExtCore

ExtCore can be downloaded from the ExtJS website, and an online demo of the simple tabs can be seen here.

The first step to building tabs from HTML markup using ExtCore is to reference ext-core.js in your page header. You also need to include the tabs.css file and the “images” folder containing the necessary 5 background images. (These can be found under “/examples/tabs/” of your ExtCore download ZIP.)

Note: I’m using ExtCore 3.0, although I believe 3.1 is available for download.

Next, we need to add the appropriate HTML markup for our tabs. Here’s a quick example.

ExtCore HTML Markup

As you can see from the picture above, ExtCore takes a wrapping DIV element (class “tab_container”) and converts a nested unordered list into the tabs. Subsequent child DIV elements contain the markup for each tab’s content. (The source code in this example is taken directly from the ExtCore tab example.)

The only thing to notice is that each DIV element has a CSS class assigned to it – these classes are essential to proper tab theming. The DOM ID properties are used to click back-and-forth between tabs.

Lastly, you need to include a JavaScript snippet which converts your HTML markup into a fancy tabbed widget:

ExtCore JavaScript Code

jQuery UI

jQuery UI has a tab widget which is dependant on the larger jQuery library. An online demo of their tab widget can be seen here.

The first step to using tabbed content with jQuery is to reference:

  • jquery-1.3.2.min.js
  • jquery-ui-1.7.2.min.js

Your file versions may differ (I think jQuery 1.4 was just released), but these are the versions I’m using. I’m also using the “smoothness” theme – for some reason jQuery UI would not allow me to download the package without specifying a theme. (That may affect my analysis for speed in the next section.)

You will also need to include the CSS file and images folder included with your download of jQuery UI. In my case, it’s jquery-ui-1.7.2.css and an “images” folder containing 13 background images.

Next, write your HTML markup:

jQuery HTML Markup

Compared to ExtCore, jQuery UI expects less HTML markup as we lose several layers of nested DIV elements. The most obvious difference between jQuery UI and ExtCore is probably that jQuery UI doesn’t need the extra CSS classes applied to the DIV elements.

Next, we add our JavaScript snippet:

jQuery JavaScript Code

Again, jQuery UI expects less code to generate the tabbed widget.

A Deeper Look

Let’s take a look at the file sizes for each library. This is about as un-scientific a study as it can get; I’m using Firebug’s “Net” tab to grab file size and download speed numbers. These numbers will probably be different for you because of any number of factors… but you get the idea.

As I already mentioned, ExtCore requires 1 JavaScript file, 1 CSS file and only 5 background images:

  • ext-core.js (78.9 KB, 156ms)
  • Ext.tabs.css (1.3 KB, 147ms)
  • 5 png files (2.8-2.9 KB each, average 107ms)

Combing the file sizes and their download times (on my home network), you get a total of roughly 94.7 KB taking 838ms.

jQuery UI requires 2 JavaScript files, 1 CSS file and 13 background images (again, with the “smoothness” theme):

  • jquery-1.3.2.min.js (55.9 KB, 116ms)
  • jquery-ui-1.7.2.min.js (188.1 KB, 221ms)
  • 13 png files (22.3 KB total*)

*Something interesting I noticed about the jQuery UI tabs is that my page only seemed to load 5 of the 13 background images, totaling something like 605 bytes and a total of 684ms. Perhaps someone more familiar with jQuery can explain that to me… I didn’t dig deep enough to figure out what was going on, but I’ll base my total on what Firebug says. I’m guessing that I’m not using all of the CSS background images for this theme.

Overall, that brings jQuery UI tabs to a total of roughly 245 KB taking 1021ms.

What Does That Even Mean?

According to my inaccurate, quasi-scientific study it appears that ExtCore requires slightly more code than jQuery UI. On the other hand, ExtCore also appears to be downloaded by my browser more quickly than jQuery UI. In reality, those numbers probably offset each other as the extra markup required by ExtCore increases the HTML file size. The fact that I’m using a theme on jQuery UI probably also has a slight impact on performance.

Which do I prefer?

In essence, both libraries create tabbed widgets from the same basic HTML markup – though the differences are significant enough that they’re not cross-compatible.

Judging both frameworks as they stand in my examples, I will say that I like the conciseness (is that a word?) of jQuery with regards to both HTML markup and JavaScript code. But I also like that ExtCore requires fewer files. As someone who uses the larger ExtJS framework a great deal, I’ll say that I am very likely to choose ExtCore over jQuery UI most days of the week.

Are there any ExtCore or jQuery UI users out there? What do you think?