Find Web Developers
Find Web Developers

Archive for the ‘Uncategorized’ Category

Tablets: Another Consideration in Web Development

Tuesday, October 9th, 2018

Let’s face it; many people are still not enamored with tablet PCs. Thousands may already own an iPad or any tablet but there are still plenty of individuals who choose the bulkier but more feature-rich notebooks or even netbooks. The tides of change cannot be stemmed though and tablets will become a major platform in personal computing in the near future.

As consumers, we can see that as an improvement over what we have today. But for webmasters and web developers, it poses yet another challenge. With sales of tablet PCs rising, the time is right to start investing on tablet-friendly website versions. Yes. Versions because you do not have to totally redesign your website to accommodate internet surfers using tablets. Like with smartphone users, you can specify a version of your site to be served to those using tablet.

When developing the tablet version of your website, here are some tips to keep in mind:

1. Keep file sizes to a minimum. In the future, all tablet PCs would be equipped with Wi-Fi functionality. Today though, plenty of tablet PCs still connect to the web using 3G networks. This means pages would not load as fast as when the PC is using Wi-Fi connection. As a result, you have to ensure that your website’s tablet PC version is light and would load easily. Most internet browsers are impatient and if you cannot deliver the info they need on time, they would easily hit the back button and try another website.

2. No Flash. Android-powered tablet PCs support Flash. Apple’s iPad does not. We can argue all we want that Android-powered tablets are better than the iOS-powered iPad, but it will not change the fact that sales figures are on the side of the iPad. That said, you have to find Flash alternative to use on your site if you need multimedia content on your site’s version for tablet PCs. Furthermore, contents using the multimedia platform from Adobe cannot be read by search engine bots thus lowering your chance to get higher ranking on search engine result pages.

3. Resolution and the accelerometer. Most tablet PCs are equipped with accelerometers so there is no definite resolution to target when designing for tablets. There’s another thing to consider with accelerometers. You have to design your site in such a way that no matter how it is being rendered, the area above the fold is well optimized. Above the fold means the area that the visitor can see without having to scroll down. Make sure that you make good use of this area in any resolution or display layout.

Remember that tablets are still relatively young and in the near future, they would come with better and newer features. Make sure that you are on top of these changes and adapt your site’s design to accommodate future changes.

Web Development in a Fair Way

Sunday, October 7th, 2018

The story

When a young man starts his LIFE alone he always have great intentions about something he already interested in be it sports, literature or technology. He always has great dreams about the future, that he will be famous in some ways, will do something nobody has ever done before and will go further then anybody in the past. He will build and then lead his business to great success, will find somebody to love, will raise a family and will lead a happy life. But as time goes by he finds it harder and harder to push through…

The business

Web development. Small or big, simple or complex, everything from one page to enterprise-level database management applications. Dealing with special needs the same way as with general queries. Working over 60 hours a week delivering only the highest quality in every job without compromise. Advanced level skills in several programming languages make it easy to select and use the right tools for every project. Having the experience to bring a project from scratch to completion. Only clean hand-written code, bespoke content management systems, unique designs, cross-browser compatibility, logical structure, extendability and interactivity – in one word, professionalism what describes the products.

Sharks in the water

Running a business always involve competitors. Old ones, new ones, smaller ones, bigger ones, less or more but there are always some. And it is all right. All right, as long as it is fair. However in the web development business nothing seems to be fair at the moment.

Customers are not aware of differences between a website and a website. They can see, what is on the screen. They can see if they can find themselves on Google. And they can see the prices. And one’s price is a really small fragment of the other. The difference is so huge that the customer thinks nobody would do it so cheap so just out of curiosity they start communicating with the guy offering the cheap price. After a few conversations it is obvious that they are talking about the same thing. It makes the customer believe that the other quote is the one which is incorrect. And there cannot be that much difference between the two products. And of course that is true.

Probably there is a little difference. Probably there is none. And even if the product is completely the same in terms of hours spent on the project, structured clean code, good results in search engines, quality design, cross-browser compatibility, high accessibility and so on, there is just a LITTLE thing… And it is called FAIRNESS.

A website can be built on a computer and can be uploaded from anywhere in the world where there is an internet connection. There are many great developers and many great designers all around the world where the cost of living is really just a small chunk comparing to the cost of living in the UK, especially around London…

So Website Owners! While you don’t call yourself a millionaire however you would be really wealthy with your monthly income in some other countries, PLEASE don’t consider your country’s prices way too high just because you are having your site done by someone from far away! Thank you.

The start

When the young man started his life finishing school with a broken-up family behind his back he still had the dream to live for. In fact, that was all he had. Everyday survival can take the focus off easily though. And it did. Forgetting your dream however does not mean that you have to lose it…

Bouncing between jobs, between pride and prejudice turned his life upside down every now and then. Everywhere he went there was somebody to tell him he is going the wrong way. Time after time somebody told him to forget his dreams and grow up. He hated them. He wished they had not been there.

Although he hated them he sometimes felt they might be right. Sometimes he felt he should gave up, like everybody seemed to had given up already around him and join the queue at the end. It seemed to be all right. It seemed to be so easy. Everybody did the same. Everybody joined the same queue. He seemed to be sticking out more and more by every day and it did not feel good. But there was something he could not get out of his mind…

“A fruit is either ripening or rotting. There is no stationary state in between.”

Those people had given up already. There was nothing in front of them. They had cut all their chances that something might change to any better. The young man suddenly had to realize that those people were the only ones who helped keeping his dream alive showing great contrast between future and survival. And he has chosen the future…

Humor of faith

The young man ended up in the United Kingdom. He came to find some answers for the questions bothering him. He wanted to stay a couple of years trying his luck and wanted to save some money. But this move gave him much more than he ever expected. Learning the language and getting familiar with British culture opened his eyes a bit wider and he has seen his dream once again. Below the surface it has grown even bigger through those years than it has been ever before. And it seems to be closing up on him now…

10 Common Problems Web Developers Encounter

Saturday, October 6th, 2018

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.