Setting up a development enviornment for developing SpringSurf apps

Setting up a development environment for developing with SpringSurf is not as easy as you might thing...or is it just me? Below is a quick and dirty listing of the things you need as well as some of the gotchas you might run into. Before I do, I should mention that there is a great tutorial at which is more or less what you need.

What you will need

  • Apache Maven installed and available via the command line.
    There is an issue on windows based environments whereby paths with spaces in it can confuse Maven. Depending on where it was installed, you may have to shift some of the files around. See this bug description for more details.
  • SpringSource Tool Suite
    This is more or less problem free, however I can never get the maven dependancy stuff to work straight off. I think you have to do some kind of rain dance whilst tweaking the nose of a white haired rat during the rainy season and then you will probably get it to work. In my experience it is better to run from the command line. Go into your working directory and use the mvn jetty:run command and things will run a lot more smoothly (if you're still having problems, try a mvn clean first and see if that helps). Make sure you install the SpringRoo addon at the same time.
  • A working Alfresco install.
    You obviously don't need this if your SpringSurf application isn't going to be using it, but it's best to have it running locally and then shift to a remote server once you've got it working. Alfresco by default (if you are using Tomcat) will run on port 8080, whilst Jetty will run on port 8180. So there shouldn't be any conflicts. 
  • Coffee
    Or some other form of pick me up. Rest assured you'll be spending many a long night screaming at the screen whilst your kids grow up around you and your hair gets gradually whiter. Ok, not quite that bad, but it takes some getting used to.

Alfresco: Wish List

There is no doubt about it, but Alfresco is already a great system that can allow you to do a multitude of things, but, things can always be improved upon. I would imagine this will be a constantly evolving list, but here's some wishes to start with. If you have anymore, let me know and I'll add them in.


The bods at Alfresco realised a while ago that configuration was a pain and not in the least bit simple. So in recent years they have moved away from hand editing XML files to using property files. And now, they have introduced JMX interfaces to make life even easier. However it would be great to get some nicely presented GUI that would allow you to do most (if not all) of the configuration. It would increase adoption as the learning curve would drop and may ultimately reduce their support costs in the long wrong. A nicely presented GUI for expanding the content model would be a dream come true!

Alfresco Share

If you don't already know, Alfresco Share is a content collaboration platform that makes it easy for people from across an organisation to collaborate on content. Whilst it has come on in leaps and bounds since its original outing, there are a few things that could be improved. Given that Alfresco seems to be putting most of their development into Share, some of these might actually already be in the pipeline.


At the moment it is possible to invite people to join a Share site with different levels of permission (Manager, Collaborator, Contributor and Consumer). It is also possible to vary the permission levels of those groups within a directory. So, for example, you may want to say that only Collaborators have access to this area and everyone else doesn't have access. But it would be nice to be a bit more granular about it. Could we instead say that Joe Bloggs only has access to this area. This is possible in the now creaking Alfresco Explorer, but as far as I'm aware, not in Share.

Batch Adding

One of the nice things about Share is its ability to invite people to join the site. Whilst this is great for a small number of users, it would be nice to be able to batch import people. For example if I was wanting to use Share as an intranet, whilst I could make the site public and let people find it that way, it doesn't show up in their list of sites. Instead, it would be nice to say that everyone is a member of the site.


As you add new users to a site, they all get an invitation. Whilst this is all very useful, there are times where it would be nice to turn it off. We have had cases where people have simply kept clicking on the join link in their email to access the site, rather than learning how to navigate to it properly.

Sharing between Sites

As far as I'm aware, as it stands, content within a Share site is isolated from other content. I can't move that content, or share it with another site. This can cause duplication of effort. It would be nice instead to have some mechanism to send it to another site. For example, I could have a collaboration site for a team of people who are working on a specific set of procedures. Once those procedures have been finalised, they send it on to a public site that contains all the procedures for public reference.

Automatic Setup of Content types based on Content Model

Again, another great feature of Alfresco is its content modelling capability. Whilst I can just about cope with creating the XML file to extend the content model, what gets really tedious is then having to extend the Alfresco clients as well. This would probably closely relate to my point above about making it easier to configure Alfresco.


This is perhaps one of the biggest areas in which Alfresco is lacking. Meaningful management reporting information. At its most basic, I'd like to have an area that lets me see how much space each user is using, how much space is each Site using. Can we see who the most active users/sites are. Who is approaching their quotas. The list could go on.

Backup / Restore

We back up Alfresco on a nightly basis, but restoring that information isn't really an easy process. If a file has been deleted from Alfresco and needs to be restored, it's not a trivial process. Instead it would be nice to be able to point Alfresco at our backups and click the file we want restored and away it goes. I can see infinite complexities with this wish give the myriad of backup options etc etc, but it would be nice!


It is possible to assign quotas to users within Alfresco, but what would be really nice is to assign quotas to areas. We have people that deal with huge amounts of data and what we'd like to do is make sure that they are putting appropriate data in Alfresco and not just using it as another storage medium for mp3/video/etc.


Building Your First Webscript

Webscripts are fast becoming the main development tool for those who are seeking to extend and enhance Alfresco. In this article I'm going to try and detail how to build a webscript. This is as much for my own documentation needs as it is for public consumption. So if you notice any errors, then please let me know!

Webscripts can sit in a variety of places, from directly in the Alfresco repository, to sitting within their own SpringSurf apps. However, no matter where you put them, they all have a similar structure.

  • XML descriptor file that tells describes important aspects of the webscript (Required)
  • Javascript file that does some processing etc (Optional)
  • Freemarker template file that returns some nicely presented information to the user. (Optional)

Although the second and third of the above elements are optional, you need to have one or the other, otherwise your webscript wont do anything.

Purpose of the Webscript

We're going to design a webscript that sits within the Webscript Extension area of the Data Dictionary. This could in theory be added to the classpath, but putting it in the data dictionary means you don't have to do a server restart everytime you change it. The webscript itself is fairly basic, and all it does is return back the structure of a given area within the repository. This kind of script can be used as the basis for site tree, or something similar.

The Descriptor File

This is perhaps one of the easiest parts of developing the webscript, and yet it can inself cause problems if you enter the wrong information. There are specific naming conventions that need to be observed for all webscript files. First comes the name of the webscript, then the type of HTTP call that is being made (GET, POST, etc), then the type of information that is being returned (HTML, JSON, etc), and finally the file extension. So for our webscript, we'll create a file called getsitetree.get.desc.xml. Here's the contents of the file.

  <shortname>Get Site Tree</shortname>
  <description>Retrieve the site tree from Alfresco</description>
  <format default="html">extension</format>

Let me take a little time to explain what this all means.


A container element that contains all the parameters of your webscript.


A brief shortname for your webscript that will be shown when browsing available webscripts. This can be anything you want.


What your webscript does.


This is a really important one. This is basically the url that your webscript will respond to. It is entirely up to you decide what you want to call it. You might want to group certain scripts under certain nodes (e.g. /node/script), or every script may just get a root name (/script). Give that for the most part you will be dealing with an evironment that has other scripts (Alfresco related) and not just your own, I find it is better to go for the first option for usabilitys sake.


This can include the default return type. One of the great things about webscripts is that one webscript can return multiple different types, all through the power of freemarker. So, for example, I might want a webscript to be able to return html, json and xml. But if no return type is specified, then whatever the default specified is, that is what is returned.


There are three different possible values for this.

  • admin
    Admin requires someone who has administrator priviledges for the Alfresco system (not just  for a specific area). Be aware that there can sometimes be a performance hit when using this one. As it has access to everything, there can be a lot more information to wade through than for just an ordinary user.
  • user
    Requires any user that can log in to Alfresco
  • guest
    No login required

Javascript File

Next comes the javascript file. This is the main engine of the webscript that will do the majority of the processing for you. The freemarker templates can do some processing, but that is more at the presentation level than the nuts and bolts stuff sometimes required. Following the naming conventions outlines above, our file will be called getsitetree.get.js (nothing being returned by this file, so no need for the html/json bit.)

var folder = companyhome.childByNamePath("WebStore/www"); 
model.www = folder.children;

This is very basic. What is does is declare a variable called folder that goes and gets all the children of the path specified. In this case it returns all the children of the folder "www", which is below "WebStore". Because we are using the companyhome root scoped object, this folder has to appear in the "Company Home" area of the repository.

Finally it declares a new variable in the model called www and loads it with the children of the variable we declared in the previous line.

Freemarker Template

Now that we have some information in our model, we can do some processing on it. We're going to pass this information back as html initially to make our lives a bit easier. So our freemarker template should have the filename getsitetree.get.html.ftl. Here's what it includes.

<#if (www?size > 0)>
		<#list www as child>
			<li><a href="${url.context}/home/page=${child.nodeRef}">${}</a>
				<#if (child.children?size > 0)>
					<#list child.children as grandchild>
	<p>Nothing to Retrieve</p>

This returns an unordered HTML list that gives the first two levels of our structure. What we might want to do in the future is change that so that it cycles through the entire tree, but this will suffice for the time being.

Line 1 checks to see whether there is anything in the www object. If there isn't, it simply skips to line 17 and tells the user there is nothing to retrieve.

Line 3 sets us up to access the child nodes of the object and output them, which is accomplished by line 4. Line 5 checks to see whether the current node has any children, if it does, the same thing happens again and those children are output.

Common problems arise from not closing your tags properly, so it is always the first thing I check when debugging a problem.

Getting Alfresco to recognise the webscript

Whilst I said above that Alfresco doesn't require a server restart, it does require an extra step so you can tell it to recognise the webscript. This is accomplished by going to "http://localhost:8080/alfresco/s/" and logging in with an administrator username and password. Click on the "Refresh Webscripts" link and all going well you should see your webscript count go up by 1.

Calling your Webscript

To test your webscript you can simply call it from the address bar in your browser. So for our example above, we would go to "http://localhost:8080/alfresco/s/alfrescocms/getsitetree".


Building Your First Webscript

Webscripts are fast becoming the main development tool for those who are seeking to extend and enhance Alfresco. In this article I'm going to try and detail how to build a webscript. This is as much for my own documentation needs as it is for public consumption. So if you notice any errors, then please let me know!

Webscripts can sit in a variety of places, from directly in the Alfresco repository, to sitting within their own SpringSurf apps. However, no matter where you put them, they all have a similar structure.

  • XML descriptor file that tells describes important aspects of the webscript (Required)
  • Javascript file that does some processing etc (Optional)
  • Freemarker template file that returns some nicely presented information to the user. (Optional)

Although the second and third of the above elements are optional, you need to have one or the other, otherwise your webscript wont do anything.

Purpose of the Webscript

We're going to design a webscript that sits within the Webscript Extension area of the Data Dictionary. This could in theory be added to the classpath, but putting it in the data dictionary means you don't have to do a server restart everytime you change it. The webscript itself is fairly basic, and all it does is return back the structure of a given area within the repository. This kind of script can be used as the basis for site tree, or something similar.

The Descriptor File

This is perhaps one of the easiest parts of developing the webscript, and yet it can inself cause problems if you enter the wrong information. There are specific naming conventions that need to be observed for all webscript files. First comes the name of the webscript, then the type of HTTP call that is being made (GET, POST, etc), then the type of information that is being returned (HTML, JSON, etc), and finally the file extension. So for our webscript, we'll create a file called getsitetree.get.desc.xml. Here's the contents of the file.

<shortname>Get Site Tree</shortname>
<description>Retrieve the site tree from Alfresco</description>
<format default="json">extension</format>


Alfresco, WebScripts and SpringSurf: An Overview

One of the great selling points of Alfresco was that if you want to do something a bit different, there's probably a way to do it. In the past this has been via Java APIs and whilst they are still there and still very powerful, there's a new kid on the block that is shaking things up a bit.

Webscripts were introduced in 2006 and have gone from being a useful little addon to being the main focus of Alfresco development. So much so that Alfresco are pouring hundreds of hours of development time into a new framework called SpringSurf (previously just Surf) that utilises the power of webscripts.

What exactly are the benefits of using webscripts I hear you cry. Well first and foremost, the learning to curve for picking up webscripts compared to Java is far lower. Webscripts are based on JavaScript (or ECMA Script for the hardcore amongst you), so if you have any previous knowledge (as most web developers will have) then you are hitting the ground running. In saying that, getting your first webscripts off the ground is no trivial matter in some cases. Getting your head around exactly how to interact with the repository via the JavaScript API, what root scoped objects are available and exactly how to present information back through Freemarker templates (yup, yet another open source technology) is not for the faint of heart.

However webscripts are more than just a nifty little tool to make web developers lives easier. Alfresco have created a script framework called SpringSurf. This project was originally code named Surf, but Alfresco in their wisdom have turned it over to the Spring community for development. SpringSurf allows you to build you own custom application that makes calls to an Alfresco repository (or any CMIS compliant repository) and the great thing is that it doesn't need to be hosted on the same server as your Alfresco repository. You can think of it in the classic LAMP sense (Linux, Apache, MySQL, PHP). Your SpringSurf application are like your PHP files, Alfresco acts like a MySQL database by storing data, with it all being run by Tomcat (or other similar servlet/JSP container) acting like your apache httpd server.

SpringSurf uses the well tried and test MVC method of programming (Model View Controller). Your controller does most of the hard computational work whilst handing data retreival over to your Models and then passes presentational information back to the user via the View. It's not the most elegant of frameworks to use it has to be said. For every webscript you will need at least an XML descriptor file and a either a freemarker template. Any information retrieval gets carried out in an additional javascript file. I wont even get started on the complexities of getting an application running and binding components to regions via XML descriptor files and naming conventions.

There is huge potential for SpringSurf to become a major player. As the knowledge management sector becomes bigger and bigger, more and more we'll need to be storing our documents and files in some kind of Document Management System. As we move to that, organisations will want to customise the capabilities to suit their enviornment, rather than trying to use a one size fits all product. However, SpringSurf has a major drawback which is holding back widescale community buy in.

It's still young, and it's still changing. For those who first got their hands dirty with Surf from Alfresco, SpringSurf introduces some changes in the way things are done. Documentation is still very poor, examples and tutorials are sparse at best, and community participation in the SpringSurf forums just isn't there at present. Thankfully those taking the lead on SpringSurf have recognised their failings in this department and are working on boosting these areas. And that in essence is the great benefit of a system like Alfresco. The developers actually listen to their users and react to the issues being raised. I have to give much praise to the likes of Mike Uzquiano at Alfresco who very kindly helped me with some issues I was having and listened to my many moans.

SpringSurf is currently available in its milestone 3 release which was originally planned as the final milestone before becoming an official release. However because of community feedback they are going to make an M4 release as well, which is hopefully due in the not too distant future. This will hopefully address some of the failings identified above in relation to ease of use and speed of development.


From download to production system

It has to be said, but unless you are a guru in Java, Spring, Tomcat, Oracle/MySQL and a number of other open source technologies, deploying Alfresco as a production system is no trivial matter. I should preface this article by saying that our production system runs on a headless install of Linux. I shall raise my head above the parapet for an instant to comment that this is not the easiest environment to do things in.

In saying that, the installation and configuration has come on in leaps and bounds since the early days of Alfresco. In the dim and distant past, configuration was achieved by hand editing XML files. This was no easy task and involved picking your way through hundreds of lines of bean configurations to try and find the correct variable. They moved on to the use of property files which made things so much easier.

We’ve come even further these days with Alfresco now providing a JMX interface to some of the most common configuration options. The technobods at Alfresco in their wisdom also included the ability to change these options without having to restart the server. In the past this has been the biggest holdup as waiting for a server restart could be tedious at best. When considering a production system, this is less than ideal.

Alfresco now comes with a built in MySQL database, so getting it up and running is relatively easy…assuming of course you don’t want to integrate it with anything. In addition, to get the full fat goodness of Alfresco Share, a number of other components need to be installed which can be problematic. I should add that a number of these problems are solved via the Windows installer, but for those of us on Linux distros, they are headaches.



Oracle is the DB of choice with our DBA firmly believing that everything from the first mission to Mars to world peace becoming possible through its goodness. From a humble sysadmin’s point of view, it has its own problems. A common gotcha is that Alfresco requires the Oracle jdbc driver to be installed before it will talk to the DB. It’s easily resolved by retrieving it from whatever installation of Oracle you are running and placing it in the lib directory of your Tomcat server (sorry, haven’t a clue about WebSphere, JBoss, etc).

ImageMagick and SWFTools

These little open source libraries are what make the thumbnailing and document previews possible in Alfresco Share. Whilst it is possible to run without them, you lose a major selling point to users by not including it. We run Alfresco on a 64bit Centos system and it would seem that SWFTools requires the latest version to accomplish this. Add into that a myriad of extra libraries that are required and you have a pretty complex installation with lots of strange error messages that are no use to man nor beast.


One of the benefits of Alfresco is that it has a multitude of access points. The most common of which are CIFS (think shared drives) and the web. Unfortunately, whilst it is possible to run Alfresco via the web interface allow both local and ldap logins, the same can not be said for the shared drive access (a failing of CIFS rather than Alfresco it should be said). Alfresco allows different authentication systems to be chained and for the web, each is tried in turn until a match is found. With CIFS, the first is tried and if that doesn’t work, game over!

Users and Groups

Alfresco has the ability to synchronise itself with an external LDAP directory. Whilst I have always been able to pull in Users, I’ve never managed to get the groups synchronised. The closest I’ve come is being able to get the group names, but they in turn are not populated with users. There is also a slight gotcha in that if you are not very careful, your users are recreated each time there is a synchronisation. This can cause problems in Share where the user is then denied access. 


We run an environment where everything is denied by default. So it can be a bit of a dark art trying to figure out exactly what ports should be opened. Sometimes the error messages generated by this can be easily diagnosed, others can send you round the world and back before realising it is a firewall issue.


This is perhaps one of the more confusing areas in Alfresco. It would seem to me, for an Enterprise Level solution, they don’t make it easy. Alfresco seems to recommend a cold backup as being the best solution. Whilst this may be the case, it isn’t an option for a production system that is being used 24hrs a day. When planning a hot backup schedule you have to ensure that the lucene indexes directory is not backed up. Instead Alfresco provides a nice helper routine that backs these up once a day in a different directory. It means if you have to restore your indexes will always be out of date, but restoring stale indexes is much faster than rebuilding them from scratch, especially if you have a very large repository.

You then have the backup of the database and filesystem. Whilst a database backup can take a point in time snapshot, a filesystem backup cannot (at least not with our systems). Therefore you have to ensure your filesystem backup is never ahead of your database backup.


Many people will want to protect their web interface using some kind of SSL certificate. Unfortunately trying to get this working seems to be a bit of a hit or a miss. I have managed in the past to get it working in Tomcat, but with no automatic redirect to a secure connection. I eventually had to give in and install apache httpd to handle the http/https redirects and certs and proxy through to Tomcat in the backend. This in itself does pose some problems with Share in that the flash uploader it notoriously flaky when uploading via https. Things seem to be stable with our install at the moment, but I’m just waiting for the day when the phone calls start flooding in after some random update of Flash. For those still using Internet Explorer 6, you may also have trouble downloading files from the Alfresco Explorer over https. This seems to be because of the way IE6 handles secure downloads, rather than a failing of Alfresco. Thankfully it is an issue that seems to have been resolved by later versions of IE.


Whilst I have listed a fair number of problems and gotchas that I have experienced with Alfresco, many will have been because of my lack of knowledge of the underlying technologies. I can’t pass by without saying that the Alfresco support agreement has be invaluable in solving these issues. Once you actually have it up and running, it offers up a world of potential to revolutionise your company into one that actually uses their data and not only stores it.


Overview of Alfresco

I've been involved in using and integrating the Alfresco document management system recently for the College of Life Sciences at the University of Dundee. I've read a myriad of reviews and guides on the system and so the time has come to add my voice to the mix.

Alfresco is an open source document management system. Whilst that description may seem boring and very unhelpful, the system itself is anything but. Contained within this little gem of a package is a system that is well on its way to revolutionising the way business will think about and do document management.

Alfresco, although only a mere five years old and a relative new boy to the document management scene, it has been making huge waves. Most of which have come in the past couple of years as it has moved on from being simply another "DMS", to being a system with a wide array of access points that can not only do document, but also web content management as well.

IT managers up and down the country no doubt cringe when they are presented with a system that touts itself as a open source technology. Open Source still suffers in many respects with the reputation of being a poor mans version of its much more robust and reliable enterprise level cousins. However I'm happy to say that those days are long gone, and now open source is fast becoming a major system of choice, not only for small business, but also the large corporations as well. It's "FREE" price tag being ones of its major selling points.

It's important to clarify exactly what flavour of open source Alfresco actually is. The technology it uses is completely open source, so in theory anyone could go and build a similar system from components freely available for download. But why would you want to do that when Alfresco offers its product free of charge? Yup, you guessed it, Alfresco has its own community version. Whilst the salesmen would no doubt tout this as being the same as the full enterprise version, there are some crucial differences.

Alfresco Community edition is bleeding edge and contains all the latest and greatest technology that Alfresco has to offer. The flip side of that is that it also has all the latest bugs as well. However that is the price you pay for getting to play with the latest tech ahead of its official enterprise release. If you know your Java from your Spring and are comfortable wtih conguring a myriad of XML files, then perhaps this is the version for you. However, buyer beware, if something goes wrong you are on your own (bar a little help from the very active forums). We unfortunately found that the hard way when it started to eat our excel files. As these files were of a legal nature and something we couldn't really have being corrupted, we had to ditch our initial trials.

And so we found our way onto Alfresco Enterprise edition, the more stable and reliable version which comes complete with a support agreement. Unfortunately, whether you are using the Community or Enterprise editions, it still lacks the grace and ease of use that the likes of Microsoft installers will provide you. However, with a little perseverance (ok, a lot!) and some help via your support agreement, you can get it off the ground and intergrated into your other systems.

In saying that, the bods at Alfreso have in recent enterprise only versions introduced configuration via JMX that doesn't require a server restart with every little change. This has significantly reduced setup times from days down to hours in some cases.

User experience with Alfresco has been extremely positive so far with the majority of our users taking great delight in the Alfresco Share collaboration package that comes bundled with it. No doubt I'll get round to writing a proper review in the not too distant future, but until then it is sufficient to say that it has placed Alfresco as a major competitor with the likes of Microsoft and its even more expensive rivals. Add into the mix the fact that Alfresco seem to be leading the way on the development of the CMIS protocol (Content Management Interoperability Service) and it's RESTful architecture and webscripts and you find yourself with a system that has the potential to integrate itself with just about any system, be it legacy or otherwise.


Preparing to build your website

You may think that the preparation for building a website starts with getting a web designer involved. In fact, this step shouldn't happen till closer to the end of the process. Simply going to a web designer and asking for a website without any planning, whilst technically possible will only result in an approximation of what you want and will ultimately not satisfy your needs.

There are a wide range of things that you should think about before you employ the skills of a web designer. The following is a summary and should not be considered to include everything. This will depend on your own situation and the purpose of the site. If you get to the stage of employing someone to do this, they should be able to guide you on other things to consider.

What do you want to achieve?

There is the mistaken impression that simply having a website makes you more accessibly to the general public. Well, whilst that is true, a bad website can have the opposite effect. It is therefore important to sit down and have a think about what it is you want to achieve with your website. Is it simply going to be a couple of pages giving directions to where you are, or is it going to become the next with huge amounts of content. In reality, what you'll want is something in between, and most importantly something that you can maintain. It sometimes helps to write down a mission statement for the website that is simply a couple of sentences you can refer to throughout the process. For example, it could be...

"We want to tell our local community about us"


"We want to tell our local community about us and also provide useful resources to other christians."

What should it include?

The following is not an exhaustive list, but one that should provoke some discussion about what you want to achieve.

  • A welcome message
  • A bit of background history on who you are
  • Some local history about the area you are in
  • Contact Details
  • A gospel message
  • Photos of your place of worship and your congregation
  • Audio/Video Downloads
  • Latest News
  • Latest Events
  • Information on the types of services/meetings you have
  • Articles on relevant topics

What shouldn't it include

This is perhaps a more difficult question to answer than what to include. Basically it shouldn't include anything that isn't relevant to your mission statement. It also shouldn't include anything that you can't keep up to date. There is nothing worse than going to a website and either seeing information that is years out of date, or that carries a "Coming Soon" that has been there for years.

Who is the target audience

I suppose the simple answer to this should be "Everyone", but in reality you'll want to target it to those you identified in your mission statement. When considering building a website for a local church, your focus really should be the community that you work in. Therefore you should try to find out as much about your local community as you can. If you are situated in an area mostly made up of elderly people, you'll want to gear your website in that direction. If you are in an area that is heavily populated with children and young familys, then that is the direction you should go.

What should it look like

This is where you research will have an impact. Depending on what type of community you are in will have an influence on what your site should look like. I've listed below some suggestions, but please be aware that these are broad generalisations and should only serve as a starting point.

The Young Ones

This may include people with your families, but it may also include those in their 20s and 30s with young familys. This generation has generally grown up with computers and the internet and therefore demand much more from a website. Sites should be quick to load and look professional. Regardless of the underlying content, many may switch off if this is not the case. Colour schemes can be a lot more bold and adventurous if required.This generation will assume the ability to interact with the website and feedback their comments on its content.

The Mid Lifers

The mid lifers are those in their 40s and 50s and whilst most would perhaps know a computer when they saw one, they can still remember when computers took up entire buildings and were for the academic and elite only. They look more for the information than the gloss desire by our previous generation and tend to be a bit more forgiving of sites lacking in the presentation department. In saying that, navigation and text should still be clear and concise with minimum effort required to find information.

The Silver Surfers

This is a term taken from the common hair colour of this internet surfing generation. Most would have stayed away from computers and the internet in the past in favour of a cup of tea and a biscuit in front of Countdown. However there is an increasing number of these people who are taking to the internet to meet new friends, follow up on hobbies and generally keep in touch with the world. Unfortunately this generation start to find that physcial and mental disabilities start to impair their abilities. The majority will have some kind of visual impairment, whilst others will find that physical disabilities are what hold them back. Sites should be clean and clear in their appearance with Accessibility kept at the forefront of the design. Font sizes should lean towards the large (or a font resize option made available at the very least). Important information should be easily accessible and not more than a few clicks away.

As you can see, there are many things that need to be considered before a web designer is even approached. In future articles we will consider what happens once we reach that stage.

Running a Childrens Club

Whether it is a Sunday School, or a midweek kids meeting, there is nothing more daunting than trying to run a kids club. It may be that you have a well established club that has been going for many years, or you may be starting one from scratch. Whichever it is, I've tried below to offer some helpful information on how to get the most out of your time with the kids.



This may seem obvious, but prayer is hugely important in a childrens work. Without it, you might as well shut the doors. Praying for it yourself is an excellent place to start. If you can get other people to pray with you, or pray for the work on their own themselves, so much the better. If you haven't been along to a prayer meeting in a while, then get along there and join with others to pray for the kids work (and other things as well!).


Before a child sets foot inside your club you should already have at least a couple of weeks, if not months, of preparation under your belt. Things will only happen correctly on the night if that has taken place. Here's a summary of just some of the things you'll need to prepare.


Who is going to help you run the kids club. Whilst you may be in the situation where you have to run it yourself, try and get others involved, even if it's just to sit at the back and boost the numbers. If there are others who are going to be involved, then it's important that you all sit down together and decide what each person is going to do. Every person should have a role, even if it's just sitting at the back and praying for the meeting.


What is going to happen every week? Are you going to do the same thing every week, or are you going to vary it? Whilst variety is the spice of life, remember that kids do like the comfort of routine, so try not to change what you do every week.


It is often best if the topic for each week is prepaed in advance. Whilst there is nothing wrong with leaving it up to each person responsible for the story to decide what they will speak on, advanced planning can bring everything together.


  • Look and see if you can not only tie each weeks activities together, but also the entire sessions activities together. This might take the form of looking at people Jesus met every week, or taking a different parable every week. The benefit of this way of working is that as the weeks go on, you can build on what was covered the previous week.
  • There are a multitude of childrens songs out there that cover a wide range of stories. See if you can't have a theme song for every story. For the kids that can't remember the story, perhaps the song will stick in their head longer.

Memory Verses

There is nothing better than seeing kids coming back week after week having memorised a passage from the Bible. Again, this is a good opportunity to tie it back to the story. You may decide that you want a different one each day/week, or you may decide that you just have one verse that is learned throughout a session to back up a central point.


  • It's all very well teaching kids a verse during the meeting, but you can be sure that as soon as they walk out the door they'll have forgotten it. Write the verse out on a piece of paper to give them home with them. One thing we have found particularly helpful is to give all the kids keyrings at the start of the session and each week give them another tag to add to the keyring. It keeps all the verses together, and as they get points for bringing it each week, you can be sure it isn't just lost.

Rewards System

This doesn't need to involve you handing out cold hard cash to bribe the little darlings to stay quiet for the duration of the meeting, but it should be something that rewards good behaviour and participation. Some will want to just hand out sweets, some will have some kind of points system. You will need to decide in advance exactly what you want to give points out for. Is it just for the quiz, or is it for good singing / actions? Do they get points for attending and bringing others? Whatever you decide make sure that everyone (yes, that includes the kids) knows exactly what is getting rewarded and what the reward is.

During the Children's Club

As I stated above, everyone should have a role during the meeting, even if it's just sitting with the kids, or praying at the back. Here are a list of some of the roles you'll want to identify.


This sounds very formal, but at its most basic, the Chairman simply tries to make sure everything is running on time. They should try to start the meeting as close to the intended starting point as possible, and finish it when it is supposed to finish. For kids who will be picked up at the end of the meeting by parents/guardians, it creates a bad impression if you are constantly keeping them waiting.

The Musician / Singer

This may be the same person, it may be two different people. Whatever the situation, they are responsible for leading the singing and trying to get the most out of the kids.

The Quiz Master

No surprise here, this is the person responsible for the quiz.

The Story Teller

Yup, you guessed it, the person responsible for telling the story to the children.

The Registrar

You will probably want to have someone who is responsible for noting which children are attending that week. Depending on how you work your rewards system, this person might also take note of them as well.

The Background People

Not everyone that's involved in kids work will be up the front. Many, if not most, will be working in the background. These kind of people are great for sitting in amongsty the kids and helping them out, keeping control, and also engaging with the mums and dads that will bring the kids.


Hopefully the above notes will help some people who are thinking about starting a kids work. If you are already involved in a kids work, hopefully it will give you some extra ideas. As with all things, the above tips are things that I have learnt work in the environments I have worked in. They may not work in all cases and should be changed to suit individual needs. If you have any hints or tips that you would like to share with others, please use the comments below to leave a message.


Telling a story

This is perhaps the most important part of a childrens meeting. You've done the singing and possibly a quiz and now you have the undivided attention of a group of kids. Make no mistake, it can be very daunting standing up in front of kids to tell them a story. However there are some things you can do to try and keep their attention and get your point across.


Prepare, Prepare, Prepare!


There is often the mistaken impression that taking a kids meeting is where beginners start and once you have found your feet you can progress onto greater things. The reality couldn't be farther from the truth. Preparation, whether it's for a kids meeting or a ministry meeting, is crucial. Therefore it is important to know your subject matter. You might be fortunate enough to stand up in front of a group of little angels, but it is far more likely you'll get one or two at the very least whose main aim is to disrupt. If you have to stop, starting again is much easier if you know the story like the back of your hand.


  • PRAY! Ask for help, ask for understanding and above all, ASK FOR MORE HELP!
  • Read the story through multiple times. If it's a story that appears in more than one place, read all the accounts. If you have different versions of the Bible available, read it through in them as well. Sometimes the slightly different language that is used can clarify something that you weren't perhaps clear on.
  • Make a list of the key characters in the story and write down one or two sentences giving a brief bit of background information on that person.
  • Write down chronologically the events in the story and make sure you know where each character comes in.
  • Think about the story and decide what points you want to bring out. Decide where in the story you want to bring them out. They don't all need to be kept till the end, but can be enumerated as the story progresses.

Keep it interesting

Gone are the days when children would sit in a Sunday School or Kids Meeting for an hour without any problems. We now live in an age when their every waking minute is taken up with some sory of entertainment. Whilst we are not solely doing this as a means of entertainment, if you fail to capture their interest, it is unlikely they'll listen to the story. Unless you are a fantastic story teller, having something for the kids to look at can make all the difference. Powerpoint is becoming the tool of choice in this matter, but don't rule out other methods just because they might seem outdated. Take the flanel graph for example, we might think that it is old and of no interest to children, but because many kids have never seen it, it can be a novelty.

The reason for providing something which the kids can look at is that some children learn by listening, others learn by seeing or doing. Providing visual as well as aural information can boost the liklihood of the children remembering what you are saying.


  • Whether it's Powerpoint, flanel graph or the OHP (OverHead Projector), you must must must must must prepare. Practice beforehand and know what comes after what.
  • If you are using Powerpoint, make sure that any animations you are using are coming up in the right order.
  • Keep your slides interesting. Bullet points are suitable for boardrooms, but in a kids meeting...too many and you'll lose a childs attention. Make use of pictures in your slides.
  • If you are using a flanel graph, have all your pieces laid out beforehand in the right order. It is then a simple case of picking up one after the other and sticking them on.
  • For those using flanel graph, make sure you sit all your bits and pieces on a sturdy object and far enough away from any draughts. You'll want avoid chasing the baby Jesus half way across the room when someone decides it's too warm in a room and opens a window!
  • For any other object, make sure that it works as you expect it to. For electrically operated objects, make sure the batteries work and are not likely to run out.

Keep It Relevant

Whilst it is good to keep your story interesting, making it too much fun can have the opposite effect. Remember why you are there. To tell them a story from God's Word, the Bible. If your method of keeping it interesting blocks the message from going in, then you're failing in your task.


  • I love using magic tricks when I'm speaking to kids. A well performed trick can stick in a childs mind for weeks, months, if not years. However there is the danger that they remember the trick, and not what the trick was there for. A magic trick should always be used to explain a point, not to impress the kids. I often find myself thinking "I have a trick, how could I use it?". Instead, I would be better asking myself, "I have a point to explain, how do I best do that?".

Keep Control

After all the fun of the singing and quizzes and whatever else you do, sometimes by the time it comes to the story the kids are getting tired, fed up and just want to go home. A disruptive child not only prevents themselves from hearing the story, they prevent others from hearing the story. Whilst a certain level of disruption is to be expected, too much and you are in danger of losing everyone.


  • As the kids meeting is progressing, try and be aware of what kids might cause a problem. Sometimes all it takes is to get another adult to sit with them during the story for the problem to go away. Sometimes it is better if you move the child to some other place in the room before you start (e.g. away from friends they were carrying on with).
  • Unfortunately sometimes a child's restlessness is down to your own failings as well as their own. If you see everyone starting to get a bit restless, try and do something a bit different that brings their attention back again.
  • Don't be afraid to stop the meeting to deal with a disruptive child, rather than trying to carry on.
  • If you are not the person who is telling the story, don't just sit back and relax, observe the behaviour and intervene yourself (without causing too much of a disruption).

Above all, remember why you are there. It is a sobering thought that for the child sitting in front of you, this may be the only time in their life they will hear the Gospel message.