Posts Tagged practice
Scrum Teams – Lean, Mean developing machine
Posted by Craig_Strong in Development, Scrum / Agile on January 11th, 2010
In the past few years I have read about Scrum, Agile and watched many a tutorials and short videos on the benefits and how to implement it in the work place. After watching from a far I managed to get my hands dirty and get involved with applying it in the workplace. Over a period of many months, bit by bit we have implemented it into our development environment. I have to say it hasn’t been easy and it’s only possible with support from the business in my opinion. Developers and testers were the first to welcome the change as it empowered them and gives them recognition for their efforts as well as control. The business took longer as the change is drastic and involves them a great deal more in product development. However once involved, the agility and development speed and project transparency becomes something recognisable and desired.
During this implementation a common emphasis raised via many sources is to keep the teams small and focussed. Many comparisons have gone through my mind, including why and how to select certain people and create teams. One of the best comparisons and inspirations to make sense of this is to compare the military structure. The comparison that strikes me is that traditional waterfall teams which consist of large scaled divisions that progress in linear fashions with a great deal of resources and structure. They take a great deal of planning, authorisation and strategy to get momentum. When the momentum has started, it’s difficult to stop and change direction. These can be compared to a military invasion, invading in stages as one large force following months of planning and financial investment all moving towards a strategic location in mass. Scrum teams to me represent a different dimension to this, I see scrum teams as small, more precise well equipped units similar to special forces. Smaller teams which are empowered, focused and take more control over their missions who often find themselves more capable and agile. They can be deployed into many different environments, are quicker to adapt and are in and out of missions quickly, sharply getting maximum results.
When you have the balance in place and the team become used to this way of working, the business will benefit and get results. Results which require less investment over time and able to see the impact and return of having small, specialist teams. After all, we have all seen renditions of the battle of Thermopylae, which is basically a tale of a small force with superior weapons, training and passion taking on the might of an army. Although not a direct comparison I think there are similarities in structure do compare in very distant kind of way. The strategy depends upon the business’s plans and objectives, but ultimately every business wants to get more from it’s resources and wants to be able to be quick to respond to environmental conditions to stay ahead of the game.
Common Misconceptions of PHP
Posted by Craig_Strong in Design Structure, Development, Frameworks, Security, Software Reviews, Zend Framework on January 2nd, 2010
As we have just rolled over to 2010 I thought I would compile a list of 4 common questions often raised against PHP from people within the IT industry (no particular user groups). Each of these 4 statements were mentioned to me within 2009, but stem back many years in some cases. Some of these questions demonstrate plain ignorance in some cases, others just a little confusion as a result of lack of understanding or exposure. Therefore I hope this contributes to clearing up some obvious misconceptions by my provision of some brief answers.
- PHP is not a secure language
- PHP doesn’t have good support for OOP
- PHP is slow
- PHP is an amateur language
Believe it or not this was stated to me by a highly ranked person within the development community. I was very surprised that such a statement was put forward considering PHP is a scripting language and security is not a definitive answer, but an on going process in which every facet of IT must undergo constantly to remain secure. To clarify this is a case of blaming poor workmanship on the tools. Although some tools are better than others, in no way do I believe this statement to be true. PHP can be as strong as the best of them in terms of security and some of the worlds most secure systems including many systems of the financial services industry as an example which hold vast amount of sensitive information can be found to be written using PHP. When using a tool to build something, the end result is that of the craftsman effort, ability, knowledge and experience. Keeping the argument of operating system security out of this which would be hosting PHP, to obtain security you need good, experienced and security aware developers. I personally believe this misconception often raises it’s head because of other languages restrict development to the framework or coding environment and developers within these environments don’t have to confront some areas of security as a result of this. I don’t think it’s good for developers to rely upon security being dealt with away from their application by making it someone or something else’s responsibility. A good craftsman will make it their job to be aware of system security and test their application before release as well as include continuous monitoring and alerting tools to support the application. Obviously there are those which specialise in such areas and their knowledge should be referred to in times of doubt or curiosity via supporting texts and communities. PHP is as secure as the developer’s knowledge and testing/release procedure involved with it as with most other languages.
I’m surprised that some people still think this. Before the release of PHP5 including the Zend 2 Engine, which was 13/07/2004 this would have been true. However please keep up people, we are in 2010 now and OOP support for PHP has been in place for over 5 years! I haven’t written procedural code for years with the exception of the odd testing script and procedure. There are great libraries available as well for those looking to extend OOP ability including such libraries as SPL, PECL, PEAR to name but a few. There are also some very fast moving and powerful frameworks available fully supporting OOP including such Frameworks as Zend Framework, Symfony, CakePHP, Codeigniter. These are also become very popular and demand for such frameworks from the workplace is rapidly increasing (see my other post).
Yes believe it or not I have heard people claim this. PHP is pretty damn fast as a scripting language written in C. If people say PHP is slow, I don’t believe the have looked at the problem or debugged their code well enough. There are so many factors that influence speed such as the OS, memory, debug code, logging scripts, the implemented code, other applications on the server etc. If your PHP code is running slow, debug it and find the problem. It’s likely that the problem could sit with any of the above or it could be badly written code. There are good debug tools out there such as Xdebug which could save you some time finding the problem. Remember PHP is so versatile you can even extend it in C. If you are doing something very complex in PHP and by taking it down a layer might reduce some of the functions taking some time, you have the option to write an extension if needed. I personally have never had to do this, but have seen it done for a workplace specific extension and it worked perfectly and very quickly.
With full OOP support and factoring in that it’s one of if not the most widespread scripting language and as mentioned briefly in point 1 above, you can find PHP in almost all industries. Now I am not one to suggest the best technology is the most widespread (no names mentioned). However if PHP was a amateur language why is it so popular in so many professional industries which demand professional results. You can write pretty much anything you want using PHP and it can be as simple and complex as you want it to be. I have used Java quite a bit in the past and often find myself using the same code design texts to reference my PHP objects as my Java objects. I even apply the same design pattern sources for both languages. An example is the built in observer pattern interface in Java, (java.util.Observer) PHP also has this (SplObserver). Again I feel that stating that PHP is amateur is missing the point that PHP it’s a tool for the job. If amateurs use PHP you might get amateur results by the same token if professionals use it you get professional results, which is obviously the same as any other language.
Overall I think some of the questions or statements raised above are raised as a result of lack of understanding. As with most things in life some people scratch the surface of an area of interest and call themselves experts. The same experts make such judgements which create barriers for others. This could reading a text titled ‘Learn PHP in 24 hrs’ then calling oneself an experienced programmer or taking your driving test after a couple of lessons in a controlled environment and calling oneself an experienced driver confident enough to race with the likes of ‘Jenson Button’ and expect to win. Personally I have been using PHP for over a decade now and I am still learning new things everyday, particularly through exposure of different implementations. The language is moving fast with PHP6 arriving soon as well as many new and exciting related projects becoming available such as the array of frameworks which provide common interfaces to integrate with many different technologies. I would encourage anyone to look under the bonnet and get to know PHP in more depth and hopefully you will see the true power and capabilities of it.
How to explain MVC to a business and convince them it’s something they need
Posted by Craig_Strong in Design Structure on May 17th, 2009
A common occurrence many development teams will encounter is a where an older system not designed to scale well, will need to consider scale to support business demands. Businesses need to move quickly and purposefully to cope with consumer demand upon services as well as innovation induced development to compete within the market place.
It could be that your current system was designed to meet previous business goals and the extent of the specification was simply to complete a given task. You might be finding that recent business demands are taking a great deal of time to implement and that the smallest change is having huge impacts on the existing code structure. This could be as it is in so many systems, a result of tightly coupled code which is infected with design debt, or it could simply be that the original design of the systems structure didn’t consider growth and re-usability beyond the scope of the original spec.
If this sounds familiar to you, you’re probably spending a great deal of time on system maintenance and testing. The smallest changes are having huge impacts not only with relation to system integrity, but having a negative impact on the professional image of the development team. Depending on how far you have gone down this road, the business could be seeing IT as a wasteful, incompetent resource.
As you’re reading this post, it is likely that you’re thinking that to make things better you are looking at introducing MVC (Model, View Controller) into your system architecture. This MVC structure maybe something that is being encouraged by a chosen framework or simply a structure you wish to introduce into your existing system whilst refactoring your code. Either way to gain project time in most cases the business have to recognise the need for such a change and allow resources to be allocated to move towards this place where the grass is said to be much greener.
Now you are in a situation where the business already blames development teams for slower production times and pretty much for all problems and bugs that are inherit from a system which may have been subject to the ‘Big Ball of Mud‘ scenario. How can you go to the business asking for more time and resources to work on a project which unlike a product development has no physical delivery. After all if you are moving your system to MVC and/or using a framework there maybe no physical difference in the end product initially. Why would the business want this? Where is the ROI?
Respect the old code and the business
When approaching the business it’s best to be honest and upfront. There is no gain to be had blaming individuals for the current state of the system. It not only looks as if you’re diverting attention, but your colleagues aren’t going to appreciate you pointing the finger away from yourself in their direction. You should also remember at this point that it’s this system which has supported the business to date and is likely to be the same system that is supplying the current revenue stream. Although the system may need work, it has done it’s job to date.
Don’t hide the facts and don’t cushion the blow
The first rule here is to respect the business and tell them the truth. I’m sure you will be surprised to how much they actually know and that could be your first factor in common to working together towards the solution. There are plenty of examples out there on the web of successful companies who are and have been in the same situation of introducing MVC and/or Frameworks. It would be a good idea to use some of these examples as this will not only provide a knowledge pool of what did or didn’t work well, but will reassure the business that the problem the system is suffering is very common and there are clear paths forward. There is no gain to be had by raising an alarm defining how bad the current system is without researching and demonstrating clear ways forward. This won’t aid your case of supporting the development of a new structure. Use real cases and put forward some other success stories where this change has been successful to inspire the business.
How did we get into this mess
The old saying ‘Learn from your mistakes’ is relative to this exact moment. However to learn from your mistakes, you must recognise that you have made mistakes.
There are thousands of reasons why systems can incur significant design debt. Many of these reasons are comforting to know as they can happen naturally by the very nature of simply being active within successful business. It’s very likely the reason your looking to for a framework or MVC structure is that you want to support growth. Business growth has taken you to this point in time and that business growth is a commendable asset and a reassuring factor to be presented with.
Common factors of business growth that influence systems and incur design debt could be the following:
- The business has grown so fast, very little resources have been available to maintain the design.
- Corners have been cut in development to ensure products are released in a short time and therefore generate income quicker. The short cuts have never been revisited and therefore they become permanent. Additional development therefore have inherited the previous problems.
- The purpose of the system today is very different to when it was originally designed and limited effort was proposed to make the transition. Instead quick fix cultures were applied to change the identity of the system.
- Customers have become larger. As a service grows you might have moved from B2C to B2B or both. This can drastically change the demands on the system and the original business intentions/system did not consider this change or scale of change
- Limited knowledge available. In fast growing businesses the developers are expected to know all the answers without been given time to research. Therefore applying solutions are done through a limited knowledge base which is not given time to increase through training and investment.
No matter what your reasons are it would be a benefit for IT and the business to share and understand some of the reasons. Both sides understanding these will help prevent mistakes being repeated in the future, but will also contribute towards design and research to be key elements in future solutions.
Remember if your system is cracking at the seems as it can’t scale well, this could be because the business is growing fast. You would do well to respect the business for this and at the same time use this fact as a reason for current system problems. If the business is successful it’s likely they will take this on board and appreciate that speed of growth has affected development. This could provide you with the opening of working with the business to get the systems into a more robust agile condition.
Introduce MVC
Remember the business are non-technical and using jargon like frameworks and MVC is likely to confuse the listeners and as a result put up barriers. The reason you are proposing MVC as a solution is that you probably want a clear system structure which will be provide an environment which is easier to develop and maintain. However before you start getting this message across you need to explain what MVC is and what benefits it will offer.
Define the existing structure clearly
One of the reasons you might be looking for an MVC structure is that your current code structure involves code where the interface incorporates business logic, or the business logic is coupled with system logic and so on. Ignoring the reasons for this as we have briefly mentioned them above, explain this is the case to the business. The better you get the business to understand this situation the more likely they will sympathise with you and understand why there is higher maintenance times and deployment issues.
Some further reading can be found here:
http://en.wikipedia.org/wiki/Spaghetti_code
http://www.laputan.org/mud/
http://www.codinghorror.com/blog/archives/000589.html
Define MVC in layman’s terms
Remember you’re technically minded and close to the code. MVC to you is as clear as day, but saying to the business ‘Model, View, Contoller’ could give them the impression that you are suffering from some form tourette syndrome. MVC won’t mean much to the business even after you define them in relation to the code. To get the business to understand why this is the answer and least of all what it is, can be more of a task than expected in my experience. Even some fellow developers have difficulty understanding this on occasion.
To get the listener to understand what MVC is and why it works what I have tried in the pass is to apply MVC to a different industries where the listeners have had more involvement. An example that has worked for me in the past in a comparison to the property or even the vehicles. Most people have had dealing’s with builders, carpenters, plumbers, electricians or have watched the flood of property shows on the TV. This experience is a good platform to use and to explain why separation such as MVC works. I know you’re probably thinking that won’t work as it’s not the same as in software, but remember you’re not trying to train the business to become developers or have an in depth understanding of MVC, simply explaining to them that separation in production is required and that’s what an MVC structure offers.
To give an example of how you could describe this I have very briefly explained how separation works in property. Keep in mind this is focused on using the system not developing which could be a completely different angle of explaination.
View
The view in MVC is the presentation layer. This is what the end user of a product will see and interact with. A system can have multiple views of all different types ranging from command line output to rendered HTML. The view doesn’t consist of business logic in most clear designs. The interface is fit for purpose and is the area of interaction. Therefore you could simply output HTML for consumers to interact with or output SOAP/XML for businesses to interact with. Both use the same business logic behind the system otherwise known as the models and controllers.
In the world of property you could think of the view as the interior of a property or the outer layer of a property that the inhabitants interact with. The interior can be customised for purpose and the same property can have many different types of tenants. For example a property of a particular design could contain residential dwellings. The same internal space could easily be used as office space, where although in the same property has a different purpose. However the property structure is the same. Therefore the environment in which the users interact does not interfere with the structure of the building.
Controllers
The controller is where the magic happens and defines the business application logic. This could be where the user has sent a response from the view, then this response is used to process the internal workings of the request and processes the response back to the user. Taking a typical response where a user has requested to buy a book. The controller has the user id, payment details, shipping address and item choice. These elements are then processed through the business logic to complete a purchase. The data is passed through the system into the model layer and eventually after the entire request satisfies the business definitions, the order is constructed and the user receives their item.
If we compare this to a property, we could compare the ordering of a book online to turning on a light switch. A tenant will flick the switch to on just like ordering a book. The switch itself is an element in the view layer which sends the request to the controller just like clicking a checkout button on a web site. The business logic in this case is what the electrician installed and are embedded within the property designs. The switch is flicked, which completes the circuit. Electricity runs through all the wires including the fuse box straight through to the light bulb. Just like the user receiving a book, in this case the tenant receives light. The whole process behind the scenes involving the electricity cabling is not visible to the the tenant. They simply interact with the switch within the space and from there the controller handles the request.
Models
The models in MVC are the bottom most layer and handle the core logic of the system. In most cases this could be seen as the layer that interacts with the data source. In systems using MVC, the controller will pass information to the model in order to store and retrieve data. Following on from the example above controller definition, this is where the order details are stored. Additional data such as stock levels, physical location of product of the book amongst many things are all stored here. If that was the last book in stock ordered, the next request for this item may check if it’s available and disallow the order as the item is no longer available.
Sticking with out example of turning on a light switch, this level in our structure could be the electricity supply. When the tenant flicks the switch, the internal circuit must request electricity to power the request which is similar when the user requested data from the database, as in data is needed to process a request. If the dwelling isn’t connected to an electric supply, it cannot complete the process.
Business benefits from using MVC
After you get the message across explaining what MVC is, you will then have to see what benefits can be obtained from it. I’m not going to go into a huge amount of detail here are I’m sure you can apply benefits more accurately which are directly related to you actual situation. To list just some of the common benefits of an MVC based system here are a few examples:
- Different skill levels can work on different system levels. For example designers can work on the interface (View) with very little development knowledge and developers can work on the business logic (Controller) with very little concern for the design level. Then they simply integrate together on completion.
- As a result of the above separation projects can be managed easier and quicker. The designer can start the interfaces before the developer and vice versa. This development process can be parallel as opposed to being sequential therefore reducing development time.
- Easy to have multiple view types using the same business logic.
- Clear route through the system. You clearly know where there different levels of the system are. With a clear route of the system, logic can be shared and improved. This has added security benefits as you clearly know the permitted route from the data to the user and can have clear security checks along the route.
- Each layer is responsible for itself. (Relates to point 1) This means that you can have clean file structure which can be maintained and managed much easier and quicker than a tightly couple system where you may have lots of duplicate logic.
- Having a clear structure means development will be more transparent which should result in reduced development time, maintenance problems and release cycles if applied properly.
Get the message across
If you’re still reading this article you maybe either thinking the example above is a good idea or that it’s just plain silly. No matter what you’re thinking, the goal here is to get your message clearly. If this example doesn’t work for you, try finding a solution which will have the same affect. The point is for the business to support you and to consider repaying the design debt you will need them to understand what problems the current system suffers from and how you can improve things. MVC is just one of many ways forward, but they will need to understand MVC to give you the green light and have time to implement it and factor it in future projects.
This has been written from my own personal approach. However if you have something to add to this post in order to give it value, please provide some feedback. It will only improve things for the next reader.
Related Links
Common svn commands using the command line
Posted by Craig_Strong in Subversion on March 28th, 2009
Over the past few months I have been switching between operating systems which have included, Cent OS, Fedora, Vista and Mac OS X. When switching through these operating systems I am very aware of cross compatibility when using OS dependent software. Other than the obvious differences which include such things as file systems, one thing I have been quite frustrated with is interacting with SVN whilst moving between these operating systems. Why this has been frustrating it’s because for each of the OS’s above there is dependent software such as Tortoise SVN on windows. This is a great SVN tool and really does make things easier. However this is a Windows SVN tool so I can’t use it on other OS’s. Although there are tools available on other OS’s, I don’t want to keep switching between OS specific software as it can be time consuming and takes you a step further away from the source/task.
Why use the command line ?
As a result of the restrictions imposed when moving around different OS’s, I have reverted my svn interaction back to the beloved command line for most svn tasks. Now I know some of you reading this may see this as a step backward in the world of modern UI, but there are a few good reasons why I have made this decision:
- With the exception of running putty on Windows to interact with my svn repository which sits on Linux, the command line makes you closer to being OS independent when it comes to svn.
- Running svn commands on the command line is much quicker as it doesn’t have to go through the rendering process or additional layers of the OS or a series of extensive third party code. There is much less clutter, it’s just plain and simple (WYSIWYG).
- I have had problems with the OS network cache, such as when ‘subclipse‘ or ‘Tortoise‘ tell you that you are working within a branch when you are actually on the trunk! As you can imagine, this can have problematic knock on effects and this is where the command line doesn’t lie. You don’t need to click refresh on your working copy directory to get the truth, you simple ask it once and it tells you there and then, no caching involved.
- You don’t have to learn how to use each OS’s svn tool’s navigational menus and can therefore spend the time learning the commands plain and simple, saving you time in the long run.
Now I’m not saying that UI svn clients don’t have a value, the visual advantages can be extremely significant, especially when merging and looking at diff’s etc. You might find yourself going back now and again to use these tools for these advantages alone. The point is for general usage the command line has a significant value for me and for general svn interaction entering simple commands can be a time saver.
Everyday SVN Commands
For those who are interested and for an online resource I can frequent to compensate for my poor memory, I have listed a few of the common commands I use on a day to day basis below:Note: For the purpose of these commands I will express the path the repository as $REPO
svn log –revision 55:90
Shows the log history from revision 55 to revision 99
_____________________
svn log -r 66:44
Shows the log history from revision 66 to revision 44 in reverse order
_____________________
svn log -r 81
Shows the log specifically for the chosen revision 81
_____________________
svn log $REPO/branch1234
Shows the log history for a specific branch
_____________________
svn log -vr 1234
Shows the modifications for a particular revision
_____________________
svn log –stop-on-copy | grep-i “update”
This will show the commit history up until it finds the phrase ‘update’ in the commit log
_____________________
svn list $REPO/branches/branch-123
lists the directories/files within the selected branch-123
_____________________
svn switch $REPO/branch/branch123/siteA
If you are in your working copy site directory, this command will switch your current location to the branch you require. For example if you are in my/working/copy/siteA which is checked out to the trunk, this command with switch you over to your selected branch. Note : You can also enter this command as “svn switch $REPO/branch/branch123/siteA /path/to/your/siteA”.
_____________________
svn mkdir $REPO/branches/branch333
Creates a new directory within the repository. Within my example I have created a new branch.
_____________________
svn cp $REPO/trunk/siteA $REPO/branches/branch456/siteA
Checks out the site ’siteA’ to a selected branch ‘branch456′.
_____________________
svn diff –summarize –old=$REPO/trunk/site –new = $REPO/branches/branch333/siteA
Shows the list of files that are different between the two versions selected.
_____________________
svn merge –dry-run -r123:200 $REPO/trunk/siteA
carries out a dry run of a merge between the head of branch ‘r123′ and the head of trunk ‘200′. (A merge can be between any two revision numbers)
_____________________
svn commit -m “A brief, but informative message here”
This will commit any changes to your trunk/branch accordingly and record a message in the commit log. Remember you will be reading these log messages often. If you are working within a team ask yourself if someone else looked at the commit log could they work out what your commit involved from your message. Although sometimes seen as a repetitive task entering messages, these are there for a reason. It might be good practice to employ a message standard within your workplace to keep messages consistent.
_____________________
svn info /path/to/site/in/workingcopy
This will output the information for the file/directory within your working copy. You can know exactly where your working and the current status from this. Example :
craig-strongs:~ craigstrong$ svn info ~craigstrong/working_copy/
Path: /Users/craigstrong/working_copy/
URL: svn+ssh://craig@repo/my/path
Repository Root: svn+ssh://craig@repo/my/path
Repository UUID: 12345-12345-12345-12345
Revision: 875533
Node Kind: directory
Schedule: normal
Last Changed Author: craig
Last Changed Rev: 875533
Last Changed Date: 2009-03-25 16:46:59 +0000 (Wed, 25 Mar 2009)
_____________________
svn status /path/to/working_copy
This will list the current status of your working copy. If you have switched any files/directories, you should be seeing these listed within the results back. Other information such as if you have any uncommitted files will also be listed here.
_____________________
I’ll restrict the list to the above for now as these are what I consider to be the most common commands that I use on a day to day basis. If I find myself often writing other such commands regularly I’ll add them to the above. If you feel you would like to add to this list, please feel free to reply to this post.
Simple guide to creating effective web forms
Posted by Craig_Strong in Design Structure on March 8th, 2009
Getting Web Forms Right
It still surprises me when you speak to experienced developers and designers and they consider form design as a simplistic afterthought. It’s quite common for the form fields required to be clearly defined often derived from the chosen database schema, followed by the common expression of “form validation” to solve all input problems. Validation which is often reliant heavily on client side javascript. Speaking recently to an associate on this subject, the idea of planning a form beyond this level was an inconceivable idea and a pointless exercise. They considered forms to be a simple process and a laborious chore which is part of standard development. Personally I am a firm believer in the age old expression “Failing to plan is planning to fail”.
As websites and web based applications require more information from users, forms become more in demand. Some forms are well presented with clear thought of structure which include step by step guides and visual aids, others are very long winded and complex where the very sight of them can deter users. What is often overlooked is that we are trying to invite the customers/users to the business to spend money. Sometimes forms are optional processes for customers and unless you have a super brand with incredibly loyal customers, failing to consider user experience when creating forms could be losing you custom and therefore money. In the real world this is the moment where the sales person usually sharply dressed sits you down at the desk and offers you a cup of coffee before asking you some personal information. Now offering a cup of coffee isn’t an option on the web, but considering the users experience is.
To enhance the users experience web forms should aim to be simple for the user to understand and navigate and quick for the users to complete. This is easier said than done in the real world. If we look at a simple phone number as an example, what variations could we expect? It would be common to check for numeric values only and string length to validate the entry. However let’s look at a simple UK phone number (029 20123456) and see how the rule would apply if we simply looked at numeric values. Here are some examples how users may enter this phone number on a form:
- 029 20123456
- 02920123456
- 29 20123456
- +442920123456
- +4429-20123456
- 029-20123456
- 02920 123456
- +4402920123456
This small example clearly shows that the assumption of checking for just numeric values in validation would fail in a lot of cases. This could end up frustrating the user or provide poorly formatted data to the system/recipient. This example although confined to phone numbers extends to all fields specified.
With this in mind I have compiled a list of common issues to consider when designing forms.
Lengthy Forms
Although forms should be concise where possible, sometimes there are occasions where the user will need to submit a great deal of information. This is commonly seen when providing details for insurance quotations. If you require allot of information try constructing the form to allow the user to return at a later date to complete the details and break the form into logical structures/steps to help orientate the user. This could mean you have to save the form details for that user.
You might also want to consider re-using data where possible to assist the user. An example of this is a persons address. If they have an address stored in the system, give them the option to use a default address rather than assume they will have to type the same address twice or more in different locations of the site across multiple forms.
Filter Input
As with the phone number example above try to “expect the unexpected”. Don’t assume that the user will provide a format which you expect. Research all the possible variants that users could provide through such methods as user testing prior release. A good way to do this is to create physical forms asking your colleagues,associates,family or friends to fill in the data on a sheet of A4 and analyse the formats they use. When you have what you consider to be a definitive list build the rules into your logic. You can filter the input using the variants found to create a common format to enter the database, providing you with a higher value in data integrity.
Highlight Required Fields
Although you would like as much information as possible from users, some users value their time highly. In this scenario it would be better obtain what you deem to be essential information from many users rather than obtain more detailed information from a less users. Over time if the users which see a value in your product they will provide more information anyway.
To achieve this goal, break your form into what you feel are required fields. These are the fields which need to be completed for the user to move onto the next stage. When you have identified these fields, highlight them clearly to the user before they start entering data. For example if they see 5 essential fields in a form with 20 fields they will be more willing to submit their information. You often see forms using the * symbol to highlight essential fields.
Visually presents the user with the fields required.
Present Field Limitations
If you have restrictions on fields such as where usernames have to be between 8-20 characters, present this to the user up front. Don’t make the user fill out the form, submit their entry then present them with an error message. This slows the process down and frustrates the user.
Presents users upfront information about limits within the field and helps avoid frustration.
Restrict Entries
Similar to the phone number example above some fields could be entered in countless formats. If possible restrict the ranges in select lists forcing the user to choose a value rather than enter one. A good example of this is dates. There are only 12 months in a year so why not give the user a list of 1 to 12. This avoids confusion and allows you to gather data in a consistent format. In the date example you could go a step further and provide a small calender.
Provides a valid format to the system and helps the user choose a valid date clearly.
Disable Action Buttons
Most forms contain buttons of some description. Some include helpers such as postcode/zip code look ups. When a user clicks a button or invokes an action provide feedback on the current status to prevent confusion. An example would be when a user invokes a postcode/zip code lookup, present a message such as ‘Locating address’ to the user and disable the action until the response is obtained. This prevents the user requesting more than one action at a time. Another good example of this is disabling the ’submit’ button on a form when pressed. If the data is in the process of being submitted, not disabling the ’submit’ button could result in the user accidentally submitting the form twice. In the event this is a payment submission this could result in two orders depending upon the way you handle submissions.
Lets the user knows in real time an action is being carried out in response to their action.
Save User Data
No matter how much you present hints and cater for various formats a user could enter, users will make mistakes when entering data through a form. There is nothing more frustrating to users than submitting a lengthy form to find out they missed a field and all the data they just entered has to be entered again. It would add considerable value to the user experience to save the submitted data and re-populate the form fields using the data when the form is refreshed. This would avoid frustration and save you and the user time obtaining/submitting the data.
Provide Help and Hints
It’s easy for tech savvy designers, developers and businesses to assume too much and expect users to know the internal company jargon. It’s safer to assume not everyone knows what an OpenID is or what your internal company number is and this will add value to your form. Where possible provide helpers and hints with clear examples of valid formats. For example if you require a date, give an example such as 12/05/09 or dd/mm/yy. This will help the users enter the data in a valid format and is a step closer to preventing user frustration.
The links below the field give the users an option/help to learn more about the field value.
The above guidelines are not definitive. There is a lot to consider when designing forms. Essentially what your aiming to do is obtain as much information as possible without deterring or frustrating users. If you aim to satisfy this task you will achieve better customer satisfaction and higher submissions from your users, adding value to your site.
If you want to read more on this subject or about general defensive design issues for websites, I highly recommend reading this great book from 37signals (Defensive Design For The Web)
Please feel free to comment on this post. If you think I’m missing anything obvious and adds value, feel free to post a comment.
Welcome to c6s.co.uk
Posted by Craig_Strong in Personal on February 23rd, 2009
I have finally managed to get enough time together to start this blog, which I something I have intended to do for quite some time. The reason why I have eagerly anticipated this is because I often find myself taking notes off-line regarding my personal experiences whilst developing, as well as posting and reading other related issues across the web. The common problem with doing this of course is that I can’t access these notes from other locations and the notes are confined to just myself. So this site should provide me with a resource where I can record development notes and experiences and share these with like-minded readers, who no doubt can provide valuable comments to my forthcoming mistakes and presumptions.
If reading my notes are anything to go by, I’ll be trying to focus the posts on development issues that I experience which will hopefully include examples of problems I have solved whilst developing. These will be based around the technologies I use on a regular basis.
Within my normal working ethic, I try to encourage those around me to speak up and voice an opinion and question my work. In my experience good communication leads to better development which helps everyone learn from their mistakes. So if my posts raise concern or you feel I’ve completely lost the plot, please don’t hesitate to comment as I’ll appreciate the feedback.
Thank you for visiting.
