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.


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.


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.

What If the iPad Magazine is Already Obsolete?

There seems to be a lot of coverage around the subject of magazine apps, and I found another couple of interesting articles. In one of his recent posts, Mathew Ingram considers the failings of the “walled garden” approach being taken by most publishers:

The biggest flaw for me is the total lack of acknowledgment that the device this content appears on is part of the Internet, and therefore it is possible to connect the content to other places with more information about a topic, or related material of any kind, let alone any kind of social features that allow readers to share the content with their friends. Some magazines have made some tentative steps in this direction, but so far they are few and far between. Meanwhile, Flipboard and Pulse have taken Twitter and Facebook and RSS and turned them into magazines — and much more appealing ones in many ways.

Navneet Alang goes one step further and questions the relevance of editorial magazines in the online space:

But another necessary question is this: What is the magazine? After all, other than its physical dimensions, what unites PeopleThe New Yorker or Tennis? What really seems to unite a magazine into a coherent whole isn’t subject matter. The same magazine could contain a column on politics and a recipe. No, what turns a magazine into a single entity with a name is editorial focus: what the overarching purpose of the magazine is. It’s the idea of a magazine as a single editorial entity that makes it work.

But here’s the problem: the web allows you to collect and gather your own content from many many different sources, putting together your own set of things to read based on your interests and desires and social network. It is the opposite of a magazine. Instead of one entity providing all the coverage on a given topic, the web allows you to cull from multiple sources to put together your own collection of things you’re interested in.

Rethinking the Mobile Web

Fascinating stuff at yiibu, where they are questioning the traditional approach to mobile web development:

While this approach may be considered entirely sensible to the majority of folks in the mobile world, this isn’t necessarily the case for those coming from the more traditional (aka desktop) web world. The current approach can be so confusing, frustrating and discouraging that it’s no surprise desktop web developers ultimately focus on optimising their sites for just one device – the iPhone.

I think this rings true: I think most web shops consider optimising a site for iPhone is the same as optimising for the whole mobile ecosystem.

Given all of this, we began to wonder if it was now time to rethink the way we’ve been designing mobile websites. Could there be a straight-forward approach, simply building upon existing knowledge, rather than requiring designers and developers to learn entirely new and unique methods of working–specifically for the mobile web?

As a result of this, they’ve developed a site which acts as a proof of concept for the ideas and concepts they’re developing, which is explained in much more detail. They’ve also colelcted together a phenomenal amount of mobile reference materials and resources.

The 1Kb CSS Grid

I’m a bit late to the table with this one, but worth noting nonetheless. The 1Kb CSS Grid is a super-lightweight CSS grid system:

Other CSS frameworks try to do everything—grid system, style reset, basic typography, form styles. But complex systems are, well, complex.

Tyler Tate elaborates in the first of a series of posts:

With added complexity comes… well, complexity: a steeper learning curve, increased development time, and — cringe — tougher debugging.

Here is a fresh take on the CSS grid (loosely based on Nathan Smith’s 960 Grid System). Its mission is to be lightweight.

Is the iPad Really the Savior of the Newspaper Industry?

In-depth analysis from Mashable about the current state of newspaper applications for mobile devices. There’s nothing conclusive in the article, but it does include some interesting tidbits and some startling facts and figures:

The Harrison Group survey found that tablet users spend nearly 75% more time reading newspapers and newspaper articles, and 25% more time reading books. Those surveyed were apparently so convinced by the digital delivery and form factor, that 81% of tablet owners believe that it is inevitable that all forms of publications will eventually be produced almost exclusively in a digital format.

Those are some pretty compelling and encouraging numbers for content creators. So why are so many of the current apps failing to make the grade?

After looking at a variety of newspaper iPad apps, our main complaint — and we’re generalizing across the entire market — is that they don’t take enough advantage of the iPad’s wowing capabilities.


The solution could be found in a new “hybrid newspaper app” suggests Fidler, in which “automated sections with continuously updated news stories and more visually rich magazine-like sections created by editors and designers could coexist.” The Reynolds Journalism Institute is experimenting with exactly that kind of new publishing model.

The NAA also acknowledges the need for newspapers to “differentiate” content, and digital strategist Levitz says that consumers read longer-form content on the iPad, and they really enjoy the high quality of the visual images on the screen. She thinks newspapers can thrive in the tablet space if they take advantage of the device’s capabilities.

So essentially, what’s being said here is “people like pretty pictures and clicky, whizzy, shiny things.” This is where so many publishers and analysts seem to be missing the point. The IPad’s wow factors aren’t it’s ability to show high-quality imagery, nor it’s slick animations. The iPad’s wow factors are it’s pick-up-ability, it’s tactile and responsive interface, it’s ability to connect your offline world seamlessly with your online world.

So many newspaper publishers got it so wrong when they tried to transition from print to the web. They failed to innovate; failed to adapt their business models; failed to see the value in their content and the power of their readers. Amid that disruption, they appear to be about to make the same mistakes again: failing to innovate, failing to adapt; failing to realise that their content has become even more valuable, and their readers ever more powerful.

iPad as the new Flash

Jeffrey Zeldman compares the trend for creating novelty interfaces in publication apps to the bad old days when Flash spawned a million bad interface designs. He also succinctly picks up on an important point as to why web standards are so important:

Everything we’ve learned in the past decade about preferring open standards to proprietary platforms and user-focused interfaces to masturbatory ones is forgotten as designers and publishers once again scramble to create novelty interfaces no one but them cares about.

While some of this will lead to useful innovation, particularly in the area of gestural interfaces, that same innovation can just as readily be accomplished on websites built with HTML, CSS, and JavaScript—and the advantage of creating websites instead of iPad apps is that websites work for everyone, on browsers and devices at all price points. That, after all, is the point of the web. It’s the point of web standards and progressive enhancement.

There’s also some really good discussion to be found in the comments. But Zeldman nails the case for why this kind of stuff makes bad business sense for magazine publishers:

Unless your organization’s business model includes turning a profit by hiring redundant, competing teams, “Write once, publish everywhere” makes more economic sense than “Write once, publish to iPad. Write again, publish to Kindle. Write again, publish to some other device.”

End hover abuse now

Cennydd Bowles speaks out on the trend of using hover states in web interaction:

Designers who pop up information panels or move page elements on hover are using flawed logic, second-guessing what users want to do before they do it. The result, which I’ve seen in countless usability tests, is that users activate these controls accidentally. You know what happens? People actually flinch: “What was that?” They return with hesitation, less confident in their understanding of the site. It’s no accident that the Twitter worm propagated through hover— accidental activation meant users spread the worm unintentionally.

He makes a good point, particularly in a time when hover states are becoming a less reliable feature anyway, as the onset of touch devices makes hovering a non-entity.

Trent Walton has written a really useful and informative article about this subject:

As designers, we’ve turned to hover states to accommodate extra content and allow visual aesthetics to trump usability. Like it or not, those days are over and the interactions we design are going to have to stand on their own two feet.

jQuery AppMenu

A Mac-style Alt+Tab menu, implemented with jQuery:

AppMenu takes the default cmd+tab functionality on the Apple Mac and imitates it almost exactly on a website, instead using alt+tab (oroption+tab).

Not entirely sure of where this could be used in the real world – this kind of thing needs to be universal to be any use – but a really nice implementation nonetheless. A great example of what can be done with keyboard navigation.