Metro App Diary

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. 

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!

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’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 

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 :)
 

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 :)

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.

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. 

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.

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 

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.

Yesterday I explored a few different ways to present search results in the app.

I’ve decided to go with this approach:

The main drawback of this approach is that you’ll do a search (for example, the phrase “feels like”) and the line that will be visible (“Design is not just what”) will not contain the words you searched for. But that’s not so bad. In fact, it’s how Mail’s search works on Windows Phone.

This approach also makes a few other decisions for us, such as using a “hub and spoke” model for reading/editing notes. We’ll discuss that next :)