Produxion

The personal weblog of Phil Powell

Microsoft’s strategy for Silverlight has shifted

Unlike Adobe, Microsoft seem to be understanding that HTML5 is the only true cross-platform solution:

When Microsoft first showed off Internet Explorer 9, its most HTML 5 compliant version of IE to date, in March of this year, questions began to arise about the company’s commitment to Silverlight. Officials insisted that the two would coexist and that Silverlight would be Microsoft’s cross-platform development platform for mobile, Web and PC platforms for a number of years to come, as HTML 5 was far from becoming an accepted standard.

But in the past few months, Microsoft’s backing of HTML 5 has gotten more aggressive. Microsoft is pushing HTML 5 as the way developers can make their Web sites look more like apps.

This is a smart move by Microsoft: they can continue to develop Silverlight as a development platform for Windows Phone, whilst encouraging developers to create cross-platform applications with HTMl5 – best of both worlds, and it won’t cost them anything.

Adobe shows off Flash-to-HTML5 conversion tool

Ars Technica report about the recent demo of an Adobe tool for converting Flash to HTML5:

Even though its Flash technology is used as a punching bag by Web standards fans, Adobe has been building tools that embrace HTML5. The company recently released its own HTML5 video player, and Adobe Illustrator and Dreamweaver CS5 now contain a number of new HTML5 export tools.

Now it seems Flash might be joining the party. At Adobe’s MAX conference this week, Adobe engineer Rik Cabanier showed of a demo of tool that converts Flash animations to HTML5 (well, technically it looks like a combination of HTML5, CSS and images).

Yes, it’s great that Adobe are slowly shifting towards the HTML5 camp, but they’re really late to the party. The demo of this tool, although technically quite clever, really is a horrible semantic butchery job. And again, this is Adobe pitching HTML5 as an umbrella term for a mish-mash of modern technologies – even John Nack, the Adobe employee who originally posted the video of this demo, is flagrantly open about this mis-appropriation:

Someone will probably start quibbling with the use of “HTML5″ as a stand-in for SVG, CSS3, Canvas, etc. I know, I know. I use the umbrella term in the loose, commonly understood sense: “Flash stuff without Flash.

Sigh. Is that really how they think about next-generation standards at Adobe? “Flash stuff without Flash”?

Khoi Vinh on iPad magazine apps

Khoi Vinh on the rush of publications hitting the iPad:

My opinion about iPad-based magazines is that they run counter to how people use tablets today and, unless something changes, will remain at odds with the way people will use tablets as the medium matures. They’re bloated, user-unfriendly and map to a tired pattern of mass media brands trying vainly to establish beachheads on new platforms without really understanding the platforms at all.

The fact of the matter is that the mode of reading that a magazine represents is a mode that people are decreasingly interested in, that is making less and less sense as we forge further into this century, and that makes almost no sense on a tablet. As usual, these publishers require users to dive into environments that only negligibly acknowledge the world outside of their brand, if at all — a problem that’s abetted and exacerbated by the full-screen, single-window posture of all iPad software. In a media world that looks increasingly like the busy downtown heart of a city — with innumerable activities, events and alternative sources of distraction around you — these apps demand that you confine yourself to a remote, suburban cul-de-sac.

iPad Opens World to a Disabled Boy

An anecdotal little piece from The New York Times about the iPad as an enabling device for a young boy with a motor-neuron disease:

Owen, 7, does not have the strength to maneuver a computer mouse, but when a nurse propped her boyfriend’s iPad within reach in June, he did something his mother had never seen before.

He aimed his left pointer finger at an icon on the screen, touched it — just barely — and opened the application Gravitarium, which plays music as users create landscapes of stars on the screen. Over the years, Owen’s parents had tried several computerized communications contraptions to give him an escape from his disability, but the iPad was the first that worked on the first try.

There are also some interesting insights about the adoption of the device amongst different groups of disabled users:

For a mainstream technological device like the iPad to have been instantly embraced by the disabled is unusual. It is far more common for items designed for disabled people to be adapted for general use, like closed-captioning on televisions in gyms or GPS devices in cars that announce directions. Also, most mainstream devices do not come with built-ins like the iPad’s closed-captioning, magnification and audible readout functions — which were intended to keep it simple for all users, but also help disabled people.

Sencha Animator: The CSS3 Alternative to Flash?

Sencha, the guys behind the ongoing development of ExtJS and some other very clever UI technologies, have announced the release of a new tool for creating CSS3 animations:

Sencha Animator allows you simply place objects (text, shapes, and images) onto a re-sizable stage area, configure their properties and then animate to bring them to life. You can move, scale, skew and rotate objects singly or at various levels of nesting, in 2D or 3D space. With Sencha Animator, you can also take advantage of CSS3 capabilities like gradients, blurs, reflections and shadows.

At first glance, it looks to have a very clean and well-implemented user interface – better than the offering Adobe previewed earlier this week at least.

I can’t say I’m too keen on this continuing trend towards using CSS for “animations” though. My worry is that people will start to abuse these kinds of tools and start to create ugly, breakable user experiences which hark back to a web we were glad to leave behind. Slick and elegant transitions I have no problem with, but give people a Flash-esque tool for CSS, and Flash-esque applications they will create.

The really interesting thing to note here is in the foot of their announcement:

For those of you wondering what Sencha Animator is written in, the answer is… Ext JS of course! Ext JS provided an enormous short-cut in development time and allowed us to deliver the product on multiple platforms without worrying about Objective-C or Windows APIs.

Very clever: a fully-fledged, multi-platform application written in Javascript. And I assume that means it would also run perfectly fine in the browser.

Preview of the Edge prototype tool for HTML5

Interesting. Short video from Adobe showcasing a prototype of their new Edge tool, for creating animations and transitions using “the capabilities of HTML5″.

A few things which instantly spring to mind:

  1. The transitions featured in this demo aren’t capabilities of HTML5, they’re capabilities of CSS3. CSS is the technology which deals with presentation logic, and to continually refer to the “animation capabilities” of HTML5 is simply misleading and will cause confusion.
  2. Speaking of confusion: it’s interesting that Adobe are seeing fit to use unfamiliar language to describe the elements of their user interface: “Layers” to identify DOM elements; “Actions” to manage groups of transitions; “Symbols” to group objects. The semantics seem all wrong, and are reminiscent of Flash authoring (something they’re probably quite keen on). It just all sounds very unfamiliar and over-complicated, because…
  3. I know this is just a prototype and proof-of-concept, but surely this is just a very basic UI for writing CSS transition rules? Webkit is being used for rendering much of the property panels seem to be borrowed from Firebug and Safari development tools. The only new thing here seems to be a Flash-esque timeline.

Well done to Adobe for stepping into the HTML5 eco-system. But surely it makes sense to jump in with both feet and present something with substance, rather than dipping their toe in with some flimsy animations?

Update: It appears than on closer inspection, this prototype isn’t even using CSS for transitions: it’s Javascript manipulating the HTML DOM. So what exactly has it got to do with HTML5? Absolutely nothing. Bad show Adobe.

Building a Custom HTML5 Audio Player with jQuery

A brilliant, in-depth post from Neutron Creations about creating a custom HTML5 audio player:

We recently built an HTML5 audio player for Tim Van Damme‘s The Box, a new podcast where he interviews people who make cool stuff. Tim wanted an HTML5 audio player on the site, and we put together some jQuery to hook up the player interface he designed. In this article we’ll run through the code to explain how it works, covering a few caveats along the way.

They provide code samples and an explanation of their really well thought out design decisions. Really surprising how little code is involved in creating something like this too.

Adobe unveiling the Digital Design Suite

Mashable report that Adobe are about to unveil their Digital Publishing Suite, a tool which will allow publishers to create Wired-style digital magazines:

The Digital Publishing Suite will let publishers create, produce, distribute and monetize their digital magazines and content across different devices and marketplaces. The App Store is obviously the biggest target of the Digital Publishing Suite right now, but the platform is designed in such a way that it is easy to target multiple marketplaces at once.

At first glance, it looks like Adobe have thought the publishing workflow through quite well on this, with distribution, monetization and analytics built right in to the toolset – they’re obviously focused on keeping ahead of the game in this profitable area. But the authoring platform is heavily focused on InDesign, and I’m not convinced that’s the right tool for creating the next generation digital magazines: it’s a tool for creating page-based print designs, not the rich, interactive experiences we’ve come to expect.

An interesting closing comment from Christina Warren:

Thanks to desktop publishing tools, the barriers to creating professional content and layouts have really been reduced. With the App Store, and mobile devices and tablets, the distribution barrier is also breaking down, allowing more publishers — big and small — to get their content onto digital devices.

The distribution and publishing barriers were broken down a long, long time ago: HTML and PDF are much better tools for modern-day publishing. HTML5 and CSS3 blow the pants off of anything these bespoke, proprietary solutions can offer.

Adobe releases an HTML5 video player

An interesting, but inevitable move from Adobe who have released their own HTML5 video player:

HTML5 has received a tremendous amount of buzz, much of it driven by the potential for plugin-free video. However, the limited browser support for the HTML5 <video> tag has forced web designers to scramble for a solution that would work across platforms as well as browsers.  To help customers overcome these challenges, Adobe has released an easy-to-use, totally CSS-customizable solution that shifts gracefully from the HTML5 <video> tag to the Flash Player when the tag is not supported. The shift takes place regardless of the screen—from phone to monitor to TV.

Shame that they’ve seen fit to only release it through the horrible Adobe Widget Browser – distributing something which is built on open-source code using such a proprietary technology is a perfect example of how Adobe just don’t get open standards.

And to say that web designers have been forced to “scramble” for a solution? Really? When there are already so many great open source solutions around like Projekktor and VideoJS?

Interesting also to see that this is a technology which is based on existing open-source project called Kaltura. Some might say it’s a good thing that Adobe are embracing open-source in this space. I’d say it’s a sign of Adobe failing to innovate, and a desperate bid to play catch-up with an industry which is leaving them behind.

Advice for a successful pitch

As part of my work at We Make Media, I regularly have to prepare proposals and deliver pitches to potential clients. A lot of the time projects come about through informal meetings and conversations with clients, gaining an understanding of what they want to achieve and preparing a project proposal which meets (and often exceeds) their needs.

Other times though, we have to go through a more formal pitching process, competing for a contract with other agencies. Last week I had to attend a pitch interview and deliver a presentation for our proposal, and since I hadn’t done one for a while, I was reminded of just how much we have to put into these things.

I’ve worked for a fair few big agencies, and I’ve had plenty of experience working with all sorts of clients: my speciality for a while was as a consultant team lead, acting as a liaison between demanding clients and (slightly less demanding) creative teams. I’ve also spent a lot of time preparing documentation and assets for pitches.

But it was only when I founded an agency of my own that I realised just how much effort we were going to need to put in, in order to secure a healthy roster of clients. It’s one of the biggest differences between working as a freelancer and taking on the responsibilities of running an agency. The projects get bigger, the paperwork becomes more demanding, and you really have to raise your game.

Sadly, we didn’t secure last week’s pitch. Although we received some very positive comments about the interview, the presentation and our creative ideas, our technical solution just wasn’t quite what they were looking for. That’s just the way it goes sometimes: no matter how good you are, and no matter how much effort you put in, you’re just not quite the right fit for that particular client at that particular time.

It’s always disappointing to loose out – it’s less the rejection, more the fact that your creative ideas and enthusiasm for the project have hit a dead-end. But it gave me an opportunity to reflect on how we go about the process of pitching, and how we can do better next time. So I’m going to share my thoughts on the process and try to demystify a few of the more daunting aspects.

The RFP

Usually, the process starts with a Request For Proposal from the potential client. This will be a document outlining the requirements of a project, and at the bare minimum will include:

  • An outline of the brief
  • A timetable of the pitch process
  • A timetable of important project milestones
  • What they expect in your proposal

It may also include:

  • Background information about the client
  • History of the project
  • Objectives and aims of the project
  • Technical requirements
  • The available budget
  • Who will be involved in the project
  • A summary of available assets

Make sure it’s the real deal

It’s a sad fact of life that a fair number of RFPs are sent out by organisations going through the motions: fulfilling their tender obligations despite the fact that the work has already been allocated. It can be frustrating when this happens, particularly because the cumulative time it wastes for everyone involved is not insubstantial: if six agencies are invited to submit a proposal, and each has one person spending just a day preparing a response, that’s six days of everybody’s time wasted.

It’s just a fact of life though, and aside from encouraging better ethics, the best you can do is try to keep an eye out for the warning signs:

  • If the brief is very short, it could be that they don’t see the need to explain a project which has already been green-lit.
  • If there’s evidence of copy-pasting from another RFP, it shows a worrying lack of care and attention to detail.
  • If there is a heavy emphasis on telling you what the creative solution should be, rather than inviting your ideas and suggestions, then it could be a sign that the project has already been well defined by somebody else.
  • If the deadline for submitting the proposal is almost imminent, then it could indicate that the pitch process is being rushed, or that you’ve been invited to submit just to make up numbers.

I’m not suggesting that these are hard and fast rules for detecting a flawed pitch process, and you certainly shouldn’t just turn down an invitation to submit your proposal based on any or all of these points. But I’d suggest that it’s always worth opening a conversation with your prospective client to get the information you need, and to get a feel for their expectations: if they’re open to questions and show an enthusiasm to engage with you, then it’s a good indicator of their authenticity; if they’re cagey or aren’t able to answer your questions, or are just too keen to refer you back to the RFP, then you might want to consider whether it’s worth putting in the effort for them. After all, if they’re not communicative with you at this early stage, are they really going to be the type of client you want on your books?

Resist the temptation to submit design ideas too early

An RFD will often include a request for you to submit design ideas, or to show an example of what your creative solution might look like. We always resist showing any visual designs or mockups at the written proposal stage. It’s time-consuming, and I think it’s unreasonable to commit so much creative resource at such a tentative part of the relationship with the client.

More importantly though, at this gestation phase of a project, there is no way that our creative ideas can be fully informed. The client should be recruiting an agency to come up with new, original, innovative ideas: creating those ideas is all part of the project and that can only happen once you’ve established a working relationship.

If we get selected for interview, then sometimes I’ll spend a little time producing some mockups – but only if it’s going to help explain an idea, not just to wow the client. Often though, it’s much better to show existing examples to illustrate your concepts – either from your own portfolio, or work which has inspired or informed your ideas – that way you can show that your concepts aren’t just pie-in-the-sky meanderings: your ideas can be visualised in a real-world application.

Include an NDA (Non-Disclosure Agreement)

We always put a confidentiality statement in every proposal document we send out. It provides a little bit of security and peace of mind that our ideas aren’t going to be hijacked if another agency gets appointed. It’s just a polite reminder to  potential clients that we take ownership of our intellectual property seriously and that our proposal to them isn’t free for open discussion with third parties.

If, further down the line, you do suspect that someone has ripped off your work, you’re in a much better position to approach them about it if you’ve explicitly stated the terms under which you’ve provided documents to them. Call it over-cautious if you like, but I always think it’s best to err on the side of caution when sharing your creative ideas: as a creative agency, our ideas are our life blood.

Be prepared

Chances are that if your written proposal gets shortlisted, you’ll be invited to interview to present your ideas in more detail, and to answer a ton of questions. And be in no doubt, there will be a lot of questions. It won’t just be one person firing them at you either, it’s likely to be a panel of different staff each of whom will be wanting to quiz you on different aspects of the proposal. It can be a pretty daunting process, so you need to be really, really well prepared. The fact that these meetings are called “interviews” is no coincidence: they can feel like a job interview, but with far more intense scrutiny, and far more of an emphasis on justifying yourself.

If you’re flying solo and attending the interview on your own, you’ll need to be clued up on every aspect of the project, including:

  • The creative approach
  • The technical approach
  • The people who will be involved in the project
  • How the project will be managed
  • The budget and any ongoing costs

And this is aside from having an impressive and well-rehearsed presentation to deliver! You need to be sure you have everything clear in your head before you go in – if you’re well prepared, you’ll be more confident, more relaxed and you’ll be able to present and field questions without having to worry too much about the words coming out of your mouth.

Technical details are hard to explain

Having reflected on recent pitches, this is the one area where I’ve realised that I need improve my approach.

I’m pretty confident that the technology, tools and methodologies we use to develop our online projects are just bloody amazing. We’re really proud of the fact that we’re able to develop projects which make it stupidly easy for clients to manage their online presence, and to adapt to their needs over time. We use agile development frameworks which provide much more flexibility and advanced functionality than a standard CMS (Content Management System).

Now, I can talk at length about the technical ins-and-outs of the tools we use, the software we write and the interfaces we design until pretty much everyone else in the room is bored to tears. But ask me to summarise the approach and explain how it works in layman’s terms, and I tend to come unstuck. Even providing a demonstration of what I’m talking about does more harm than good, as there are so many caveats and if’s and maybe’s involved. A lot of it is theory and design patterns, which aren’t very client-friendly topics of discussion.

If you can demonstrate the technology or software you’re proposing, then do. And where you can, I think it’s worth showing it in the context of what you’re talking about: if people can see something actually functioning, then they can much more easily visualise how it will work for them.

I tend to take our technology for granted, and don’t appreciate how unfamiliar and alien it can seem to people who aren’t so technically savvy. I need to do a better job of evangelising how damned clever it is.

Don’t be tempted to quote too low

Costing and scheduling a project is a whole article in itself, but I will offer up this little bit of advice.

If an RFP gives a guide to the budget which is available, and you think it’s way too low for the amount of work involved, then think twice before putting in a low quote just for the sake of securing the work. You’ll likely come to regret it further down the line. Clients can often put unreasonable demands in their brief – they’re obviously looking to get good value-for-money, so they’re hardly going to hold back on the spec. But an unrealistic proposal is eve more dangerous than an unrealistic brief. Aside from the fact that it can make you look desperate for work, if a schedule of work looks unrealistic when you’re in the planning stages, it will become a very sobering reality when it comes to actually delivering what you promised.

If you think the scope of a project is unreasonable within a proposed budget, then say so in your initial proposal, explaining your rationale. Providing suggestions for cost-saving solutions can be a virtue which makes you come across as pragmatic and reliable.

And if the scope of work seems ridiculous for the budget being proposed, then don’t be afraid to just walk away.

Think long-term

One thing I hear and read more and more often these days is that a client is looking to “establish a relationship”. It’s very rare these days that we finish working on a project once it launches. We usually embark upon a project with the intention of maintaining and evolving it over time – it just makes good business sense for us and the client. It’s also a good thing creatively, because it means we can continually review, improve and refine elements of a project once it’s in the wild.

So that’s something to bear in mind when you’re pitching your ideas. Yes, you’re being asked to deliver on the specifics of the client brief for this particular project, but your relationship may continue for months or years into the ongoing life of the project. This is going to be in the back of the client’s mind, and so you need to think about ways you can give them confidence that you’re future relationship is going to be based on reliability and value-for-money.

Conclusion

These are just my thoughts and very general advice – it’s all very subjective. I don’t expect everyone to agree with the points I’ve written – I see that as a good thing: everybody’s approach should be different; tailored to the way that you approach your work. I think that’s the trick to a good pitch really: find what works for you.

I would love to have feedback on the subjects raised here, and feel free to contribute any of your own suggestions on things I’ve missed out.