Metro App Diary

We're building a great Windows Phone app from scratch and posting every sketch, every email, and every decision here.

Update: Stalled, Closed, But Fun!

It’s pretty clear by now that this project stalled out. It happens :)

We learned a lot, plus it was fun to design/dev while it was in active development. Thanks for following along!

Summer’s done, now for the cloud

Jon wrote:

Hi Matthieu! How have you been? Your summer was wonderful, I hope?

I’m wondering if you’d have the time and interest to add simplenote
integration to the app you built. I think the app works very well now,
but I’m starting to think I’d like the v1 to have simplenote built in.

What do you think?

Matthieu responded:

Hey !
 
It as been great !


Yeah I will take a look at Simple Note, it could be a good idea. I don’t think it will be that difficult.
I’ll keep you updated on the progress. By the way, do you want to touch the design or you think it is good this way ?
 
Matthieu

Jon said:

Great! Re design: I’m sure we’ll tweak later but for now it’s fine. 


Progress, July 27th

We have good news and bad news :)

The good news is that the app is functional, installed on our phones, and it’s awesome.

The bad news is I’ve been sitting on the app because I’ve been busy between work and a vacation in the wilds of British Columbia.

Soon I’d like to post the latest version here, though it’s not fully designed, just functionally complete. Then a later version will bring better design.

The next big question I’m pondering is whether simplenote integration should be in v1 or not.

More soon!

Progress, June 10

Matthieu wrote:
Hey,
 
Thank you for your feedback. I don’t know what it is with you designers to make everything prettier with almost nothing; I am so impressed !
 
To estimate the time spent on the dev I’d say I worked about 8 hour, maybe a little more on the code, counting the time spent researching the algorithms and implementing them.
 
About the search in long lists, I tried with about 100 items and the search is still fast, but the UI take a little time to refresh, nothing too inconvenient though. I am working on a workaround to enhanced a little bit more the performances.
Speaking of that, should we provide the user a way to delete his notes ? Or are they in the vault forever once entered ?
 
So, I tweaked the UI as you suggested and it look already so much better. I continue working on the storage, let me know if you need anything from me.
 
Matthieu
Jon replied:

Thanks Matthieu! Looks like it’s coming along great. Pretty soon it’d be fun to post a XAP to the blog to share with everyone :)
When it comes to deleting data, my DB experience tells me we should have a “isDeleted” flag rather than dropping rows from the table, to maintain data integrity.
So for now let’s go with that - and if we feel like we need a more robust way to delete, we’ll work on that later on.
Thanks! Hope you’re having a good weekend,
Jon

The App! It’s ALIVE!

Matthieu wrote to say:

Hey!

How are you doing ? For my part, I am working on the app ( sorry didn’t have much time lately ).

And I managed to create a first preview, following what you thought for the design ( tell me if I misunderstood something ). 

A few thing about the preview:

- It is ugly as hell ( I think it is worth noting ), but I did not want to waste time in the field you exceed in.

- For the search algorithm, I went for the Boyer-Moore search method, I am still working on slight improvements, but it works fine.

- There is no storage yet, the app is almost functional except it is a one shot, you can enter notes, edit them and all, but close the app and you loose everything ( next step I am working on )

I am eager to hear your feedback.

A très bientôt,

Matthieu

Jon responded:

Matthieu,

THIS IS SO AWESOME. Thank you for putting it together!

I know you’ve been busy with other stuff - I’m curious, how many hours of development do you think this took you? I want to post in the blog - it’s been several weeks since we kicked off, but I know you haven’t been coding the whole time, and people may be curious how complex the app is.

The search is super fast in my testing so far, which is great. Do you think it’ll still be fast at 100 items?

I’ll put together some real visuals soon, but for now, here are some minor tweaks you could make to the design to get it closer to what I’m imagining.

Could you please:

* Remove both headers (the small “SNIPPETS” and the big “HOME PAGE”)

* Make the text field have a black background/white text and a single pixel of white on the bottom border, like an underline.

* Bump up the font size of the list text by about 50%.

* On the edit page, let’s change the background color from gray to black with no border, and white text.

Thanks so much! This is very exciting :)

Talk to you soon,

Jon

Here are some screenshots taken from the emulator:



Why Not You?

I remember how common it was in 2007 and then 2008 to write off iPhone development. Apple didn’t have any marketshare, iPhones were too expensive, their competitors were too entrenched, only Apple Sheep would bother, on and on.

Somewhere along the way, a story was written about an indie developer who made real money on the App Store. Suddenly the conventional wisdom shifted from “why bother” to “why not me?” and the gold rush was on.

But of course not everyone can be an App Store millionaire, so then the media backlash hit. Most people, it was rightly pointed out, don’t make enough on the store to justify their dev costs, let alone strike it rich.

So then the fair-weather types probably shrugged and looked for the next big thing. Meanwhile, lots of interesting apps showed up, and some companies made quite a bit of money off them. No, not everyone was making millions, but it became clear that quality apps were able to find an audience.

I think of this pattern when I think of Windows Phone development. We’re in stage one right now. But in the coming years, there will be huge success stories. The kinds where people scratch their heads and say “why wasn’t that me?”

Well? Why can’t it be? Don’t wait for someone else to make the next must-have app. Now’s the time. Quality is always popular. And on Windows Phone, you have a lot less competition between your great idea and lots of publicity and loyal fans.

So what’s stopping you? Why can’t you be the next success story on this new platform?

I Changed My Mind: A Postmortem

Several weeks ago, I posted “You Will Be Wrong”. An excerpt:

Your first idea may be wrong. Build that truth into your process. Embrace it.  Use it to find your next idea, and your next, and pretty soon you may have something. Just don’t be afraid to admit when you’re wrong. Being wrong helps you see what to do next.

Recently, I wrote an article called “Let’s Speak Frankly About Saving State”, where I said I was considering breaking with Windows Phone guidelines so my app can save state. I wrote:

In making the decision to save state, I’m creating an experience that’s different than most Metro apps. And as I tweeted, it’s something we’d want to be very careful about. Maybe it’s just too shocking in practice, so we’d go back to the traditional model. That may happen.

I’ve been thinking about this decision a lot, and I’ve changed my mind. In the process I learned a few things I’d like to share with you.

Asking the Right Question
When you ask the wrong questions, the answers are beside the point. In this case, I was asking “Am I willing to break with Windows Phone guidelines in order to save state?”, which gave me two results: “Yes, break with convention and save state”, or “No, act like other apps and lose the ability to save state.”

But what I really should have been asking was why I wanted to save state so badly. The answer was “So you can quickly get back to your last note”.

So the next question is “Can I design a way to quickly get back to my last note without breaking Metro recommendations?”

Why yes. Yes, I can.

Picking the Right Precedent
Debating in the Windows Phone design studio is a lot of fun. (really!) It’s common for a design issue to come up to a four person group and trigger five different opinions. When this happens, everyone whips out their Windows Phones to start looking for precedent:

"See, look - on Battery Saver, we throw a dialog when it turns on"
"Right, but it’s apples and oranges, because this feature is more like airplane mode"
"I disagree - it’s an issue of discoverability versus learnability, and I think in this case…"

… and on it goes. In the middle of the debate, it’s really easy to cling to a certain screen that makes you look “right”. For example, saying, “IE does it the way I think we should do this feature. Case  closed. I win.” But this is a mistake.

My Poor Precedent
In this case, I was using Amazon Kindle as my precedent. When you open Kindle, it doesn’t land you at the book list for more than a second before swooping you into the last book you were reading. I believe this is the right behavior on Kindle, because over 80% of the time you’re wanting to keep reading your book between app launches.

I don’t think the same is true for a notes app. Yes, sometimes you want to see your last note. But other times you want to see all your notes, probably with the most recently read notes on top.

"Wait, Stop. Can You Say That Again?"
A bad debate is one where neither side wants to budge, out of some sense of honor, or ego, or some other dumb emotion that has nothing to do with delighting users.

But you know a debate is in a good place when people are saying things like “What I’m hearing you say is …” and “Can you help me understand …” and “Ok, I can see that …” and my all time favorite: “Wait, stop. Can you say that again?” It means that people are really listening, and are actually able to change their minds.

In my own internal debate, I had a “Wait, stop” moment when I realized this: if we list the notes in reverse chronological order, based on the last date something was read, your most recent note is always on top.

Ah ha.

Re-evaluating the Compromise
So let’s put everything together. We don’t save state. We sort notes in reverse chrono, based on read time. What’s the result?

1. We’re back to how Windows Phone apps normally behave (not saving state).
2. Your most recent note is always one tap away if you launch the app fresh.
3. We don’t have to hack in a “software up” button to get out of screen dead-ends.

Sounds good to me :)

Design’s Supporting Role

I’ve done both code and design, and I think designers have it pretty easy. We can mock up ideas very quickly, whether on the whiteboard or in Photoshop, and technical issues don’t have to slow us down. On the other hand, devs struggle every day with the crazy ideas some designer has foisted on them.

A lot of designers wave off the technical challenges with a “Oh, the developer will find a way”. Which is pretty similar to coding something up and saying “Oh, the designer will make this pretty”. I think both quotes point to a lack of collaboration, and a lack of respect for the other side’s skillset.

Matthieu is going to be working through code in the coming days and weeks, and it’s my job as designer to involve him in my thinking, go deep in the design thinking to get ahead of possible technical problems he may come across, and be patient while he converts some of my hand waving into actual code.

Here’s an email exchange from a few days ago:

Jon said:

I’m going through my todo items for the weekend and I wanted to check in with you on our app.

Is there anything you’re waiting on me for? Anything you’d like me to do? How are things going?

Just wanted to ask so I can cross it off my list :)

Hope you’re having a great weekend! 



Matthieu said:

Hey !

Sorry for not giving much news. I am now looking at the offer from Telerik. And I began to work on a really early version of something that can store notes a search dynamically among them.

If everything goes ok, I will be able to send you a first version by the end of the Week.

From your side have you fixed the hub and spoke model ? So we can start to work ok the final architecture.

Bonne fin de Week End :)
Matthieu  


Jon said:

Oh, I think our model is done:

* List page is our hub
* Each note is a spoke

And I would like a software “up” key so we can return people to the note they were on and give them a way to get back to the list.

Please let me know if you need other details and I’ll be happy to provide them.

Thanks! :)
Jon 

Are We Open-Sourcing The App?

Matthieu asks:

Hi Jon,
 
I was very interested by [the discussion about RadControls for Windows Phone]. I have however an interogation:
 
Wouldn’t it go against the philosophy of the project to use paid project to help build the app ? If we release the project on codeplex, users won’t be able to test the project without installing and paying for the telerik controls.
 
What is your opinion about that ?

Jon responds:

Good point. But my goal isn’t “give code to the open source community”, it’s “design an app as transparently as possible, and hopefully people will learn from it”.

So the open code repository was more of a “see? Look how open this is!” situation than any philosophical resistance to paid libraries.

My big concern is shipping as high quality a project as possible, as efficiently as possible. If you think the library will help you, let’s use it. If not, no prob! We learn (and teach) either way :)

 

Let’s Speak Frankly About Saving State

Before we Speak Frankly About Saving State, I should point out that the opinions on this blog are mine alone and not necessarily those of my employer. I’m just a guy designing a Windows Phone app in his free time. Here goes :)

I’m a purist regarding application state. If I close my laptop for an hour, then open it up again, the desktop should look exactly how I left it. Same window positions, same scroll position, everything.

What about mobile? Well, because incoming phone calls can take over the entire screen at any time, and are not initiated by the user, it can be argued that saving state is even more important than on the desktop. If you’re composing a long email when a phone call interrupts you, you’d expect to go back to the email upon completion of the call, right?

Same if you’re composing a text message. Or launching the Kindle application and expecting to go straight to the page of the book you were last reading. Or opening IE and expecting to see the last webpage you were on. Or in the case of our notetaking app, land you back on the last note you were using.

Windows Phone handles this with the back button. Try this test:

Go into the messaging app, start typing something to a friend, then press the start button, then press the back button. You’ll return to messaging, and your text will be waiting for you.

But this doesn’t work for apps that are launched anew. Try the same test, but instead of using the back button, try tapping the Messaging icon from start. You’ll notice that your text will disappear.

Because of this behavior, and because I think saving state is important, I mentioned that I am designing a way to save state between application launches. That lead to the following question on Twitter:

 

(“Fast application switching” means using the back button)

I responded and we went back and forth a bit. Read from the bottom.

In making the decision to save state, I’m creating an experience that’s different than most Metro apps. And as I tweeted, it’s something we’d want to be very careful about. Maybe it’s just too shocking in practice, so we’d go back to the traditional model. That may happen.

But until I can prove to myself that it’s not worth it, I continue to think that saving state in a notes app is important. Meaning we’ll need to design “software up” for our app to work correctly. Meaning we’ll be doing something different. But that’s the thing about Metro - it’s not a strict set of rules, it’s more a philosophy.

One of the core goals of my app, and Metro in general, is to be fast. To get you through your task as quickly as possible. For a note taking app, that means saving state so you’re always taken to the last note you were in, without having to re-discover the note you want each time.

And failing that, well, we have a plan B :)

Some Competitive Analysis for Our App

Our app (codenamed “Snippets”) records notes. Our goal is to record and retrieve notes faster than any other product in mobile. After all, we know our main competition is the  humble sticky note.

But what about our other competition? I went looking for other notes apps in the Windows Phone marketplace and wanted to share my initial reactions here, as a way to explain what I think they do well, and what they could improve.

OneNote
OneNote comes with the phone, has a strong cloud story, and has clients on all major platforms. We can’t compete at that level. But we can compete with an app that’s more focused, since OneNote is quite robust, and not everyone needs that kind of power.

I think we can be faster than OneNote at recording and retrieving, precisely because we’re not going to attempt as many bells and whistles.

EverNote
Everything I said about OneNote applies here, except EverNote is not bundled as part of Windows Phone.

Light Notes
This app looks as simple as we’re aiming for, but the interaction model feels a bit cumbersome in use. Because Light Notes splits the notes into “read” and “write” pivots, I’m finding myself swiping back and forth more than I think should be necessary. This is a good example of pivots causing more trouble than they’re worth.

Notes
As proven by its popularity in the Marketplace, Notes does a lot of things right. My main concern is that while it’s pretty straight-forward, it’s still trying to show too much.

Showing the GPS coordinates for a note isn’t going to help anyone, although showing notes as points on a map is a nice touch. On the same vein, using technical date stamps like 6/20/2012 9:05:13 PM makes the app feel like it’s designed for robots. I’d go with relative dates (“Yesterday”) where you can, and make prettier dates (“June 20, 9:05pm”) everywhere else.

It’s quick to add a note, but unfortunately there’s no search, meaning you have to remember where your notes are. Not a deal breaker, but something we should be able to improve on. 

HTC Notes
I can’t find this one on the store, so maybe it’s only available on HTC devices. The app has an animated background, an illustrated corkboard, the ability to collage notes however you want, and sound effects when you tap on the note to edit it.

It’s an interesting demo, but it’s not following Metro principles, it’s too flashy, and I find it hard to use.

Notepad Free
Notepad Freeis pretty good. The first thing I noticed is the use of the panorama control. Unfortunately, I found the panorama getting in my way during use. One screen of the control appears to just be a space to advertise the website for the developer, and other is used for settings.

I do like some key features in this app, but I find that the IXD slowed me down too much.

Notepad
I came across Notepad while writing this article, so I threw it on my phone at the last minute. It’s a fascinating appbecause of how my first impression of it changed so dramatically.

On first load, the app dropped me on a simple screen. “Uh oh”, I thought. “This app might be as quick and well designed as I’m trying for. This might be our best competition.” I typed some text and tapped save, and then these steps happened:

* I was asked to enter a filename for the note
* A modal dialog appeared telling me about other features in the app

This is where my brief love affair ended. The app wanted too many details out of me. I tapped the “new” button to make a new note and was asked if I wanted a new note or folder. When I selected “folder”, it asked me to add “remarks” on it. I quit the app.

Final Thoughts
If you’re developing an app on any platform, but especially on Windows Phone, put extra thought into the first run experience. You should work hard at removing extraneous questions, options, and settings. Otherwise your users may have an experience similar to mine: “I love this!” followed three seconds later by “Now I’m confused.”

And that was my best experience. The other apps I didn’t love first. Put extra time into getting people to fall in love, and you’ll stand out.

Rad Controls for Windows Phone

I was contacted by the makers of Rad Controls for Windows Phone:
http://www.telerik.com/products/windows-phone.aspx

Here’s a list of all the controls they offer:
http://www.telerik.com/products/windows-phone/overview/all-controls.aspx

I’ve passed it along to Matthieu, since he’s the dev expert. Perhaps these controls will come in handy on your Windows Phone project. 

Sketches: Our Hub and Spoke Model

Here’s a simple flow moving from:

1) A list of your snippets
2) A single snippet
3) A single snippet in edit mode 

But we have a few details to work out. First, because we want to allow line breaks in our notes, we can’t assume that the “enter” key will submit a note. Meaning we should add one, perhaps in the app bar:

Ok, so we lost some vertical real estate. That’s not too bad. But there’s a new wrinkle that we need to discuss. It’s important that notes save state. For example, if I’m in a taxi reading a note with a hotel address, and I jump over to my maps application for a quick second to check traffic, I should be able to jump right back to the note. Not the list on the top level of the app, but right to the note I was last reading.

Which is a problem on Windows Phone, because there’s no concept of “software up” the way iOS has. Either you force people to the top of your app, or you build in a software button to jump up a level. Let’s try the latter.

Pretty simple. When looking at an item, we’ll provide a software button that takes us back to the list. Now let’s see everything all together with our revisions:

Now we have an appbar button in both places we have a keyboard, and a “software up” button on both screens that represent the item.

Notice between screens 2 and 3, I remove “software up”. This is a bit of trickery to retain some vertical space. Looks good on paper, but soon we should try it in a prototype to see how it feels in practice.

Email: Kick Ass Performance

Jon said:
Hi Matthieu!

How are you doing? Haven’t talked with you for a few days, so I thought I’d check in :)

Matthieu said:
Hey, yeah sorry, still there :)

I didn’t warn you, my bad. This week end was a long one in France ( I don’t know if may the first is a holiday for you too, but here, I didn’t work since Friday and get back to work on Wednesday).

So I took this long week end to go camping with my boy scouts, it was very fun and we had a great weather.

I took the time to read your latest blog posts this morning though and I began to think about a way to get the search to work in a very fast way; because I think we need some kick ass performance, it is gonna be great!

I will start really working as soon as I get back to work.

Matthieu
 

Why We Won’t Be Using Pivots

Last week I recorded a 90 second clip called The Thing About Metro, where I essentially said “if you know what you’re doing, Metro will set your app apart. If you don’t know what you’re doing, you may get yourself in trouble”.

Pivots are a good example of this. Most people new to designing in Metro dive right into pivots because they’re such a unique and fun feature. But we won’t be using them in our app. Here are a few things to keep in mind with your app:

Think Carousel, Not Tabs
It’s common to port an iOS app to Windows Phone and assume that each tab on iOS should be a pivot in Windows Phone. But because pivots require a swipe to reach, they’re a carousel, not a button. Meaning an app with five pivots (such as the Facebook app) can require up to four swipes to reach an area of the app. This can be frustrating.

Additionally, a pivot control doesn’t show you all the pivots it contains (since they run off the side of the screen), so there’s a bit of guessing involved to find the area you want. In a tab model, you’d read the name of the tab, tap it, and jump straight there. Because pivots don’t offer this, they shouldn’t be used the same way.

Pivots Work Best With Two
Because tabs are more of a carousel model, the best number of pivots is two. This means you’re only ever a swipe away from the other pivot. When done correctly, this can be a very satisfying and quick experience.

Only 80% Cases Should Be Pivots
If you’re designing a screen that’s going to be used very often, a pivot might be perfect. But if you’re thinking of putting an uncommon screen (for example, your “Settings” area) as a pivot, resist the urge. It will make traversing your app a chore.

You should also make sure that all the pivots hang together. Putting two types of functionality side-by-side as pivots often doesn’t work. Use pivots carefully and sparingly.

You Lose Some Real Estate
Pivots take some vertical space, so make sure you’re ok losing those pixels for a navigation control. In my app, where the keyboard will almost always be deployed, losing that space is something I can’t afford.

Pivots Don’t Save State
If you navigate to a pivot, leave the app, and return, you will not be shown the pivot you left on. You’ll be taken back to the first pivot every time.

Let’s say you have an app for reading news articles, and you have a pivot called “Unread”. If you believe most people will prefer that view to an “All” pivot, make sure “Unread” is first, or else people will have to swipe each time they load your app.

Pivots Can Be Great
There are plenty of examples of great pivot usage. But in your own app, don’t assume you have to use pivots just because you’re designing a Metro app. Use them if you’re sure they’ll provide a great experience, but otherwise, consider leaving them out.