app

Texturing of AR Characters from Colored Drawings

Coloring books capture the imagination of children and provide them with one of their earliest opportunities for creative expression. However, given the proliferation and popularity of digital devices, real-world activities like coloring can seem unexciting, and children become less engaged in them. Augmented reality holds unique potential to impact this situation by providing a bridge between real-world activities and digital enhancements. In this paper, we present an augmented reality coloring book App in which children color characters in a printed coloring book and inspect their work using a mobile device. The drawing is detected and tracked, and the video stream is augmented with an animated 3-D version of the character that is textured according to the child’s coloring. This is possible thanks to several novel technical contributions. We present a texturing process that applies the captured texture from a 2-D colored drawing to both the visible and occluded regions of a 3-D character in real time. We develop a deformable surface tracking method designed for colored drawings that uses a new outlier rejection algorithm for real-time tracking and surface deformation recovery. We present a content creation pipeline to efficiently create the 2-D and 3-D content. And, finally, we validate our work with two user studies that examine the quality of our texturing algorithm and the overall App experience.

When responsive design will make sense for your application

A few months ago, I found myself in a Twitter debate over whether or not responsive design can work for web apps.

While it was a fun debate, trying to answer the question of whether or not responsive design makes sense for your app is futile. Let me explain.

We don’t have a common understanding of what responsive means.

I wrote about my struggles with figuring out what is “responsive” recently. People think they know what others mean when they say something is responsive, but our definitions often differ.

The best responsive designs use much more than responsive design. When that is the case, it is easy to find faults with any given responsive implementation that can be used to say, “Well, that’s not really a responsive design.”

What happens when you use responsive web design, but add to it things that seem to be at odds responsive design? Is it possible to add something that make it no longer responsive? If so, where is the line?

What is a web app?

If responsiveness has a murky definition, “web app” is considerably worse. Jeremy Keith has long argued that “like obscenity and brunch, web apps can be described but not defined“.

Chris Coyier recently polled his readers about whether or not it was useful to distinguish between “web apps” and “web sites”.

While people agree that the distinction is important, there was little consensus on what the distinction was. Chris summarized his findings thusly:

I was kind of hoping we could get somewhere close to a solid distinction between these two classifications, but I don’t think it’s going to happen. There is very little agreement and heaps of opinion.

So any time we’re discussing web apps, we’re going to have trouble agreeing on what we’re talking about. Discussing responsive web apps is just asking for trouble.

A case study in different perspectives

Here is a timeline of articles and discussions that illustrates my point perfectly:

June 17, 2013 — Responsive design Web apps – good or bad?

On a content only site it [responsive design] probably is very wise to start small and scale up. But in a highly interactive functional UI the UX will be damaged by the time you scale up. Or vice versa. Take a demanding environment such as online betting or a tipping platform. The users needs are potentially very different between device environments.

July 4, 2013 — Why Responsive Web Design is a Must for Gambling Sites

I personally have no doubts that responsive web design will become an official standard for all good web pages and web content design to comply in the future, sonow is the right time for you to start using it on your gambling and sports betting sites.

June 13, 2013 — Case Study: Betting on a fully responsive web application

Kambi
 is one of the top sports betting providers and their services include popular sports from all over the world…At Kambi 
we went all-in on this bet and decided to build a web application that scales across the board. The value was clear, unified development process and consistent user experience on all platforms…Fully responsive web applications is not just a pipe dream anymore*. With the right mindset, tools and processes it all becomes possible.

July 9, 2013 — I point to Kambi as an example of responsive design being used for a web app. Nick Finck replies:

To summarize:

  1. Gambling apps are too complex to use responsive design.
  2. All gambling apps should be responsive.
  3. A case study of how a popular gambling app was built to be responsive.
  4. The gambling app in the case study is too light-weight.

Therein lies the problem. Even when we have a specific niche app/site (e.g., gambling), we can’t agree on the definitions. We have a case study of how a gambling app was made responsive, but we derive different conclusions about how applicable the case study is.

And I’m fine with that. I don’t mind ambiguity. People don’t have to agree.

I just think it points out how futile it is to try to convince others that responsive design for web apps makes sense.

My thoughts on responsive design for apps

For my own part, I believe responsive design for apps is a no-brainer. We’re building apps for clients that use responsive design. I’ve seen large, complex apps for Fortune 500 companies that are in development. I’ve seen what other agencies are working on.

This stuff is coming. And perhaps when enough of these projects launch, we’ll move on from the debate about whether or not responsive design works for apps like we’ve moved on from similar questions about responsive design for ecommerce. (We have moved onhaven’t we?)

But even if I wasn’t fortunate enough to get a behind the scenes look at upcoming responsive app projects, I would still argue that responsive design for apps is inevitable:

Once you start accepting the reality that the lines inside form factors are as blurry as the lines between them, then responsiveness becomes a necessity.

I’m not saying there isn’t usefulness in device detection or looking for ways to enhance the experience for specific form factors and inputs. This isn’t a declaration that everything must be built to be with a single html document across all user agents.

What I am saying is that even in scenarios where you’re fine-tuning your app code and UI as much as possible for a form factor, that the differences in screen size and the various forms of input within a form factor alone will be enough to require you to design in a responsive fashion.

Sure you can build a complex web app without responsive design that only targets tablets, but that app would be limited. There is too much variation in the screen sizes of tablets for a design that isn’t responsive to work on more than a handful of devices.

I’m much more interested in skating to where the puck is going to be, no matter how difficult, than to fixate on what is easiest to do now.

We’re focused on helping our customers make their apps work across devices. And that means taking on many complex challenges. Making apps responsive is just one of them.

So how will you know when responsive design makes sense for your app?

When you decide it does and put in the hard work to make it so. The rest of the discussion is just noise.

Source

BLINKDRINK transforms your phone from “that thing you play with when no one is talking to you at the bar” into a pint-sized party. Open the app, choose your color, and put your drink on top. BLINKDRINK uses the prism of your poison to keep time to whatever song is playing. You’re thinking, “iPhone as coaster? Sounds like a bad idea.” Well we put a lot of drinks on top of phones while making this thing- the only bad ideas generally happened afterward. Source

One Size Fits Some


“Paid-up-front iOS apps had a great run, but it’s over. Time to make other plans.”

(via Marco.org)

This article from Marco Arment on his pricing strategy for the upcoming Overcast app has created quite a stir. I encourage you as an app developer to read it. There are a lot of valid points in it.

I don’t disagree with most of what he wrote. But when I get to a line like the one I just quoted above, I’m reminded of exactly what bothers me about most blog articles from app developers: “This is true for me, so it must be true for everyone and every other app in the universe.” The one-size-fits-all mentality that caused the race to the bottom in the first place continues.

If I were Marco, making a podcast app for iOS, I’d be considering seriously something other than a pay-once-up-front business model. Of course, I’m not going to be making a podcast app anytime soon, because I have no intention of getting into what’s already a crowded and I think pretty well-served market. Nor would I want to compete with his new app by any means. I’m sure it’ll be good, and deservingly successful.

There are many other kinds of apps where moving to this sort of model might make a lot of sense, too. It’s certainly worth careful consideration. But the problem arrives when you assume that all iOS users think and behave alike, and therefore all apps must be monetized similarly.

If we were to convert Teleprompt+ to the free with in-app purchase model, for instance, the three of us at Bombing Brain would be out of business in a couple of weeks.

Our customers are primarily prosumers and pros—people who wouldn’t trust their business to a “free” app. Our high price is a large part of what has made us successful in this market. (Along with years of cultivating a reputation for being better than our competition.) Converting this particular app to free with in-app purchase now would likely be an unmitigated disaster. We know, because there have been free alternatives that have crashed and burned. Hard.

Our target customers, the few who don’t blink at $15-$20 for an iPad app, are completely oblivious to the entire “free” app market. Free = invisible to them when it comes to finding solutions for their businesses.

To be fair, I don’t think Marco is actually suggesting that companies like ours change business models. But I do fear that too many developers read posts like this and walk away with that impression.

The fact is, there is a whole world of untapped potential on the App Store for developers who can solve real problems for people who are happy to pay. I’ve said it a million times, but it bears repeating: it’s not about price; it’s about trust. People are willing to spend money if they are sure what they are getting will solve their problem.

Is it easy to convince people that your app is worth a fair price? Of course not. Does that mean that you should make your app free in hopes of enticing a small percentage of people to convert to “paying” users? Not necessarily. Not for every kind of app, at least.

Giving a limited app away for free and charging to make it feature-complete is, in theory, one way to build trust. But given the reputation in-app purchase has acquired over the past few years, it’s going to take serious convincing before professionals, prosumers, and small business owners view IAP as anything but a scam in the short term. This is unfortunate, but you will be judged by the unscrupulous developers who have abused IAP before you, whether you like it or not. So you’re going to have to work even harder to gain that trust than you might think when associating yourself with this pricing model.

While it is true that the vast majority of iOS users scour the App Store looking for free alternatives, there is a not-insignificant number of users who wouldn’t go near a “free” app with a ten-foot pole. In their minds, free-with-in-app-purchase apps are all essentially Candy Crush.

So the risk is gaining a large number of users who are unlikely to pay you and who will write tons of bad reviews, while completely turning off the most valuable demographic in the Store.

Users looking to pay a premium price may be few and far between, but each one is ten times more valuable than the “average” iOS user to a developer like me.

Then there’s also the bulk of the education market to consider, which can’t, as a matter of policy, use any app with in-app purchase.

The point is, there are lots of different kinds of users in the App Store. And you need to know which ones are the most likely customers for your app. Don’t go treating them all equally.

Marco’s argument is essentially one of market share. He views total number of users as the primary goal. He wants to target as large a percentage of the total iOS user base as possible. That’s a perfectly valid business model that has worked for many. And for a podcast app, I think it’s a smart way to go. But it’s not the only way to skin this cat.

There are millions of iOS users in the world. I only need a tiny fraction of the right users to be successful.

I guess what I’m saying is, take everything you read from other developers (including myself) with a grain of salt. There’s no one way to be successful at this thing. Different apps in different markets, with different audiences, command different business models. You need to think about how you want to monetize your app long before you start building it. Consider all the options carefully. But don’t dismiss any of them out of hand because of what one or two others have experienced.

I’m happy that more devs are experimenting with in-app purchase as a legitimate way to encourage people to “try before they buy.” Look no further than MoneyWell for iPad as a primary example of IAP being used with positive results. Of course, this is an established company with a paid companion Mac app that already has a reputation for quality. Your mileage may vary. And, as Kevin Hoctor himself admits, his preliminary numbers are likely to be skewed for at least a few more months. But maybe in the long run, in-app purchase will gain the trust of users that currently avoid free apps like the plague. I think it’s going to be a long, uphill battle.

I look forward to seeing how other such experiments from other developers go. In the meantime, be cautious with anyone who tells you there’s only one way to go about doing things on the App Store.

Source

Premium vs Freemium vs Subscription

For mobile apps, there are three dominant pricing strategies: Premium, Subscription and Freemium.

According to a report by app-store analytics company, Distimo, freemium now accounts for 71% of Apple AppStore revenues in the US, up from somewhere around 50% last year, and rising. In Asia, freemium is 90% of App Store revenues.

71% app revenue from freemium

Is freemium always the most optimal? What factors should you consider when choosing a pricing strategy?

Firstly, here is what these different pricing models mean, as applied to mobile apps:

Premium apps (or Paid apps) have an upfront price before they can even be downloaded. Similar to licensed software, except that the App Store makes all future upgrades to the premium app free once purchased.

Contrast this with freemium (a portmanteau of “free” and “premium”), where the app is free to download and use. However, some features inside the app are unavailable until you pay for them. App stores make it dead simple for developers to charge small amounts of money inside the app.

Subscriptions are a regular fixed fee the user is charged automatically via the App Store for using the app. Magazines in the iOS Newsstand are usually subscription-based. Subscriptions can actually overlap with either premium or freemium models. For example, Spotify requires you to have a subscription to even use the app (premium), while Pandora is closer to freemium where you can pay a subscription to get ad-free and unlimited hours of music.

How do you decide which to choose?

Premium has very limited use today

Perception is a large factor in how high a price is acceptable, and going premium helps create that perception. With premium, every user pays upfront, but the amount each user pays is fixed, regardless of how much utility each gets. Also, users have come to expect apps in the $2 – $5 range (a few niche apps can charge $10-$20) and there is no way to get higher ARPU.

In general, premium works in the following situations:

1. There is a strong demand for your app – niche areas are good candidates here.

2. You have a strong brand already and can establish trust with users where they are willing to pay before they download the app.

3. There is not a lot of competition that will almost certainly drive the price down.

4. You don’t care much about reach – which will be much smaller because of the “pay gate” into your app.

5. There are no ongoing feature or content costs that can drive up the average cost of of supporting a user to levels higher than what the user paid for the app.

Freemium helped create those million-dollars-per-day games

Freemium was popularized by casual games in Japan and Korea and has quickly become the winning model in mobile apps. It works really well in the following situations:

1. There is enough competition that users invariably have other cheaper or free options (low barrier to entry). This has been partly the reason for most mobile apps today moving to freemium.

2. When reach is important. You need large amount of users quickly to create network effects. For example, to drive virality or gather significant data.

3. When there are a small % of power users willing to pay significantly more than the other light users. The pay-as-you-go model facilitates this. Hard core users can drive as much as 100 – 1000 times more revenue than the other users. This is why some free-to-play games are reaching a $1MM per day revenue runrate.

chart of freemium vs fixed price

More users in freemium, but a small percentage of them drive astronomical amounts of revenue.

The mobile app economy has progressed to a point today where all of the above usually hold true. Freemium does require some operational effort in managing your free and paying users, converting the former to the latter, and driving repeat purchases. However, this helps create a sustainable business rather than a one-time hit.

Subscriptions: the Holy Grail

A subscription provides a guarantee of repeat transactions and hence, businesses with subscription revenues tend to be valued far higher. The subscription price is usually smaller than the one-time price to incentivize the user into a longer term commitment. As the seller, you make up for the discount by being guaranteed future transactions.

A single issue of The New Yorker costs $6, but a year’s subscription of 52 issues is $70. That is a 77% discount and is still better, revenue-wise, than selling individual copies. Of course, they make a lot of money through advertising, so a guaranteed customer in the future is far more important to them. This may not be the case in all businesses. Amazon gives you a ~15% discount to “subscribe” to certain household items.

The subscription model does have a few drawbacks:

1. Like premium, there is a single price for all users, regardless of how much they use. There is a lot of money left on the table because hardcore users willing to pay a lot more cap out at the fixed price. There is some more money left on the table where the subscription price and commitment is too high for a large number of light users who will not sign up.

2. Tiered subscriptions does let you set different prices, but still creates ceilings on both price and consumption. Netflix has a 1 DVD plan for $8, 2 for $12, all the way up to 8 for $44. The lost opportunity? (a) A user can only do 8 DVDs. There may be a few subscribers who want much more. (b) A $44 price tag for DVD rental has a sticker shock. It is easier to charge $5.50 eight times than to charge $44 one time.

So when should you use subscriptions? Whenever you can. Subscriptions are considered the holy grail of revenue models. But it is important to make sure you are not leaving money on the table just to get a subscription commitment from a customer.

The ideal pricing strategy

loaded grocery shopping cart

Escalators are faster than stairs, even faster if you run up them.

At the risk of over-generalizing, a combination of freemium + subscription is the ideal for most apps.

Not everything being sold lends itself to subscriptions. Impulse purchases typically don’t. For example, a power-up that will help you cross this level in a game, or an Instagram filter that makes this photo of yours look exceptional. In such cases, it is best to start with a freemium model and then offer subscriptions to your  regular customers to drive  purchases further. Content (magazines, music streaming, movie streaming)  has more commonly been a subscription business. For these, it is a good idea to start with the accepted subscription, but remove any ceiling on purchases and consumption by offering more content that can be purchased in-app in addition to the subscription.

The mobile app economy is already large and growing even bigger. Get all the value you can out of it.

Drop in a comment, or shoot us an email if you want to chat about this for your app. We’re happy to help!

Source

iFrame. We convert your presentation to the application for the iPad, and there is nothing extra: no buttons or select documents or receiving network indicator - only your presentation. We follow the rule: the simpler - the better. Simply, does not mean poorer: the iFrame-presentation can insert pictures, galleries, video and 3D-view. Easier, more convenient means. Source

iOS Resizable App Icons Concept. Inspired by the more living home screens of Windows Phone and Android, this concept video shows how the iOS home screen could become more. 

In this concept, an app icon can be resized from 1x1 to 2x2 or 4x2, similarly to how you would on Windows Phone 8. The increased size can house widget like functionality and provide easy access to core features of that particular app. For example, you could expand the Settings icon into a widget with a brightness slider, and quick toggles for WiFi, Bluetooth, Personal Hotspot and Do Not Disturb. 

The newfound space could also be used to give a miniaturized window into the app, showing content already on the home screen. This could be useful for Phone, Messages or Mail. Instead of a glaring red badge, you’d be able to see the messages or calls directly on the home screen.

To launch the app, you can press the shrunken app icon in the lower left. 

The expanded icons can be moved around like regular icons and placed in the manner you like. But for obvious reasons, you cannot place an expanded icon in the dock; it would just slide back onto the home screen. 

One could imagine that this functionality would also be available to developers, who could include it for their apps.

This would rather nicely complement the existing feature set of iOS and make the home screen more engaging.

BEV - The Incredible Sampling Robot (BOS Ice Tea). BEV is the world’s first Tweet activated sampling machine. Simply tweet her unique hashtag when standing in front of the machine, and enjoy an ice cold BOS Ice Tea on the house.

Source. KRAFT Macaroni & Cheese, delivers an iPad app that stops the wastage (at the hands of Kids) of tonnes of pasta pieces the world over, and creates a new, super cool way for those same kids to create all the best Macaroni Art they can possibly imagine.


This Grolsch multi-screen campaign is an interesting example of extending a TVC into interactive an online video and mobile experience, that in turn drives retail foot traffic. Starting with a TVC introducing a bold character, the ad then challenges you to go online to continue the conversation.

Users are then introduced to the character more personally over a beer and are asked to text him their name in real-time as the online video plays… For users who’s name the character recognises, he sends them back a text message, literally buying them a beer in real life, with the text linking straight to a coupon code and store finder to claim. Created by the BMB Agency.

Design Case Study: iPad to Metro style app

Article: Source

iOS is a popular platform for creating apps that are touch first, fun, and engaging. With the introduction of Windows 8, designers and developers have a new platform to unleash their creativity.

In this case study we want to help designers and developers who are familiar with iOS to reimagine their apps using the design principles for Metro style apps. We show you how to translate common user interface and experience patterns found in iPad apps to Windows 8 Metro style apps. We draw on our experience building the same app for the iPad and for Windows 8. We use common design and development scenarios to show how to leverage the Windows 8 platform and incorporate the design principles for Metro style apps.

To learn more about the business opportunity of Windows 8, see Selling apps. For more info about the features used to build Metro style apps, see the Windows 8 Product Guide for Developers.

Download this article: To download this article, see Offline version of this article.

The app

The app we are developing is a connected photo journal where users can view and manage their photos and videos online using a timeline view.

The Photo journal Metro style app.

The app was first created for the iPad. The next figure shows the anatomy of the iPad app. Let’s now see how each component translates to the Metro design style.

The Photo journal iPad app.

1. Layout and navigation2. Commands and actions3. Contracts: search, share, and others4. Touch5. Orientation and views6. Notifications

Layout and navigation

Focus on content, not chrome

The Photo journal app needs to be great at showing user’s photos and recent social activities for those photos. When creating the Metro style app, our first goal was to remove all UI elements that were not directly relevant to the core functionality of the app. For example, the top navigation bar, pagination controls, and the bottom control bar can all be removed. In the next section, we talk about how users can bring up chrome when needed using the app bar.

For more information about navigation in Metro style apps, see Navigation design for Metro style apps.

iPad app user interface elements.Metro style app user interface elements.

iPad app

A. Top navigation barB. App contentC. Pagination UID. Bottom tab bar

Metro style app

B. App content and logo

Example: timeline view on the home screen

Both apps show photos on their home screens organized by month, but how the month is represented is quite different. In the iPad version of Photo journal, the page is optimized to display all 12 months in a year with a stacked photo metaphor used to represent each month. When designing the Metro style app home screen, we chose to bring more pictures and social content to the top level, to provide users more context. We removed borders from the pictures and instead used whitespace to provide more visual focus to the photos, which are the focal point of the app.

Month view in the iPad app.Month view in the Metro style app.

iPad: each month is represented by stacked photos with only one photo visible.

Metro style app: each month is represented by multiple photos, their titles, and the number of comments associated with the photos. Users can see more highlighted content for a month on the home screen.

Flatten the navigation hierarchy

We used the hierarchical navigation pattern in the Metro style app design. When redesigning the app, we flattened the navigation hierarchy so more content is accessible via the app’s hub screen, eliminating the need for navigation.

Example: removing bottom tab bar

View states in the iPad app.Comments view in the iPad app.

iPad app

A. Photos viewB. Comments view

The bottom tab bar with two pivots (photos and comments) is always on screen. Users can see one view or the other.

View states in the Metro style app.

Metro style app

  • We combined the comment and photos in one view to eliminate the need for a tabbed user interface.
  • The hub design for the home screen reveals the most relevant content for each section.
  • To see the entire list of comments, users can tap on the group header labeled Recent comments.

Use direct manipulation to navigate

Direct manipulation allows users to interact with content and navigate to different areas naturally. When designing the Metro style app, we used direct manipulation whenever possible, using built-in controls like Semantic Zoom, which lets users navigate more efficiently.

Navigation in the iPad app.

Navigation in the iPad app.

Navigating the Metro style app.

Using semantic zoom to select from groups of data.

iPad app

On the home screen, tap on the Years button on the top navigation bar to bring up a popover and select a year.

Metro style app

On the home screen, pinch two fingers to zoom out and see all the months and years. This way users can jump to any month in any year quickly. Users can also see an overview of which months have photos and which don’t (faded red background). Users can navigate entirely by manipulating the content without using chrome or navigating to a different page.

Commands and actions

Keep app contextual actions in the app bar

When redesigning contextual actions or commands in the app, we again followed the “content before chrome” approach and made all contextual actions available via the app bar control. Frequently used commands are near the right and left edges so that they are easy to reach by hand. This way the app design surface isn’t cluttered with controls, and no matter where a user is, they can swipe the app bar from the bottom or top of the screen to see relevant actions. All Metro style apps can use the app bar for their commands. Because users will be familiar with app bar interactions, it also increases the usability of our app and makes the whole system feel cohesive.

Example: deleting photos

Deleting photos in the iPad app.Deleting photos in the Metro style app.

iPad app

  • App commands are on the top of the screen when a user enters the selection mode.

Metro style app

A. The app bar is hidden by default to provide users the immersive experience. A user can swipe from the bottom or top of the screen to open the app bar.B. When a user selects objects on the page, contextual actions for the selected items appear on the bar. The actions change depending on whether there are objects selected and where the user is in the app. Global commands are usually placed on the right side of the app bar. Commands that come and go should be placed on the left side of the app bar.

Contracts

Use Search contract to centralize the search experience

Instead of creating a search input interface that is permanently part of the app canvas, we implemented the search contract. Users can consistently invoke Search through the charms, and the results can be presented in the app in a way that is natural for the content. By using the Search contract, users can invoke the Search charm from anywhere in the system to look for content from apps that support the contract.

Example: searching a photo within the Photo journal app

Searching in the iPad app.The search contract in the Metro style app.

iPad app

  • Search is available within the app on the home screen.
  • When a user types a search term, results start to appear and the user can select a result.

Metro style app

  • The user opens the charm bar and accesses the Search charm. The Photo journal app is selected by default because the user is currently inside the app.
  • When the user starts typing, the app supplies search suggestions to the pane. This way users can quickly see which terms will generate search results. After the user submits their query, they see a search results view and select the result they want.

Example: searching for a photo outside of the Photo journal app (available only in Metro style apps)

This example shows how to search for a term across different apps by choosing a new app via the search pane. This functionality allows users to search for any piece of content, in any app, at anytime.

Searching outside of the Photo journal app.

Metro style app

A user searches for the term “Barcelona” in the Tweet@Rama app and wants to look at photos of Barcelona using Photo journal. Photo journal is now the search results provider. The app launches automatically and displays the search results. The user doesn’t need to launch the Photo journal app and then perform the search.

Use the Share contract to reach more destinations and people you care about

Social media integration is a key component of most apps. When designing iPad apps, designers and developers generally choose which social media channels the app supports (such as Twitter or Facebook) and then the developers must integrate each of these services individually, or use one of the available frameworks. When there are API changes to these sharing services, developers must update their code for the sharing services to continue to work.

When translating the sharing capability into the Metro style app, we used the system’s Share contract. This contract simplifies design and development because there is no need to connect with every service that a user might want to use. In addition to social networks, users can also save content to other services, such as a note taking app like Notespace or EverNote. Using just a small amount of code, our app becomes connected with every Metro style app that has implemented the Share contract. There’s no need to deal with API changes to external social networking sites or web services. From the user’s perspective, they can always share from a consistent location by accessing the charms bar and opening the Share pane.

Example: sharing a photo in Photo journal with another app

Sharing a photo in the iPad app.

iPad

To share a photo from the iPad Photo journal app, a user first taps the action button from the top navigation bar and then chooses to share on Facebook. The developer needs to do additional work and add more share buttons if they want to integrate with other social networking services later.

The share workflow in the Metro style app.Choosing a share target in the Metro style app.

Metro style app

  • Users can always find share options in a consistent location, regardless of which app they’re using.
  • Any installed app that has been designated a share target appears in the app list in the Share pane. For example, Socialite, Tweet@Rama, Notespace, PaintPlay, are all share targets.
  • Users can share a variety of content types. For example, users can share links, photos, or save info to a note-taking app.
  • The most frequently used share targets are displayed at the top of the list to help users complete tasks quickly.

In addition to being a share source, we designed our Photo journal app to be a share target too. Users can easily share photos from another app to their photo streams in Photo journal. This connection is also enabled by the Share contract. See Guidelines and checklist for sharing content for more info about which apps make great share targets.

Example: sharing photos from another app with Photo journal – share target (available only in Metro style apps)

In this example, a user in another photo app looks at photos from a trip to Mexico. They want to share the photos from the album with their own Photo journal app collection so that it is easier for them to view these photos in a timeline view. As the user opens the Share pane, they see that the Photo journal app is listed as one of the Share targets and then invokes the Share workflow.

Sharing photos from another app with Photo journal.

Use file picker to access files from various locations

File picker is a full screen dialog that lets users access files and folders located on the local PC, connected storage devices, or a HomeGroup. It can also access items from apps that participate in the File Picker contract.

Example: uploading a photo from the local file system

Accessing photos from the file system and social media sites in the iPad app.

iPad app

The iPad app supports accessing photos in the local photo library and a couple of social networking services.

Accessing the file picker UI in the Metro style app.

Metro style app

A. The user taps the Upload button in the app bar and the File Picker UI opens. This is a consistent UI surface that the user sees whenever they want to access files.B. Tapping the Files header, the user sees a flyout of all available file locations and navigates to a file folder.C. The user selects multiple photos from the folder and a list of thumbnails at the bottom left showing the selected photos.

Example: using a photo from Photo journal in another app (available only in Metro style apps)

We also take advantage of a feature that’s unique to Metro style apps and add support for picking photo content from Photo journal within another app. This saves users the step of first downloading photos from Photo journal to the local file system and then uploading the photos to another app. Photo journal implements the File Picker contract so the system recognizes it as a file storage location.

Using content from Photo journal in another app.

Metro style app

A user is on the PC Settings screen and taps Browse to customize their account photo. Because Photo journal implements the File Picker contract, the user can see that the app is available to access in the file directory. The user can then select a photo stored in their Photo journal collection.

Touch

Edge swiping for app and system commands

Using Windows 8, a user can swipe from edges to access commands and navigate between apps.

  • App commands are revealed by swiping from the bottom or top edge of the screen. The app bar should always be used to display app commands.
  • Swiping from the right edge of the screen reveals the charms bar that contains system commands.
  • Swiping from the left edge switches to previously used apps.
  • Swiping from the top edge toward the bottom edge of the screen lets you dock or close apps.

Example: accessing the app bar and the charms bar in a Metro style app

Accessing the app bar in the Metro style app.Accessing charms in the Metro style app.

Swipe from the bottom or top edge of the screen to access app commands.

Swipe from the right edge of the screen to reveal the charms bar that contains system commands - Search, Share, Start, Devices, and Settings.

Cross-slide to select objects

With Windows 8, a user can slide their finger a short distance, perpendicular to the panning direction, to select an object in a list or a grid. When objects are selected, the app bar is revealed, automatically showing relevant commands.

Example: selecting multiple photos to delete

Selecting multiple photos in the iPad app.Selecting multiple photos in the Metro style app.

iPad app

  • Users enter a specific edit mode to perform the selection action and other edit actions. This is because tap is reserved for primary actions such as launch.
  • Users exit the edit mode when they are done.

Metro style app

  • Users swipe down on the object to select and the app bar shows up automatically with contextually relevant commands.
  • Users can perform both tap and selection on an object without entering and exiting another mode.
  • This gesture is reversible, which makes selection a lot more efficient in Windows 8 apps.

Pinch and stretch to semantic zoom

While the pinch and stretch gestures are commonly used for resizing in both iPad and Metro style apps, in Windows 8 they also enable jumping to the beginning, end, or anywhere within content using Semantic Zoom. Semantic zoom enables the user to zoom out to see data in related groups and provides a quick way to dive back in. Instead of providing navigation for reviewing long lists of content, use semantic zoom when possible for this type of interaction. Of course, when a user is viewing a photo in full screen mode, pinch and stretch can be used for optical zoom.

Example: semantic zoom on home screen and on a month spoke page

Using semantic zoom in the Metro style app.

Metro style app

A. Semantic zoom on the home screen lets users jump to a particular month in any year quickly.B. Semantic zoom on a month view spoke page lets users jump to a particular day and also provides an info graphic detailing how many photos are available from that year.

Orientation and views

Design adaptive layout for orientation and screen sizes

An iPad app has a fixed screen size and resolution with two orientations that designers need to consider. Windows 8 runs on various form factors, from portable tablets to all-in-one desktops. As a result, you can use additional screen space to show users more content. When redesigning the Photo journal app, we considered how the app would look in two device orientations, taking into account screen resolutions and device sizes. The grid layout makes it easy to scale the design for both portrait layout and high resolution screens. For example, we include more highlighted photos in each month when there is more vertical space available.

Example: home screen design in landscape, portrait and large screens (Metro style app only)

The iPad app in landscape and portrait mode.

iPad app

The same content is shown in both landscape and portrait layout. The content reflows in portrait orientation.

The Metro style app in multiple view modes and resolutions.

Metro style app

The app shows more content in each section on the hub page in portrait layout and larger screens, using extra space. Similar to creating images for an iOS retina display, we created multiple images for different Windows scaling percentages— 100%, 140% and 180%. These images are loaded automatically on HD tablets.

Use snap view to engage your users

Windows 8 lets users multitask by “snapping” an app next to another app. The snapped view is a great way to increase the app’s time on screen and engage users for longer periods. It’s easy for a user to change the main app and the snapped app by manipulating the splitter between the two, so it is important to maintain context across resizes. We don’t want users to lose app state as a result of resizing their app.

Example: home screen snap view

The Metro style app in snapped view.

Metro style app

  • The snap view of the home screen is just a different view of the home page where a user can still access the same content.
  • In snap view, a user pans vertically to get to more content because it is more comfortable to pan along the long edge. This is different than the horizontal panning in full view, which is also optimized to pan along the long edge.

Notifications

Use tiles for persistent and dynamic updates

iOS 5 introduced a notification center where new notifications appear quickly on the top of the screen and users can swipe from the top to view all messages in the center. In addition, app icons in the iOS Springboard can have number badges attached to them to indicate that there are new messages. The tiles on the Windows 8 Start screen combine the functionality of both numeric badges on app icons and the Notification Center on an iPad. Users can launch apps and read notifications all from one place. In addition, unlike the notifications in iOS which have a fixed format, Metro style app tiles have a rich collection of templates for designers to choose from.

Example: notifications on the home screen

A Photo journal notification on the iPad Springboard.The Photo journal tile and notification on the Start Screen.

iPad

A. App icon with numeric badge on iPad Springboard.

B. Notification center with Photo journal notification.

Windows 8

C. Tile on the Start screen with both numeric badge and notifications. Many tile templates are available.

Use toasts for transient and important notifications

You can use toast notifications to notify users of events in real time. Unlike tile updates that are passive, toast notifications in Metro style apps are important updates that interrupt users. They show up on the top right of the screen and can appear anywhere in the system. Generally, it’s best to let users opt-in to notifications during their first run of the app. If applicable, show recent toast notifications on tiles while they are still relevant. Toasts are similar to the iOS transient alerts displaying as banners at the top of the screen. But designers can choose from a collection of toast templates to make their notifications more relevant.

Example: Photo journal notifies users when they receive a comment from a family member

A toast notification on the Start Screen.

User is set up to receive toast notifications when a family member has commented on photos in the app.

Double is the simplest, most elegant way to be somewhere else in the world without flying there. The minimalist design and intuitive touchscreen controls allow you to freely move around without inconveniencing others. You can stay at eye level, whether sitting or standing, by adjusting your height remotely, which makes conversations fluid and real. Retractable kickstands will automatically deploy to conserve power when you are not moving around. Efficient motors and lightweight design give Double the ability to last all day without recharging the battery.