10 Common Problems Web Developers Encounter

Solutions to common problems web developers deal with during a project

After spending a few years developing websites both big and small, certain patterns seem to have revealed themselves. Over time, you adapt to these issues and forget about them, but the reality is other people will encounter these problems in due course. For that reason, i thought a quick treatise of these common problems was called for.

Considering the same challenges crop up again and again for everyone in web development, it’s interesting to note that different people come up with different solutions to the same issue. The context often defines what an appropriate solution is, so what works for one business may not work for another. Obviously, I can only talk about strategies I myself have used, or ones suggested to me by my peers (nb. there may be other solutions I haven’t considered).

Without further delay, let’s have a look at some challenges, and more importantly, some solutions:

1. Content issues – this happens when a customer either takes too long to supply their content, or what they do supply is amateurish or lacklustre. The most common way I deal with this is to use some place-holder text, with the intent of having the client say “hey, that’s not my text”; this can prompt them to put in their correct content. Another trick is to use a questionnaire to illicit responses from the client. This can be used as the basis for writing rudimentary content (e.g. “what does your company do?”, “who are your customers?” etc). A technique I have used in the past is to turn off pages which are empty (e.g. client: “where’s my press releases page?”, developer: “the page hides itself if there is no text on it”). I recall reading an article some time back which suggested getting a copywriter involved from the start of the project. Having someone work closely with the client at an early stage is a good method for ensuring copy is ready prior to launch.

2. Delays in obtaining the company logo or graphics files – it’s pretty hard to start on a website when you don’t have the client’s logo. Often this is just a case of getting the client to contact their graphic designer to get you the files you need. This isn’t a major issue, but it can cause a small delay which is unnecessary. All you have to do is give the client forewarning that this material is required. This is why one of the questions I have on my Needs Analysis form is “is your logo & branding material ready?”

3. Vague feedback and indecisiveness – this is a situation which can result in not only delays, but rework which isn’t billed for. This really boils down to ineffective communication. A classic example of vague feedback is “I don’t like the design” (a more helpful version would be something like “the design doesn’t communicate the fun and relaxed nature of our company”). The evil brother of vague feedback is indecisiveness, or when a client is unwilling to make a firm decision on how something should be. With vague feedback, patients is the remedy. Some would say it’s a matter of ‘educating the client’, I find that term to be somewhat condescending. If I get feedback like “I don’t like the design”, I would respond with “what in particular don’t you like?” or “can you be a bit more specific, I need more detail in order to get your design right” (the response depends on the client’s personality, understanding the DISC model helps). In the case of indecisiveness, if it’s related to a feature, I will make it an option in the admin module (e.g. an option to show a group of company logos horizontally or vertically). With this approach, the client can set it whichever way they want.

4. Scope creep – the bane of a developer’s existence. This topic alone could span many pages, however I will try keep it simple. Scope creep occurs when a client asks for features which weren’t originally agreed upon. This can be problematic as it can cause delivery dates to shift and displace other work, it can introduce new bugs in established features, and impact on momentum. Some people take a hard line on this matter, suggesting that you should just say ‘No’ to the client. I have a personal philosophy which goes like this “there is no such thing as no, it’s yes – and this is how much it’s going to cost”. At the end of the day, it’s about business, if a client is willing to pay for the work, it’s simply a matter of project management and version control. One technique I use when developing large web applications is to group features together into a ‘mini-spec’. These features would be added to the system after launch and thus constitute a point upgrade (i.e. v1 ;rarr; v1.1). A good suggestion I have also seen is to create a cost-to-benefit spreadsheet in consultation with the client, that way they can prioritize and understand added costs.

5. Undescriptive bug reports – client: “the system crashed” or “the system is buggy”, developer (thinking to himself): “gee, thanks for all the information”. Explaining to a person that a bug can’t be fixed unless they give more detail usually solves this problem. When logging a bug, it’s essential that the person says where the bug occurred, and gives step-by-step instructions on what they did when the bug appeared. If a client knows how to take screenshots and annotate them, even better.

6. deposits, pricing and payment problems – not taking a deposit when working with a new client is unprofessional and exposes you to unnecessary risk. However, deposits aren’t as much of an issue when dealing with long standing clients. Having a good pricing structure for small projects is also important (e.g. projects under $5,000). A good general structure is 20% deposit, 70% milestone payment when most of the work is done, and the final 10% when the client signs off. The 10% final payment is very helpful in situations where a project stalls for whatever reason. There is also the issue of clients saying “but another developer said they could do it cheaper”. In such a situation, you need to demonstrate the value you bring to the table above and beyond your competitors (e.g. quicker development time, face-to-face meetings as often as required, etc). Another major problem is clients that don’t pay their bills on time. The majority of clients are reasonable business people and will respond positively to a courteous reminder, for example: “hi Tom, just a friendly reminder, have you had a chance to pay the last invoice I sent? It was due one week ago. I would appreciate if you could pay this invoice as soon as possible. Let me know if you need to discuss it. Thank you” – will there still be people that attempt to take advantage of you? Of course, but you’d be surprised how far good manners will get you in the business world.

7. Project malaise and uncommitted stake-holders – this can bring a project to a grinding holt, quite literally. It occurs when a client loses interest in their own project or decides to focus their energies elsewhere (usually on more pressing areas of their business). There may be times when this is understandable, for instance if a client is about to launch a new product or needs to spend time on ‘disaster recovery’. I don’t have a sure-fire solution for this problem, other then being proactive (e.g. get on the phone, communicate). If you have the time and inclination, you can take onboard tasks which were originally assigned to the client (e.g. communicating with the graphic designer directly to get graphics files). That said, you have to be careful not to pressure the client too much, this can actually cause something of a backlash. At the end of the day, it’s up to the client if they want to stall their project. If you have a good payment structure in place, you won’t be unfairly penalized for the delay in project progress.

8. Dealing with third parties or vendors – adding a third party to the project introduces risk because your power to influence outcomes diminishes. Not only has an additional communication channel been added, but so have potential bottlenecks. Take for example a fully-fledged ecommerce enabled website. Here we have three additional third parties which need to be dealt with during the course of the project: 1) the client’s bank has to be consulted with to setup an Internet Merchant Account, 2) a SSL provider has to be contacted to setup a certificate to allow for secure shopping, and 3) a credit card gateway provider has to be involved to provide credit card clearing facilities. There’s a lot of potential for hold-ups there. The best answer for dealing with third parties is to get in early; arrange things which you have less control over towards the start of the project, before they are needed.

9. Best practice advice being ignored – for some people no amount of logic or statistics will satisfy them, they just want it their way (e.g. “there doesn’t need to be a home page” or “i want scrolling red text at the top of my page”). In situations where the request flies in the face of best practice standards, I say the following and then get on with the work: “my professional recommendation is... but it’s up to you how you would like it”. I am a firm believer that the customer is always right. That includes them having the right to make choices which diminish the effectiveness of their product. Some developers have a hard time ‘doing the wrong thing’ on a client’s project, but if it isn’t immoral or unethical – get over it.

10. “I want something like facebook, how much?” – this is an all too common request, any developer worth his salt will have the warning bells go off early when they hear something like this. It may not be facebook or Amazon which they want cloned, it can be any leading website with majority market share. The other tell-tale sign is a ridiculously low budget. Many developers will outright turn down these kinds of projects as they see it as a waste of their time (nb. the client may be ‘fishing’ for free system analysis consultation). Answering the ‘how much’ question can be dealt with by providing a ball-park estimate with a wide variance, for example: “the project could cost between $10,000 and $20,000, I can only provide you with a fixed price once a specification is written”. This brings us to another important strategy to weed out the time wasters. Have the client pay for the creation of a functional specification before agreeing on the final cost of the project.



I would have liked to cover some of these points in more detail, but this article is really meant as a brief treatment of commonly encountered problems. There have also been many other important items left off the list, so don’t be surprised if you see a sequel to this article in future.

Special thanks goes to the people of Stack Overflow forum for their valuable input.

10 Usability Tips for Your Web Applications

Simple tips and techniques for improving the usability of web-based applications

Usability is a quality attribute that assesses how easy user interfaces are to use. The word "usability" also refers to methods for improving ease-of-use during the design process.
- Jakob Nielsen

It’s definitely an exciting time to be part of the software development industry, companies are really starting to embrace usability in a serious way. Not so long ago usability was an after-thought or novelty, a specialty field only trendy types took interest in. Now, any developer worth his salt appreciates the significance of usability. This is a good thing for users since they are the main beneficiaries of the trend (i.e. they are getting more usable, or better, software). Obviously, those companies investing in usability knowledge will possess a competitive edge as well.



During my software development travels I have come across a few nuggets of usability wisdom which I’m inclined to share. What follows is a short list of some of these tips and tricks. These suggestions are mostly applicable to web-based applications, although there is no reason why they can’t be applied to standard websites.

1. Provide in-place animated feedback – using a JavaScript pop-up to tell a user they’ve forgotten to fill in a required field is not only old-school but just down-right annoying. You need to place a notice as close as possible to the point of error. In addition, it should not require a page reload, it should just appear in place using CSS and JavaScript.



In the example picture below you can see a fairly standard looking login box. The lower portion shows what happens when you click the ‘Go’ button without entering a username or password (i.e. a warning message appears). What you can’t see here is that the background for the red warning box was actually an animated GIF which started as a deep red color and faded to the pastel red you see. This animation makes it blindly obvious to the user where the problem is.

2. Put important messages in a yellow box – its common knowledge that users skim information on websites. The danger of this is that they may miss important information as they attempt to muddle their way through your content. The trick here is to encapsulate the information in a nice yellow box. Why a yellow box? Because it resembles a post-it note. People associate these with ‘reminders’ or important tit-bits of information.



3. Highlight recently added features – some of the more common approaches for letting users know when features have been added to their system include; sending them an email with a list of new features, putting a list of new features on the home page of their system so they see it when they log in, or putting it on a wiki which you expect them to come look at. In an ideal world these tactics would probably work. Failing that, it’s far more effective to just highlight the new feature in some way (whether that’s with a pastel colored background or a little icon that says ‘New’). An additional point is that these highlights should ‘fade’ over time, meaning that after one month, the highlight should disappear.



4. Hide features a user wont initially use – I’m sure there is no doubt in your mind that your software is fantastic, you can’t wait to unleash the fury of the 400 features your software has to offer. But spare a thought for the poor user who enters your application for the first time, they are suddenly inundated by buttons, drop-down menus, icons, pop-ups, fancy controls – it’s a foreign land, and the user is like a French exchange student who’s forgotten their phrase book back home. What can you do to help? By setting expanding panels to their collapsed state by default. When the user logs in for the first time, they wont be bombarded with widgets, instead they will be pleasantly surprised by the simplicity of your interface and will probably think to themselves “this doesn’t look so complicated, I can get this in no time”. Don’t worry, users will be curious and explore, they will click the expanding icons and discover how things work in their own time.



5. Let users reduce the complexity of their interface – this is similar to the Hide features a user wont initially use principle since its about reducing interface clutter. But this is something which is more likely to happen after your users has experience with your application. For example, a user may become so familiar with the system after a couple of months that they no longer need any pop-up help. These kind of options would commonly appear on a My Profile or Settings page. A word of caution here; allowing a user to set their interface to 'Beginner' or 'Advanced' mode may seem like a great idea, but what does this really mean? How does the user know what features will be hidden in 'Beginner' mode? Maybe some of the things you consider to be advanced features, the user would think of as being basic.



6. Give feedback messages which say what just happened – if you are giving users some kind of feedback after a button is pressed, that’s great (e.g. “Operation Successful” or “Task Completed” shown in a box at the top of the page). Taking this one step further involves presenting a little extra information about what just happened. For instance, rather then just saying “Upload Successful”, you may display a message like “The file holiday.jpg has been uploaded”. Why bother? Well, the web being what it is, people often wonder off or task switch in the middle of something. They could start some process in your application and switch to another browser tab or go read an email. Ten minutes later they come back to your application and wonder “what was I doing again?” Be sure to use feedback message sparingly, for reporting significant actions, especially for things which aren't instantaneous.



7. Use a red star inside textbox controls to indicate a required field – there’s nothing ground breaking about using a red star to signify a mandatory field, this is more of an optimization on an old concept. What you are doing is using CSS to set the background of a textbox control to a GIF of a big red star. This saves a little space and gives some additional control over UI layout. The other significant factor is it’s big, making it virtually impossible for a user to miss.



8. Provide a way to reset a control or interactive element – why provide a reset button? Because its a long way to the browser’s refresh icon or to the F5 key. Well, it’s not really that far, but you do whatever you can to optimize the speed with which a user interacts with your application. There is also some logic to placing a reset button near the controls it affects, it’s just a matter of convenience. To a certain extent this is a question of personal taste as you don't really need a reset button for most fill-in forms. This is one of the reasons why I use a small 16x16 icon for a reset button as I don't believe the space taken up by a full reset button is warranted.



9. Pre-fill textboxes with suggestions or instructions – if you have the space available, why not make use of it to give users informative suggestions or instructions. In the example below, you can see a portion of a standard contact form. A user can either choose an option from the drop-list or start typing in the adjacent textbox. The moment a user clicks in the ‘or’ textbox, the pre-filled text is blanked-out so they can type in their own custom subject. Below this is another textbox, this time we are letting the user know that this is an optional field. Using gray text rather then black is preferable since it diminishes the attention it attracts (its of minor importance in the overall scheme of things).



10. Use arrows to visually connect related controls – using a bent arrow to say “hey, these radio buttons affect how this textbox works” can be a real boost to the effectiveness of an interface. It provides a natural flow rather then the usual disjointed placement of controls. In the example shown below it would be pretty clear to a user that they have two options for refining the scope of their search (i.e. the arrow indicates an implicit connection between the controls).



Armed with these new usability tricks, you are ready to go forth and make the world a better place, or at least make your software more usable. Because usability isn’t a directly tangible thing that can be listed on a project schedule, it’s often ditched in favor of more features or additional quality testing. This way of thinking isn’t going to last much longer as more users are spoilt by the fantastic interfaces they receive from companies like Google and Apple, people are coming to expect usability as a given, not a treat.

Special thanks to Dmitry Fadeyev of Usability Post for his excellent suggestions which helped improve this article.

What Does an IT Project Manager Do? - Part I

A description of the responsibilities of a typical project manager in the IT industry

This article is split into two parts due to its length. Part one starts with an introduction which describes the role a project manager plays during software development.

If you looked at the most prominent job searching website in your region you would find that different industries mean different things when they use the word project manager. For our purposes, we are going to talk about a typical project manager within the software development industry. By no means is this an exhaustive treatment of their duties and chances are good that no single person in a company would undertake all the tasks described here.

Before we can say what a project manager does, we should first take some time to define what a project actually is. We know that a project is often a novel undertaking, an attempt to create or achieve something which hasn’t been done before (hence why projects are inherently risky). The other identifying features of a project include; they have a deadline, a set budget, and a beginning and end point.

A project can be broken into a number of components; design, programming, project management, quality control, etc. These are just the titles I use, but they do have direct parallels with traditional waterfall model stages (e.g. programming = implementation, quality control = testing, etc). For simplicity, I usually roll requirements gathering and system analysis into the project management component. I tend to refer to components rather then phases or stages. The reason for this is because it’s limiting to try and force a software development project into a series of linear steps. It just doesn’t turn out that way because there is so much iteration and overlap between stages (e.g. project management is a process that occurs the whole way through a project).

To get a project done you obviously need people with specialized skills, these people are often geographically distributed, whether that’s down the hall from each other, or on another continent. The chances of these people coming together as an organized group is pretty slim. And this is where a project manager comes onto the scene.

So then, what is a project manager? You could say they are the glue that binds things together, they don’t actually do the work, but rather help others do it. They are at the helm of a ship, steering it via a predefined route to a particular destination, with course corrections to be expected along the way.

Sure, this is a somewhat simplistic definition, but we are just getting started. If we were to expand on our description, we could also say a project manager is meant to make the unpredictable predictable, ensure resources are used wisely, and handle problems which seem to appear out of nowhere.

The purpose of software is to solve a business problem or exploit an opportunity. Based on this goal, a project manager is likely to assist in figuring out what features the application should have. Before a project begins in earnest, they also have to determined if the project is technically feasible and not prohibitively expensive.



A project manager should know about the people on his team and what their capabilities are. Who’s good at JavaScript? Who knows about video encoding technology? Who’s the best person to research a shopping cart component? This isn’t just a matter of utilizing peoples’ strengths, but also making them happy by allowing them to do what they like. For example, creating a timesheet template may be hell for one person, but sheer joy for another.

Setting up the ground rules for communication is also the domain of a project manager; is the team going to have regular meetings or impromptu chats? Are we using MSN or Skype to talk to our overseas contractors? How often will programmers report their progress so the project schedule can be kept up-to-date?

Scheduling is arguably the most important task a project manager undertakes. He needs to know if there are any dependencies (e.g. an Internet Merchant Account has to be setup before credit card payments can be accepted on a website). They need to be aware of any external factors affecting the project’s deadline (e.g. the client wants to show off the software at a trade-show in two months). Regardless of what tool is used, the project schedule needs to at least say what is going to be done by when, how much time tasks will take, and who is doing what.

Resource allocation is a juggling act project managers need to excel at. Which programmer should work on what? When can they work on the next project? How much time should be set aside for bug fixing? Often companies will have multiple projects running simultaneously. This makes it quite tricky to get the most out of the limited resources available.

Making sure that the software solution delivered to the client is bug free and in fact what they asked for is another major responsibility of a project manager. This could involve writing tests plans, creating quality assurance standards, defining acceptance criteria, and organizing independent testers to carry out testing. A project manager is often the first person a client contacts when they find a bug in their software, ideally the client should be logging defects in a bug tracking system. The project manager then assigns the logged bugs to the most appropriate programmer for resolution.

A project manager is responsible for risk management. They need to be aware of what can go wrong and how likely it is to occur. Finding out about it after it happens is too late, a good project manager will spot a problem coming from a mile away and have a plan ready for dealing with it.

A project manager might need to consider external factors like: competition, industry standards, future market forces, environmental issues, social and political impact. It’s quite rare for a project manager to be called upon to analyze and document these forces (e.g. they may do this as part of an e-strategy). Most of the time this information would be in the client’s business plan.

At smaller companies it’s not unusual for a project manager to wear a number of different hats. For instance, they will commonly double as a business analyst, responsible for writing functional specifications, creating wireframes, making recommendations on technology, and deciding what development tools to use. They may even have minor administrative duties like preparing invoices for clients.

Read part two of this article... (not available yet)