BASIC blog full text feed

Visiting BBC Online at Salford

2011-11-18T10:00:00Z

Last week I travelled with some of my new R/GA colleagues to Salford near Manchester to visit the BBC’s new Media City development and talk to The Beeb about their continuing efforts to engage more openly and effectively with the online community. The BBC are keen to share their thinking and product plans for this and the event was kicked off by Ralph Rivera, Director, Future Media.

Rivera began the afternoon by talking about the ambition to unify the existing silos around the BBC into a cohesive online experience. The ten core online products of Home page, Search, News, Sport, Weather, Knowledge and Learning, TV, Radio, cBBC and Cbeebies are set to form the backbone of the online offering accross the various BBC estates.

The common theme throughout the day, was that of how best to deliver a simple, intuitive and accessible experience on “the four screens”:

TV
Computer
Tablets
Smart phones

Also a hot topic was how we can leverage the red button as a bridge to a more connected and engaged experience with the content that the BBC has to offer.

Many parts of the BBC have been steadily rolling out all manor of innovations, not only through the R & D team, but also through steady iterations and evolutions of existing products across the BBC offering. The News offering was a good example of that, where the recently released news application for Android rapidly achieved half a million downloads and served to redress the balance of a slight perceived skew towards Apple products and platforms.

It was interesting that Rivera observed that there was a gap between the official R & D activities, and the innovation that happens within the product streams, and described that there is a push to close that gap over the next year. This effort will include bother internal and external initiatives including many events and a significant financial investment.

Holly Goodier, Head of Audiences BBC Future Media then gave an excellent presentation describing the audiences and contexts that people consume BBC products. This built further on the theme of the four screens and nicely illustrated how the vast majority of the audience is capable of multi-screen consumption in some form or other. I was impressed at how considered much of this was and at how the BBC were clearly looking to fulfill that desire in their audience.

A breakdown of the type of content which is popular on different screens, and so in different contexts was interesting to learn, as was the statistic that between 40-48% of TVs are now IPTV capable. Personally, I have doubts about whether that is a good indicator of what capabilities that same audience has given how little of my TV’s capabilities I, as a techie, geeky bloke, exploit.

The BBCs focus on content for children yielded some interesting conversations. Of particular interest to me was the observation that significant knowledge transfer occurs through games and rich interactions. Given that many of these games are developed in Flash, I was curious to find out how the BBC was planning to make the most of this across the four screens when Flash is experiencing ever diminishing support on mobile platforms. The future of HTML5, and other web technologies for delivering game content seems, quite rightly, high on the radar for the producers of children’s content on BBC on-line.

Ben Gollop, Head of F1, and Ciat O’Riordan, Head of Product for Sport and 2012 gave us some interesting insights into the scale of the undertaking to keep systems running during periods of massive demand. With events such as the 2012 Olympics on the horizon, there is clearly a great many design and engineering challenges ahead to ensure that online sevices and the provision of live video content is invisibly simple and flawlessly effective for the consumers. No small tasks at these scales.

Finally, Daniel Danker, General Manager, Programmes & On Demand spoke about the drive to simplify the experience and more effectively meet the needs of the audience. Danker, quite rightly observed how far the experience needs to evolve before it can truly be successful. I found his comments to be right on the money. Personally I’ve found that my TV watching methods, even in the living room, have grown to include a ‘workflow’ rather than just being utterly intuitive. Certainly something that needs addressing. The panel discussion that this lead on to with a number of different television set manufacturers was interesting, but took an alarmingly long time to include the word ‘standardisation’. Like many others, I’d prefer manufacturers to compete on things like price, size, picture quality, sound and energy consumption. Not how many apps are built in and which ‘app store silo’ does the TV support. Give me a capable, but dumb display any day.

Photo credit: Ray Morris

Reflecting on Full Frontal 2011

2011-11-13T10:00:00Z

The third installment of Full Frontal, the JavaScript conference hosted each year in Brighton by LeftLogic, was a great event once again. I was lucky enough to be a speaker this year, which perhaps gave me a slightly different perspective of the day, but as an enthusiastic attendee I also found it to be an excellent experience.

Something that strikes me about Full Frontal is that it has established itself in just two years to be a really valuable addition to the web development conference calendar. Never mind the speakers who Remy managed to secure (I found myself among an impressive line-up of established conference speakers and well-respected technologists - somewhat daunting for my first outing as a proper conference speaker), but also just a glance around the venue at the delegates revealed a gathering of some amazing talent. Clearly, over the last couple of years, Full Frontal has been doing something right just to attract so many big brains.

This all added to the sweat on my brow, and the shortness of my fingernails as my time on stage approached.

As it turned out my talk, entitled Excessive Enhancement, was very well received. This was incredibly encouraging to me given that it was something of a cautionary tale, and delivered to a crowd of smart developers who wanted to learn about exciting new techniques and opportunities for interesting ‘browser shizzle’.

Many people who were nice enough to complement me on my talk at the after party (a nicely judged event in itself with a generous kitty behind the bar - thanks Remy and sponsors!) commented on how important my main message, of caring for the Web regardless of the cool effects we can create, was also important to them. That is an extremely positive thing, which might perhaps reflect on the kind of people that this conference attracts, but hopefully also points to a wider community of folks who share a similar set of values which can only be a good thing for the Web.

Everso slightly unfortunate, was the fact that almost every photo I’ve seen from my talk, features me standing in front of a giant sign saying “Sex Enhancements” (as you may have spotted above). I guess that’s the price you pay for being a smart arse and/or channeling the chatter happening on Twitter!

The slides from my talk are available on SpeakerDeck

I was interested to hear what Jeremy Ashkenas had to say about CoffeeScript, as I had to admit to being a little hesitant to embrace it myself. In Jeremy’s session, he described some of the design decisions involved when he created the language and demonstrated some beautifully intuitive and expressive features. Much to think about. When I spoke to Jeremy and mentioned my hesitance due to concerns around debugging tools and adding a layer of abstraction atop JavaScript he replied that this was a common concern from people who have not tried CoffeeScript, and that it is seldom a problem for those using it. Perhaps I’ll give it a whirl.

Both Marijn Haverbeke and Rik Arends gave fascinating presentations on the state of rich text and code editing in the browser from slightly different angles, with Rick demonstrating the rather splendid looking web-based Cloud 9 IDE. This is evolving into a really compelling IDE and has some beautiful integrations with GitHub and Heroku for all manner of integrated workflow and deployment strategies. Rather nice, and certainly one to watch as the pace of development at Cloud 9 seems to be steadily increasing.

I enjoyed every talk during the day, but the two which really entertained me and got me thinking most were Glenn Jones, who demonstrated umpteen different examples of uses of emerging browser APIs, and Marcin Wichary of Google who showed us a glimpse into the world of creating the Google Doodles we all love.

Glenn’s demonstrations were superb and provoked all kinds of discussion at the after party. He also gave a great introduction to Web Intents. You can see his slides and demos on his blog.

Marcin was superbly entertaining and gave us all a fascinating glimpse into what goes into the creation of the interactive Google Doodles such as the Pac Man and Jules Verne doodles. With such a premium on optimisation and reach, the inventive techniques employed on these 24 hour delighters are cheeky and inspired. Marcin demonstrated some of those to us brilliantly through his slick, web-based presentation rig. Crafty bugger!

Many reviews and blog posts of the day are popping up and many are nicely aggregated over on Lanyrd

From the conversations I’ve had, Full Frontal is set to be popular again next year. Thankfully I’ve got a free ticket already in the bag as a reward for speaking this year (thanks again Remy!). Otherwise I’d certainly be monitoring the @fullfrontalconf twitter feed for news of when to grab a ticket next year before they get snapped up.

Photo credit: Remy

Excessive Enhancement at Full Frontal

2011-11-03T10:00:00Z

In a few days I will be speaking at Full Frontal in Brighton. This conference, now in its third year, has done a great job of capturing so much of what is important and exciting to many front-end web developers.

I’ve attended Full Frontal each year so far and so I’m rather delighted to get the chance to speak. The technical community in Brighton is fantastic and attracts smart speakers and a knowledgeable and enthusiastic audience from far and wide. Somehow I’ve managed to fight my way in and find myself on a list with some awesome speakers.

This is both nerve racking and genuinely exciting.

I’ll be slightly running the risk of being the wet blanket of the conference as I’ll talk about the pitfalls of being seduced by all the cool things that we can do in modern web browsers. Other speakers will most likely be showing all manner of engaging, bleeding-edge developments in Javascript and browser technologies, perhaps eliciting the occasional “ooh” and “ah” from the crowd. I’m confident though, that while we web developers love making exciting interfaces and experiences, we do also value the underlying integrity of that thing that feeds us: The Web.

At least, that’s the drum that I’m bringing to bang.

I’ll post my slides along with a look back at the conference on this site after the event and coverage from the other speakers will most likley also be posted on Lanyrd.

Joining R/GA

2011-11-02T10:00:00Z

While I was sad in my previous post to share that I was leaving The Team, I can now share with some excitement that I’ll be moving on to join the considerable talent present at R/GA.

As I mentioned before, the decision to leave was a difficult one, but the potential at R/GA provides a substantial pull and I can’t wait to get stuck in. I’ll be joining in the role of Technical Director, the same role that I have enjoyed so much at The Team, but the outlook is somewhat different. The organisation is digital to its core and has real momentum in attracting high profile, engaging clients who seem to have a real appetite for R/GA to push the boundaries of creativity and innovation in the work that they do for them.

Since this is a bigger company, the development team is also rather larger than at The Team. This is sure to present a new set of challenges and opportunities which will be great to take on. I’m hoping to apply many of the things I’ve learned along the way but do expect to be regularly surprised (and hopefully delighted) by fresh obstacles.

There is a buzz at R/GA London at the moment. A real feeling that the agency is on the brink of unleashing some recently harnessed potential to deliver ever more awesome work. Their steady move away from purely Flash-heavy sites into a more considered and future-proof approach to web technologies is also rather exciting.

I can’t wait to be a part of it.

Time to move on from The Team

2011-11-01T10:00:00Z

After a few great years at The Team, the time has come to move to new pastures. Leaving a job is always, I find, an exciting but difficult experience and this feels particularly true in this case.

I joined The Team tasked with leading the way for the front-end development efforts across all of our clients and projects, but soon became responsible for all of the development and technical output of the agency. This represented a significant challenge for me, and it has not been a road entirely free from bumps.

I take significant pride in the journey that The Team has taken in this time, and have particular affection and respect for past and present members of my team, the development team. I feel safe in saying that the quality and efficiency of that small team’s work has steadily been improving and over the last couple of years the team has evolved into something really rather special.

During my time at The Team, I’ve also been involved in countless impassioned debates about what is important on the Web. These have been in stark contrast to the debates I had at Osmosoft where the vantage point was a little different. Being surrounded by talented designers, some of whom have rather different relationships with the web than myself has been frustrating, challenging, rewarding and enlightening.

I cherish heartfelt debate with smart people who disagree with me

During my time here, I’ve been incredibly lucky to work with some outrageous talent from all aspects of the web design and development fields. It’s hard to describe the excitement when all of the pieces fall into place perfectly and the work lives up to your collective expectations. It’s safe to say that I’ve made some great friends here as part of the experience.

I’ve also worked on the occasional stinker where I’ve done a less than stellar job and those projects yielded some of the biggest lessons for me. Tough, but true.

So, thanks for everything, you folks at The Team. You’ve been amazing and I’m sorry to be moving on. But now, a new challenge awaits.

Photo credit: Phil Whitehouse

Profiting from a happy hack day

2011-09-19T10:00:00Z

A few weeks ago at The Team, inspired by the Atlassian model of FedEx days which we have have successfully employed before, we managed to make some time for the development team to spend the day away from the office to work on something for themselves. No clients and no managers, just our own requirements and some time to work in new ways together. It yielded some valuable results.

The notion of creating value from activities like this is not immediately obvious to all, but there is value to be found in many different places when working together on a project like this. I’ll try to mention a few of them here as a kind of a primer for anyone who is looking to arrange a similar day of their own. That might be useful when you need to convince the folks at work who need to look carefully at things like utilisation, opportunity cost and project resourcing.

When arguing for the value of this kind of activity, it can be difficult to protect the time needed to make it really useful and valuable. I’d suggest that this is actually a vital activity in helping a development team to remain fulfilled, motivated, efficient and sharp.

This was a modest hack day. First of all it was just a single day, while I would have preferred to have it last for two. We had just the time that we could stay awake and productive for one day to plan, design, develop and deploy our project. Also, while I would have liked to involve a wider team in order to profit from a range of disciplines and specialisms, it was just our small development team who could be spared for one precious day. Nieman Journalism Lab recently wrote about the benefits of similar hack days at NPR which involve wider disciplines and dubbed them Serendipity Days. I rather like that.

We cheated a little. We had something in mind that we wanted to build. A simple need that we felt could be basically fulfilled with modest amount of development. That idea, we labelled Scamp Cat. So named as a bit of a hat-tip to Sprite Cow, a little side project by Jake Archibald which we each had some fleeting involvement in, and also just because we needed a way to refer to this thing, and Scamp Cat made us giggle. We are easily amused. Having something in mind to build, and having the opportunity to talk to potential users of this application ahead of time was a great way to get started quickly on the day. We already had an idea of the high-level requirements, and had identified a likely ‘customer’.

Having a customer was my first tactic for justifying the day to my boss and to my Financial Director. We would be making something that has an application right here at work on a regular basis. Yes, there are tools around that provide a similar service, but none quite satisfied the needs of are colleagues in the EA and Design departments. Building this thing would be of value to us right here at work.

When I presented what we built back to my elders and betters, I was eager to point out that Scamp Cat, the most tangible product of the day, was perhaps the least valuable output. More important to me, are the various processes and conventions that we used during the day, and the insights into some new technologies and conventions we gained. For instance, during the day, we made use of Git Flow, a code versioning model in Git. This served us tremendously well and resulted in very few code conflicts and high confidence in our small but active codebase over the day. We now use Git Flow on all of our active client projects. Win!

We also started tuning our approach to provisioning our infrastructure using Puppet and normalising on virtualised development environments with Vagrant. More Win! In addition there were a number of small but useful pieces of reusable code which came from the project. These got rolled into our set of code snippets and plugins which form part of our project bootstrapping suite. Winning again!

My favourite part of the day was the fantastic sense of team spirit which was evident. We set ourselves a tough challenge, and together we knuckled down and met that challenge. Creating an opportunity for a team to pull together away from outside influences and commitments develops some great trust and mutual respect, which is perhaps the most valuable output of all.

But for those wanting to see an actual thing as an output from our day, Scamp Cat has found a little home on the Web, and is functional enough to use. Just. It can be used to upload, or reference, an image and add annotations to that image. The resulting annotated “scamp” can be freely shared via a public URL. There are similar products out there already, but none quite ht the spot for us.

We’ve already got some great feedback and are planning several iterations to evolve the functionality.

More photos from the day on Flickr

Value in a happy hack day

2011-09-19T10:00:00Z

We’ve already got some great feedback and are planning several iterations to evolve the functionality.

More photos from the day on Flickr

Expectations of web development at agencies

2011-09-09T10:00:00Z

Recently I was involved in an very short bit of consultancy for an e-commerce company. We were focussing on the performance of their site in the browser, and they were more than a little surprised at the software engineering rigour that we exhibited given that we are just an agency. Perhaps we’re thought of us web development production lines who churn out web sites. That’s not my view.

This isn’t the first time that I’ve encountered that attitude towards agencies. It seems that there is a perception from companies whose bread and butter is developing their product for the Web, that an agency would never go to the same lengths as them to ensure quality and performance.

There is a kernel of truth in that. Realistically a product company or e-commerce company can labor over fine-tuning and optimising their web site over long periods of time, making many, often constant, iterations to drive up the quality. Long term engagements in projects is often a luxury that agencies are not afforded, and so it is more difficult to agonise over finessing the performance and all that entails.

But hang on. Agencies should be experts in their field. Web development practitioners have a responsibility to their clients to craft and deliver amazing results. That doesn’t end with the branding or the design, but should, nay must extend through to the development and delivery of the ‘product’ on the web. Otherwise everything that came before delivery is for naught.

Where I work, we have gone to great lengths to instil robust software engineering practices because without them, frankly we’d be screwed. Deadlines are always tight, and clients always want a lot for their money. If we stand a chance of delivering that, we must find ways to reduce risk and create opportunities for innovation.

Of particular surprise to the recent client, was the degree to which we optimise the performance in the browser. We care about this stuff. It’s essential to providing a good experience to the user and that is true no matter how large or involved the project, or how ambitious the web site or application. While this particular client poured a great deal of effort and expertise into optimising the performance of their back-end systems, the browser technologies were not given the same kind of care and attention. This is huge (and common) missed opportunity to optimise where it really matters. They exclaimed to us “oh, you treat JavaScript like a real, first-class language!”. I’m no stranger to hearing people look upon JavaScript as something that is supplementary, or a bit of a play thing, and the power and approachability of jQuery has made many people think that good JavaScript is easy, because they can make things happen with little code.

The truth is that doing this right takes just as much care and skill as any other kind of software engineering, and without the proper process, the proper approach, or the proper standards, you’ll often be creating a weaker user experience, and setting up a train-wreck for you to fix just around the corner.

Photo credit: Toyota UK

Social media did not cause the London riots

2011-08-09T10:00:00Z

It seems to me that this is the time for some responsibility. In the face of the kind of civil unrest that we have witnessed in the UK over the last few days, starting in north London and spreading to many other areas across the city and then to other cities we must have a return to responsible behaviour. I’m not just talking about the people turning to criminal acts, young and old, men and women, but also about, specifically about, the media.

It’s easy to watch the footage playing in a depressingly lengthening loop and simply shout at the idiots looting, mugging and destroying. I know, because that’s what I have been doing into the early hours of the morning. But the media needs to be careful. The apparent need to fill the airwaves with an uninterrupted stream of coverage as the disgraceful activities unfolded has lead to presenters resorting to delivering noise rather than facts.

I quickly grew weary of hearing late-night presenters struggling for content as they provided the narrative for the pictures of buildings burning and angry mobs. They seemed content to say things that had clearly not been verified or even widely suggested in order to fill the silence until the next link. Rumour and elevated anxiety easily get fuelled that way.

But I’m also annoyed to see a familiar, small-minded piece of commentary surface again. That is one that lays blame at the feet of social media and technology. Throw-away bits of commentary about the mob coordinating over Blackberry messaging, or spreading over Twitter quickly get repeated, embellished, compounded, and then before we know it, are being viewed as causes of the riots rather than simply communications mediums just like telephones or television. Headlines like “Nail the Twitter rioters” demonstrate an ignorance and a disregard for responsible journalism which is all too familiar.

I’ve noticed that a few people (on twitter, as it happens) are beginning to ask the important question of “why are these people rioting”. Let’s not fool ourselves that this is because of a police shooting. A protest does not equal a wide-spread riot complete with looting and the mugging of anyone seen carrying an expensive phone. But there is an underlying reason for this kind of civil unrest beyond the obvious observation that “they are a bunch of thugs”.

I digress. The point I wanted to make is that these riots were not caused by the existence of social media. I watched the ITV news as it began demonising social media and casting it as that thing that the hooded youths of today use to coordinate their shop lootings and happy-slappings. This kind of suggestion seems to me like saying that photography is bad because it is responsible to pornography, computers are bad because they lead to piracy, or that telephones are bad because they let terrorist communicate. (ITV news went on to ask viewers to keep them in the loop via Twitter!)

The immeasurable good that has come from enabling communication in our society on this kind of scale seems so quickly forgotten when commentators are looking for a fashionable sound-bite, or a convenient place to direct some blame. A few small examples off the top of my (sleep deprived) head of more positive examples of modern media usage:

Raising awareness of countless charity and fundraising events with JustGiving via twitter
Spreading the awareness of official campaigns and charities such as Save the children
Fire departments and individuals in the US distributed updates to at risk communities during the California wild fires when other infrastructure failed
I also love this little idea that places some stock in people being basically decent. Jonathan Stark decided to share his Starbucks card and allowed anyone to either use it to buy coffee, or to top up the balance as a gift for the next person. Shared via his site and on twitter, I find this a rather heart warming experiment which, while being a tiny thing, reminds us that we can use these tools to be generous and trusting. and not just cynical.

Indeed the overwhelming response from people coordinating on the likes of twitter to engage in an effort to clean up after the riot should be an indication not only that there is a will and solidarity in the communities effected, but also that people are using the tools available to them for good.

Let’s keep the focus here on what the problem is, and not direct out fear towards the infrastructure that supports not just the activities of thugs and vandals, but also police departments, fire services, hospitals, journalists and the rest of us.

Photo credit: http://twitpic.com/63d9bu

Getting started with Node at AsyncJS

2011-05-27T10:00:00Z

Yesterday I had the pleasure of talking about Node at AsyncJS , a meetup of smart and motivated developers and tech enthusiasts in Brighton.

Async, which is organised by Premasagar Rose of Dharmafly fame meets every 2 weeks and is a regular haunt for members of Brighton’s thriving technology community. My talk on Node is not the first on the topic at Async, which has already seen great sessions from Simon Willison and Alex Young, but focused on getting started with Node.js and looked at some of the tools created by the Node community to help ease development.

The slides from my talk are available now on Slideshare or to download as a PDF. The complete Keynote presentation is available for download too, but weighs in at a hefty 182MB due to some animated screen-captures.

Photo credit: Karl-Ludwig Poggemann

Developing a side project

2011-05-09T10:00:00Z

One of the nice things about being a web developer today, is that thanks to the incredibly low cost of resilient, scalable hosting infrastructure, and the abundance of free tools and technologies, you are empowered to create things and release them to the a huge audience. You can experiment with much less risk than ever before. We are seeing evidence of this with so many entrepreneurs and startups entering the market. Some more successfully than others.

Thanks to this low cost of innovation, conversations in pubs between friends who have the right set of skills can quickly flourish into exciting and viable products (or indeed, display the inner madness of their creators and become curiosities or simply be overlooked.)

One such pub-based conversation for me has lead to my working on something with a few friends to build something that we each felt would scratch our common itch. Funnily enough it was around the subject of pubs and bars (we do think about other things, honestly) that we felt there was a missing resource. I’ll come back to what we felt that was in a moment, but there was a more essential point to our discussions. That was that we all felt a similar frustration in not being able to exert our skills to pursue so many of the ideas that we each had. We’re all familiar with the maxim that ideas are cheap, and that the value lies in the execution. I’m a strong believer in that and indeed many of us are brimming with ideas for things that we’d like to make if only we had more time, money, development skills, design skills or what have you.

The most common missing commodity in this situation seems to be time. We all have busy day jobs which are not conducive to the pursuit of the vast majority of out “big ideas”. Individually, we may not have the requisite skills to realise many of these fanciful ambitions. Together, we can take it on.

Our view was that a small, carefully assembled group with the right motivation and ambition, could coalesce around their ideas and do a pretty good job of going off to simply create things. Freed from the constraints of supporting an existing business with ambitions in different direction, and servicing clients, we decided that as an experiment, for our own satisfaction, and mostly to simply satisfy a need that we felt, we would work together in our spare time to ‘make stuff’.

So that is what we are doing. We are just making things that we wish existed already. For now, it’s just for fun. And boy, is it ever!

Our first project, which I promised, I’d return to, is very much in its infancy but starting to shape up nicely. We’re entering an already crowded space, that of finding and reviewing pubs and bars, where we think we can do a better job. The UK, where we are based has many pub review websites and indeed Google have recently started to make it easier to find pubs and bars by the reviews of patrons, but we just don’t think the experience of using them, or the quality of the data is good enough.

And so, we’ve begun work on a project which makes use of mobile devices, geolocation, carefully designed user-generated content and lots of other fun (and occasionally buzzword-heavy) things.

I’ll be talking about this more as it progresses, but for now, I’m just loving getting my hands dirty with building something for the Web. I don’t do as much hands on development these days as I used to, so it feels good. Working with Django, JQuerymobile, Fabric, Vagrant, Amazon AWS, PivotalTracker, Github and other things on our own terms, and to satisfy goals that we ourselves have set, is fun and exciting.

I hope to be able to share more details as we approach a usable beta. Things can move along quickly when you are your own customer. Even if you only have evenings and weekends to work towards you target.

Photo credit: Mike Hoff

The next generation stack. Is NodeJS ready to go mainstream?

2010-09-10T10:00:00Z

I’ve been building things with web technologies professionally for a little more than 11 years now. In that time, I’ve used a variety of technology stacks with varying degrees of success and comfort. While at university, I was making use of the faculty infrastructure and so was building the simplest of sites on top of Apache on their unix environment. Then as I moved into developing Web applications for a living, I found myself working on Windows NT servers with IIS and ASP. Later on I moved into using the LAMP stack, which after the initial shock to the system, was a revelation and I have never looked back.

This combination of Linux, Apache, MySQL and PHP is a tried and tested technology stack which is powerful, available and free. No wonder then, that it has become the first choice of so many web developers. I’ve seen a swing in the default technology stack from Windows over to LAMP and have become comfortable in the LAMP world with it’s GUI free interfaces, consistent and repeatable operations through SSH and so on.

The stage is set though, I think, for a new stack to emerge. The amount of work taking place on NodeJS, both on the framework itself and utilising it to build high performance web applications is really impressive. NodeJS really is causing quite a buzz in the Web development community, not just because it is so performant, but also because it enables Javascript developers to expand into writing the server-side application support that their web apps need, without leaving the comfortable world of Javascript. Very empowering stuff.

Through the work that we are doing with NodeJS, we are adopting a common usage pattern. NodeJS can provide its own http server, and we tend to have several NodeJS projects being served on a single box. These can all make use of different versions of NodeJS if necessary (via the handy nDistro distribution model) each publishing on its own port. We then proxy requests to those NodeJS servers through either Apache or Nginx. This brings me to my point. A stack that I now commonly employ looks less like:

Linux
Apache
mySQL
PHP

and more like:

Not Windows
Nginx
noSQL
NodeJs

I’m not just trying to be antagonistic by stating “Not Windows”. Yes, this is a conceit in order to wangle nnnn or 4N or whatever, but the real point is that all of the pieces of the puzzle work beautifully on various flavours of Linux, Unix and OSX. Windows, less so. I’m going to be using this ‘4N’ stack for more an more projects now, and as some big players start taking a more serious look at using Node and Nginx, I think that it will become more and more common.

Hitched

2010-07-27T10:00:00Z

After more than 14 wonderful years with my girlfriend, Verity, last weekend we finally tied the knot.

It’s hard to put into words just how excited I was to finally get to enjoy our wedding day with so many of our family and friends and there is a risk that this post could become a sprawling gush-a-thon. I’ll try not to do that. You can take my gushing and delight as read. I do want to take a moment to acknowledge the effort that so many people put into making our day so fabulous though, and perhaps mention a few highlights.

Verity and I were married in the lovely little church in Horringer near Bury St Edmunds before a reception at the West Wing at Ickworth House. I was surprised at how my nerves didn’t really manage to rise too much while I was waiting at the church but the fun of greeting dear family and friends as they arrive with huge smile on their faces seems to chase the butterflies away. The downside of that is that (just as everyone had advised me) the time was flying by before I had realised the day had even begun.

A running joke among our friends is how Verity is often late to social engagements, so there was a lot of banter around how long she would keep me waiting. Happily, she was only a fashionable 10 minutes late (or so I’m told, I was too busy soaking up the atmosphere to start looking at my watch). In that time I was incredibly well supported and attended by my best man, my brother Stephen. A quick tip - a best man who has already been through a wedding of his own has some great little insights which can really help as you arrive at the church and prepare for your big moment.

Nothing, however, prepared me for the moment I saw Verity arrive at the church and make her way up the aisle towards me. Breathtaking.

From my vantage point, the ceremony seemed to be fun and spirited while being sincere and weighty. A difficult balance to strike so I was delighted with how well Rev Sue Nutt did. She made it really enjoyable. It also helps that when you turn and glance around at the congregation, you see nothing but the beaming faces of friends and family. (…and I said I wouldn’t gush!). We had memorable readings from Verity’s brother Mark, sister-in-law Faith (ably assisted by niece and nephew Molly and Stan), and my sister Claire. All of which had special and poignant moments for both Verity and I.

The sun came out to welcome us out of the church and we spent quite a few happy moments chatting to everyone on the green before climbing into a carriage, feeling like royalty, for the short journey up to Ickworth House where we were greeted by our lovely Toastmaster, Colin. Colin really helped to keep things running roughly to schedule and looked like quite the bobby dazzler.

The next part of the day went by in the blink of an eye. We had our group photos taken in the grounds of the West Wing. Meanwhile a local brass band provided some music while the canapes were supplemented by an ice cream bike serving ice cream to the kids (and the adults). I would have loved to spend a good long time mingling at this point, but this was our time to gather groups for the photos. Our awesome ushers did a great job of that, which helped keep things moving quickly.

When looking for a photographer, I was quite specific about the kind of style and quality that I was looking for. Being a little less organised than I would have liked meant that we didn’t find quite what we were looking for in the area and so widened the search a little. At the time of writing, we’ve only seen a few sneaky peeks at the photos, but the signs are really good. We couldn’t have been happier with the friendly and talented Barrie Downie who directed us really well, clearly loved his job and has an amazing eye. It never felt like Barrie was dominating the proceedings and was really sensitive to what was important to us.

While I’m talking about people who did an amazing job for us, we were just delighted with our florist, Zoe Mills. Zoe is from the area and operates under the great name of Mills and Bloom. Zoe was just fantastic and we’d eagerly recommend her. She seemed genuinely excited for us and about the details of the flowers as they developed. That kind of excitement and calm in the run up to the day was really helpful and energising for us. She carefully listened to all of our requests and added her own insights and considerable knowledge to really bring things to life. Thanks Zoe!

Castleton Brass, the Icicle Tricycle and the staff at Ickworth House were all wonderfully helpful and friendly.

With guests seated and ready for some grub, Verity and I got to make our entrance and make our way to our seats to loud applause. Having gobby enthusiastic friends guarantees you a generous and exciting entrance. It. Was. Awesome.

We opted to have our speeches before we ate, which certainly helped me enjoy my food all the more without my nerves mounting as the moment approached. As it turns out, far from being particularly nervous at this point, I was actually more excited to get the chance to thank everyone and say some things that were important to me. I firmly believe that you can’t get a warmer, more receptive audience than at your wedding and you can’t go far wrong as the groom if you are just sincere. It felt wonderful. My father-in-law, Keith gave an excellent, warm speech which got me settled for mine. My brother Stephen gave an absolutely remarkable best man speech which he set up and delivered entirely as rhyming couplets. Full of moments to make me cringe, everyone laugh, and many of us cry it was, frankly, legendary.

The food was followed by drinking, chatting and dancing. All of which went by too quickly. Verity and I opted for a combination of a home made playlist (the contents of which had been largely crowd-sourced from all of the guests) to provide some quality, wedding-grade cheese, and a live band to provide some funk. My good friend Nigel plays the bass in an excellent band called Club Soul who were absolutely amazing and packed the dance floor immediately and for the duration. Another hearty recommendation.

Another detail which was important to us was that ours should be a child friendly wedding. So many of our friends have young kids now and our family has grown over the years to include kids and teenagers of all ages who we couldn’t imagine the day without. We debated for a while about whether or not a creche service, which had been recommended to us, would be worth the effort. I argued that people might not want their kids vanishing into the adjoining room to be monitored by strangers, and that they might feel like their kids weren’t being included. Verity thought that many people would find it useful and that having the option would give several of our important friends the opportunity to spend more time celebrating with us, and prolong their evening. Boy oh boy, was Verity right! We used a group called Artful Splodgers who did a fantastic job. Kids of all ages were being entertained with all manor of crafts and activities and they were totally engaged. Several of our friends gave us enthusiastic hugs and thanks specifically for the creche which worked perfectly. For a wedding which had so very many children in attendance, there was no disruption during the speeches, no drama from anyone getting “over tired” and yet we got to enjoy the company of lots of excited kids who were keen to show us the latest things that they had made. Yet another recommendation!

All too soon, the night wound to an end and after saying some emotional goodbyes, we retired to the Angel Hotel in Bury St Edmunds with a handful of friends who were also staying there. We, the final few, chatted away over a bottle or two of fizz until well into the early hour before our eyelids got too heavy to manage.

Verity and finally came to terms with the fact that we wrung every last drop out of the day and headed for bed around 4am and spent the next hour sitting in the window of the hotel watching the sun rise over Bury St Edmunds’ Abbey Gate excitedly recounting the day. I think that we’ll be boring people with details, highlights and photos for a very, very long time to come.

Nodejs. I just have to use it for something

2010-02-15T10:00:00Z

A little while ago, inspired by Simon Willison‘s demo of Nodejs at the FullFrontal conference, I felt the urge to make something, anything, using Nodejs. Nodejs gives lightening fast, event driven IO with Javascript running server-side in the rather nippy V8 Javascript engine. Until Nodejs, I hadn’t seen much need to bring Javascript to the server other than for testing and as a bit of a novelty. Nodejs changed all of that.

Built by Ryah Dahl with a strict philosophy that none of its procedures should ever perform a blocking operation, it has a single threaded architecture and relies heavily on the use of a single event loop. Anyone with a good knowledge of Javascript or even just a familiarity with jQuery will be familiar with the pattern of event handlers, callbacks and closures needed to build some really rather powerful things, quickly and easily with Nodejs. For my part, I just wanted to make something to explore the ease in which Nodejs could support comet-style long polling for some real-time, collaborative task. The Web is already getting flooded with examples of chat rooms and IRC servers built with Nodejs, but I really wanted to make something that felt like a real web application, not an example.

To that end, I resurrected an old idea which I first built circa 1999 for randomly choosing someone from a list to make the tea. Not earth-shattering, but a bit of fun and simple enough for me to see through to completion. For this incarnation, dubbed Teafr.com, I piggybacked on the lists feature of Twitter to allow people to create and manage their lists of potential tea-makers somewhere they are already comfortable. My app would allow a user to recall a list of their choosing and then perform a lottery, selecting a winner (or loser) from the list at random. To add a little suspense (in the loosest possible sense) I added a basic animation which gradually got slower until the winner was revealed.

I captured a couple of videos showing teafr.com doing its stuff, one of them on an iPhone. The fun part of this for me was in allowing this lottery and the animation to be visible to everyone viewing the same list from wherever they are. Nodejs makes it trivially simple to handle long-lived http requests so that all clients could listen out for the initiation of a new lottery event. Since this is all just lightweight HTTP, HTML, CSS and Javascript, it also runs pretty nicely on both my iPhone and Palm Pre.

It is rather satisfying to stand next to someone who is viewing the site on a desktop machine, and then start their screen animating with a quick tap on your handset. Cheap thrills, I know. It seems to me though, that the cheapness of the thrills is what is so exciting. I’m no rocket scientist, and I managed to create this entire application, complete with real-time online views in a couple of evenings work. The short hop and low cognitive friction for a Javascript developer to be able to build these kind of things from end to end is incredibly liberating. I’m bursting at the seams with ideas for things I want to build, and am now capable of building with a new, powerful and yet familiar tool set. The only detail which kept my new toy from the masses was having a suitable place to host it.

I’ve been using Dreamhost for a while now and have to say that I’m pretty happy with them, but even with the great level of control and access to your server that they give you, you need a little bit more control to compile and run Nodejs. The easiest and cheapest way that I found to host Nodejs powered site was with a dedicated virtual server. There is no shortage of providers in this space and as Web developers get more sophisticated, the use of this kind of solution is getting more commonplace. I opted for Linode which is working out rather nicely for me, but equally, I could have plumped for a similar offering from Slicehost or Amazon Web Services.

I’ll soon migrate all of my sites onto the single Linux instance that they host for me. For now though, I need to resist the temptation to spend all of my spare time (ha!) noodling away with Nodejs, MongoDB, jQuery and various other fun things which ‘speak Javascript’ that smart people on the Web keep on creating and selflessly sharing with the world for free.

2010-01-01T00:00:00Z

In defense of IE6

2009-08-10T10:00:00Z

No really! Read that title again. I’m about to argue against placing so much blame for painful Web development at the door of Internet Explorer 6. I’m not going try and claim that IE6 isn’t a huge pain in the arse of all good Web developers. Let’s face it, Web developers love to bitch about it, but I do think that it’s time for some accountability.

The problem with IE6 is simple. It has poor support for Web standards. It doesn’t always correctly render valid HTML and CSS, and requires nudging, tweaking and finagling in order to display the content in the desired way. Its interpretation of Javascript and interactions with the DOM are also less than perfect. That’s a pain, but does it really warrant such massive hatred from Web developers? As a Web developer, my first instinct would be to answer, ‘well, yes’. The cost of developing for IE6 is extraordinarily high, even when compared to the benefit from its market share, because it is such a horrible and time consuming slog.

But hang on a moment. The Web is something of a meritocracy. People tend to vote with their feet (or mice) and will abandon the weak experience in favor of the strong. Doesn’t this concept stretch to the browser too? Surely if IE6 was really that bad, people would have abandoned it and adopted a better, newer, more well behaved Web browser. Right? Yes and no. Many people have done exactly that. They have upgraded to IE7, IE8, Firefox, Safari, Opera, Chrome or something else. Let’s be honest, it isn’t hard to find a better browser than IE6 these days. But it isn’t quite that simple. First of all, not everyone who uses the Web really understands what A Web browser is. Many people just know that they click an icon to get to “The Internet” (by which they often mean Google) or directly to their email (by which they mean one of the many Web based email services). Understanding that they could choose a different application which accesses hese services to perform these tasks is something of a cognitive leap. Others realised that they could use a better browser and have upgraded the browser on their home computers, but at work they are locked in to using whatever the company IT department dictates. Often, this means IE6. Why is that? This is my beef. It’s not that IE6 is out-dated and substandard (although it is), but that large organisations have needed to lock users in to using an approved Web browser.

Having worked in a few large organisations, I’m no stranger to that scenario, and it’s immensely frustrating to be a user forced to use something so sub-par, and to be required to support it when you are trying to build the Webs next new hotness. So why do they do that? There can be many reasons, but the largest, and most difficult to dispute is actually of our own creation. We (the Web developers of the world) built expensive, bespoke Web applications for large enterprises and (naturally) ensured that they worked on the most popular browser of the time. Critically though, this was done without thought to how the code might perform in future, standards compliant browsers. In many cases, the code just wasn’t future proof. As a result we have applications and systems which depend being viewed in IE6 in order to function. This represents a huge risk to many large companies who invested so heavily in their development, and have come to depend on the applications. It’s little wonder that they force their employees to use IE6.

Remember that this isn’t just the fault of IE6. There have been many poor browsers over the years, but thankfully, natural selection has let them disappear and allowed better browsers to take over. IE6 suffers from its own success. That is, it’s market penetration. Combine that with bad habits from developers and you have a browser which despite being left behind by evolution, is artificially kept alive by large enterprises as if it were on a magical life-support machine. I imagine that it would rather be left to die in peace.

Surely then, we Web developers have learned our lesson. We’re not going let something like that happen again are we? Staggeringly, after all the grumbling and pain, I see evidence that many of us haven’t learned our lesson at all. We still write code which detects which browser is being used, before going on to specify behaviour accordingly. What we should be doing is testing for the support of our chosen implementation, then implementing accordingly. Think object detection, not browser detection. That way, when a browser improves its support, or the user starts using a new browser, the application can enjoy the benefits, rather than just falling over. I was particularly aggravated to learn how IE8 can be set to render as if it were IE7. With a meta tag to provide “Internet Explorer 7 Compatibility mode”.

Why would this feature exist? Microsoft explain that it is so that developers can opt for “backwards compatibility with Internet Explorer 7 JavaScript and layout behavior”. In other words, it exists to try and get around the fact that so many developers wrote code to satisfy the quirks of IE7 without a thinking about how their code would fail when the quality of the browser is improved (have better conformance with W3C standards for HTML and CSS). Microsoft didn’t want people to be resistant to upgrading to IE8 because of so many sites failing to render correctly in their shiny, new, more compliant browsers, so they provided a way to force the browser to continue to mis-interpret the code. I’m afraid I have to call “bull-shit” on this practice. I think that all this does is create another wave of Web sites and applications which are likely to get stuck in non-compliance land and require old rendering engines and legacy browsers to be kept alive to server them.

Only by developing for the rising tide of web standards, rather than the various quirks of specific browsers, can we hope to avoid locking our users in to a given browser. It’s time to make sure that we don’t get into this situation ever again. So next time you are tempted to grumble about IE6, remember that you can help avoid a similar mess in future by developing with standards in mind.

Image credit: John Martz

Using Quicksilver to control Last.fm

2009-08-07T10:00:00Z

For a while, I’ve been using handy Quicksilver triggers to control iTunes. I like not needing to switch my attention from what I’m working on, in order to skip a track, pause the playback, set a rating or whatever. You can find out how to create a trigger from one of the many great Quicksilver tutorials out on the Web.

At the moment though, I find myself listening to Last.fm more and more, and have been looking for a similar way to control the Last.fm application. I couldn’t find a plugin for Quicksilver to achieve this so I set about writing an Applescript which I could trigger with Quicksilver. I’m not much of an Applescript whizz, but I managed to put the following script together to skip the track currently playing in the Last.fm application:

tell application "Last.fm" to activate
tell application "System Events"
        tell process "Last.fm"
                click menu item "Skip" of menu "Controls" of menu bar 1
        end tell
end tell

AppleScript

After saving this in a suitable location (I have a Utils folder where I keep lots of scripts and utilities), I set a Quicksilver trigger to run the script. Simple! Happy with the result, I created similar scripts for some other controls like love, ban, play and stop and assigned them all keyboard triggers.

My only wish was that I could do this without giving Last.fm focus. Generally this is fine for my because I have it running in a second display, so it doesn’t steal my attention, but it would be nice if I could get Applescript to execute the command without activating the application. I’d welcome suggestions from anyone with more Applescript fu than me.

Flash v Web. Behind Enemy Lines

2009-07-27T10:00:00Z

OK, I’m being over dramatic, but sometimes it does feel like I’m on a bit of a stealth mission. Pity that I forgot to bring any stealth! I’ve been working here at The Team for 3 months now and am enjoying myself greatly, but there is an issue that challenges me on a daily basis. That is that we do a lot of Flash work here, and yet I’m a big advocate of using Open Web Technologies.

In the past I have ranted on and on about how The Web is better off when we build things out of Web technologies than from proprietary technologies which seal in the content, limiting opportunities to get at it. How do I reconcile that? Well, The Team is not just a Web development agency. We are a brand communications agency who have a digital arm. That digital arm (of which I am part) produce all sorts of output, and not all of it is destined for the Web. We produce video content and interactive Flash content for DVDs, kiosks and the like which are jaw-droppingly beautiful. Such content is produced by some very talented folks who in many cases, regard Flash as their weapon of choice. Building things from Flash in this context is fine with me. Often it can be the ideal choice. It is when this hunger for Flash crosses over to building web sites, that I have a problem.

I enjoy a stunning, well crafted, interactive experience as much as the next guy, but I have pretty strong opinions on how and when we use Flash to deliver such an experience. For me, Flash content lives in a similar category to video content or a pdf document. That is, you can put it on the Web, but that won’t make it a Web site. (as I write this, I’m find myself hearing Wesley Snipes proclaiming: ‘You can put a cat in the oven, but that don’t make it a biscuit!’ Perhaps I’ll refrain from that level of trash talking for now.) Being vocal about this opinion (of Flash and The Web, not cats and biscuits) in my new role, while in the company of many Flash developers and Flash fans has raised a few eyebrows and brought about some interesting debates.

I was particularly chuffed to hear my colleague Stephen playfully remark that I must be part of the “Anti Flash Mob”. I’ve got news for you Steve. There are loads of us out here, and we’re thinking of getting t-shirts! In truth I’m not anti-Flash. I’m all for choosing this right tools for the job. But my contention is that when the job is delivering information to the widest possible audience, with the greatest amount of confidence that everyone (and everything) wanting to get at that information can do so, then Flash is the wrong choice. At TED this year, Tim Berners Lee gave a fascinating talk where he touched on his vision of the future for The Web (which until HTML5 with its native video tag comes along, you’ll need Flash to watch online). That future was for an “Open Data Web” where we have access not just to documents (as in The Web as conceived by TimBL in 1989) but also ready access to the core data beneath. That sounds good to me. I’d much rather build a site which lets people bookmark pages of interest, copy and paste content to other places, be addressable via hypertext links, be accessed by screen readers and search engines, provide deeper context for information with Microformats, and so on.

Usually during a conversation like this, someone will bang their fist and say “…but you can do that with Flash!”, Well I’d be delighted to be proven wrong, so consider this a challenge. Show me. I’ve heard talk of Flash sites which offer all (or at least much) of the good stuff you get from developing for and with The Web, but have never been shown any evidence. I’d love to see examples. The comments section below awaits your links. For the time being, I’ll keep challenging any automatic choice of Flash over Web technologies on projects, but that’s just common sense, right? Every technology choice should be justified.

Moving on from Osmosoft

2009-04-23T10:00:00Z

Last week was both sad and exciting for me. Exciting because I was gearing up to start my new job at theTeam, a London-based communications agency with a slightly silly name. Sad because it was my last week working at Osmosoft (a company that created plenty of silly named things itself).

I had been at Osmosoft since it grew from a one man band into an open source innovations team at BT, and had a terrific experience along the way. I think that it is safe to say that I have learned more about The Web during my time at Osmosoft than in any previous job and that is in no small part due to the quality and experience of the people around me.

During my time I honed my appreciation of what makes a good Web citizen. From technology choices to quality of delivery. From interaction design to exhibiting good taste. From the importance of the ‘View Source’ experience to openness and data availability. I’m going to miss the raging debates and big opinions which regularly surfaced at Osmosoft. The people there are intelligent and articulate.

Osmonauts, I salute you!

But now I’m off to pastures new. theTeam has a young, but growing digital arm with an impressive client list. I’ll be involved in what we deliver into the browser and how. A chance to influence the nature of the browser experience by pushing for unobtrusive technologies and best practices on a range of sites which is due to increase in both reach and diversity is a big draw for me. I’m looking forward to the challenge.

My transition has been made easier by a number of things. Firstly, Osmosoft and theTeam have already established a bit of a relationship. Co-hosting a recent Open Source Show and Tell revealed some common interests and enthusiasms. I’m hoping for more crossover at events like that. Secondly, a big part of my time at Osmosoft was spent developing for an open source project called TiddlyWiki. While I’ll have to scale back my time on that, there is no reason for me to turn my back on it altogether. I’m keen to keep on contributing and building applications with TiddlyWiki. Besides, it’s nice to bump into familiar friends in the TiddlyWiki irc room.

Osmosoft really sparked a lot of enthusiasm for me when it comes to both open source software and compelling Web content. In addition to contributing to TiddlyWiki, I’m hoping to start a small open source project of my own to feed my desire to make great stuff for the Web that anyone can use.

Thanks for everything Osmosoft. It’s been a blast!

Photo credit: Phil Whitehouse

Leveraging jQuery and jQuery plugins in TiddlyWiki

2009-03-13T10:00:00Z

The recent release of TiddlyWiki v2.5 included something rather exciting for me: jQuery, the popular Javascript library is now part of the TiddlyWiki core.

This is exciting for a number of reasons.

The TiddlyWiki core functions can now use jQuery to perform all manner of DOM inspection and DOM manipulation. We can refactor a ton of code to benefit from jQuery’s blistering Sizzle engine and pass the burden of maintaining lots of utility functions over to those clever jQuery bods. All of which will simplify the TiddlyWiki codebase and ultimately make it easier to read and easier to maintain.
TiddlyWiki plugin developers will now be able to make use of jQuery in their plugins. That’s great news for both hardcore plugin developers and people dabbling for the first time. jQuery is elegantly expressive, powerful, and superbly documented. All of this lowers the barriers to entry for a would be developer and smooths the way for exisiting developers.
There is a huge wealth of jQuery plugins which can now be utilised by TiddlyWiki. The quality of many of these plugins is tremendously high. Bring ‘em on!

But how does a TiddlyWiki plugin developer get started? How can we bring a jQuery plugin into TiddlyWiki and make it available via a Macro? Let’s take a look at an example.

Fred, my colleague at Osmosoft stumbled upon a plugin which creates a nice navigation structure from an HTML List element. The plugin has lots of examples and documentation and seemed like a good contender for bringing something useful into TiddlyWiki.

To include the plugin, all we need to do is copy it into a tiddler and then tag the tiddler with systemConfig. After saving the file and reloading, the plugin is available for us to use.

With the jQuery plugin availble, we can use it to provide a snazzy UI for any UL or LI elements on the page. The Javascript syntax for that is nice and simple:

// Turn the list element with an ID of 'myList' into a funky ListNav
    $('#myList').listnav();

JavaScript

This is great, but we want people to be able to call this from TiddlyWiki without having to write Javascript. If we create a TiddlyWiki macro to call this for us, people can easily make a nice NavList anywhere. Let’s make a macro which turns the contents of a tiddler into a NavList like this:

JavaScript

To make that available, we should create a TiddlyWiki plugin which delivers this macro. We do this in a new tiddler. I created a tiddler called ‘ListNavPlugin’ and once again tagged it with systemConfig so that it becomes code that TiddlyWiki knows to interpret. To start with, let’s just create the macro and ensure that we can invoke it.

// create macro object
 config.macros.listnav = { 
   // Add a handler function to be invoked by > 
   handler: function(place, macroName, params, wikifier, paramString, tiddler) {
     // do some magic...
     alert("I'm gonna make a funky listnav!");
   }
 };

JavaScript

To see it working, I created two more new tiddlers. MyFruityList holds a list of items, and ExampleListNav holds a call to the new macro.

Saving the TiddlyWiki file and reloading will make the macro available to call. If we open the ExampleListNav tiddler, we should see our macro called like this:

All good, but not exciting yet. Let’s flesh out our TiddlyWiki macro a bit. We’ll use a TiddlyWiki function to get the text from our desired tiddler and then make a list from it. Where we might once have used some TiddlyWiki utility functions to help us create the HTML elements (like createTiddlyElement), we can now use jQuery’s helper functions to append elements to the document.

// create macro object
 config.macros.listnav = {
 
   // Add a handler function to be invoked by > 
   handler: function(place, macroName, params, wikifier, paramString, tiddler) {
 
     // target tiddler passed in as macro parameter
     var title = params[0];
 
     // read list items from tiddler contents
     var text = store.getTiddlerText(title);
     if(text) {
 
       // generate list
       var items = text.split('\n');
       var list = jQuery('<ul></ul>').attr('id', 'listnav').appendTo(place);
       jQuery.each(items, function(i, itm) {
         jQuery('<li>').text(itm).appendTo(list);
       });
 
     }
   }
 };

JavaScript

Now we’re getting somewhere. We’ve grabbed each line from our MyFruityList tiddler and used jQuery to turn them into an unordered list.

We can now call the jQuery plugin to render our list as a NavList. The plugin requires a little extra HTML so we can create that, and then call the listnav plugin.

// create macro object
config.macros.listnav = {
 
    // Add a handler function to be invoked by > 
    handler: function(place, macroName, params, wikifier, paramString, tiddler) {
 
        // target tiddler passed in as macro parameter
        var title = params[0];
 
        // read list items from tiddler contents
        var text = store.getTiddlerText(title);
        if(text) {
            // generate nav bar
            jQuery('<p />').attr('id', 'listnav-nav').appendTo(place);
 
            // generate list
            var items = text.split('\n');
            var list = jQuery('<ul></ul>').attr('id', 'listnav').appendTo(place);
            jQuery.each(items, function(i, itm) {
             jQuery('</li><li>').text(itm).appendTo(list);
            });
 
            // apply listnav
            list.listnav();
        }
    }
};

JavaScript

When we save our plugin, reload the page and open up our ExampleListNav tiddler, we see the navlist. Cool! Hang on though, it looks a bit rubbish. Not like the examples we saw earlier. We have to include the CSS to style our new navlist. Easy enough, let’s use our TiddlyWiki plugin to create a sylesheet for our new HTML by adding this:

// add default styles (adapted from http://www.ihwy.com/labs/downloads/jquery-listnav/2.0/listnav.css)
   config.shadowTiddlers.StyleSheetListNav = '  \n' +
   '#listnav-nav { margin: 20px 0 10px; }\n' +
   '.ln-letters { overflow: hidden; }\n' +
   '.ln-letters a { font-size: 0.9em; display: block; float: left; padding: 2px 6px; border: 1px solid #eee; border-right: none; text-decoration: none; }\n'+
   '.ln-letters a.ln-last { border-right: 1px solid #eee; }\n' +
   '.ln-letters a:hover, .ln-letters a.ln-selected { background-color: #eaeaea; }\n' +
   '.ln-letters a.ln-disabled { color: #ccc; }\n' +
   '.ln-letter-count { text-align: center; font-size: 0.8em; line-height: 1; margin-bottom: 3px; color: #336699; }';
   store.addNotification('StyleSheetListNav', refreshStyles);

JavaScript

And we’re done. The jQuery plugin is turning our boring old list into a dynamic indexed list with navigation. Cool! For extra credit, we can make our jQuery a little more concise. Notice that we call jQuery by name rather than with the common idiom of $. We could simply replace each jQuery with $ in our code and that would work, but beware! There are other Javascript libraries that use the $ shortcut. we don’t want to introduce the possibility of a clash. Luckily, there is a simple way to get around that. All we need to do is wrap our TiddlyWiki plugin in a closure and pass jQuery in as an argument (as explained on the jQuery documentation site). Then we can use whatever shortcut for jQuery in our code that we like. The final code looks like this:

(function($) { // set up alias
 
   // create macro object
   config.macros.listnav = {
 
   // Add a handler function to be invoked by >; 
   handler: function(place, macroName, params, wikifier, paramString, tiddler) {
 
     // target tiddler passed in as macro parameter
     var title = params[0];
 
     // read list items from tiddler contents
     var text = store.getTiddlerText(title);
     if(text) {
 
      // generate nav bar
      $('<p />').attr('id', 'listnav-nav').appendTo(place);
 
      // generate list
      var items = text.split('\n');
      var list = $('<ul></ul>').attr('id', 'listnav').appendTo(place);
      $.each(items, function(i, itm) {
        $('</li><li>').text(itm).appendTo(list);
      });
 
      // apply listnav
      list.listnav();
     }
   }
 };
 
   // add default styles (adapted from <a href="http://www.ihwy.com/labs/downloads/jquery-listnav/2.0/listnav.css)">http://www.ihwy.com/labs/downloads/jquery-listnav/2.0/listnav.css)</a> 
   config.shadowTiddlers.StyleSheetListNav = "\n" +
   "#listnav-nav { margin: 20px 0 10px; }\n" +
   ".ln-letters { overflow: hidden; }\n" +
   ".ln-letters a { font-size: 0.9em; display: block; float: left; padding: 2px 6px; border: 1px solid #eee; border-right: none; text-decoration: none; }\n"+
   ".ln-letters a.ln-last { border-right: 1px solid #eee; }\n" +
   ".ln-letters a:hover, .ln-letters a.ln-selected { background-color: #eaeaea; }\n" +
   ".ln-letters a.ln-disabled { color: #ccc; }\n" +
   ".ln-letter-count { text-align: center; font-size: 0.8em; line-height: 1; margin-bottom: 3px; color: #336699; }";
   store.addNotification("StyleSheetListNav", refreshStyles); 
 
 })(jQuery);

JavaScript

You can explore the finished example in a TiddlyWiki.

Mashing up flickr in the client with jQuery

2009-02-15T10:00:00Z

Recently I saw Tim Stevens post on Twitter about a slide show he had built using his Liveloom application. His slide show grabs some photos from Flickr tagged with ‘Osmosoft’ and then renders them with all manner of visual effects using Flex. While the visual effects available via Tim’s app are impressive, I’m a big advocate of open web standards and enjoy making things from HTML and Javascript, rather than using tools like Flex.

My first encounter with the slide show made by Liveloom was on an iPhone where it couldn’t run. The temptation to cobble together a simple Flickr mashup which could operate in any Javascript capable browser was too much to resist. Let’s not pretend, that there aren’t already slide show mashups galore, or that I was going to be able to rival some of the advanced visual effects that Liveloom can offer, but making a simple, attractive slide show which could run on lots of devices seemed like a fun and valuable exercise. I was also keen to see just how quickly and easily I could produce this using jQuery. I’m forever going on about how good jQuery is at manipulating the DOM, so this seemed like a good chance to demonstrate that. I shared the result my efforts as the ‘Poloaroiderizer’ and after getting some great feedback, promoted it to its very own domain.

Check it out over at polaroiderizer.com As it turns out, the task was incredibly simple and took just a few hours one evening. The interface is rendered with HTML and CSS. As such, it will work in any modern browser. I used jQuery to request JSONP from the Flickr API. JSPONP gets you around the cross domain scripting restrictions and delivers JSON to the browser which is a snap to parse and render. There is no logic on the server. All of my code is run in the browser. The animations are provided by CSS and DOM manipulation, made simple by jQuery’s animation functions. The display needs Javascript to render, so without it Polaroiderizer is a bit toothless, but that doesn’t mean we can forget about those without Javascript. If you submit a flickr tag while you don’t have Javascript capabilities, the form will submit your tag to the standard flickr interface and you’ll find yourself at the flickr search results page. This is another example of progressive enhancement. A topic close to my heart that I tried to demonstrate recently on Unobtrusify.

Another little bonus of building this slide show app this way, is that it is super-easy to share the results. I made sure that the tag entered was echoed into the address of the page as the page fragment identifier. Manipulating and interrogating the frag id can be useful in Ajax applications as my colleague Michael Mahemoff explained recently. When the page loads, it looks for a tag stored in the frag id as its starting point. That means you can bookmark slide shows and share them as easily as email a URI. Here are a few:

Unobtrusify your Javascript

2009-01-05T10:00:00Z

Recently Jon Lister, a colleague of mine at Osmosoft showed me a website made by his friend Joshua Bradley. The site, used some of the Javscript code from TiddlyWiki‘s animation engine to create some nice visual effects. I loved the design, but could see some room for improvement in the implementation. I’m a big advocate of Unobtrusive Javascript and Progressive Enhancement and so I set about producing a quick demo of how a similar result could be achieved in the most Web-kind and accessible way available using jQuery for the behaviors.

The result has been published as Unobtrusify.com.

The aim.

Create a similar effect to that on Josh’s site, but make sure that the page is readable without Javascript.
Use images to make the headings look snazzy, but make sure that they are not required in order for the content to make sense.
Use only unobtrusive Javascript and keep the HTML as clean as possible.
Reduce the number of http requests required to as few as possible in order to improve performance.

The approach.

First of all, I wrote the text for the page. I chose a simple statement and tried to structure it such that it would make sense regardless of which sections were expanded.

Then I used the simplest HTML markup I could to logically represent the content with its various headings. This is how the page would look to text-only browsers search engines, web-crawlers and screen-readers.

I then used a well-known CSS technique to replace the text in the headings with images. This would ensure that the text would remain for non-human consumers of the site, while the images would be presented to those able to appreciate them. The technique is simple. You prevent the browser from scrolling the content of your element with overflow:hidden and then scoot the text out of the way with text-indent. Now that the way is clear, you can display an image with background-image. Be sure to specify the dimensions of your desired image as the background-image property will not resize your element to the correct size automatically. The CSS would look something like this:

#myHeading {
    text-indent: -9999px;
    overflow: hidden;
    background-image: url(myImage.gif);
    width: 380px;
    height: 123px;
}

CSS

My content had 6 headings to render in this way. I also wanted to have a mouseover effect to give some affordance for the click-ability of the headings so this would require another 6 images. Rather than having 12 images to download (which would require 12 separate HTTP requests), I combined all of these images into a single image. This would have a number of effects. Firstly, combining the 12 images into one meant that the total download would be a bit smaller due to the way that the file was compressed. (A tiny saving, but every little helps.) Secondly, there is an overhead with making HTTP requests so when it comes to performance, the fewer the better. This method cuts out 11 HTTP requests. Score! Thirdly, as the browser uses the same image for the original heading images and their associated mouseover images, there is no need to preload the alternate images to avoid that nasty pause when mousing over. The image is already downloaded and ready to display. A nice bonus.

In order to use this ‘image sprite’ for each and every heading, I just needed to specify the background-position for each one. Some attributes would be common to each one so I could save some code like this:

h1 {
    text-indent: -9999px;
    overflow: hidden;
    background-image: url(images/unobtrusive_sprite.gif);
    width: 380px;
}
 
h1#uj {
        background-position: 0 0;
        height: 123px;
}
 
h1#cmh {
        background-position: 0 -123px;
        height: 150px;
}
...

CSS

At this point our page looks like this. This is exactly how we want things to appear for those without Javascript. There is no ability to toggle the display of the various sections, the content is shown in full, and there is no mouseover behavior on the headings to suggest that they can be clicked (since they cannot). This is the essence of Progressive Enhancement. We have a perfectly serviceable web page (albeit a simple one) which we can now enhance for those with Javascript enabled.

Using jQuery to easily and unobtrusively add behavior to elements on the page, we can now hide all of the expanded sections. We do this with a simple jQuery statement like this:

$('#wrapper > div').hide();

JavaScript

This hides all of the div elements which are a direct descendent of the element with an ID of wrapper. (my chosen HTML structure).

Headings are not by default clickable so we can add some behavior to suggest that the clicking a heading will have a effect by changing the cursor for them like this:

$('#wrapper h1').addClass('clickable');

JavaScript

A CSS class of ‘clickable’ specifies the cursor with cursor: pointer;

We also use jQuery to show the hover image by just repositioning the background image when we hover with the mouse and also to show the hidden div element when we click a heading. Remember, none of this will happen unless Javascript is available.

I also use an additional trick to prevent a flash of unstyled content or FOUC (gratifyingly pronounced ‘FOOOOOOK’ by John Hicks) while the Javascript is being downloaded. This trick is very well explained by Karl Swedberg on the excellent learningjquery.com site.

For a better picture of exactly what is going on, why not swing by Unobtrusify.com and exercise your right as a citizen of the Web to view the source. Hitting View Source is so often the best way to learn how things are done. Go on! Go and get your hands dirty!

Announcing JigglyWiki. A TiddlyWiki experiment with jQuery

2008-08-27T10:00:00Z

Once upon a time I was resistant to the idea of Javascript libraries. That was due to a couple of things. Firstly, I was comfortable with writing the Javascript for my projects myself and didn’t like the idea of relying on someone else’s code which I couldn’t easily inspect. Secondly, at the time there weren’t really any libraries. Then there were a few, but they were all, well, to be blunt, a bit pants.

That all changed for me when jQuery came along. jQuery is a lightweight, elegant but powerful Javascript library originally developed by John Resig. jQuery provides fast and efficient interrogation and manipulation of the DOM and borrows conventions from CSS and XPATH to provide concise and expressive queries to be constructed. It’s worth checking out if you haven’t already. TiddlyWiki has been around since before the existence of Javascript libraries and long before jQuery came along, so it was never developed in a way to take advantage of such things. It could easily be argued that TiddlyWiki is itself, a Javascript library since it provides helper functions for many common Javascript tasks. The extent of this library though, is a little limited since it has evolved to serve a single purpose: To drive TiddlyWiki.

Recently I have been longing to experiment with replacing a lot of the TiddlyWiki core with code built to take advantage of jQuery. The idea of developing TiddlyWiki with a Javascript library turns out not to be a new one as similar discussions have occurred in the past and different libraries considered. I then began to imagine other benefits from reengineering TiddlyWiki from first principles taking advantage of all of the lessons learned over its lifetime. It became too hard to resist. Over the course of 2 reasonably long train journeys, I set about building my own version of TiddlyWiki with jQuery at its core. I settled on a number of objectives:

To use jQuery to provide the core TiddlyWiki functions.
To make the code modular such that the core could be very small and additional functionality could easily be included via bespoke jQuery plugins.
To use unobtrusive Javascript
For the document to be sensibly parsed by screen readers and web crawlers.
To allow navigation of the document even without Javascript
To use HTML and CSS which is valid according to the W3C
To conform to the TiddlyWiki naming convention and adopt a suitably ridiculous working title for the project

An important thing to note, is that I am not attempting to replace TiddlyWiki. I see JigglyWiki as an experimental prototype to explore ways that TiddlyWiki 3.0 might evolve. I also hoped to keep this quiet for long enough to allow it to progress to the point that I was happy to reveal a working prototype for general discussion. That proved tricky thanks to my own excitement and the way that gossip spreads around the web and discussion groups!

In its current state, it provides some of the more basic TiddlyWiki functions in terms of displaying tiddlers and allowing editing. It also demonstrates how it might elegantly degrade when CSS or Javascript are not available. Below are a few different build which demonstrate those scenarios.

Just the HTML. I’ve not included CSS or any of the Javascript here. The data store is visible and you can navigate the document via the tiddler links.
The HTML and CSS. This will function just as the version above, only it will look a bit prettier. In environments where Javascript is not available or is slow to be initialised, this is how things look until the Javascript kicks in.
HTML, CSS and Javascript. Now the data store is hidden and the default content is displayed with additional, Javascript dependent functionality included.

I’d love to get comments on this approach. I’d also be very interested to get advise on TiddlyWiki issues that we might be able to avoid if the opportunity to develop this into TiddlyWiki 3.0 really did come about. I’m less interested in bug reports though. This is a very early proof of concept which will contain many bugs and glitches. You can get to the source of this project via the TiddlyWiki subversion repository More to come!

Enthusiasm and Good Food at TiddlyParis

2008-08-27T10:00:00Z

Yesterday I was fortunate to be able to make the quick trip over to Paris to attend a meeting of TiddlyWiki enthusiasts at TiddlyParis. Arranged by long time TiddlyWiki community member and Una Mesa stalwart Saq Imtiaz, this event was a great chance to put some faces to the names of some of the TiddlyWiki developers and users whose work I have been enjoying and benefitting from for some time.

Gathering in a funky bar on the Champs Elysees, the 10 of us shared a beer or two and got to talk about what we were all doing with TiddlyWiki and get to know each other a little better.

The spectrum of TiddlyWiki experience was pleasingly broad.

Zap recently found TiddlyWiki and is using it to manage his notes and background material to support the effort in writing a novel. He is also tinkering with TeamTasks and made the observation that once you start experimenting with ways to customise and extend TiddlyWiki, you can easily find yourself absorbed in the endeavour. Ideas spring forth even faster than you can execute them.

At the other end of the spectrum we have Jacques, who has been working with TiddlyWiki since the very early days. Jacques showed us all his TiddlyWiki PIM on his 4 year old tablet PC. The file was well over 3MB in size (something of a beast in TiddlyWiki terms) chock full of content and heavily customised. I mean really heavily customised! Jacques had moulded it to fit his way of working and had borrowed from the best TiddlyWiki adaptations around the web. With advanced workflow management and various task lists, widgets and doohickies, I found it a bit hard to drink it all in, but it was a perfect fit for Jacques and goes everywhere with him. Jacques pledged to make a blank copy available at some point. You’ll need to speak French though as he had also carried out extensive translation.

I was delighted to learn that relative newcomer Pier, whose Google Maps / TiddlyWiki mashup gathers information about popular activities and movements around Paris, chose TiddlyWiki primarily because of its ease of use as a mashup platform. Score! (He was also attracted by the snazzy tiddler animations!)

Loic Dachary revealed several TiddlyWiki resources which have been around for a while, but I had failed to stumble upon. Perhaps targeted at the more techie geeks among us, they were impressive nonetheless. My favorite was TiddlyWiki_CP which is a ruby gem providing a library and a command line interface to copy TiddlyWiki tiddlers to files and vice versa. Incredibly useful for any developer who builds a variety of TiddlyWikis.

I was very keen to meet BidiX who has quietly been producing great TiddlyWiki assets for some time. Recent work includes iTW, the best iPhone TiddlyWiki that I know of. The TiddlyParis edition of iTW went with me in my pocket to help me find the venue and read about the agenda. BidiX is also the man behind TiddlyHome, a lovely and seemingly simple hosted TiddlyWiki resource which he recently deployed to Google App Engine for its next release (which we got to play with, but he insists isn’t quite ready for prime time yet).

For my part I spoke about TeamTasks, which I was happy to learn was being used to some degree by several people around the table. I also answered questions about BTs interest in TiddlyWiki and motives for being involved in such a project and community. I’ll not go over that again here, as it has already been well articulated by several of my colleagues on their blogs.

I went on to talk about a new pet project of mine which, following the TiddlyWiki convention for absurd names, has been dubbed JigglyWiki. (As it turns out, the French accent lends this name much more gravitas due to the soft ‘j’. Marvelous!) JigglyWiki deserves a blog post of its own. For now, through, let’s just describe it as and experiment to explore what TiddlyWiki 3.0 might be like if it were to be developed from the ground up with the use of the jQuery javascript library and adopt an unobtrusive Javascript approach.

JigglyWiki (I can only hear that in a French accent now!) created quite a bit of discussion. Proppy and Loic Dachary were particularly vocal about the potential for a TiddlyWiki implementation benefitting from unobtrusive javascript and built in a modular way with a library such as jQuery. Debate raged about the need for a javascript library to properly manage plugins and dependancies. A topic that I’m sure I will be discussing more in a later post.

My thanks go out to all of the folks I encountered at TiddlyParis. Not only for their passion about TiddlyWiki, but also for making me feel so welcome and for conducting the entire event in English rather than in French which I know required considerable effort from some. For what it’s worth, my French stretched far enough for me to order my meal (which was bloomin’ great) and a few drinks without totally shaming myself. Big thanks also to Saq Imtiaz for putting it all together. When’s the next one?!

A bientôt!

Get your Task Management wiki

2008-07-16T10:00:00Z

After a bit of a hiatus, I’ve recently been concentrating on developing my pet project, teamtasks again. Teamtasks is a simple application built using TiddlyWiki to provide a place to manage your tasks alongside other content in your very own personal wiki.

This little project is by no means new. I have been tinkering with it for quite a while but have been working on other projects so teamtasks has had to sit patiently in the corner and wait for me to get back to working on it.

Rather gratifyingly, quite a few people had seen the early work on teamtasks and expressed interest in using it for all manor of purposes. The attention made me realise that it was time to promote teamtasks from its place in my playground (version 0.3 can still be found there for those keen on glancing in the rear view mirror) to the big time! Or at least, a place of its own. And so getteamtasks.com was born. From there you can download the latest version (v0.4 at time of writing) and configure it to fit your task management habits.

This is an open source project and I’m doing my best to resist the urge to tinker with it until I think that it’s perfect before letting it out into the wild, so you may find things about teamtasks that don’t work perfectly or you just don’t like. If that’s the case, then please let me know, or better yet, fix it and then show me. I’m living by the old “Release early. Release often” mantra here and welcome contributions, in the form of suggestions, bug reports, bug fixes, enhancements, criticism, praise, sticky buns, pats on the back, or hugs.

Along with the new site and new release, there is a new way to get in touch and keep track of developments. Obviously, you can leave your comments here, but now you can also follow teamtasks on Twitter. You’d get to hear about teamtasks developments if you just followed me on Twitter too of course, but then you’d also be subject to other random utterances.

After just a few hours of launching getteamtasks.com, I have already had a nice response. This really helps to keep me motivated and on track. As the project gains a little momentum, it also gains more pairs of hands to do the work. We’ve spent some time here at Osmosoft today planning the next set of enhancements for teamtasks which will soon be listed on the site for you to inspect.

Roll on version 0.5!

NBA updates on Twitter

2008-05-19T10:00:00Z

Just in time for the 2008 NBA playoffs, and heavily influenced by Robbie Clutton’s marvellous UK football scores service, I have created NBA Results

This simple service monitors results published as RSS feeds from TotallyScores and then sends updates to twitter. By following NBA Results on Twitter, you can get alerts of all NBA match results. Only interested in updates for your team? That’s fine, you can choose instead to follow your team. There are currently accounts for:

I’ll be adding more teams ready for next season, but if you want to make sure that you can get updates on Twitter of your team’s results, feel free to email me (phawksworth [at] gmail [dot] com) and push your team to the top of my todo list.

I’m also readying MLB Results to provide Major League Baseball results. MLB Results will be active very soon. As with the NBA teams, please poke me if you want to get updates for your team and I’ll be sure to create their account.

The code which drives this, is my first outing into the world of Python. You can find the code here. Feel free to take it and use it as you wish. I also welcome feedback and suggestions on the code, please be gentle though, as I said, this is my first time playing with Python.

Many thanks to the nice folks at Carsonified for permission to use their site’s background image on NBA Results. Thanks also to Balakov who published the image used for each NBA team twitter account icon under a Creative Commons license on flickr.

JSSpec bundle for Textmate helps with writing tests

2008-04-18T10:00:00Z

Recently, we at Osmosoft have been trying to make good on one of our pledges: To introduce a unit testing framework to Tiddlywiki development.

Along the way we examined several Javascript testing frameworks and found that JSSpec suited our needs quite nicely. JSSpec resembles the popular RSpec testing framework popularly used by Ruby developers.

As a result, I have been dabbling away at writing tests in my favoured text editor - the rather lovely Textmate. Since this is a repetitive task, I figured that it was worth creating some helper to speed things along. Textmate offers an easy to make powerful bundles to automate tasks and help you in your code development and so I quickly put together a JSSpec bundle Textmate. This simple bundle offers a set of snippets which can act as a quick reference of what methods are available in JSSpec and let you rapidly create your test code. Textmate users can download this bundle and just double-click it to make it available for use in Textmate.

I won’t go into the workings of testing with JSSpec here, rather, you can learn about that at the official site.

Feel free to take this bundle and modify it to fit your purpose. Enjoy.

How to create and distribute lovely screencasts

2008-03-28T10:00:00Z

For a while I have been meaning to start posting screencasts of some of my work to spread the word, and to explain some of the details that are difficult to describe in text.

After much tinkering, I think that I have arrived at a nice setup and have found a good way to distribute the screencasts, making them available to stream over the web or to download for consumption in your own sweet time.

In this post, I’ll share my findings so that you can set yourself up with a similar environment. I use a Mac, and so these tips are levelled squarely at the Mac users out there. Sorry to everyone else, but I’m just writing about what I know.

Here is an example screencast. The best view is in HD over here.

I think that in order to create a good screencasts you need to think about the following things:

Good content. Know what you’re going to say/show and prepare yourself in advance.
Have a clean environment on screen.
Capture your content with the optimal settings.
Compress your content correctly.
Host and distribute your content in the most effective way.

Let’s take a look at those in more detail.

1 - Good content

I think that it is worth practicing what you are going to show and getting everything ready in advance so that you don’t waste any time. As far as having something compelling to show, I’m afraid that you’re on your own on this one.

2 - Have a clean environment on screen.

Removing clutter which can be distracting and untidy is a good way to help communicate you message more effectively. Since I don’t want to have to disrupt the setup that I use for my everyday work, I created a new user on my Mac called Demo which I use not only for capturing screencasts, but also for when I need to use my laptop to give a presentation using a projector. Having this separate user account allows me to keep the desktop totally clear and to keep it set to the optimal screen resolution for captures and projection. I chose to hide any mounted drives and whatnot by modifying my Finder preferences. I also increased the font size and icon size in the Finder View Options.

There is also value in having a simple, clean wallpaper displayed. Again, the aim is to reduce noise and distractions. People don’t all need to see the photos of your kids learning to ride a bike while they are trying to absorb what you are demonstrating.

3 - Capture your content with the optimal settings.

I chose to use SnapzPro as my screen capture software. There are others, but this suited my needs and worked well for me. The screen resolution that you choose is important here. It took me a little time to settle on the right screen resolution. Initially I chose 1024x640. SnapzPro allows you to scale your capture which I did, choosing 70%. This gave a nice result which was big and clear and the file size was also good. In the end, I increased my screen resolution for capture to 1280x800 and didn’t scale it down at all.

The reason for this is due to the channel that I chose to distribute my content through. More on that in point 5. I also lowered the frame rate a little. I dropped it to 18 frames per second in order to save a little on the file size.

I also like to let the viewer see what keys I am pressing during demonstrations. For this I used the rather handy Mousepose application. This also allows you to highlight the location of the mouse pointer.

4 - Compress your content correctly.

Now that you have recorded your content, you need to make sure that you compress it appropriately. This will of course be influenced by the your chosen hosting and distribution method. I compressed to h.264 to give good quality output while squeezing the file size down. My other settings are shown below.

5 - Host and distribute your content in the most effective way.

I wanted to be able to embed my screencasts on my website, but also allow any interested viewers to be able to download them to keep. Reducing any barriers to accessing the screencasts was important to me, so I didn’t want to require the viewer to install any software before being able to view them. For that reason, a flash based video seemed sensible, due to the ubiquity of the flash player in browsers. I also wanted the screencasts to be of a suitably video quality. Vimeo.com will host HD content and stream content to your site. A bit of a sticking point at the moment is that they don’t yet allow HD streaming to your embedded videos. You need to view them on their site for that. Apparently, this is will be available soon. They allow you to download the videos from their site and their fullscreen viewer is super-slick. Vimeo. fitted my requirements pretty well and I heartily recommend them. Their site is slick and they offer lots of support on how to best create your video content.

Observing Twitter behaviours

2008-01-07T10:00:00Z

It seems that the Twitterverse is all of a flutter following recent blog posts from Phillie Casablanca and Paul Downey. I’m watching this with keen interest and it has been the subject of much impassioned discussion in our office.

Frustrated by the noisy habits of some twitterers, Phil opened a discussion on good Twitter practices that led to him posting the 10 Commandments of Twitter, an attempt to articulate some of the good, and highlight some of the annoying, practices when posting tweets. For the record, I’m right behind him, and was quick to follow the 10 commandments. It has been interesting though, to observe the response to his post, and to see how many people agree and how many people strongly object to his suggestions.

Many people, object to being told how they should use Twitter, and that’s fair enough. It isn’t for any one person to dictate how we should all use [Twitter][]. Rather, patterns of usage will emerge and we will all find our own ways of using Twitter to get the most out of it. It is reasonable though, for people to express how they think the best value can be derived from Twitter and to describe some useful guidelines for people to either adopt, or not, as they wish. In my eyes that is what Phil was doing with the [10 Commandments of Twitter][]. I also think that Phil will be the first to admit that the use of the word ‘commandment’ may be a bit strong, but it was used to elicit a response. Job done!

Sharing similar frustrations, Paul Downey took things a step further on his blog describing two different camps of Twitter users: Twits and Twerps. Judging by some of the responses to that post, many are upset at being labelled a Twit or a Twerp, thinking that the terms are a little strong. (Paul clarified his use of the terms recently in a tweet) I personally find the terms merely playful and see that I am a Twit who sometimes displays Twerpish tendencies(!).

One worry that I do have though, and this was articulated by JP Rangaswami on his blog much better than I am likely to do here, is the experience of the Newbie. We should avoid creating an environment which is intimidating and unwelcoming to the new user. Some of the emerging nanoformats add great value to Twitter, but we must never try and dictate that they are used by all. Instead, we should provide complete, and accessible information on them for anyone who is interested enough to use them. I for one was scared off IRC and the like for years by the seemingly ferocious users who knew the conventions inside and out, but didn’t appear to tolerate newcomers. I’d hate for twitter to end up like that. We should use things like the 10 Commandments of Twitter as useful tips for people, rather than an iron rod with which to force people to use Twitter ‘our way.’

Photo credit: Mike Hoff

Osmosoft return from LeWeb3 intact

2007-12-17T10:00:00Z

Last week the entire Osmosoft team visited Paris to attend the LeWeb3 conference. Initially, we had intended to be attending simply as delegates, but as time went by, we decided that we might be able to build something handy to use at the conference, and that perhaps, others might find it useful too.

And so, RippeRap (then dubbed ‘TiddleLeWeb’) was conceived. We considered that building a tool based on TiddlyWiki where you could make notes on the conference and effortlessly share those notes with others, while being shielded from network hiccups, would be cool. To be ready, we had much to do, and little time to do it.

We found that getting up-to-date and accurate information about the agenda from the LeWeb3 website, was a little fiddly, so including an agenda and using it as the basic navigation in RippleRap seemed like a natural choice. For added value, we also used Microformats to markup the agenda so that you could export the sessions to your calendar and so on.

Since we were planning to hand out copies of RippleRap to other delegates, we decided to have a stand at the conference so that we could explain what we were doing with RippleRap, and in the open source world. Osmosoft and BT shared a stand which was busy throughout. I think that having Paul Downey around to talk people through his excellent, and popular uber-doodle, ‘The Web Is Agreement‘ (more than 60 thousand views on flickr at time of writing) helped draw people to the stand. I rather think that the retro-chic bat phone also raised a smile. We enabled every copy of RippleRap to make free calls to the bat phone at the stand in order to get support. Building that feature was made easy with Mojo, BT’s REST exposure to its 21cSDK.

RippleRap was distributed with the mantra ‘release early, release often’ ringing in our ears. There is no arguing with the suggestion that this is an application in it’s early days. Releasing software in this way has been something of a revelation to me. I’m used to a more traditional release cycle, where you possessively guard your work until you are good and ready to face the scrutiny. As I attend more conferences like this, I hear ‘release early, release often’ more and more regularly, and it is always met with lots of enthusiastic head nodding from around the room. There has been a lot of feedback and we are finding it all valuable. Hopefully, the next release of RippleRap will have some of the useful improvements that were suggested.

The LeWeb3 conference was, on the whole, pretty good. Some of the speakers where really interesting, and I found some unexpected gems. Yossi Vardi and Philippe Starck were really entertaining, although I gather that some of these talks were already available on YouTube. Listening to BT’s JP Rangaswami was as ever, rather inspiring. I was also lucky enough to listen in on several ad hoc discussions that JP had around the conference, and noted that you rarely saw JP talking, without a small crowd gathering around him. I unexpectedly found myself on stage with JP and am now enjoying the glory of photos on flickr described “JP Rangaswami takes the stage at Le Web, supported by Phil Hawksworth”. Brilliant! (just don’t tell anyone that I was up there in nothing more than a ‘helper-monkey’ capacity!)

There were a couple of things about LeWeb3 that I did find a little irksome though (aside from the absurd name - this is not the third year of the LeWeb conference, the 3 refers to web 3.0!). I found that the time allocation for the various speakers was a bit odd at times. It seemed that some panel discussions that featured Loic Le Meur (organiser of LeWeb3) went on for a very long time, and I found them, to be blunt, a little self indulgent. This is all well and good except that several other speakers had their time trimmed to ridiculously short slots. Notably, Doc Searls, who I was particularly looking forward to listening to, had to rush through his presentation at lightening speed and was told that he didn’t have time to take questions. Booo.

I was also really disappointed at the handling of some of the questions from the auditorium by Loic. At times I found him rather rude in the way he dealt with those asking questions, especially if the questions were in any way challenging to the panel. Perhaps Mr Le Meur was just trying to take care of his speakers by shielding them from any potential awkwardness on stage, and the rudeness was just a artefact of a slight language barrier, but I suspect not.

The facilities at LeWeb3 were very good. I had reservations about the conference being split into 3 separate buildings, but this was not actually a problem. The staging and audiovisuals where outstanding. The food was superb and the provision of power on every row of the main auditorium was very welcome. I am led to believe that a significant amount of money had been spent on providing free wifi, but sadly the wifi was rather unreliable - but hey, that’s what you get at conferences, and why a tool like RippleRap might be a handy thing to have at your fingertips.

Check out the photos that Osmosoft took at LeWeb3. Several Osmosoftians more talented than I have posted pictures at flickr.

Opening a Finder window from the Terminal

2007-11-04T10:00:00Z

I stumbled upon a simple method for opening a Finder window at your current Terminal session location recently. Since it is something that I have a regular need for, I thought that there might be other Mac users out there who might also find this useful from time to time.

To set things up so that it is easy to use whenever you need it, you just need to follow these two steps:

First, using your preferred text editor create a file which contains this command:

#!/bin/bash
open /System/Library/CoreServices/Finder.app $PWD

Bash

You should name this file with whatever you want to use to call it later. I named it fndr.

Second, you should place this somewhere that is visible on your path. I collect any little utility scripts like this together in a directory called Utils which I added to my path to make all of its contents easily accessible.

Now you can simply type fndr in your Terminal window to open a Finder at your present directory.

If you need help adding something to your path, I recommend creating a file in your home directory (it may even already exist) called .bash_profile. This file gets invoked whenever you enter the Terminal environment.

Add an item to your path by entering a line something like this to your .bash_profile file:

export PATH='$PATH:/Users/PhilH/Utils'

Bash

I’m always on the look out for bits and pieces like this to help make my life easier in Mac OSX. Not that I think that things are difficult in this excellent OS, but there is always room for shortcuts to speed up common tasks. If you have any little gems that might be useful to the Mac OSX world, it would be great if you could post them in the comments. Thanks!

Update:

This can simple be done with a single command already as it turns out. Just use this:

open .

Bash