Mind you, the first couple of updates were meant to solve two specific problems:

1)  Address a couple of small bugs I had identified.

2)  Get the Microsoft Advertising Control to actually work in my app.

Every app is going to have a bug or two, and there’s nothing terribly interesting about those, but the ads WERE tricky.  I created my ad units at PubCenter (which as it turns out, is not a place to find a frosty pint.)  I added an AdControl to the pages of my app using the identifiers from my ad units.  But they didn’t show up in my app when I published it.  In fact, after I published the first time, they didn’t show up in my development environment anymore either.

Being Lazy Was a Problem

One of the consistent pieces of feedback I had given developers was to uncheck the “Internet” option in the app capabilities if you weren’t using it.  Having that box checked also requires you to publish and include a privacy policy, and being lazy and averse to legalese, I decided my poker app, which didn’t have any need to connect to the internet, would not get this box checked.  (Of course, you do this right before you publish, not realizing you’re breaking everything.)

I opened a support ticket with PubCenter, and after a couple of days of trading emails and eliminating the obvious problems, they simply asked to see my code, if possible.  I pointed them to my github repository, where they identified that I had turned off “Internet” capabilities, and the AdControl needs this to serve ads.

Looking back, this is one of the most obvious statements I have ever written.

At the time, however, I seemed to me that the AdControl would probably have its own mechanisms for serving ads, and that they weren’t dependent on my app’s settings.  WRONG.

Anyways, once I flipped that switch on March 8th, the ads started showing up, and much to my surprise, I started making a little money.

Let’s Define “Making Money”

In the first few days after the ads started working, I averaged about $1.30 a day.  Not retirement money by any means, but my expectations were in the pennies a day range.  A dollar or more seemed HUGE.  Here’s a chart of my first month:

As you can see, March 18th was a huge day, grabbing me $4.55 that day.  I thought this thing was just going to take off.  As it turns out, that was my first day in the “New & Rising” category, and the shine slowly faded on that $4+ day.  Regardless, I’ve been consistently averaging more than $2 a day, which would be over $700 annually.  Not a fortune, but now I’ve got a baseline to start from, and I’ve got big plans to elevate that number over time.

What About eCPM?

The important number in the mobile app game is something called eCPM.  If you haven’t seen this term before, everyone uses is, but nobody really seems to define it.  eCPM means “effective cost per thousand impressions.” 

In simpler terms, this breaks down to the amount of money you made for every 1,000 times an ad was shown.  For the month of March 2013, my eCPM fluctuated as I was adding users, and ended up at an average of $0.73.  This number seemed a little low, until I looked at where I’m hovering each day lately:

Day to day, I’m averaging about $2.30 for my eCPM.  Since I’m averaging around 1,000 impressions per day, it makes sense that I’d be making about $2.00 a day.  (I’ve had peaks of 5,000+ impressions in a day, but lately it’s been more in-line with 1,000 per day.

So What’s Next?

My plans for the future are pretty simple: drive more impressions per day.  One idea I have for this is to offer a prize to users who hit a royal flush in the game.  This should incentivize people to play more, in the hopes they’ll win the prize.  I need to determine whether or not this is really legal, as well as whether or not it’s permitted in the Windows Store.

Another one is to make it more simple, and just reward those players that play more than a specific number of video poker hands each month.  Something like 10,000 hands.

In either case, I’m looking for ways to get more players to play more often, to drive up the number of impressions I’m getting each day, which should also drive up the amount of money I’m making each day.

I’ll keep you posted on how this all works out.

Is that gambling?

Let’s now say, hypothetically, that in this video poker app, you created an offer to all of your users to award the first person each month that achieves a ROYAL FLUSH a prize of a giant, stuffed teddy bear.  The users still risk none of their own money, but playing the game “might” win them the prize.

Is that gambling?

Now let’s swap out that teddy bear for a $100 gift card.  Does that change anything?

Now is it gambling?

I’m considering this approach with my app, to encourage more people to play more often, but I also am jail-averse.  I’m also massive-fine-averse.  But to me, this seems about as cut and dried as it can get.  How could it possibly be gambling if the player never risks anything?

Please leave your thoughts in the comments.  I am sincerely interested in your opinions, and if you know a lawyer that has any insight into this, I’d love a chance to chat with them.

Thanks!

I’m still working on my Windows 8 application, King Poker, and have I learned some things this week.  (It’s also available for Windows Phone, btw.)

In general, my app is pretty straightforward.  It’s a video poker application designed to look as similar to the real video poker machines in casinos as it can.  Last week, I got ambitious, and decided to add some functionality that goes above and beyond the core functionality you’d expect.

I added Azure Mobile Services, and if the user was online, every single hand was recorded to my cloud storage database.  In the 10 days it’s been live, I’ve recorded over 45,000 random hands of video poker to my database.

In addition, I added Microsoft Account authentication, which means that if you log in with your Microsoft credentials, I could persist your credit count and hand history across all of your devices.  This is where the story gets ugly.

I spent HOURS writing and testing this functionality.  Log in on my Surface RT.  Play some hands of Deuces Wild.  Log out.  Keep playing.  Log in.  Play some more.  Cut the wi-fi connection.  Play some more.  Reconnect.  Sync the hands that were played when disconnected.  Log in to the Windows Phone 8 version.  See the identical credit count.  If you were logged in to these apps, everything worked marvelously.

When you weren’t logged in, it still worked marvelously.  It still logged your hands in my cloud database.  My mistake was that I didn’t notice that even when you were logged out, it was trying to sync your credits.  Anonymously.

So I pushed this new update chock full of new features to the store.  And it passed.  I was so excited!  And then the negative reviews started flowing in. 

“Used to work well on RT. Last update broke it. Lost all my money, well pretend money anyway. Please fix it”

“This is a great poker game. Play it all the time. However installed update yesterday and now it crashes all the time.”

“Credit counter still going crazy...Change the word HELD...back to HOLD, like in Vegas and Atlantic city...”

As it turns out, everyone that wasn’t logged in was synching their credits with everyone else that wasn’t logged in.  Ouch.

I’ve been really careful about thorough manual testing, as well as running a full suite of unit tests, but this one got by me.  I was so focused on what the experience was like for authenticated users, I didn’t give enough to time to think through all of the scenarios for those people that chose not to authenticate. 

I fixed it immediately, but it was Friday night, and the Windows Store team doesn’t approve apps on the weekends.  It wasn’t until Monday afternoon that my new patch was finally released, and almost immediately, I found yet another issue.  (It’s funny how much more obvious bugs are when they’re in production vs. development.)  I now have to wait at least another day before this issue will finally be solved.

Take Your Time

My point in all of this is to take your time.  I was so anxious to get my new set of features into the hands of my users, I completely neglected to remember that apps that have to go through stores are SIGNIFICANTLY harder to fix than a simple website.  If I find an issue on my website, I can fix it instantly.  In your app, your users may have to suffer through days or bugs before you’re able to fix an issue.  Take your time, get it right, and give your users the experience they deserve.  It’s the only way you’re going to get MORE users.

In short, no matter how great your set of features is, a little extra diligence to think through ALL of the user scenarios will benefit everyone in the long run.  That’s how you build a great app.  Keep your users’ confidence high, and give them a reason to tell their friends about it.

If you’d like to

Many of you have probably done this before: you want to recognize a specific key that has been pressed when a user is entering something into a TextBox.  Maybe you want to take action when they press the Enter key, for example.  This is generally simple enough, you just set up a KeyDown (or KeyUp, depending on your needs) event on the TextBox in question, and then just check every time the event fires until you find the key you’re looking for.

That’s not what I wanted to do.

To give you some context, here’s a screenshot of my app:

For the cards in question, I want to hold the three Queens, and then re-deal, hoping to get the 4th Queen, or maybe one of the Wild Deuces.  (If I’m very lucky, BOTH!)

As the game currently stands, it is designed for use on a touch screen or with a mouse.  Clicking/tapping on a card will mark it as “HELD,” and won’t replace it when you click the “DEAL” button.  But you have to actually move your fingers or mouse to each card to mark them.  For speed players, they’d prefer physical buttons that can be pressed over having to touch a screen.

This is where my key capture needs come in.

I don’t have a control that I can just drop a KeyDown event on.  I want to be able to monitor keystrokes at all times.  For this, we can simply wire up an event in the code-behind file, and capture it there.  Here’s what it looks like:

protected override void OnNavigatedTo(NavigationEventArgs e)

{

    Window.Current.CoreWindow.KeyDown += CoreWindow_KeyDown;

}

void CoreWindow_KeyDown(Windows.UI.Core.CoreWindow sender, Windows.UI.Core.KeyEventArgs args)

{

    switch (args.VirtualKey)

    {

        case Windows.System.VirtualKey.Number1:

            if (HoldRound) HoldCard(Card0);

            else SetBet(1);

            break;

        case Windows.System.VirtualKey.Number2:

            HoldCard(Card1);

            break;

        case Windows.System.VirtualKey.Number3:

            HoldCard(Card2);

            break;

        case Windows.System.VirtualKey.Number4:

            HoldCard(Card3);

            break;

        case Windows.System.VirtualKey.Number5:

            if (HoldRound) HoldCard(Card4);

            else SetBet(5);

            break;

        case Windows.System.VirtualKey.Space:

            Deal();

            break;

    }

}

protected override void OnNavigatingFrom(NavigatingCancelEventArgs e)

{

    Window.Current.CoreWindow.KeyDown -= CoreWindow_KeyDown;

}

As you can see above, I subscribe to the Window.Current.CoreWindow.KeyDown event, which fires before anything else gets access to the key event.  This is also a great way to capture keystrokes before they get to your TextBox controls, etc.

Once I’ve got this event rigged up (and un-rigged it with my OnNavigatingFrom event), I can now easily provide physical keys for my power users by enabling the #1 - #5 keys to hold the cards rather than having to move their mouse all over the screen.  In addition, I’ve also set the Spacebar up to provide “Deal” functionality, which means they never need the mouse once they start playing the game.  Here’s a look at the cards held:

And finally, in case you were wondering, here’s what I drew (I got that wild 2) to get my four of a kind!

Summary

So there you have it.  A simple way to capture keystrokes in C# and XAML applications for Windows 8/Windows RT applications.  Many apps have a need for this in some way (even if it’s to provide a shortcut or even an Easter Egg), so consider this in your applications as well.

In my numerous years of XAML and C# development,  I’ve almost always had the good fortune to be working in a constrained box.  In Silverlight, I knew exactly what size the control was going to be when it was embedded on a web page.  In Windows Phone 7, there was only one resolution: 480 x 800.  It allowed me to get lazy.

With Windows 8, laziness is no longer possible.  You’re required to support 3 distinct resolutions out of the gate:

• 1024x768 (filled view)
• 1366x768 (minimum full screen resolution)
• 320x768 (snapped view)

Using Grids

I knew going into this project that I was going to be making extensive use of the Grid control.  By setting the widths to “*”, I could have my content automatically scale to the size of the container, effectively scaling everything up to the appropriate sizes.  I had another problem though: the amount of content I was presenting varied also.

ProTip: When layout a dynamic grid system, figure out what you want your layout to look like in fixed values on a 1366x768 screen.  Set every ColumnDefinition and RowDefinition explicitly, so that it is EXACTLY the way you want it to look.  Once you know those values, figure out what percentage of the width or height of the screen that takes up.  Use these percentages as the dynamic values in your Column and RowDefinitions.  Like this:

<Grid.RowDefinitions>

   <RowDefinition Height="38*" />

   <RowDefinition Height="36*" />

   <RowDefinition Height="7*" />

   <RowDefinition Height="5*" />

   <RowDefinition Height="12*" />

</Grid.RowDefinitions>

At the top of each game, there is a “paytable” that indicates how many credits you will win for certain types of poker hands.  Some games, like Jacks or Better, have only 9 different hands that pay out.  Other games, especially those that include wild cards, can have as many as 15!  Here’s two screenshots of my app (before I solved all of my scaling issues.)

Jacks or Better (9 rows)	White Hot Aces (11 rows)

As you can see, the paytables are different heights, and there’s a variable amount of space between the cards and the content below them.  This was unacceptable, but I couldn’t figure out how to keep my paytable box a consistent height while having the content inside of it scale to fill it appropriately.

Discovering the Viewbox Control

Last night, after fighting with this issue for a couple of weeks, I discovered the Viewbox control.  Not sure how this has eluded me for so long, but that time has passed, and I am a HUGE fan.  Its simplicity is its genius.  Wrap any content inside a Viewbox control, and it will automatically scale it to fill its container.  What this meant for me was that I could set my paytable box to be a fixed percentage of the screen, and the text inside that box would simply scale to fill the box.  This means that 9 rows can fit in the same box as 15 rows, because it will just make the font size smaller for me automatically.

Sidenote: I had already started writing an elaborate “Page_SizeChanged” method that was going to manually set all of the font sizes, image sizes, etc. based on the resolution of the user’s machine. I am so glad I don’t have to do that.

You don’t need to do this with everything.  For example, I’m only using it for my paytable grid and the advertisement.  Everything else is able to scale on its own by the default behavior of a Grid.  Here’s some screenshots of the new interface, with many more rows, yet more available vertical space:

Black Jack Bonus Poker (14 rows)	Deuces Wild (10 rows)

You can see that now, my interface looks identical, regardless of how many rows I add to that paytable box.  What’s also cool is that the second image, the Deuces Wild one, is actually at a significantly higher resolution than the Black Jack Bonus Poker one.  Yet they look identical.  THIS is exactly what I was going for.

Struggling with Dynamic Layout

So it may seem, at this point, that my problem is solved, and we’re done talking about scaling.  Wrong.  See those 5 card images?  Their size is dynamically determined by the size of the grid cells they reside in.  This works perfectly fine until I want to swap them out for other graphics (like when a user deals new cards, for example.)  When I change their source, for a brief moment, they don’t have a width or height.  More specifically, their width and height are zero.  My intial solution (so far) to this problem is to determine what size the images are when they are loaded, and then set their MinHeight, MinWidth, MaxHeight, and MaxWidth equal to their “loaded” size, so that even when I swap out their source, they’ll remain the same size.  I tried many different events until Tim Heuer suggested I try the ImageOpened event on each image.  This is where I landed:

private void Card_ImageOpened(object sender, RoutedEventArgs e)

{

   ResizeSingleCard(sender as Image);

 }

private void ResizeSingleCard(Image i)

{

   i.MinWidth = i.ActualWidth;

   i.MaxWidth = i.ActualWidth;

   i.MinHeight = i.ActualHeight;

   i.MaxHeight = i.ActualHeight;

}

By doing this, each of our images are “locked” to their size for the duration of the user’s game session.  I am also handling some weird stuff for the very unlikely situation that a user changes their resolution during a game session, but that’s not something most of us need to worry about.

Summary

In short, getting your app to scale to multiple resolutions is hard, but it’s much easier than I was making it thanks to the Viewbox control.  Now to find a way to get this control into my Windows Phone version, and I’ll be set.

A special shout-out needs to go to Ryan Lowdermilk, because without his constant beta-testing and encouragement to clean up my scaling issues, I probably never would have fought through it to get where I am today.  (Also, check out his great podcast, The Windows Developer Show.  I’m hooked on this weekly broadcast of the latest news for Windows 8 & Windows Phone Developers.)

1. Use the WACK (Windows App Certification Kit)

The first time I was denied, most of it was completely avoidable.  There is an amazing tool called the WACK (Windows App Certification Kit) baked in to Visual Studio 2012 that will analyze your app package for all of the computer-verifiable issues your app may have.  This includes things like:

• Forgetting to provide all of the appropriate icons.
• Accurately checking your capabilities vs. functionality.
• Performance metrics.
• Many more (the entire list can be found here.)

2. Don’t advertise outside of your app.

In my Settings charm menu, I included an About page.  On this about page, I included a way to get a hold of me if you have comments, suggestions, requests, or discover a bug.  I also included a mention that this same app exists in the Windows Phone marketplace, if you’re interested in that.

THIS IS APPARENTLY A BIG NO-NO.

2.3 Your app must not use its description, tiles, notifications, app bar, or the swipe-from-edge interactions to display ads

The elements of your app's description, such as screenshots, text, and promotional images must describe your app and not contain additional advertising.

This means that you cannot provide links to your other apps, because this is considered “advertising,” which I guess in its truest definition is accurate.

3. Be prepared for the challenge that Taiwan, South Africa, Korea, and Brazil will present.

More accurately, those four countries require a game to have an age rating verification, and the Windows Store doesn’t do a great job of warning you about this before you submit your app.  (They also don't offer any guidance on how to accomplish it.)  On one screen, you have the ability to choose from well over 80 countries.

On a completely separate screen related to game ratings, they subtly mention that there are four countries that require a game rating:

If you don’t put two and two together to make four, you’ll likely get denied for this, so take one of two approaches here:

1)  Take the time to wait for the official ratings boards to get you a certificate that verifies your rating.

2) Submit your app without these four countries initially, and then update the app to support them once you receive your ratings.

Here's where you can submit an application for each country:

Brazil - DJCTQ

Korea - GRB

South Africa - FPB

Taiwan - CSRR

Summary

So, those are my simple lessons learned from my first Windows 8 app submission.  I hope to have many more in the near future, and I’ll be sure to announce them here when it happens.  If you would like to check out this app I’ve made, you can check it out here:

It’s an authentic re-creation of the video poker machines you find in every casino.  I’d love your feedback, your requests for more features, and especially your positive reviews.

Let me know what you think!

1. Their app is making great progress, but they’ve hit a technical hurdle that they can’t solve.

2. Their app is nearly done, but it really needs some UX help and some design sense.
3. In order to accomplish the goals of the app, they need some funding to buy data, developers, time, resources, etc.

To that end, I’ve constructed a way to try and help you in each of these regards.

Technical Office Hours – I am dedicating every Thursday to helping you with your apps.  Have technical questions?  Bring them (and your code), and we’ll work our way through it.  To sign up for a slot, I’ve started using OHours at http://bit.ly/blankenhours.  You can attend in-person at TechColumbus, or join me via Skype, Lync, or Google Hangout.

Design & UX – I will help guide your app design to the best of my ability, but I’m also partnering with some of the top designers in Columbus to help you take a good app to great.

Funding – I am working directly with TechColumbus, and if you have an idea that interests them (and you’re based in Columbus), they might just be interested in investing in you.  Come talk to me.  I think you’ll be surprised what you can do.

Finally, if you haven’t found it already, check out Generation App.  You’ll find free technical and design support via phone, as well as contests and giveaways just for building apps.

Today is the last day of this series, and we’re going to focus on designing Windows 8 applications today.  You might be asking yourself:

I’m a developer…why would I want to read an article about design?

I’ll tell you why.  Because we developers have been making user interfaces that look like this for decades:

The point of this article is to get you to think differently about you user interface, not just the colors and shapes that are user, but the ENTIRE EXPERIENCE.  The way pages show content.  The navigation experience.  Even page transitions.  It all matters now. Here’s more proof, if you need it.  Think, for a moment, about what an app running in Windows 7 looks like.  Any app.  Picture it in your mind.  It probably looks like this:

If you take a closer look at this diagram, there’s no indication whatsoever about what this app does.  We’ve tended to focus on how we use the app, not what the content is.  Windows 8 fundamentally shifts that idea.  Now think about a Windows 8 application in your mind.  It probably looks more like this:

In this illustration, the ENTIRE image shows content.  This means that instead of remembering how to use your app, users are far more focused on the content of your app.  This is part of the conversation we’re going to have today.  This article will be divided into several sections, and each section talks about a different part of user interface creation.  Here’s the topics we’ll cover:

• Content Before Chrome
• Using The Windows 8 Silhouette
• Navigation Patterns
• Fluid Motion
• Make Touch a Priority

That’s a ton of topics, so let’s get right to it.

Content Before Chrome

In this section, I want to focus on one of the most important lessons in this entire article:

STOP MAKING BUTTONS.

The focus of every screen of your application should be about the content.  If you’re adding buttons, you’re likely doing it wrong.  Here’s a very common scenario:

We have several sections to our application, and we want to provide an interface for our users to get to each section.  In general, most people would say that there’s absolutely nothing wrong with this interface (except that maybe those giant gray boxes should have photos in them.)  The key lesson to remember is that the entire colored block IS the button.  There’s no reason to add the circled arrow icons.  Instead, consider this:

By removing the circled arrows, we’ve made the interface cleaner by removing the clutter, we’ve provided the user with a larger touch target for their fingers on touch devices, and given ourselves less to worry about on the page.  “One button to rule them all",” if you will.

When you desperately feel the need to add a button to the screen, ask yourself:

Could this live in an application bar?

If it can, do it.  For more on the application bar, check out Day #4.  In short, let the user tap the content instead of creating another button for them to click.  If an action can be taken on more than one item at a time, use the App Bar to provide contextual actions when multiple items are selected.

Using the Windows 8 Silhouette

It would be a dreary, boring world if every app looked exactly the same.  That considered, it is also difficult for users to learn a new interface with every application that they use.  This is where the idea of a silhouette comes into play.  Take a look at the four different application examples below.  They all present very different content in very different ways, but there’s a uniform experience about them that makes it very obvious to the user where the important content lives.

There are many ways to utilize this familiar silhouette, here are just a few examples:

All of the previous images follow a familiar format, which makes it easy for the user to figure out how to use your application, while still looking diverse enough to make your app visually unique.  The reason for all of this is because there will be learned behaviors your users will acquire simply from using Windows 8.  They’ll start to rely on the Charms bar.  They’ll start to expect that right-clicking brings up an AppBar with more options.  They’ll try pinching the screen to zoom.  Taking advantage of these silhouettes is another example of the expectations users will have about your application.

Navigation Patterns

As developers, we have a tendency to try to accommodate our users’ needs, almost to a fault.  One example of this that is rampant in both desktop applications as well as the web is this idea:

We need to allow the user to get TO any page, FROM any page.

You do NOT need to do this.  When we provide this type of functionality, we limit the amount of space that can actually be used for the purpose of the app.  Here’s an example of an RSS reader app that practices the “everywhere navigation” pattern (click to enlarge).

As you can see, an app that is dedicated to reading only uses about 30% of the screen for actual content.  We need to think about our application in a navigational scheme that makes sense for our content, which will almost always be hierarchical or flat.

Hierarchical Navigation

In this style of navigation, we work in a hub-and-spokes model, where the users’ choices move them further and futher from the home page, and using the back button allows them to return backwards through their path before choosing another branch of the tree to travel down.  Like this:

We build pages with a master/detail structure so that navigation is intuitive and simple to use.  The user should always know where they are in the app, without having to lay an elaborate trail of breadcrumbs for them.  They should be diving into deeper and deeper detail about the original choice they made.  The default News application in Windows 8 is a great example of this hierarchy.

On the home page of the app, I can scroll to the right to see a few articles from each section (Entertainment and Sports are currently shown):

Using Semantic Zoom, the user can easily see all of the categories, and jump to the one they want to read more about.

If I tap on one of the section headers on the main page (like the word Entertainment above the large photo of the woman, Lynn Shelton), I am taken to a new page that contains only Entertainment news.

Finally, and this can be done from anywhere in the app that I see an article, when I tap on a specific article, I am taken to a detail page for that item.

In each instance, there is the presence of a back button which will take me back through my previous choices.  What you don’t see, however, is the ability to jump from an Entertainment news article over to a Sports article.  In fact, there’s not even a way to get to the Sports category without using the back button.  That is, until you take a look at the AppBar for this app.

There, you’ll see that they succumbed to the need to let the user navigate quickly between sections without cluttering up the screen with all of this navigation.  The AppBar is a great way to provide some of these navigation mechanisms without taking away from the visual appearance of your application.

This is a hierarchical navigation pattern.  Learn to use it.  It will be your friend, and clear your screen of all of the navigation elements you would need otherwise.

Flat Navigation

Flat navigation is something that you see every day in your web browser.  You also see it in instant messaging apps, and other places that have similarly formatted, but somewhat unrelated content.  A picture would look like this:

When we navigate a website, we’re using this flat navigation style.  We can move forwards and backwards, but there is really no concept of branches in this format.  Since you’re likely using a web browser to view this article, I’m going to assume you know what I’m talking about.

Fluid Motion

Motion is one of those things that we never think about as developers.  We tend to focus on the important topics, like data, and never really consider how much nicer our app would look if it incorporated a little animation.

When I talk about animation, however, I’m not talking about it for visual adornment.  It’s not a decoration that you slap on your page.  Animation should be purposeful.  If you can use animation to transition between screens of your app, your user will perceive load times to be shorter, and feel that your app is faster and more responsive than it actually is.

In addition, there are a bunch of animations available to you with minimal effort.  Check out this article on Animating Your UI from MSDN.

Make Touch A Priority

A “tap” and a “click” in Windows 8 are the same thing.  It requires no effort on your part to make touch happen.  Making your click targets big enough for a finger, however, does.  Always, always, always make anything on your page that is clickable larger than 48 x 48 pixels.

Incorporate gestures where possible.  Your users will expect them.  It requires minimal extra effort, and it lets your users interact with your app the way they expect to:

In addition, it’s important to remember that because your users will be touching the screen, this also means that there are optimal places to put your buttons and content.  Generally, a user will hold a tablet horizontally, with their thumbs hovering over the two sides of the tablet.  This means your primary buttons should probably live in these regions as well.  What shouldn’t live there is your content.  If the user’s thumbs are hovering over this region of the screen, this also means they can’t see what is happening on that region of the screen.  Here’s a good rule of thumb:

Summary

In this article, we covered some of the important things you should be thinking about when you start building, and more specifically designing, your Windows 8 applications.  There are tons of additional resources at

http://design.windows.com

and you should definitely make a trip over to the site to check them out.  There are additional design patterns, UX guidelines, Adobe Photoshop templates and much more.

This article also puts the finishing touches on this lengthy series, and we want to sincerely thank each of you that have taken the time to read our words.  There are many reasons to write an article series like this, but our primary reason is that it’s an amazing excuse to dive deep into a technology stack and really understand it.  My second reason, however, is you, the reader.  Clark and I have made our best effort to understand each of these topics thoroughly, and explain them in a “no assumptions, start from the beginning” manner.  You, our readers, bring us comments and questions that we hadn’t anticipated, and for that, we truly are thankful.

Please leave comments and questions on our articles.  These will continue to live on as excellent learning resources for developers looking to build Windows 8 apps, and your contributions only make them that much better.

Thanks.

Wow, here we are finally talking about the Store. This is really our last step ( and a very exciting one no less ) in your development process. Today we’re going to share with you some of our steps and experience in not only helping others get their apps into the store, but also submitting our own.

If you’ve gotten to this point, then no doubt, these are exciting times. Whether you’re a few code slingers at Rovio making Angry Birds or someone like me who was building an app on the nights and weekends, it’s exciting. If you’ve have an app in the Store, I would also invite you to share in the comments the things that have worked well for you, and not so well.

Microsoft announced just a few short days ago, that they’ve sold 40 million licenses of Windows 8 in it’s first month of life. I don’t know about you, but that’s a pretty big audience for some indie developer like me. The Store is our new platform for us to ship our software to.

For purposes of today, we are only going to talk about the public facing Microsoft Store. If you feel you fall outside of that scenario, say you’re an enterprise developer and might like to deploy through group policy, I would suggest start by reading the Managing Client Access to the Windows Store.

To the Store

Now to get in the store, you have to have to first be signed up as a individual developer ($49 USD) or a company ($99 USD). Once signed up, you can then start reserving app names. Now I know this might sound a bit like duh, of course, but maybe you already have an idea but just haven’t started it. Nothing is stopping you from creating your account and reserving those application names now. Now unlike all of those domain names you’ve been buying over the years and just parking until you get time, you have 1 year from the time of reservation to shipping. If you don’t release anything, then that reserved name goes back into the pool. As someone who has a few apps reserved, it’s a pretty good incentive program for me.

Pre-Certification

If for some reason you’re new to this notion of a “store” or “marketplace” concept, as developers once we finish our app we have to go through a certification process before our application will be officially published. While this may seem somewhat cumbersome, this certification process is really there for everyone's benefit. Having been through it, the first time you submit your app the minutes can feel like hours but in the end it’s the right thing.

Of course the certification process is both automated and manual. For the Microsoft Store you as the developer have access to the same automated tools (WACK) which are used once you’ve submitted to the store. This allows you to go through the process before you’ve ever submitted addressing any potential issues.

The Windows App Certification Kit or WACK is really two different kits; one kit for Intel based processors and another one for ARM based processors. These kits are tools that you would of course install on a test system which will run through the same automated process that the Microsoft Store would do from it’s servers. The beauty about these kits you can run them on yourself before you ever submit your application to the marketplace. As I said this really helps to ensure you’ve cut down any issues long before submitting to the store, ultimately cutting down your certification time if you we’re to have any issues.

After starting the Windows App Certification Kit you have 3 different categories of apps that you can select. For our apps we would select the validate Windows Store App option. Once selected, you’ll be asked as to what application you want to validate.

Once you pick out your application, the WACK tool will start running. It will start to run a variety of tests against your application and even do things like open it, to see how long wait times are. After it’s completed, you will get a detailed report as to what was validated. Of course just like in TDD, green is good and red is bad. Below is just a snip from a failed event report.

The WACK tool provides a very detailed report as to its findings. Having said you should run it across all of the platforms you expect to run on, as your load times on a low power ARM device might be a lot longer than that of a multicore Intel machine. It’s also not a replacement for hard core testing, both manual and automated. Just saying…

It’s also true, when you submit there is still a potential for failing the certification. Now Microsoft has released a pretty good document which details a number of the most common certification failures but make sure you have read through the certification requirements such that you’re not surprised.

One of the biggest reason apps fail is certification requirement 4.1. 4.1 states that an app with the Internet Access capability checked must provide a policy policy to the Store. Of course this means you might have to setup a simple website just to contain the privacy policy required. If you’re not using the internet, just uncheck it.

TIP

All of the Visual Studio templates for the Windows Store create the shell of an app but with the internet capability.enabled. If you’re *not* using the internet – uncheck it and save yourself the hassle.

App Images

Like it or not, the first thing your potential customer will see is an image of your application  in the store. In fact, there are a number of different images your user might see depending on where the store app has placed your application. Now mind you, this is all before your potential customer has even installed it, so make sure you have some great store appeal is a good thing.

During day 1 when we talked about the blank application, we discussed a number of different images you needed to include in your application. These were things like the store logo, small tile, wide tile and so on.

As it turns out, when you try and submit your application, you’re not done with the image creation process. At the time of submission you will be asked for a number of new logos that will be used by the store specifically. They are not part of your app’s package, they are images uploaded directly to the store. Specifically these images are your billboard images as well as screenshots of your application.

Making logos is clearly an art form. To help make things a bit easier, a friend of mine build a number of Photoshop templates around these Store submission graphics. I would encourage you to check them out as they could save you a number of hours.

Whatever you do, please, please, PLEASE replace all of the default images. Now I do not know who wrote Backgammon Gold nor am I not trying to place a dig on all the hard work they’ve done. But, I would never spend $4.99 on something where someone hasn’t even taken the time to replace the default Visual Studio images. I’m not saying, but I’m saying. Clearly their rating proves my point.

Making Money

Your monetization model is clearly something that only you can determine. While charging outright for the application is one way, there are many creative ways as well. The minimum price someone can charge for an application is $1.49 USD with increments starting at .50 USD.

While charging upfront is a clearly an easy way to make some coin, it’s not the only and it might not be the best depending on your scenario. What about offering the user a time-limited trial, or a feature-limited trial? Remember the goal is to make money and getting user to test drive your app isn’t a bad thing. There are a number of studies written about how trials have a much higher conversion rate that ones without trials. You don’t buy a car without driving it first, why not test drive an app?

Another very popular mechanism for making money is an ad supported model. This is nothing more than putting some ad container in your applications such that you’re displaying ads to your customers. While you can use any ad platform you wish (assuming they adhere to Microsoft’s certification requirements ) Microsoft offers an ad sdk from Microsoft Advertising which will get you easily up and running on Microsoft’s platform.

Lastly offering the ability for an in app purchase shouldn’t be out of your reach either. Using a game app example, one could offer more levels once the user got to a particular point in their journey just for a bit more money. I personally think this is a pretty interesting scenario as it gives you the ability to get people using your app, but offers them the ability to purchase something more full featured.

Now when you’re making most of the money, the Microsoft Store is doing all of this legwork for you, hosting the bits, transitions, currency conversions etc.  As you might expect there is a cut that Microsoft needs to take just to offer such support. For your first $25k Microsoft will charge you a 30% fee, but after your app makes $25k, that fee will drop to 20%. These are just a few of the items you will find in the app developer agreement.

Creating the package(s)

Creating the packages for the store is a painless process. There is basically two reasons to create a package, sideloading or WACK testing OR to upload to the store. The difference between the two different packages is really one is signed with your developer account whereas the other isn’t.

To get started, Project –> Store –> Create App Packages… As you can see, the first dialog box you’re presented with is in fact the two different options we just mentioned.

If we’re building a package for the Store. Then our next step is to select what our app name was in the store such that we can associate things correctly.

Regardless of what direction we choose first the next step in the process is picking what platform we want to build for. These will be the packages we will later either sideload or upload to the store.

And once created all of your glory should look something like:

For more information about sideloading please see this article: http://technet.microsoft.com/en-us/library/hh852635.aspx

Ready to submit

Submitting your application is mostly just a one page web form you’re required to fill out. These are things like, description, search keywords, release date and so on. The Windows Store team has done an excellent job of documenting everything, so I won’t rehash that here but rather ask you to please read their article.

App Update(s)

You’ve pushed and now you need to fix up a bug. Well, thankfully you’ve already been through the entire process already. Now it’s just a matter of creating a new release and changing anything that might be now applicable. Oh yea, of course you would need to update the new package too.

Summary

Honestly submitting your app into the store is the easy part. All of the planning and development that’s been done to this point has really been the hard part. While you have a plan in mind about how you may make money, don’t be afraid to think outside of the box and try a few different things. You never know what will net you the best results.

Tomorrow, we’re going to talk about our last day in this series which is focused on design.

Today, we’re going to talk about Application Lifecycle.  I wish there were a cooler word for this topic, but ultimately we’re looking at the management of the different states our application can be in on a user’s device.  Here’s an illustration (image from MSDN):

The reason that this is important to us as developers of Windows 8 applications is because we want to provide a seamless user experience in our apps.  When a user presses the Windows key on their machine, and leaves your app, you want to make sure you save or preserve their data in some way, so that when they come back, it’s all still there.

I Thought Windows Handled This Automatically??

Yes and no.  By default, if you run a Windows 8 application, leave it, and come back, it will automatically be exactly where you left it.  However, if you leave it, and then open 6 or 7 more applications, it’s likely that the operating system is going to suspend your application, or even terminate it.  Thankfully, there’s a couple of great mechanisms we can use to manage this.

Recognizing Your App Has Been Suspended

According to Microsoft, “an app can be suspended when the user switches away from it, or when Windows enters a low power state.  Most app stop running when the user switches away from them.”  There’s a few things you need to know about how your app will end up in a suspended state:

• Your app “might” be suspended.  For the simple app I’ve built for this article, I’ve never seen it enter a suspended state on its own.
• Generally, when the system runs out of resources, this is the time your app will enter a suspended state.
• When you leave an app to use another, Windows will wait a few seconds before suspending it, just in case you were planning to return to it quickly.
• If you need to execute any code before your application is suspended (we’ll talk about how next), you get a total of 5 seconds before your app is assumed to be unresponsive and terminated instead.  Keep this in mind…web service calls are probably not the thing to do.

So, if you’re anything like me, you’re probably wondering how we are going to write and test some code that only occurs when Windows feels like making it happen. Thankfully, there’s some tools for that.

First, let’s write some code.  On each page that a user might provide some input (whatever type of data), we can add an event handler that gets called when our app is suspended.  In the code below, I have created this event handler, and saved two values to local storage when it is called.

using System;

using Windows.Storage;

using Windows.UI.Xaml;

using Windows.UI.Xaml.Controls;

using Windows.UI.Xaml.Navigation;

namespace Day29_ApplicationLifecycle

{

    public sealed partial class MainPage : Page

    {

        public MainPage()

        {

            this.InitializeComponent();

        }

        ApplicationDataContainer settings;

        protected override void OnNavigatedTo(NavigationEventArgs e)

        {

            Application.Current.Suspending += Current_Suspending;

            settings = ApplicationData.Current.LocalSettings;

        }

        void Current_Suspending(object sender, Windows.ApplicationModel.SuspendingEventArgs e)

        {

            settings.Values["suspendedDateTime"] = DateTime.Now.ToString();

            settings.Values["customTextValue"] = CustomText.Text;

        }

        protected override void OnNavigatingFrom(NavigatingCancelEventArgs e)

        {

            Application.Current.Suspending += Current_Suspending;

        }

    }

}

You’ll notice, that like with all event handlers we create, I also remove it when the OnNavigatingFrom event is called.  We covered saving data on Day #8, so I won’t spend any time explaining that, other than to say that we are saving the time our app was suspended, as well as any text that was currently entered into a TextBox that I have on my MainPage.xaml page.  In order to verify this information has been saved, let’s add the Resuming event next.

Recognizing That Your App Is Resuming

In this case, we’re going to add a Resuming event, just like we did with the Suspending one.  When the method is called, I’m going to write the date and TextBox content back to the screen, so that the user can continue working on their data.

using System;

using System.Collections.Generic;

using System.IO;

using System.Linq;

using Windows.Foundation;

using Windows.Foundation.Collections;

using Windows.Storage;

using Windows.UI.Xaml;

using Windows.UI.Xaml.Controls;

using Windows.UI.Xaml.Controls.Primitives;

using Windows.UI.Xaml.Data;

using Windows.UI.Xaml.Input;

using Windows.UI.Xaml.Media;

using Windows.UI.Xaml.Navigation;

namespace Day29_ApplicationLifecycle

{

    public sealed partial class MainPage : Page

    {

        public MainPage()

        {

            this.InitializeComponent();

        }

        ApplicationDataContainer settings;

        protected override void OnNavigatedTo(NavigationEventArgs e)

        {

            Application.Current.Suspending += Current_Suspending;

            Application.Current.Resuming += Current_Resuming;

            settings = ApplicationData.Current.LocalSettings;

        }

        void Current_Suspending(object sender, Windows.ApplicationModel.SuspendingEventArgs e)

        {

            settings.Values["suspendedDateTime"] = DateTime.Now.ToString();

            settings.Values["customTextValue"] = CustomText.Text;

        }

        void Current_Resuming(object sender, object e)

        {

            Message.Text = "Resumed.  Was suspended at\n\n" + settings.Values["suspendedDateTime"];

            CustomText.Text = settings.Values["customTextValue"].ToString();

        }

        protected override void OnNavigatingFrom(NavigatingCancelEventArgs e)

        {

            Application.Current.Resuming -= Current_Resuming;

            Application.Current.Suspending += Current_Suspending;

        }

    }

}

How In The World Do I Test This Scenario?

Because this is a tough scenario to make happen automatically, there are tools inside Visual Studio that allow us to simulate these states in our application.  First, make sure that you’ve opened the Debug Location toolbar in Visual Studio.

Once you’ve added that toolbar, it’s as simple as choosing one of these three options:

• Suspend will immediately put your application in a suspended state.  This will also fire your suspended event handler before it stops running.
• Resume will obviously resume your app from a suspended state.  If your app is not suspended, nothing will happen.
• Suspend and shutdown will simulate what happens when Windows terminates your application.  The suspended state will happen first, followed by a complete shutdown of your app.

If we use these buttons on the application we’ve created in this article, you’ll get an experience similar to the one in this short video:

In short, this is how we manage data on a page-by-page basis.  If you’re looking to do things at the overarching application level, you can take a look at your App.xaml.cs file.

Using App.xaml.cs to Manage the Lifecycle

There are already two methods sitting in your App.xaml.cs file, and you’ve already used them in previous days of this series.

• OnLaunched is called when your application is launched normally.  This will not be called when your application is resumed, as the user will be taken directly to the page they were on previously.
• OnSuspending is called AFTER your page event is called, but is also called when the application is suspended by Windows 8.  Saving any of your application-level data should be done here.

These methods provide you a little more power on a global level, but you’re still going to need to rely on your page level events for most of the state preservation you’re going to attempt.

Summary

In short, we want to provide a seamless experience for our users, so keep the lessons in this article in mind.  Don’t overdo it, though.  Saving unsaved data for a user is a convenience, so unless you think it will be important, don’t exhaust yourself trying to anticipate everything the user might need.

In games, if the user leaves, and they have to replay a level, so be it.  You don’t have to remember that they were jumping over that block to make it a great experience.  Remember which level they were on is probably enough.

If you would like to download the sample app that uses the code from this article, click the icon below:

Tomorrow, we’re going to dive into the Windows Store, and give you all of the information you’re going to need to get your app available for sale.  See you then!