We are quickly learning that creating an iBook involves a new way of thinking. An iBook is really a hybrid between an eBook and an app—it includes text and images like an eBook, but it also allows for all kinds of extra user interactions like an app.

Panoply of skills

What skills are required to create a great iBook? At least these:

• Layout/typography
• Interaction design
• Visual design
• Copy editing
• Image editing
• Videography
• HTML5/Javascript programming (to create widgets)

So although iBooks Author makes it possible for anyone to publish an iBook, to make something exceptional requires multiple skills that generally do not all reside in one human being. In fact, the range of skills necessary to create a compelling iBook is arguably broader than that required to create a great iOS app.

iBook UX

And what’s more, the first two skills listed up there—layout and interaction design—actually meld together to be a new category of user experience design here-to-fore unknown—”iBook UX” anyone? One designer must consider how the text, images, video clips, and interactive widgets can work together to create one meaningful, coherent, and delightful experience. Creating this experience involves both specifying interactive widgets and video content that will work well with the other content and placing all of these diverse pieces together to form a superb whole.

How to read an iBook

A big x-factor with this iBook UX business is that we do not yet have much understanding of how most readers/users will interact with a rich, multi-media iBook. We can safely guess that different users will interact differently. Some will likely treat it like a traditional book, reading the text and viewing the images without interruption, then going back and checking out videos and widgets as icing on the cake. Others are likely to do just the “fun stuff”—look at the picture, watch the videos, and try out the widgets—and maybe never read much of the text. Some may actually interact with an iBook “as intended,” reading the text and interacting with each image, video, and widget as encountered. So should an iBook be designed to flow properly in each of these three different interactive modes? Whew! This stuff ain’t easy!

Giving it a go

Anyway, what better way to figure out how to design an iBook than to get some relatively talented folks together with the general skill range mentioned above and give it a go? That is what we are doing with Cleaning Mona Lisa. We have connected with a great author, Lee Sandstead—”the world’s most fired up art historian”—who has a great concept with well-written text and fantastic images. We are adding some Tapity design finesse from our team of in-house designers and interns. And we are hoping for an engaging result that reaches toward the kind of compelling iBook experience that we think iBooks are all about. Watch this space for more specifics on our experience as we lead up to the launch of Mona Lisa.

Hours — an early mockup

Since our next app, Languages, is more or less designed and is now in the programming stage, we’re hungry for yet another adventure.  And we’ve already decided what we’re going to do.  In addition to Languages and Cleaning Mona Lisa, we’re taking on two new in-house projects. One is Grades 3.0.  Stay tuned for more information on that in the coming weeks.  But right now I will be telling you about our other new in-house app.  We’re really excited about it.  And, like all great apps, it begins with a problem.

It’s all a matter of time

Keeping track of your hours can be frustrating and sometimes infuriating.

Every week day we go to work.  Most of us are obliged to keep track of our hours. Innumerable small headaches, pains, and inconveniences accompany this. Some find logging hours tedious because they are constantly switching tasks (lawyers, for example).  Other find it tricky because they opt to fudge it and may not record their hours until the end of the day or the end of the end of the week; they often cannot remember exactly what they did and when. Everybody does it differently and everybody has their unique woes.

Bosses, employees, and self-employed entrepreneurs all wrestle with this issue: how to reduce the tedium and trickiness of time-tracking to an absolute minimum.

Is there an app for that?

Yes—sort of.  There is a throng of time-tracker apps.  But in our experience none of them are satisfactory.  We have tried to use a number of them, only to abandon them in favor of timesheet and pencil.  We find that generally the cure kills more than the disease and the side-effects are worse than the sickness.  There is no alpha dog in this space.

We have identified three areas that none of our competitors deals with successfully:

1. Starting, stopping, switching between tasks and remembering to do so—all via a simple and coherent interface.

2. Identifying errors and fixing them.  All the apps now make it extremely difficult to edit your time once you record it.

3. Back-end integration with billing and invoicing systems such as FreshBooks.

Where we come in

We believe that it must be possible to create an hours-tracker app that is simple, intuitive, and simultaneously powerful.  Having failed to find any such app available today, we have decided to make it ourselves.  We want to create an app that will cover as many use-cases as possible—from the programmer who switches tasks twice a day to the lawyer who switches clients continually.  We want to serve the meticulous time-tracker as well as the guy who fudges it.  And we want to do all of this via a UI that is clear, crisp, and delightful.

That is the vision.

And we’ve decided on a name.  In keeping with our other product names inspired by Apple’s Pages—Grades and Languages—we are calling our time-tracker “Hours.”

We are already deep into interaction design and are laboring on it furiously in the hopes of launching it ASAP.  Now back to work!

We like to try stuff out. For example, three years ago Jeremy felt like trying out app development; and the rest is history. You never know what will happen when you try stuff out, but it can open up whole universes of possibility that you had never seen or known before.

So it is in the spirit of trying stuff out that we are creating our first iBook. Yes, we do not know what will come of Apple’s newly opened up iBook platform. We think, but are not sure, that the iBookstore may soon become analogous to the Music Store or App Store—both in terms of volume and profit. Others disagree. The waters churn uncertainly. But we figure that if we can build up iBook-creation capacity now, when the platform is young, we may be able to profit substantially when it is mature. We want to offer our services to many creative people who can write and want widgets and professionally-edited video to enhance their work.

A digital publishing revolution may be on the horizon. And, to quote Steve, “I skate to where the puck is going to be.”

Lee Sandstead

So, our first book. Actually, it’s not really our iBook—it’s a piece by the world’s most fired-up art historian, Lee Sandstead. Lee is a professor, speaker, photographer of art, and was the host of the Emmy-nominated Travel Channel show Art Attack. The piece we are working with him on is called Cleaning Mona Lisa. As the title suggests, it’s about cleaning the Mona Lisa; and it’s also about all the things that hinder most ordinary people from really appreciating and enjoying fine art.

So where do we come in? We take Lee’s text and images and weave them together in iBooks Author. For this, we had to spend some time trying our hand at its levers and dials. But we’re getting the hang of it. We’re also creating widgets, standard and custom. You’re going to get to do your own digital restorations and clean varnished paintings with the swipe of a finger; so make sure and buy the book when it comes out!

Cleaning Mona Lisa is sixty to seventy percent completed right now. The text is in place. The layout has congealed. Now it’s primarily a matter of editing Lee’s video and completing work on the widgets.

So stay tuned!

After mulling over the feedback with the team, we’ve redesigned the prototype to include some buttons. Here is why.

Buttonless only works for extremely simple apps

Virtually buttonless experiences can delight but that only works when you eliminate not just the buttons but the functions as well. Imagine if Clear attempted to include even half of the functionality of power-user apps like OmniFocus and maintain a relatively buttonless interface; it’s impossible. Why?

• Number of gestures: Tap once, tap twice, tap and hold, swipe left, swipe right, swipe up, swipe down, pinch out, pinch in, twist, drag a part of the screen… Without buttons, there are only so many different functions you can allow with these interactions.
• Memory: we can only use a small number of gestures without making user’s brains explode.
• Mental model: using gestures for certain functions will feel extremely forced. Gestures only work for functions where the user’s mental model matches how the gesture works. You can help form the user’s mental model using metaphor. If it’s a book, the user expects to drag the page to flip it. Users can easily grasp gestures where they are directly manipulating objects like that but many functions are so abstract that you will be hard-pressed to find gestures that feel natural for them.

So part of the genius behind Clear wasn’t just the gestures but the minimalism, without which the app would break down. There is obviously a market for these kind of minimal apps but that route generally excludes power-users who will complain of the lack of functionality. That’s fine for cases like Clear where a large enough percentage of the population doesn’t need power features but you need to question whether that’s the case for your own app before making the decision to go the minimalist route.

Buttons are not our enemy. They are not as satisfying as directly manipulating objects with gestures but in interfaces that accommodate more than a few simple functions, they are often very necessary in order for the interface to make sense.

I’ve also come to the conclusion that buttons may be the best way to teach gestures, especially when considering making our apps accessible (which, I know from first-hand experience, Apple’s App Store managers pay attention to *very* much). More on that later.

That said, our new Languages design is very much gesture-driven but includes buttons where gestures don’t make sense or to supplement less-obvious gestures.

My mind is exploding with thoughts on gestures and I plan to write a lengthy article that covers gestures in depth, with some ideas on how to best teach gestures as well. In the mean time, check out Josh Clark’s great talk, entitled Buttons are a Hack.

But we at Tapity were all atwitter (though we didn’t tweet much) for a different set of reasons:

• There is nothing limiting iBooks to textbook publishing.
• iBooks Author would be free, allowing anyone to create iBooks (well, anyone with a Mac and a little word processor experience).
• iBooks Author makes is relatively easy to create relatively good iBooks with relatively little effort.
• The iBookstore would accept all kinds of books from all kinds of people, allowing anyone to publish iBooks.

So—hold the phone—iBooks can compete with all published books, and anyone can be an author and a publisher at virtually no cost. Whoah. No publisher in between author and customer. Whoah. Did you get that?

In our view, iBooks 2 + iBooks Author + iBookstore = a new Wild West of publishing. And not only that, with interactive widgets, iBooks can also be a much less expensive way to create certain kinds of iPad applications, particularly ones that are primarily about presenting content. And not only that, iBooks could become a platform for publishing all kinds of other highly-interactive crazy stuff, from fancy ads to annual reports to digital album extras to college course catalogs to user’s manuals to movie promos to…you get the idea.

But Apple is not promoting iBooks the way we are talking about it. Curious. Consequently, the explosion of iBook publishing that we are anticipating is happening in slow motion. We believe it is happening, and we want to be part of it (more on that later), but there is still time to get in on it. We plan to be talking about iBooks a lot more. Stay tuned.

Second, it’s been way too long since I’ve blogged.

Third, wow, we’ve got a new Tapity.com redesign. What do you think?

Fourth, innovation is in the air and it all started with a to-do app of all things. You’ve heard of it; it’s called Clear by Realmac Software, Milen and my friend Phill Ryu’s new studio Impending.

Phill questioned everything: the need for a navigation bar at the top, chrome, inessential features, and even buttons. Phill hates buttons:

“Buttons are about the most unsatisfying interaction you can have in a touchscreen device. Just think about it. At least when you’re using a mouse, you click a button, and you’re clicking a button. When you’re using a phone you are smudging glass, and there is absolutely zero feedback.”

I think that’s awesome. A huge part of great design is figuring out what we can obliterate and Phill did an amazing job at that: it’s demolition design! No buttons, just gestures. It’s a very satisfying and fun experience and one that I’ve integrated into my daily life.

I like to think that I question inessential elements and features but Phill’s demolition design put me to shame. It’s downright inspiring.

This is scary

Clear is controversial, dangerous, and inspiring. Chrome disappears and gestures are the interface. Starting with Clear, apps won’t be cool just because they look pretty. There are lot’s of pretty apps. I think to make a cool app in 2012, we need to pay heavy attention to the interactions – each interaction needs to be delightful. Now the danger is that people are going to see Clear and mimic it; they’re going to throw usability out the window and build super unintuitive gesture-based apps. We don’t want to go to that extreme — as David Barnard rightly points out, user interface chrome definitely has it’s place — but we shouldn’t throw the baby out with the bath water. I think we need to find ways to use gestures to improve the user experience. David has some good ideas here too.

Designing gesture-based interfaces

When we are designing gesture based interfaces, I think we need to keep in mind at least four points:

• Gestures can make interactions faster and easier. It’s easier to swipe the whole screen than tap on a target on the screen.
• Directly manipulating objects is so much more satisfying than pressing a button and getting a result.
• Gestures can remove the need for buttons and chrome, as Clear has done. This can make the app really clean. The problem then is that users might not know how navigate the app if they don’t know the gestures. They aren’t as discoverable as buttons so we may need to play some usability tricks to make sure our users can easily figure them out and remember them.
• Gestures are cool. That shouldn’t be underestimated.
• Update: I can’t believe I completely forgot to mention one of the most important. Gestures are terribly undiscoverable. While Clear’s gestures look extremely intuitive, they are actually not. They are only intuitive if you watch a video or tutorial illustrating them being used. Without such help, we would be clueless on how to use Clear and would easily get stuck. This means that with gesture-based interfaces we need to always be thinking about how to teach users our gestures or provide alternatives to them.
• Gestures sometimes require two hands. Make sure that there is some kind of alternative to a two handed gesture. Pinching is often cooler than tapping but make sure you don’t require users to pinch to use your interface.

Rethinking Languages

That said, we have been completely re-imagining the Languages design. We’ve questioned features and unessential UI, taken a chrome-less, very much buttonless gesture-based approach, and think we’ve added a few of our own innovations along the way. To see if a gesture-based interface *really* works, you really have to use it so we conducted several hackathon sessions with our Sonico buddies over in Austria and prototyped all the major gesture interactions.

Let me tell you, it rocks and I can’t wait to show you what we’ve come up with.

SXSW

Speaking of which, I’ll be at the South by South West conference in Austin for the next week and would love to get input on the gestures we’ve been working on in Languages so please ping me if you would like to meet up and get a demo.

Marketing

Christain Billings and Matthew Miller did some amazing work on the icon and teaser website!

We’re starting our marketing initial marketing push for Languages. I’ll be at SXSW giving out previews to the press, I created a @languagesapp Twitter account and Facebook page. Last, but certainly not least, we just launched a pretty incredible teaser website that you really have to check out.

Let me know what you think… Exciting times!

Last time we talked about how to build a fantasy app by using magic. That led us to a list of features to put in version 1.0 and wrapped up strategic design. Now we can rocket on to the second stage of our process: interaction design.

Interaction Design

The purpose of interaction design is to design the app’s interface while focusing on the ways in which the user interacts with it. Thus it’s not simply spatial—figuring out what buttons go where; but it is also temporal—related to the user’s experience over time. Interaction design demands an empathetic imagination, because the interaction designer must always bear in mind, as they are putting down buttons, the ways in which the user will interact with the buttons. Interaction designers must be able to look at what they are designing from the user’s perspective.

The way we did the interaction design for Languages was typical for us. First, I did a first draft of the interaction design in OmniGraffle (which is an excellent tool for designers). Then I presented the draft to the team. We then went into a cycle of design and iteration that is still ongoing. Generally I make a first pass at a design and then Jeremy refines and massages it to perfection—all amidst a vigorous feedback loop.

Here is one of our early wireframes of the primary dictionary interface. Things have changed a lot since this iteration.

We decided to start the app off with a home-screen that would be a bookshelf containing all of the language dictionaries. The idea was that users would tap one of the dictionaries to access it (a la iBooks).

Visual Design

Although we are still wrangling with interaction issues, we have also begun the third and final stage of design: visual design. This is the part where we make the app real pretty. This is also the part where we make the app delightful and add those little touches of fun and humor.

We do visual design in the following steps. First, we decide on a visual theme; in the case of Languages, we decided on a physical dictionary metaphor. Second, we decide on a color scheme; in this case we decided to go with earth tones with a brown emphasis. Third, we decide on fonts. And finally we roll up our sleeves and begin thrashing away. We decided to have Jeremy take the lead on the graphics for the dictionary, while I got to design the shelf (Christain, one of our interns, has been designing the icon).

Behold, the shelf!

As things stand now, the shelf is basically completed, with only a few minor refinements left to do; meanwhile the dictionary interface is in a state of flux due to some revolutionary and very exciting insights that Jeremy recently had. He’s going to talk about all of that in an up-coming post.

"I endorse this message" — Plato

The strategic design of our next app, Languages, continues apace.

In the last post we gained an understanding of our personas’ experience without an app. We now need to imagine how an ideal app could make this experience 100% better, without worrying about bothersome constraints such as money, technology, time, or reality. It’s time to build a Platonic app (Plato, as you’ll recall, thought that all physical things are fail and that their is an ideal, perfect form of all things floating in heaven). Construction materials include aether, fluffy-golden clouds, and joyful thoughts.

It is essential to have a vision of an ideal app so that we know to what our imperfect app should aspire. You have to have a clear understanding of the ideal if the real is going to approximate it.

Here’s how it works. We look at our three experience domains (solo, social, and travel), look at all of the experience nodes in those domains, and then yell out ideas for how an app could improve those nodes 100%. Jeremy then writes these ideas on a sticky and posts them in our “ideal assistance” section beneath each experience node. The aggregate of all these ideas is our fantasy app.

Please pardon the calligraphy and the shaky-cam.

For example, when we examined the “social” domain, we determined that when you’re in a business meeting in Milan and an Italian colleague says “sono molto dispiacentissimo” you want to be able to nod your head and find out what that means without him knowing that you have no idea what he said. You don’t want to look like a fool. So we wrote down “incognito,” indicating that the ideal app could feed you definitions on the sly (of course this sounds impossible; but stick around). We also determined that an ideal app would feed you definitions extremely quickly, because you don’t want to spend five minutes in the street figuring out what “Achtung! Achtung! Ein Auto kommt!” means.

Once we have posted all of the characteristics of our Platonic app on the wall, we go through and draw a big, red x over all features that (1) are beyond our means or (2) would bloat 1.0. We call this step “killing the baby.”

Killing the baby is a traumatic experience for some.

So, of the two feature examples above, we put a big, fat, red x on “incognito” due to technical constraints. But we kept the idea of quick definitions because we felt that it was doable and essential.

What we’re left with is the list of features that will appear in Languages 1.0.

Back to Languages.

So we are describing the process of strategic design, in which we figure out the company’s goals, the user’s goals, and the intersection of the two. The purpose of this is to create an app that exists at that point of intersection. First, we established Tapity’s goals for the Languages app. Then we developed user “personas”—fictional users with concrete characteristics. Now we can move on to the next step of strategic design: user experience mapping.

Now that we have our personas, we need to map out their current experience without an app. This helps us create an app that is tailored to the user’s actual experience. Those who skip this step risk creating a list of features that sound helpful in the abstract, but are not helpful to users in their actual experience.

First, we need to decide what the major experience domains are. An experience domain is simply an area or realm of experience. In the case of Languages, we decided that they were (1) “solo,” (2) social, and (3) travel. Solo involves any linguistic situation in which it is just you and the language; reading a foreign book, for example. Social encompasses any situation involving discourse between you and someone else. And travel explains itself.

We put a big sheet of paper up on our Tapity-blue wall and then demarcate the three domains. We then place our personas on the far left of the paper. Now we’re all ready to map our our personas’ experiences across the three domains.

We first turn to Emily, our student, and analyze her solo experience. She studies French. So we decide that she (1) looks up French words for her workbook exercises, (2) looks up words for writing essays in French, (3) looks up words while reading Les Misrables, and (4) uses a physical French-English dictionary. We put up stickies with drawings to represent all of this.

We then repeat this process for all of our personas across every domain. We try to cover all possible experiences in order to get the fullest possible picture of what we’re dealing with. The wall gradually fills with stickies.

Now the appless user experience is storyboarded.

Next time, if our app could do anything, how could it produce an ideal user experience?

Woah, way too much me in that picture

Startup Plays is a really cool concept: break down the information and processes it takes to run a successful startup into actionable “plays”, templates to success in a particular aspect of the business such as getting your company incorporated or pitching a VC.

I was a bit skeptical when Scott Annan first asked if I could help build a play on iOS app marketing but, after looking through a sample play, I found that the format is really unique and valuable. It is essentially a down-to-earth to-do list your team can run through from start to finish with detailed information and expert advice on each step. You can also collaborate with your team by commenting on the different steps and adding additional steps to the play. The plays will really help you hit the ground running and the company has had a tremendous response so far.

Working with Scott was amazing and I think the play turned out really well. The steps in there are based on my experience in marketing my apps and what I’ve seen work in the industry. Some advice will be familiar, some won’t, but it’s really the format that goes beyond what you’ll get on the Tapity blog.

So there you have it, check out Market and Launch your iPhone Application like a Pro, by yours truly. I hope you find it helpful.

Full disclosure: I am definitely getting a very fair cut so you can feel free to take what I say with a grain of salt. We’re in luck, though, since it looks like Macgasm recommended it this morning too.