Summer Camp will take place right at the Carsonified campground (office) in Bath, England and the two day event is structured like the good ‘ole summer camp you went to as a kid with sessions such as “Orienteering” with Ryan Carson (navigating your way through marketing your start-up), “Sailing” with Jonathan Howell from Huddle (sail through building your app with agile software development), “Arts and Crafts” with Mike Kus (learn how to put together good design), and several others, plus s’mores, some fun outdoor activities, “bonfire” (movie night), and new friends!

Carsonified Summer Camp is FREE, but only has eight spaces (due to the small size of our “campground”) that will be open to fully enrolled students and founders of web start-ups who have yet to launch their site or web app or who have their app in the private beta stage only. Our aim is to host a fun and unique event, that also is valuable and accessible to our community of young web-preneurs and students who can’t always afford to travel and attend our other conferences. Summer Camp will be a small group that can support lots of chatter and questions between attendees and speakers and will cover the basics to help young web-preneurs feel inspired and ready to go out and kick-ass :)

Of course, in the interest of having some good old fashioned fun we won’t be cooped up inside all day- we’ll be heading out after lunch for Wiffle Ball or Ultimate Frisbee and getting together for s’more desserts, a movie night, and grabbing a few drinks out on the town.

You can apply online for Summer Camp until Tuesday July 7th at 12pm GMT and we will choose and announce the eight people who have been selected by Friday, July 10th. The application is easy, just some basic information and then either in a brief write-up or in a brief video (2 minutes max please) tell us why you’d like to participate in Summer Camp, what you want out of your experience, and what you feel you can contribute to the environment and discussions. When considering attendance keep in mind that although Summer Camp is FREE and we will be providing breakfast, lunch, and snacks; accommodations for your stay in Bath and travel are not included although we have some great (and cheap) recommendations for those who will be joining us and could use some suggestions.

Summer Camp will also be working alongside BathCamp (Bath’s chapter of BarCamp) and Summer Camp participants are invited and encouraged to attend BathCamp after Summer Camp on the 21st. It will be a new BathCamp layout that is set up with a “rapid fire” agenda in which there will be about 10 slots for 3 minute presentations on the topic of “What’s the one technology that has blown you away more than any other in the last year, and why?” In five minutes a presentation should cover: why it has changed your life, the way you work or how it has improved the world. A panel will then assess presentations on the level of enthusiasm, originality of suggestion and the merit of the suggestion itself; how much real world penetration, profit (financial or social) or benefit the technology brings. The winner will receive a prize!

So, grab your trainers, pack your knapsacks and come sit around the campfire with us at our two day Carsonified Summer Camp!

If you have any questions about Summer Camp, please feel free to contact trista[at]carsonified.com or twitter.com/tristamyers :)

The team at Microsoft recently sent us over a Silverlight Deepzoom composition of the wall and I have posted it here for you to check out, be sure to scroll around and zoom in and out for full effect.

Microsoft have also kindly donated five webcams and a couple of mice for a little “Deep Zoom” competition fun.

Find Ryan’s head and win!

Somewhere on the wall is a headshot of Ryan Carson, just like this one:

If you can find it and would like to win a webcam or mouse all you have to do is the following:

1. Find Ryan (Hint: you will need to zoom in quite a way)
2. Take a screen shot of the section containing Ryan’s head and email it to keir[at]carsonified.com along with your full name and address

Competition Closed: We now have our seven winners! See the comments to see if you are one of them

Edinburgh - Graeme Mathieson (http://woss.name)
Leeds - Lorna Mitchell (http://www.lornajane.net)
Cambridge - Dorothy Briggs (http://www.rabbitsoft.com)
Bristol - Ian Broom (http://www.weboo.biz)

They are in the process of finalising their talk titles but their sessions will focus on:

- Learning from start-up mistakes (Graeme)
- Architecting web services (Lorna)
- Building for the enterprise (Dorothy)
- Extreme efficiency in web development (Ian)

Thanks to everyone who entered a talk. There were some amazing ideas for talks and it was really hard picking four.

What is Tipster?

Tipster is a simple app built by me with the help of Django that has the aim of helping web developers and designers share their tips in 140 words or less. We thought it might be fun to limit the number of words, after all we all seem to like the brevity of Twitter.

We launched the site quietly last week and over the weekend I cleaned up some elements that weren’t working too well and fixed a few bugs. Feedback also provided a lot of great improvement ideas, especially around for the “Hot Tips” section which currently only displays the most popular tips.

Time wise I spent about the equivalent of three work days on the code, HTML and CSS so am pretty pleased with the result. Thanks go to Mike who despite being extremely busy found time to knock up the logo and offer his design eye here and there.

What’s in it for you?

Obviously we would love you to submit your tips to the site. It’s really easy and you don’t need to register to get involved, simply complete the form and submit your tip. All entries are currently moderated but we are checking for new ones regularly.

We are also planning on displaying some of the popular tips during the breaks on the FOWA Tour and are considering piping them through to Think Vitamin as well. All submitters will be linked up so it’s a great opportunity to show off and get some link love.

Feedback

Let us know what you think in the comments and you can of course follow Tipster on Twitter.

Here’s the winning slide that will be used during the conference this Thursday.

In second place was Kassy

and Derek Rossman claimed the last step on the podium with his entry

Thanks again to everyone who participated. If you entered and are coming to FOWD be sure to check into the auditorium before the first session as we will be showing every entry during registration.

It’s been tough but we have picked our top ten and would now like you to choose the winner. Simply select your favourite and vote for the slide you would like to win. The poll will close at midnight next Wednesday (22nd April).

Thanks again to everyone who entered.

We have some amazing speakers for you this year including Tara Hunt from Horse Pig Cow, Mathew Patterson from Campaign Monitor, Reshmi Sohoni from SeedCamp, Robin Christopherson from AbilityNet. I am also super excited to announce Paul Boag from Boagworld has just been confirmed to speak. Paul and Marcus from Boagworld fame will also be Podcasting and interviewing on the day! With sessions focusing on e-mail marketing, funding, usability and community this event is not to be missed.

We will also be holding speed networking at the end of the day, a fun way to meet your fellow attendees and new business contacts!

New for this year we are holding a Fuel Workshop the day before, with the awesome Tara Hunt: Building your Business with Social Networks .

There are still Early Bird tickets available for the workshop. All workshop passes include a FREE Fuel conference pass so be quick!

For more information and to book tickets please click here, If you have any questions please e-mail natasha at carsonified dot com!

Ideally (although not essential) you will be based locally to our office in Bath and available to work from our office on the 6th and 7th May. In return we will give you a free pass to the Future of Web Design conference on April 30th and the final leg of our FOWA Tour in Bristol on June 3rd.

If you are interested please email keir at carsonified dot com for further details. Thanks!

If you haven’t already entered you still have time, the closing date for submissions is Wednesday 15th April 4pm (full details here)

At the time of writing we have had 34 entries, here they are. Head on over to Flickr to view them in all their glory and leave your comments.

I realise, of course, that these contractions are inevitable when you’re performing a task over and over again. To bring it a bit closer to home, they’re like keyboard shortcuts. But really, I’ve never seen any barista actually save any time by leaving off the “-puccino”. So what’s happening here?

The answer, of course, is perceived speed. It doesn’t actually have to save any time, as long as it gives the impression of saved time.

A good example is this: setting your microwave for one minute and eleven seconds actually takes less time than setting it for a minute flat - because you don’t have to move your finger from the 1 button. 1-1-1 is much easier to type than 1-0-0. Of course, the microwave will be running for a good eleven seconds more, but you aren’t sitting there watching it for eleven seconds - you’re off dicing and slicing, or whatever people do when they cook. I cook by phone.

A lot of this stuff has to do with efficiency of data structures. If you keep all your receipts, you put them in chronological order when you store them, right? Each one has to go into its alotted position. Would you design a data structure like that? A lot of expensive writes? You only ever pull all your receipts out of the box once a year, so that read action can afford to be slow compared with the hundreds of writes you might do. You should throw them into specific boxes (heh, sharding) and sort them in one go later on, or once a week or whatever. It’s like a cron job.(00 18 * * sun ./tidy_room.sh).

I was reading a great article the other day at Assert True which says that twice-as-fast isn’t good enough. A speed-up factor of 10 is what’s required to really make any difference. That really only applies to foreground actions - which are high in cognitive interaction. If something locks up my computer, then a 20-second lockup and a 40-second lockup are pretty similar. They both interrupt my computing experience, and generally tempt me to wander over to the coffee machine.

What I’m effectively doing here is backgrounding the process. It’s still happening, it still takes time, but it requires none of my cognitive space. I only notice something’s happening when I’m actively waiting for it - and in this instance, I’m not. So if the application backgrounds the process for me, it’s doing exactly the same thing. If I can use the rest of the computer while it does its thing, then my workflow is pretty much uninterrupted.

This is why background processing is such an awesome tool. If you have to do 10 non-urgent things when an action takes place, put them all in a queue and report back straight away. This is for more than just server-client requests, too. For example, when I was building Twiggy last week, I found that the jQuery remove() function was really slow at removing all the tweets from the results page. That meant that when a new search took place, the whole application would lock up while jQuery cleared the list. Empty() and .html('’) weren’t fast either. Nothing would make this bit of my application run more quickly.

What was fast, though, was adding a ‘hidden’ class to the tweets and hiding them. That was instant. So, the trick was to hide the old tweets and conduct the search. Now, when a search is conducted, the delay is huge. There’s at least a 3-second gap between clicking search and having the results available. The difference is, this dead time is expected. So I told jQuery to remove all old tweets during this searching process. It locked up the phone for the same amount of time, and probably added to the total search time. But when you’re waiting for the results to come back, you know you’re going to be waiting anyway. The really important thing is that hitting the “search” button has an immediate effect. The old results disappear, and the “searching” text comes up. Things are happening. Happy user!

In interaction science, we’re told that the human brain needs less than 50ms response time between an action and its perceived reaction. Any longer, and it feels as though the system is lagging behind. Symbian, buddy - that’s you. That’s why the ubiquitous AJAX loading gif was invented - it doesn’t actually tell you anything. There’s no indication of how long the action might take, but the main communication is there - something is happening. And that’s important. You’ve acknowledged my request straight away, and told me you’re working on it.

In truth, the difference between the tweet-clearing and the asynchronous searching can be huge. On a cellphone, where latency is really high, the searching might take 10 times as long as clearing out all the tweets. But that’s fine - the user knows this. What I can do, therefore, is hide all the other slow interactions inside this searching query, where they pale into insignificance. Better yet, I can spread the invisible functions out during the course of the application’s usage. If I remove a hidden result every half a second, it takes almost no time at all. It’s effectively a process queue.

So if your app does loads of stuff on a request, like emailing 10 people, or processing credit card stuff, or generally doing ANYTHING with the filesystem, run this process in the background. I use BackgroundJob in Rails for its simplicity, but there are others like BackgroundFu and Starling that have other feature-sets. Some can use multiple processes to run the jobs, and some are kept in memory. Pick the one that suits your jobs best. http://wiki.rubyonrails.org/howtos/background-processes

Either way, remember to keep stuff as snappy as you can. This is an optimization, and premature optimization is the root of all evil - so remember to do this reactively once people are using your application. It’s really just intelligent optimization - instead of spending hours speeding up your code, just leave the stuff that doesn’t need to be done straight away until later, when it can be done in the background. Uploading to S3, rotating and cropping images - there’s loads of stuff. If you have a process that generates big ugly graphs, make it run once every six hours, and memcache the result - because there’s nothing worse than a 15-second page load.

All you need to remember is this: perceived speed is the only test of speed.

Photo: Burt Munro (Anthony Hopkins) on an Indian Scout from here