Designer Silverlight

I’m working on a new project in which I need multiple ListPickers in a ScrollViewer.

The ListPicker is available via the Silverlight Toolkit for Windows Phone 7. If you don’t have it, you should get it. Get the source as well, for reasons that will be clear in one more sentence.

The only problem is that I can’t scroll if I do this because I run the risk of accidentally opening the ListPicker (which should be a tap interaction) when swiping (which is a gesture interaction):

I posted this as a work item on codeplex, so it will probably be fixed in a couple months (sometime in early 2011), but if you’re having a problem with it, do the following:

Open up the source, go to the Microsoft.Phone.Controls.Toolkit project, the ListPicker folder and open the ListPicker.cs file. Go down to the OnManipulationCompleted event and after the line

base.OnManipulationCompleted(e);

add the following conditional for the rest of the code in the method:

if ((Math.Abs(e.TotalManipulation.Translation.X) < 20) && (Math.Abs(e.TotalManipulation.Translation.Y) < 20)){
[Other code]
}

This catches manipulations that are less tap-y and more scroll-y and lets them slide by without opening the ListPicker. If you wanted to be really careful, you could probably change the conditional to 10 or even 5. Most of the taps I checked had pretty small (single digit) manipulation deltas.

One of the things that I’m fascinated with is trying to deconstruct the motion design in Windows Phone 7. I actually came to software design out of multimedia production so I’ve always loved animations in UI design. At some point, I hope to do a series of posts overall on motion design in Windows Phone 7. Actually, I really want to do a talk about Windows Phone 7 motion design at MIX 11. Take note, powers that be.

Anyway, the first step is to get some solid video of the WP7 motion so that I can look at it closely. After 3 cameras and testing a couple different lenses, I got what I think is pretty decent video. Eventually, I’d like to pair these with the XAML necessary to recreate them, but for now I hope it helps someone.

Also, now that I’ve got this process down, if you want video of a particular animation, let me know and I’ll make it happen. Make sure you tell me exactly how to get the animation you want or I might focus on the wrong thing.

E-Mail

Animations: List Item-to-detail animation
Download higher resolution video

Video of e-mail program in Windows Phone 7 from Matthias Shapiro on Vimeo.

Marketplace

Animations: dynamic Button animation, Panorama animation, List Item-to-detail animation
Download higher resolution video

Video of Marketplace App in Windows Phone 7 for motion study from Matthias Shapiro on Vimeo.

Messaging

Animations: List Item-to-Detail animation, cascading list item swivel (in and out), main screen selection animation
Download higher resolution video

Video of Messaging Motion in Windows Phone 7 for motion study from Matthias Shapiro on Vimeo.

Main Screen

Animations: Main screen-to-application list animation
Download higher resolution video

Untitled from Matthias Shapiro on Vimeo.

Main Screen

Animations: Main Screen load in animation, application selected animation
Download higher resolution video

Opening and closing applications in Windows Phone 7 (for motion study) from Matthias Shapiro on Vimeo.

One of the most frustrating things about developing for Windows Phone 7 has been the experience with the application approval process. To illustrate the problems my team is having, let us demonstrate with a theoretical sample application.

Let’s say we want an application for reading all of Shakespeare’s sonnets. There are 154 of them, so we’ll want to break them out, maybe one per screen, allow the user to read them sequentially or jump to a particular sonnet. Maybe we want to be able to search through the sonnets too, just a nice easy way of navigating to that one line we can remember.

Let’s say we have a design that looks something like this (opening page on the left, reading page on the right):

We want the sonnets to be front and center in this app, so we take up the whole screen with them. The buttons at the bottom facilitate a very normal “next sonnet”, “previous sonnet” paradigm for navigating the sonnets. Think of them as discreet chucks of reading material. They’re small enough that it doesn’t make any sense to break them up into a page-by-page groupings (like with the Amazon Kindle apps).

Because of the specific needs of our user, we decide that we want the “back” hardware button to go back to the main page instead of cycling back through the sonnets. Our reasoning is that the user could be reading 10-20 sonnets at a time and we don’t want them to have to back out to the main page with 20 “back” presses.

That’s all well and good until we try to submit out application and we get the following error report.

“Pressing the Back button must return the application to the previous page.”

But in our paradigm, it does. The “reading a sonnet” is one page and the “home page” is another page. For our specific application’s needs, it does what needs to be done. Changing it to pass the Microsoft application process would break our user experience. The situation I described above (reading 20 sonnets in a sitting) would result in the following interaction to get back to the home page:

You may object and say “Why don’t you just put a ‘home’ button in the reading pane?” That, my friend is a fantastic idea. And we would totally do that if it didn’t add the home page to the back-stack. Our navigation scheme looks a little like this:

If we navigate to the home page via a button, we have two choices. We can only do one of the following:

• the button can simulate a “back” press
• the button can use a navigation service and point to the “home” page

Doing the first isn’t an option because, if we got to the sonnet via a search, we would go back to the search page instead of the home page. An inconsistent navigation interaction. Rejected. (And, worse than that, it’s horrible UX.)

However, the second isn’t an option either because if we navigate to the home page, the app will stick the home page into the back stack so that the following interaction:

Results in the following back-stack:

With this back-stack, pressing “back” from the home page would take us to the reader so that we fail another one of the Microsoft user guidelines (pressing “back” at the home page MUST take the user out of the application). We have no way of accessing the back-stack and we can’t programmatically exit the application.

The result? We have no choices. Damned if we do, damned if we don’t.

We have taken a 3 page application that would take less time to create than I’ve spent writing this blog post (and that some people would really like to have) and backed ourselves into a corner due to nothing more than Microsoft’s UX back-stack approval regulations.

We’ll have to build this incredibly simple application a totally different way. A way, I should note, that will confuse the user and complicate something that should extremely easy.

My point here is simple and larger than the issues with the back-stack:

You cannot strictly enforce a specific user experience across all user possibilities.

Each application should know its own users. Each application needs to be able to create a user experience that is specific to its users’ needs . Otherwise, this process will stifle creativity and sap energy. Imagination will fly out the window (pun intended) as the app will be unable to pass the UX guidelines. And users will be poorer for it.

Some of the Microsoft UX acceptance guidelines make sense.  I understand the need for some degree of uniformity in the Windows Phone 7 ecosystem and I’m all for spiking an application that has inconsistent or broken navigation. But I’m working with clients who are getting pretty upset because we made some very common-sense UX decisions that are being spiked by the Microsoft application acceptance process.

Humbly, I propose the following:

• Get rid of most of the onerous back button requirements. - Sure, require that the application provide a consistent “back” experience throughout the application. But outside of that, let the UX designers do their jobs.
• Allow access to the back-stack. - We’ve run into a set of extremely frustrating scenarios where the user ABSOLUTELY NEEDS to use an application a certain way, but doing so messes up the back-stack so that the back button functionality doesn’t allow the app to pass.
• Allow the developer to exit the application. – I’ve seen developers hamstrung with situations like this that could have been simply solved if only they were allowed to exit their own applications.
• Lighten the hell up. – I’m going to speak plainly, Microsoft, and it’s because I love you. You are not Apple. Apple attracted some people who were willing to put up with their approval BS for a long time because they loved the iPhone. And because they were early to the game, they weren’t losing devs to other platforms. Although, you may note, I think they did end up losing devs to Android over time in no small part because Android basically doesn’t want their apps to crash. Outside of that, they let the market decide what is worth keeping and what isn’t.

Regarding the issue of winning over mobile developers, I want to make this as clear as possible:

Windows Phone 7 is, as we speak, losing fantastic applications because of its approval process.

I can’t overestimate how frustrated my clients are with the Microsoft approval process. It ranges from sadness to fury. Clients who are on virtually all other platforms are expressing frustration that they have never had so much trouble getting through an approval process. The rejection reports are inconsistent, spotty, and fragmented. We will submit an app 5 times and get different “errors” back each time. Nine times out of ten, those errors are not errors, but complaints about UX functionality. Of those, at least half of them are complaints about functionality that, if fixed, would worsen the user experience.

I love Microsoft and I love Windows Phone 7, but rejecting apps based on the UX guidelines (while not giving us the tools to abide by the guidelines effectively) is a recipe for suicide.

Click here if you don’t want to hear me complain about the Silverlight toolkit and you just want to get to the animations.

If you are like me, you’re working on Windows Phone 7 applications in your pajamas, subsisting on pork jerky and Coke Zero and dreaming of that one project that will make you richer than your wildest dreams while begging Dell to actually announce some kind of release date for the Dell Venue Pro.

But I suspect that we have less in common. In fact, the only thing we probably have in common is a desire to know how to actually replicate the Windows Phone 7 motion design.

That and our breathtaking good looks.

But back to the motion design. If you download the Silverlight Windows Phone toolkit source code, download and run it, you’ll see some animations that look kind of like the animations on the phone but not really. There are a couple of reasons for this.

Reason #1 – The easing functions have been placed on the wrong keyframes in the toolkit. They should be placed on the second keyframe, but they are on the first keyframe. This, of course, doesn’t make any sense since there is nothing to ease in the first keyframe, so I suspect it is some kind of transcription error.

Reason #2 – The easing function is an exponential one. Not a problem, pretty normal. But its exponent is 15. To give you a good idea of what that kind of “easing” looks like, here is the Blend representation of an exponent 15 easing:

It’s basically like cutting the animation time by two thirds. In contrast, here is the function with an exponent 5 easing:

Much ease-ier (get it?).

OK… enough about the Silverlight toolkit. You want to actually know how to write animations that approximate Windows Phone 7, right?

I currently have no phone, so I can’t study the animations in the closest detail (waiting for the Dell Venue Pro), but here is what I’ve gathered from the Silverlight toolkit and what I can see in the emulator:

“In” animations

When some UI component is appearing, we would use an “In” animation. “In” animations are a shade longer than “Out” animations. I assume this is to help the users’ eyes adjust to the new UI.

To the best of my knowledge, “In” animations:

• are .35 seconds long
• use exponential 5 easing

“Out” animations

When a UI component is exiting (either through navigation or due to the lack of need for it) we use an “Out” animation. Their shorter length leave the user with the impression of speed when they want to get to the next UI.

“Out” animations:

• are .25 seconds long
• use exponential 5 easing

OK… now on to some XAML:

Turnstile Animations:

This is when the screen-wide UI turns on its left-hand edge, such as when the user opens an application.

Turnstile Forward In

Turnstile Forward Out

Turnstile Backward In

Turnstile Backward Out

Slide Animations

We see these animations in things like creating new e-mails. They seem to be used when the user is doing some task that fits within the context of the screen they are already on. Slide animations use an opacity animation combined with a horizontal or vertical animation.

Slide animations use the same .25 seconds on animate out and .35 seconds on animate in and, according to the toolkit, the UI slides 200 pixels in whatever direction it is sliding.

Here is a sample Slide Up and Slide Down animation:

Slide Up Fade In animation

Slide Down Fade Our animation

Coming soon… swivel animations and rotate animations… I’m not totally certain on what I’m seeing in the toolkit. It doesn’t seem to jive with what I’m seeing from the phone. I may wait a few days until I get a phone and can dissect the motion design a  little bit more closely.

I haven’t blogged for a while not because I haven’t had anything to say but because I felt I need time to triage all cool stuff I’ve been learning about Windows Phone 7 Silverlight development. However, one thing that I’ve learned cannot wait. That is support for international characters in the WebBrowser control.

Basically, the problem is as follows: We want to show HTML that uses international characters. The most straightforward way to show HTML in a Windows Phone 7 app is to use the WebBrowser control and the "NavigateToString(string myString)” method to input the HTML.

However, when we hook international text (like Japanese, Arabic, Korean, Russian or Chinese characters) using this method, we get a mess. The following code:

string testString = "<html><body>日本列島の占領の最初の兆候が縄文時代で約14,000のBC、竪穴住居の中石器時代新石器時代に半定住狩猟採集文化と農業の初歩的なフォームから続いて、30,000年頃旧石器文化と登場しました。</body></html>";
BrowserControl.NavigateToString(testString);

produces the following result:

In case you’re not familiar with Japanese, this is not Japanese. This is, instead, the ASCII version of the Japanese characters we want to see. Why does it do this? I’m not sure. But my effort to show the actual international text in the WebBrowser control was met with tears time and time again.

Until I found this post unhelpfully titled “Windows Phone 7 Character Testing…”. Here the author gives us this extremely helpful method for delivering the string we need to show international characters:

private static string ConvertExtendedASCII(string HTML)
{
    string retVal = "";
    char[] s = HTML.ToCharArray();

    foreach (char c in s)
    {
        if (Convert.ToInt32(c) > 127)
            retVal += "&#" + Convert.ToInt32(c) + ";";
        else
            retVal += c;
    }

    return retVal;
}

With this in place, we can very simply run our string through the method to give us properly encoded HTML so that

BrowserControl.NavigateToString(ConvertExtendedASCII(testString));

gives us:

And we’re happy. Very happy.

UPDATE: There are a number of other possible solutions in the comments.

While working on a Windows Phone 7 project I came up against a problem in which the project would crash after we took a picture, giving us the error:

NavigationService.Navigate(new Uri(“/OurView/NextView.xaml”, UriKind.Relative));

The scenario we wanted went something like this: We wanted the user to tap a button and launch the camera task. This would close (tombstone) the application until the camera task was complete (the user took a picture and returned to the app). Upon completion, the application is re-initiated and the camera task hands the application an image stream that we can use to determine the bar code number. We then navigate to a screen that will show all the information about the product the user just scanned.

The problem with this way of doing things is that when we tried to navigate to a new page in our camera.Completed event handler (helpfully titled camera_Completed), we got a NullReferenceException on our NavigationService.

“How could this be?” I asked myself and the Internet. The NavigationService was there when we left. How could it not be there when we got back? The Internet had no helpful answers. Stupid Internet.

As it turns out, the NavigationService doesn’t actually show up in a page until the page UI is fully loaded (or so I have been told). That means that we simply can’t navigate directly from the camera.Completed event because the UI isn’t loaded.

Most other Windows Phone 7 programs with camera tasks we looked at had some additional user input after the task was completed that users would then interact with to handle navigation. We didn’t want that. Once the user took a picture, we wanted them to start getting results without any additional interactions.

Here is our solution for navigating after the camera task (which will also work for navigating after any task):

First, add a property to the page that can determine if the application was initiated after the task.

bool comingFromCamera = false;

Make sure you set this to true in your camera.Completed event handler:

void camera_Completed(object sender, PhotoResult e)
{
this.comingFromCamera = true;
}

Add an event handler for the page loading event  in the page constructor:

public MainPage()
{
InitializeComponent();
// Whatever other stuff you need in here
this.Loaded += new RoutedEventHandler(MainPage_Loaded);
}

In the MainPage_Loaded event handler, check to see if the page was initialized after the camera task or initialized normally. If it was initialized after the task, navigate to your heart’s content.

private void MainPage_Loaded(object sender, RoutedEventArgs e)
{
if(this.comingFromCamera)
NavigationService.Navigate(new Uri(“/OurView/NextView.xaml”), UriKind.Relative));
}

And that should work. Let me know in the comments if you’re having additional difficulties.

I’m currently working on porting the run-away hit mobile application ShopSavvy to Windows Phone 7 (sign up to be a beta tester) and one of the things I really wished I had was the WrapPanel.

(For those who are new to Silverlight/WPF/Windows Phone 7, the WrapPanel stacks UI elements either horizontally or vertically like the StackPanel except that, when it hits the panel limit it… wait for it… wraps and starts stacking in a new column/row. Handy.)

I found a way to add it with the Silverlight Toolkit, but doing that added 140 Kb to my application. Maybe I’m just stuck in the world of J2ME, but adding 140 Kb to my mobile app isn’t OK if I can help it. I found this post from Jeff Wilcox on adding the WrapPanel and that didn’t seem to work for me. (My comments are the whiny ones at the end of the post.)

But I finally got it working and I’ll tell you how.

Or I could just taunt you. That would be fun too.

Naw, I’m just kidding. Here’s the stuff you need.

Windows Phone 7 WrapPanel and DockPanel (Source)

Windows Phone 7 WrapPanel and DockPanel (DLL)

All you have to do is download the DLL, unzip and reference in your app like so:

Right click on the “References” section of your project.

Select the WP7Panels DLL from whatever folder you put it in and see it show up in your References

Open up the “Assets” section and type “wrap” or “dock” the wrap-or-dock panel should show up. Double click it or drag it onto the canvas to add it to your app. Blend will take care of the rest of the namespaces and everything.

And start adding items to your panel. It should work the way it’s supposed to work.

One note with the DockPanel… items placed in the DockPanel need to have the attached property

[xmlns]:DockPanel.Dock=”[something]”

if you want them to do something other than align in the center. The [xmlns] name should be the same thing that is before the “DockPanel” in the XAML. It will most likely be “WP7Panels”. Therefore, the following XAML:

<WP7Panels:DockPanel>
    <Button Content="Button" WP7Panels:DockPanel.Dock="Bottom" />
    <Button Content="Button" WP7Panels:DockPanel.Dock="Top" />
    <Button Content="Button" WP7Panels:DockPanel.Dock="Right" />
    <Button Content="Button" WP7Panels:DockPanel.Dock="Left" />
    <Button Content="Button" />
</WP7Panels:DockPanel>

…should look like this:

If you want to add the actual files to your Windows Phone 7 app instead of just referencing the DLL (perhaps you are crazy or you have a deep and desperate need to fully understand absolutely everything you touch or you are a C++ developer), you can download the source. I’ve consolidated the DockPanel code into a single file (DockPanel.cs), but you’ll need the following files to get the WrapPanel working (all included in the source).

• LengthConverter.cs
• NumericalExtensions.cs
• OrientedSize.cs
• TypeConverter.cs
• WrapPanel.cs

Finally, if you need something else for Windows Phone 7 from the Silverlight Toolkit, you can either add the entire toolkit (explained here) or download the source for the latest Silverlight 3 build and open it in Visual Studio 2010 (for some reason, I couldn’t get it to open in Visual Studio 2008). It should update and you should be all set playing around in there to extract the stuff you need.

Good luck!

In case you haven’t heard this before, this blog is basically a collection of things that I’ve learned and will almost certainly forget unless I write them down. Kind of a public short-term memory overflow. I’ve been working on motion flow design a lot and there is no better way to do motion flow design than to look at cool interface animations.

I’m also doing some Windows Phone 7 design and I want to have a place to go to look at as many videos of Windows Phone 7 in action to figure out how to design an application motion flow that fits with the rest of the app. Watch these videos carefully and notice that pretty much everyone is doing something slightly different for their motion flow. The same navigation concepts are in place, but the motion flow is different for many of the apps.

So… here is my collection of Windows Phone 7 videos and animations.

From Engadget:

(more at the Engadget post)

E-mail on the Windows Mobile 7 Phone

The AP application (by Archetype) (skip to 3:30)

Seesmic for Windows Phone 7 (skip to 6:40)

The marketplace hub

That’s all for me for now… I’ll try to update this with more examples later