Website design Birmingham
While we have been running the eSterling website and blog for some time we thought it would be handy for new readers and anyone looking at the services we offer to have a short overview of the company.
eSterling is a Birmingham web design agency made up of a team of 20 people covering all aspects of development, support and SEO. We operate as a full service web agency offering web design, web development and search engine optimisation.
We mainly build websites for companies based in the West Midlands. We pride ourselves on producing a bespoke solution that meets the needs of businesses rather than foist a website template solution on them. We won’t hand you a basic template website or an older design with a new logo placed on top. Our team carefully researches your brief, requirements and market you are in and from that creates a tailored web solution just for you. We have over 14 years of experience in the web development industry and guarantee a fresh, jargon free and professional approach to developing your website.
We have provided many hundreds of companies in the Midlands with various categories of web solutions from brochure websites to ecommerce websites. If you are looking to sell products online eSterling have many years of experiencing producing bespoke ecommerce sites. We can provide you with a secure platform with easy to use CMS software that puts you in control of selling goods through your website. Integration with payment services such as SagePay, Worldpay, PayPoint and Worldpay is no issue and we’ll even advise on ways we can help with building support for CRM or Sage accounts into your website.
For a free, no obligation meeting and quote contact eSterling on 0121 766 8087 today.
Start Me Up: Tips for Getting Your Big Idea off the Ground
While big in America, start-up culture doesn’t seem to have quite as much traction in the UK. Sure Dragon’s Den gets the viewing figures but it is little more than reality TV panhandling and doesn’t offer any insights into how to get the next Facebook beater off the ground. Here then is a quick guide to how to build your empire from scratch.
First up. What is the problem you are trying to solve? What possible solutions are there? What key metrics do you need to measure to see if what you are doing is a success? What is your unique value proposition? What advantage do you have that cannot easily be replicated? Who are you targeting? What will it cost? How are you going to make money from it?
Solve genuine problems. Don’t just come up with a list of features and don’t just offer a workaround to common problems offer a complete solution. Interview potential customers and find out what their problems are? What would be your solution? Everyone has that one great idea but it’s execution that counts.
Minimize your total time in getting something in front of potential customers. Launch as quickly as possible in fact you need to be even quicker than that. Your first step is your Minimum viable product, MVP in start-up lingo. This is always less than you think. It could be just a one pager with a sign-up form or a blog outlining your big plans. But you need to get something, anything, out there in front of your potential customer base.
Waiting until something is perfect is a recipe for failure. Things will never be just right and you’ll tinker forever over things that are just not important at all. You ain’t gonna need it is a mantra programmers follow and you should too when cutting features from your product. That’s right, you should always be thinking about what to get rid of next rather than what your next great feature is. Less is more. Keep it simple stupid. You need to find the one feature that customers LOVE. You’ll know you’ve found it when they complain that you’ve taken it away.
Iterate rapidly. Launch your MVP. Measure the analytics. Test your assumptions and trust in the data. Make the changes you need, optimise your product and launch again. Rinse. Repeat.
Fail Fast. You need to know if your product is succeeding or failing. This is why it’s essential to iterate and not go with the big up front product that is perfect. If you do and it fails you’ve thrown away months of work. Get the MVP out there and measure. If it fails start over again with the data you’ve got in hand.
Don’t feel guilty about making your product pay to play. It can be a big mistake to offer up all your work for free in the hope that someone might pay for it down the road. By charging money you’re telling people you think it’s worth something. By giving it away you’re telling them it’s not worth anything yet. Maximise your user acquisition, make your current customers happy and they’ll work as your viral marketers. You also did remember to set up your Twitter and Facebook accounts right ?
Don’t let customers get away. If you’ve converted someone through a signup you have their details. Follow up. Send them a personal email asking why your product didn’t meet their needs, what problems they encountered. If it’s viable then consider it for the next iteration.
Once you have found a fit between your product and customers you need to transition to growth and riches! Possibly. If you do make it to be the next Mark Zuckerberg just remember who gave you the advice…
WebDev Frameworks – CodeIgniter – Part 3: Authentication
One area lacking from the CodeIgniter feature set is user authentication. This is a feature fundamental to a huge number of standard web applications, be they globe-spanning social networks or a shop front for a local business. Indeed, the majority of sites that allow any kind of user experience customisation will at some point require assigning users a username and password to allow these features to be utilised. Many sites, both global and local, now use social media connections to provide authentication which enable users to interact with the application without the need for creating a new account to maintain. This approach has the added benefit (or detrimental consequence, depending on your world view) of allowing an application to potentially interact with more of the user’s data already available through their social networking activities, creating a more personal experience. Believe it or not, however, not everyone is on Facebook, and as such the current online landscape dictates that there must be a way for users to create an account in a web application with nothing more than their email address.
From a development point of view this means having a robust and reliable authentication system is a regular requirement. CodeIgniter doesn’t attempt to fulfil this need whatsoever and the inherent silver lining in that decision is that it helps to preserve the CodeIgniter mission statement of “maximum performance, capability, and flexibility in the smallest, lightest possible package.” There is no half-hearted effort to introduce a feature to CodeIgniter which has been deemed, rightly or wrongly, as non-critical and thus risk compromising the integrity of the framework.
The cloud to this lining, therefore, is how best to implement this functionality.
Not surprisingly, we’re not the first ones to ask this question. A discussion on Stack Overflow spanning over 3 years has hammered out the finer points for us and directly resulted in the creation of a new authentication library built upon comments and recommendations from the thread. This library is called Tank Auth.
Tank Auth is a rock-solid, fully featured user authentication library for CodeIgniter. Functionality includes user registration, activation, password reset and captcha support for new users and login, logout, logging and credential management for current users, all based on a well-defined security model that integrates smoothly in to the CodeIgniter core. This is a great solution to our authentication requirements that can easily be hacked in to shape for specific requirements.
Whilst everything that is present works well, it does still have a little way to go. Account profiles (as opposed to mere account credentials) are included but not implemented in any useful way. There is no ‘role’ management or user differentiation built in. And, as with the rest of CodeIgniter, there is no backend provided whatsoever.
That’s next on our list.
Javascript vs Ruby Hipsters
Over the weekend, there’s been trouble brewing in the web development world… A kerfuffle has broken out over the lack of semi-colons in the Twitter Bootstrap javascript libraries. Nerd slapfights like these would under normal circumstances not be notable but in this particular case programming luminaries such as Douglas Crockford and Brendan Eich have waded deep into the argument.
The authors of the widely used (indeed we have discussed it on this very blog) Twitter Bootstrap library have chosen to omit semi-colons in their javascript code. Javascript, being a C based language uses semi-colons as a statement terminator. However, the javascript parser is able to automatically insert semi-colons if they have been omitted and it detects a newline. Howerver, in his book Javascript: The Good Parts and in various talks he has given on the topic, Douglas Crockford makes it clear that the semi-colon is a necessary statement terminator. Newlines should not be used in its place due to the likelihood of bugs creeping in. Backing up this point of view is Brendan Eich, who we should point out, actually invented Javascript.
The issue has raised its head on a bug opened on the official Github Bootstrap repository wherein Bootstrap is described as not working with JSMin, minification software created by Douglas Crockford. Commentators say the issue could easily be resolved by adding the semi-colons. Crockford himself comments on the thread, his opening gambit being, “That is insanely stupid code. I am not going to dumb down JSMin for this case.” Lines are drawn, sides taken and insults thrown around.
So why are these developers choosing to use new-lines in place of semi colons? Some claim that semi-colon usage arguments are a form of Bikesheding; concerning yourself with trivial issues such as what colour to paint the Bike shed rather than focusing on more complex and relevant issues. Others argue, and indeed in the comments of the Github thread in question it is stated by the project’s owner, that if you are familiar with javascript you can omit semicolons and rely on the automatic semi-colon insertion. Doing so is in some way a showing of skill, mastery over the javascript interpreter. The omission of semi-colons is also an aesthetic choice. By not using them the code is more readable to Ruby developers. This drive to make the language more Ruby-like led to the creation of Coffeescript and it is understandable that developers might way to use standard javascript in a similar way.
However Ruby developers are also seen as San-Fran livin’, fixie riding, floppy haired hipsters with giant egos who are more concerned with image that substance. Developers who are concerned with making code “beautiful”, as if programming were a medieval art like glassblowing or being a blacksmith. People who wear T-shirts proclaiming them to be “Code Poets”; programming Lord Byron’s. It is unsurprising then to find that Bootstrap is the output of Ruby developers.
Having a C based language overridden by the aesthetics of Ruby can be jarring especially when it runs counter to how it is supposed to be used. Indeed as another commentator states in the thread, “Semi-colonless Javascript is an ego-stroking attempt at rejecting standards for the sake of rejecting standards, not for the greater benefit of the community.” That Crockford’s views are assailed by commentators who’s photos have them posing with teddy bears, oversized sunglasses and ironic haircuts doesn’t dissuade the view of hipster Ruby developers.
The bug has now been closed with no resolution and a lot of acrimony, the debate will, we are sure, continue.
WebDev Frameworks – CodeIgniter – Development
So far we’ve established that CodeIgniter is simple to install, streamlined to develop and efficient to host, but what do we actually get with this package? There are two main areas of functionality provided by CodeIgniter that form the core of its existence: classes and helpers.
Firstly, classes. We are provided a whole heap of pre-built class libraries to help build a back-end that can easily deal with common situations. These are essentially a compilation of well written and thoroughly tested functions designed to simplify the tasks most web-facing applications will require somewhere in their repertoire.
As an example, dealing with user input is notoriously laborious in web development. Collating form data, validating the input, removing malicious entities and formatting the results is the bane of any productive day. However, using the form validation class provided with CodeIgniter is, by comparison, trivial. It allows us to ensure user input is safe and present when required and, coupled with the email class, allows us to quickly generate emails to send back to the user. We can allow file uploads and zip them, we can manipulate images and generate thumbnails and we can keep this all in session data for authentication or displaying errors and notices. The database class ensures we can keep a permanent record of this data easily too, and throughout this whole process we haven’t written a single function of our own.
On the front-end CodeIgniter provides us with a selection of helpers. These are a series of functions designed to literally help with the creation of an interface. Continuing from our scenario above, the form helper can dynamically create text boxes and file upload forms and even populate them with session data or previous input. We also have helpers to format text, HTML, dates and URLs and CAPTCHAs to help us retain our humanity. A full list of CodeIgniter’s classes and helpers can be found in their user guide.
Don’t be fooled by this simplification of CodeIgniter’s rich feature set. Due to the fundamental nature of the framework a certain level of technical knowledge is required to shape CodeIgniter in to something useable – this is not the point-and-click-and-blog service you will find with the likes of WordPress. But nor is it designed to be and the “right tool for the job” axiom is just as appropriate in web development as any other profession. Similarly, there are a few gaps in the CodeIgniter arsenal and we will take a look at these next time.
PHP: The filth and the fury
The favourite whipping boy of programmers everywhere has once again taken its licks in a blistering blog article titled PHP: a fractal of bad design. While no stranger to lengthy lists of its shortcomings the latest attack is a cavalcade of issues that the language suffers from. Apart from the vigorous nodding in agreement, debate online has centred on the most pertinent of questions, “Why would a programmer use this abomination of a language?”
PHP is not universally held in such low regard. It is, for the web layperson looking to dip their toe into the world of development, an easy and forgiving environment which allows them to peruse a few tutorials and have a basic site up and running in almost no time at all. By just creating a text file adding a bit of code, changing the extension to .php and uploading to a web server you can instantly create a site. Skimming a few more articles will have you connecting to a database and proudly running a “real” website. Besides it’s used on some of the largest websites in the world such as Wikipedia and Facebook, they must know what they are doing so it can’t be all bad right?
Detractors would point out that enabling amateur web developers to throw together sites will almost no idea of what they are doing is a recipe for disaster. While the site they produce may indeed work, in the eyes of a developers it is only in the most tenuous sense possible and will most likely be riddled with security holes. When such code bases are inherited the amount of refactoring require means that almost none of the original code will be kept. As a developer you will have to view PHP code that will likely leave you bug eyed in disbelief. For the language itself the bizarre rules of equivalence, the inconsistencies in everything including the standard functions will likely drive you mad. The avoidance of any discussion of parameterized sql statements in the official documentation in favour of telling you to escape your strings is insane. The list goes on and on.
So why use PHP? Simply there is no viable alternative if you need to be able to host your site almost anywhere. Other languages require software stacks and web specific frameworks to run a site, ensuring you will need to have knowledge of more than just the language used. The site produced will probably have to run under Fast CGI on a server resulting in less than grand performance. PHP in contrast is ubiquitous and supported by pretty much all web hosts. It is unavoidable if you are to be a web developer and you will need to know the language even if it is not to be your primary skill. Even then your job most likely will be using PHP given that easily 80% of development jobs will use it.
To know PHP’s shortcomings is to be able to avoid them. You do not need to program in the Cargo Cult, copy and paste method used by beginners. There are a variety of frameworks now available that take care of the boilerplate and require you to structure code with a separation of concerns. While PHP is forgiving when used poorly there is no reason you cannot code in a correct manner following best practices. Doing so will help raise the awareness of these issues with potential developers and allow them to avoid the mess of spaghetti code that has come before. When used with a framework such as Codeigniter PHP becomes almost pleasant to use, but maybe that is the Stockholm syndrome speaking.
WebDev Frameworks – CodeIgniter Overview
CodeIgniter is a Model-View-Controller (MVC)-based application development framework. Essentially this means that each element of an application will be split in to three distinct sections – the model, which deals with data structures; the view, which presents everything to the user; and the controller, which serves to tie the models and views together along with processing other required resources such as user input.
The defining concept behind an MVC architecture is to seperate different aspects of the application whist providing a framework to link them together. For example, since these sections will be the focus of the application’s front-end, our design team can be working away on the view components independently of the rest of the project. This enables the development team to construct the back-end (e.g. model sections) without worrying about conflicting with design changes or, conversely, without preventing the design team from working by forcing them to navigate database issues.
This approach leads to more streamlined coding both front and back. It is easy to define flexible model functions that can be recycled by numerous views. Likewise, views can be created with just presentation in mind and dynamic content can be introduced cleanly and simply by a controller. This structure has the added bonus that models and views are only loaded as they are required which helps keep page load times and resource usage to a minimum.
CodeIgniter provides a well-trimmed solution in other areas too. The first bullet-point in CodeIgniter’s official feature list, entitled “CodeIgniter is right for you if…,” states “You want a framework with a small footprint.” And it certainly delivers. The latest version available for download at the time of writing clocks in at just 3.9 MB uncompressed, positively tiny considering the features we are promised as that list continues. The default installation is also minimal: as simple as copying the files to the web server root. The software doesn’t come bogged down with loads of unnecessary code – in fact, no models are provided whatsoever – just a simple welcome controller and view ensure there exists a default index page. These are easily removed and we’re ready to create our brand new application.
Client side frameworks, the new hotness
A recent article on javascript frameworks and the almost inevitable switching of focus to client based development from the server-side for web applications has left the blogosphere all in a tizzy. ‘Rails is just an API’ couldn’t have targeted a more grasping and rant happy clientele, given that the Rails framework is held in an almost messianic regard by certain sections of the web development community. The gist of the article is that with rich client side frameworks such as backbone , knockout and batman the server side elder statesmen like Rails, Django and ASP.NET MVC will be relegated to being JSON providers with a bit of authentication sprinkled on top.
One of the triggers for these observations is the release of the new version of Basecamp from 37signals. The original Basecamp being the application from which the Rails framework was first extracted. Instead of embracing the new client side ideology it appears that 37signals went out of their way to avoid a javascript front end and have been triumphantly tweeting about the lack of such. Compare and contrast with Twitter itself which heavily uses javascript to render the entire interface. We are now at a point where browsers can support extensive rich interfaces whereas before switching an image on mouse-over was a somewhat mind-blowing feat. The support will only improve, browsers will only get faster, so it appears that the snubbing of client-side javascript for the release of one of the premier web apps is not only short sighted but predicated on supporting the now almost long in the tooth Rails framework’s appearances to web developers. While no one can blame them for rah-rah-rah-ing their own framework it runs, some say, against the clear direction web development is heading.
For our own part we recently have been using Knockout.js to develop a rich and responsive search interface for one site in development. The framework has been a joy to work with and it’s clear that this will be a useful tool to use in future and it’s capabilities will even be in mind when we build other sites that could benefit from rich interaction. One caveat is that, for now, such frameworks are useful mainly for web application development and not simple websites. Given that much of the interface will be created by templates on the user end it currently impacts SEO, and so is best left to un-crawlable pages behind log-ins. That might not be the case for long as the Google bot has been executing javascript for some time and may soon be able to emulate a full browser, letting the use cases expand for these frameworks.
What do you think of these javascript frameworks? Are they the future? Let us know.
What pictures should I use on my website?
They say that ‘a picture tells a thousand words’ and if this is true, it’s crucial that you get the imagery on your website right. Potential customers will judge your business based on the photographs or graphics that they find on your website, so any images must be professionally presented and appropriate to your company.
It’s worth spending some time carefully editing the images that you use on your website, starting with the home page. This is the most likely entrance for potential customers and the images need to encourage them to stay on your site and convert to a paying customer.
Your homepage needs to be eye catching and include welcoming images that are relevant to your sector. Always make sure that your imagery suits your company ethos – whether your company is strictly corporate, or relaxed and friendly.
You don’t need to stick to the obvious when it comes to imagery. Photographs can be used to suggest the things that you offer, which is particularly important if you are selling a service or idea, rather than a product. For example, a company offering loans might show a picture of a happy couple with a new house, rather than documents or a pile of money. You can buy these types of lifestyle photos from picture libraries such as iStock.
Once a customer has been convinced that your message is relevant, they will hopefully move on to your products and services. If you have an e-commerce site, you need to make sure that product photos are well presented. If a customer can’t see your product because the photograph is blurred or too dark, it’s unlikely that they will have the confidence to buy it online. It’s therefore worth investing in professional product photography, or alternatively source images from your suppliers.
The about page is another place where you should consider placing images. This gives a personal view of your company and is a space where you can introduce yourself and your team. Head shots or a group photo are perfect for this. You could also consider adding a photo of your premises.
At every stage, the quality of the images you use should be your top priority. Pixellated, distorted, dark or blurry images are a big no-no. You need to make sure that all of your pictures are taken with a good quality digital camera. If you’re not confident taking the pictures yourself, consider hiring a professional photographer.
If you’re still not sure which images would be best for you – talk to your web designer. They will have worked with similar websites before and will understand what does (and most importantly doesn’t) work!
The Twitter Bootstrap Backlash
In recent days there have been grumblings of disquiet over a few vocal bloggers decrying an apparent rampant overuse of Twitter Bootstrap – a toolkit of simple but elegant HTML and CSS conventions used for building web apps. While this nerd backlash may seem to some to be a storm in a teacup, it’s raised a few heckles with developers who find the convenience of the library to be a good thing.
The issue appears to be the “samey-ness” of websites using the framework. Sites such as the Built With Bootstrap Tumblr feed showcase the variety of websites built with the toolkit. When flicking through the galleries a certain style does leap out and, admittedly, some even use the library “as is”. The result though is not entirely unpleasant, and as one wily commentator pointed out it is better than the ‘Geocities look’ that developers would routinely come up with on their own.
Still, there are others fighting in its corner. Dave Winer has run to its defence and compares Bootstrap to the legendary Apple Macintosh, arguing that the standardisation and ease of use it offers allows people to focus on what’s important with a web application. The negativity he believes comes from people worrying that such frameworks commoditise user experience, will block development of alternatives or even somehow remove creativity from web design. Winer believes that the benefits of adapting to resources like Bootstrap allow developers to build ever better software on these foundations rather than wasting time on the basics over and over again.
I heartily concur with his opinion. From my own perspective I have found working with Bootstrap to be a great experience allowing me to concentrate on the nuts ands bolts, nitty gritty of development without having to worry about how form controls look by default. Bootstrap offers a standardised and useful set of defaults that allow the developer to focus on content and usability rather than wrestling with getting the same appearance with a dozen different browsers. All that and it doesn’t look half bad either.
One of the cornerstones of development is to not repeat yourself. Using third party frameworks or developing your own saves wasted time and allows us to focus on the needs of the customer. Bootstrap is the beginning. The rapid take up and support it has generated shows there is a need for such frameworks. Eventually there will be replacements and soon thereafter Bloggers complaining that everything looks the same. Again.