I’ve not had a chance to play with it myself yet, but it looks like a very slick, well-made and easy-to-use tool for creating interactive books — something which has been missing from the market for far too long.

I’ve seen a fair bit of negative talk on Twitter though, mainly about the terms of Apple’s SLA and how books created with iBooks Author can be distributed. The short story is that if you’re planning to sell your publication, you have to distribute it through Apple’s store — you’re forbidden from distributing through any other means. Seems to many like a dictatorial move from Apple, but David Smith has an interesting take on this:

The real story here today shouldn’t be that Apple has ‘audaciously’ claimed ownership of the books make with iBooks Author but that they have created an avenue for non-commercial distribution that would exclude thementirely. That is actually unprecedented.

If I create a textbook using iBooks Author and then decide to made it freely available to the world (à la Khan Academy) I can do that without any restriction. Simple click ‘Export’ within iBook Author and the resulting file can be distributed by any means I choose and then loaded in iBooks. The mind boggles at what things may come out of this.

All Apple is doing with this restriction is saying that if you directly profit from this free tool and platform that we have created, then we deserve our cut. Which seems entirely fair to me.

And John Gruber has followed up on this with an interesting point about the HTML5 foundation of this iBooks format:

Second, it’s about not wanting iBooks Author to serve as an authoring tool for competing bookstores like Amazon’s or Google’s. The output of iBooks Author is, as far as I can tell, HTML5 — pretty much ePub 3 with whatever nonstandard liberties Apple saw fit to take in order to achieve the results they wanted. It’s not a standard format in the sense of following a spec from a standards body like the W3C, but it’s just HTML5 rendered by WebKit — not a binary blob tied to iOS or Cocoa. It may not be easy, but I don’t think it would be that much work for anyone else with an ePub reader that’s based on WebKit to add support for these iBooks textbooks. Apple is saying, “Fuck that, unless you’re giving it away for free.”

Worth noting that Apple pitched their launch event at the education market, and they’re probably already a long way down the road with making deals with educational institutions (Apple has a track-record of quietly making individual, private deals in the education sector). Amazon et al have had a massive head-start in the ePublishing sector, but none of them have been audacious enough (or powerful enough) to make these kinds of bold moves into education.

Apple are doing a very clever thing here: they’re making efforts to put iPads into the hands of young adopters. Talk about brand exposure!

And now it is quite easy to see why the media apps are failing. They are all difficult to navigate requiring too many swipes, flicks and scrolls to find things. Eureka has a lovely opening navigation and the magazines have contents pages but where are the search bars? Have they learnt nothing from the web? Where are the related articles, tags and comments. They are not taking advantage of the fundamental tools available to them. Instead they are creating gimmicky apps without any real substance. Media companies are changing but without realising what is their best asset, their quality journalism and ability to edit, which they sacrifice to fads and pointless interactive content. Newspaper and magazine sales are down because the internet allows easy consumption and access to lots of information; the only way to start making money is by championing this in their apps and combining with excellent user-interface and editorial design. At the moment there isn’t an app which is better to use than the newspaper or website equivalent and this should be worrying to an ailing industry. The approach is entirely wrong; it is not the content that is the problem, it’s the way it’s being presented.

I’ve, personally, yet to find a media app which feels “right” — even the very popular and innovative Flipboard doesn’t fit the bill, for the may of the reasons that Oliver flags up: too many swipes, no way to effectively filter and search.

The 1140 grid fits perfectly into a 1280 monitor. On smaller monitors it becomes fluid and adapts to the width of the browser.

Beyond a certain point it uses media queries to serve up a mobile version, which essentially stacks all the columns on top of each other so the flow of information still makes sense.

It’s a nice, simple idea explained in a very clear and concise way.

To design for the Baker Framework you just have to build HTML5 pages with a fixed width of 768px and you can unleash the power of WebKit.

That’s all. Use your favorite tools, test it on the iPad from Safari, refine as much as you want.

It seems to have a workflow – which is being refined – which allows you to easily compile your HTML5 as an application which is ready for submission to the Apple spp store.

Mashable has a short feature on the framework:

“HTML5 is out there,” co-founder Davide Casali wrote us in an e-mail. “Why is nobody really making the convergence between the publishing industry and the web, and why are we confined to those crappy designed epubs?” he asks.

Casali and his team hope their creation will lead to more beautiful e-books and digital magazines on the iPad, and for other WebKit-enabled devices later.

Ber interesting to see how this develops and what gets created with it. I’m sure the fact that it’s being released under a BSD license will encourage plenty of experimentation.

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.

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.

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.

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.

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.

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.