Internal Server Error

what the voices in my head tell me to write

Friday, April 02, 2010

This blog has moved 

This blog is now located at You will be automatically redirected in 30 seconds or you may click here. For feed subscribers, please update your feed subscriptions to

Permanent link and Comments posted by Rob Cornelius @ Friday, April 02, 2010

Thursday, January 14, 2010

So I had an idea..... 

A while ago I saw a BBC show with Monty Don travelling the globe looking at gardens around the world. He visited Cuba to look at the fantastic urban farms and community gardens there which are going a long way to helping feed the people of Havanna in a way they can afford.

Then I read a few things about the urban farmers and community gardeners in Detroit and Todmorton where wastland is being turned into gardens to feed the residents. I guess watching people like Hugh Fearnsley Wittingstall, epecially his landshare intitive and Carol Klien on tv and reading their books have helped too. Definately having our own garden helped immensley.

The problems with gardening are various. One, its hard work at least at the start and at peak times of the year too. Two, you either have too much stuff or not enough. Three, economies of scale come into it, bigger gardens are cheaper to run especially for things like compost etc. Four, you cant always be in your garden when you should be to water, plant or harvest. If you could share these problems it would be good. Trade time, resources and money for quality produce.

I got to thinking. What might work would be a sort of co-op. You sign up to the scheme and say you will donate x ammount of land, y ammount of time and z ammount of money. This is a sliding scale for all three. If you can donate enough of any of one out of three you get the others free. So people with a large enough ammount of land dont pay or spend time. If you have no land and put in enough time you would get the benefit with no other outlay. Simple cash donation get rewards too in the form of the produce as in buying fruit and veg from a shop.

The intial investments of time, land and cash get put into a pool. Landowners get first pick of what gets grown on their land but have to accept that stuff will be grown that they don't necessarily want themselves. Cash gets spent buying tools, seeds and other materials. The land gets coverted into efficient fruit and veg plots by people volunteering their time. Things like compost, tools, seeds, transport etc can be done from a central location.

These then get maintained by the volunteers and harvested etc. Each landowner can take what they like from their own plot but only enough for themselves and their family etc. All surplus produce gets first redistributed amongst other people in the co-op so the people who are time rich get their free produce and the people who invest money get the produce they paid for. Anything left after that is sold on the open market. Profits are returned to the scheme for new tools, seeds etc.

The system has to be kept small in scale. The key to it is how much time is required to invest to get a unit of produce. In effect a wage for the volunteers. It has to be set at a level that encourages people to invest time and not money unless it soon becomes easier to go to the supermarket to get produce than through the scheme. There would have to be limits on the ammount of land, time and cash one person could put into the scheme though this may vary locally.

I guess to get this off the ground you would need to speak to someone with far more knowledge of economics than me. Then get some advertizing done. Then get digging.

Permanent link and Comments posted by Rob Cornelius @ Thursday, January 14, 2010

Saturday, December 12, 2009

Towards a more unified way of developing sites 

The division between designers and developers has existed almost from the birth of the printed word. Technologies have been produced to make information more rich and interesting from more complex layouts, pictures, and now video, sound and all kinds of interaction.

There is always some form of either a technological development being exploited by designers or a technology being developed to meet a design based need. In most cases it is likely to be a combination of the two.

The problem lies that designers and developers do not always see eye to eye on many levels. There is often a level of resentment in the relationship between the two. Developers view designers as head in the clouds types with no idea of how things get really done. Designers view developers as stick in the mud types resistant to change. They both talk about teamwork, Agile methodologies and co-operation but often the creation of a site ends up as a basically two stage process. The designers create a plan of how they want the site to look and work and hand it over to the developers. Then they may double check things at the end of the project or iteration etc.

This is just a waterfall process by another name. The designers "hand over" their wireframes etc to the developers and say "get on with it". They might have used Agile to develop the wireframes and the developers might use Agile to make the actual site but there is still a massive discontinuity between the two parts of the work.

Often the designers and developers are in separate teams and entirely separated in different offices etc. Even in my current job the designers are at one end of the office and developers are in the other end. Often the designers can be in a separate company to the developers.

I personally believe having worked as both a designer and a developer in different roles that close communication between designers and developers is vital. Communication is all about the exchange of ideas and more communication means more ideas. Maybe not better ideas but there are still more ideas than there were.

Designers and developers should be involved at every stage of the entire process of creating a site from its conception right through to its on-going use by real people. Database developers need can help plan the basic functions of the site. It will make their job of developing a schema easier and they might well be able to say "if you want it to do XYZ to make things easier" and create something entirely new that the designers had no idea could happen. That is only one example. The opposite of course can happen as well. A designer can come up with a requirement that a developer would have never have thought of.

At the moment the process is one way. Designers design and developers develop. When either group crosses the boundaries into the others territory then conflict occurs. There needs to be a breaking down of barriers to some extent. Of course there have to be specialists. Its crazy to expect a graphic designer to be a DBA as well.

Processes like SCRUM and Agile help with this to some extent as they should get people working together. However this does not always work for the reasons outlined above.

I think that there are enough similarities between different roles to implement a sort of eXtreme Programing technique combining developers and designers. This is based in part on my experience several years ago. I was working for a small college as a web developer working with a designer to create all kinds of material based around HTML content.

We quite often worked on interface elements of a project at least as an XP team. I would be working in Dreamweaver, Photoshop or the like with the designer sat in the "co-pilots" chair and between us we came up with a solution for a problem. At the time it could be hell and led to some quite spectacular arguments and I am not advocating this exact approach but it is a good starting point for a discussion.

What I am proposing is a kind of buddy system. There is enough common ground between several types of jobs in both the design and development fields to make this work. For instance a information architect designing the high level specifications for the site could work alongside a database developer who models how the site is represented in a database. They are both concerned with how the site is organised and that gives them common ground.

The obvious team up wit the UX and front end developer working closely with each other. The developer can advise the designer on what is possible but the designer can come up with new ideas that the developer might have missed.

The problem lies with who to team back end developers with. They are not a natural fit with graphic designers. They may have to be involved with some aspects of UI development but they often avoid this sort of work. There seems to be more correlation between the sorts of structures and organizations that an information architect creates and object orientated design than anything else. Taxonomies, Labelling schemes and metadata all have their place in the object orientated world.

Some other functions a site may be expected to have may be very interdisciplinary. Search for example will involve aspects of information architecture, user experience design, front end development, back end development and database design. If any one of these is omitted the function is likely to be less useful to the end users.

A personal example is a good way to illustrate this. Recently I was asked to provide a series of wireframes and other UX documents to a recruitment company for a site that its candidates could use to look for positions, clients could use to look for candidates and its consultants can use to match candidates with vacancies. By co-incidence the first real commercial website I produced was for a different recruitment company nearly 10 years ago now. Back then I looked at the companies paper based forms and processes to create a database schema to store the information they used and built the site from the back to the front so to speak. This time round I evaluated the companies existing site and interviewed its staff and also some candidates and clients about the site to conduct a basic usability study and expose some new features that would be useful on the site. These data were then turned into personas, sitemaps, wireframes and other documents which were turned over to the clients developers to implement.

Essentially the same process took part this time round as 10 years ago however. The difference in the two is 10 years ago I was more of a developer and understood more about databases that information architecture and user experience design. Now I understand far more about the design side of creating a site than the back end development of a site, certainly I know more about usability than SQL now. What occurred in both cases was that I modeled the users needs and requirements. I just used two totally different methods to do so. However this time round I could apply the knowledge I gained 10 years ago when designing a database to model a recruitment company to my current design problem.

The key area of the site as with many others is search. Candidates want to find jobs, consultants want to find clients for candidates and vice versa. Clients want to see a good pool of candidates. All of this when you get down to the real nitty gritty is a well designed and executed database schema and set of queries to interrogate it. However it is down to the user experience designer and information architect to make the search as easy to use as possible. No one wants to type in SQL queries to get their data out. (apart from real DB geeks) Users demand power and flexibility. They want to choose from a small list of options and sprinkle a few keywords to find their dream job. It shouldn't take long and it shouldn't be difficult.

This is where good design comes in. Both the DBA and IA have to accurately model the users needs. They are both using different forms of design to achieve that end. The DBA has to work out a schema that is both accessible in terms of the ease in constructing SQL queries to interrogate the data within it and also usable in terms being performant in returning data quickly. The IA/UX designer has to model the users needs into in effect a web form that generates the SQL queries that the DBA uses to interrogate the database. This has to be accessible in terms of ease of use and performant in terms of enabling a user to get the results they requested.

Its not implausible that the IA/UX designer may model some user behaviour that the DBA had not thought of. Similarly the DBA may be able to spot and model some user behaviour that the IA missed. What is often overlooked is that when two experts work together on a common problem from different angles they are able to collaborate to gain insights that they would not otherwise have come up with independently. It might be possible to discover a new way of requesting data that might have been overlooked. A unique selling point perhaps or certainly a competitive advantage. If the "designers design then hand it over to the developers" model was followed in this case they this synergistic process would be missed out on.

Teamwork is the core to all of this. Maybe not the extremes of XP or lesser peaks of Agile but good communication and the sharing of ideas and concepts cannot be a bad thing. When people share they create something they would not be able to do individually.

Permanent link and Comments posted by Rob Cornelius @ Saturday, December 12, 2009

Saturday, November 14, 2009

This is both inspiring and though provoking 

I came across Leagh Buley's presentation on Being a UX Team of One the other day. I have to say I watched more or less every minute of the video and followed the slides too.

Leah seems to have experienced some of the same problems I have come across when working as the "Front End Developer / UX guy" and has some great ideas for overcoming them. So often someone has come up to me and said "can you come up with a page to do XYZ?" and I go away and think for a bit and come up with one design solution. In the bad old days I would have started coding straight away. Now I can write html and css quickly but not that quickly.

Then I got into using graphics packages to create high fidelity mock ups before I started coding. Almost the old slice-n-dice photoshop table layout days all over again. Of course I obsessed over details and didn't come up with a coherent design.

I was never that keen on sketching UI with a pen and paper. Mainly because I am really bad at drawing I think. It brought back bad memories of sitting in an art class aged about 13 with no idea what I was doing there. Then I joined I ♥ wireframes on flickr. Yes there are some very beautiful wireframes created in graphics packages but the most interesting ones (IMHO) are sketched.

Leah definitely is a big fan of sketching and I think am now converted. The main thing I got out of Leah's section on sketching was that you "brainstorm, a lot". Produce many ideas and mix and match. Let them evolve. Don't limit yourself. I think I might have frustrated my co-workers quite a bit in the past by coming up with one design and "evolving" it without really asking or telling them. Evolving the design on paper stops this sort of problem.

As an aside from all this there must be something wrong with computer based UI design in general if it limits this sort of creative process or other similar creative activities.

The next stage of working as a team of one is a bit contradictory. Basically don't be a team of one. Assemble an ad hoc team around you. Basically get some help from your co-workers. This isn't really a team of one thing if you ask me but there you go. I can see the point that your co-workers will put their oar in anyway so why not get their input. From personal experience I think this can go one of two ways. Either they will tell you to sod off and stop asking you to do your job for you. Or they will jump in with tons of unhelpful suggestions that stop you working that way.

I guess the trick is to fall between these two extremes and get coders to help you constructively. Leah and Adaptive Path have a range of techniques like sketchboards, open design sessions and the like. One of my favourite ideas is to decorate your workspace with your work in progress to get people looking at your work and commenting on it - hopefully constructively. The idea of passing someone who is commenting on your work a pen and saying. "Draw your idea then." is great.

The final section is a bit ass about face I think. I would be coming up with design principles at the start not the end. If I had to for instance come up with a set of designs for a hotel's site I would try and figure out the design principles at the start and then use them as a filter for ideas right from the start rather than at the end. Though that could mean rejecting ideas that don't fit the preconceived ideas which is a bad thing. So maybe this isn't a bad idea after all.

Watching the video and googling around the subject has really made me think. I can definitely improve my process for coming up with a design from this. I might not agree with all of it but hey that is bound to happen.

Permanent link and Comments posted by Rob Cornelius @ Saturday, November 14, 2009

Saturday, October 24, 2009

UX isnt just for the big boys 

Recently I have been looking at a lot of relatively small scale web development companies. They produce a whole bunch of sites for small and medium scale businesses. They all seem to view UX as a either part of the graphic design of a site or an unnecessary luxury that they can not afford.

I would personally argue it is something that they cannot afford to be without. It adds an extra selling point to their pitches at clients. It might require explaining a few extra things at the same time but at least it should give their potential clients something to latch on to compared to all the other competing agencies. Its not a unique selling point but at least its a different selling point.

Small agencies seem obsessed with graphic design and SEO. Its almost as if nothing else matters to them or their clients. I would argue that they often fail to meet their clients expectations because they don't consider the user experience. Getting things like e-commerce right is not a matter of fitting things into a CMS/e-commerce system that comes off the shelf. Its a complicated process that needs tailoring to individual sites customers needs. Its in areas like where UX comes and has a huge potential to make a difference to the clients bottom line and the agencies chances of getting more business.

If a small 10 or 12 person agency had one UX person working for them I would personally be prepared to bet that they can pull ahead of their rivals as it would give them a competitive edge. UX is not for the big boys. It gives the little people the chance to compete by giving them more tools to work with.

Permanent link and Comments posted by Rob Cornelius @ Saturday, October 24, 2009

    follow me on Twitter

    My recent photos


    Creative Commons License
    This work is licensed under a Creative Commons License.

    RSS feeds and things

    Feed Button Help

    This page is powered by Blogger. Isn't yours?

    contact the author

    rob cornelius can be contacted by email use his name with an dot and googles web based email domain