Skip to content
Jan 28 16

Return to the Empire

by Brandon

It’s hard to believe that three years have passed since I was here posting my farewell to Microsoft. In early 2013 I ventured out into the big world of startups, and life has been a bit of a rollercoaster ever since. First I took on some fun projects of my own. I built a unique news app + service called Newseen, a little game called Cattergories, and then made Tweetium – a Twitter client that became the most popular third-party client in the Windows Store (and has been on the Top Paid list for over a year). After a year on my own, I joined a very early stage startup, where I spent more than a year and a half building the Zealyst web+mobile app.

Over the last three years I tried a lot of new things. I tried some things that worked out well. I tried a bunch of things that didn’t work at all, but which I would like to try again someday and do better. I also tried at least a few that I will do my best to avoid at all costs. I consider all of these valuable experiences. I’ve learned a lot, and found that there’s always more to learn.

I learned that building a business is hard, even with a great idea and a passionate, creative team (and even if you have some great customers who want what you’re offering). I learned that raising money is hard. I saw firsthand some of the unique challenges faced by women founders like ours, and many more challenges which I’m sure most startups face. I learned that stretching yourself too thin can take a real toll on mental and physical health. I learned the excitement of making a big sale, the thrill of deploying a brand new homegrown service to real users for the first time, the anxiety of patching problems in production, and the heartbreak of cultivating business relationships for months only to see them fall through due to reasons beyond your control. I learned the importance of having a strong, caring, supportive team – I am eternally grateful to have found that. And I am very, very proud of what we built together.

It’s easy to look back and focus on things I could’ve or should’ve done but didn’t (e.g. traveled more, ported Newseen to iOS and Android, spent more hours on Zealyst, been more or less involved in business strategy or fundraising, moved to Hawaii, etc). On the other hand, these last years have brought me new friends, new skills, new perspectives, and I think new self-awareness. While I relished the freedom, potential, and challenge that came with building a new business, I also came to long for the impact that I had when I worked on software used by a billion people. Further, I’ve missed being part of a fully-funded team of developers (and Program Managers!). They say you never fully appreciate what you have until it’s gone. PM friends, consider yourselves fully appreciated 😉

Over the last few months, we’ve been winding down Zealyst operations as the company (at least in its current form*) comes to a close. This has afforded me some time to do a little bit of traveling, relaxing, soul searching, and exploration of what I might want to do next. I’m incredibly grateful to be in a position where great options are plentiful. After a lot of consideration, I decided that the right next step for me is to take what I’ve learned these last few years and apply it in a place where I know my passion and level of impact are strongest.

As you’ve probably figured out by now, I am excited to announce that I have accepted an offer to return to Microsoft. Starting next week, I will once again be a developer on the Windows Shell team. Over the past couple of months I’ve discovered a Microsoft and a Windows team which is both familiar and yet substantially reinvented. They’ve begun the incredible task of changing Windows into a new kind of OS-as-a-service, which is a change to the development process and culture as much as to the code and how it’s delivered. I am very impressed with the progress they’ve made over the last couple of years, and even more impressed with the ambition to bring the best parts of the mobile + cloud delivery and user engagement models to all Windows devices. I can’t go into specifics at this time, but suffice to say that I believe the team I’m joining is crucial to this effort, and that it’s a compelling time and place to apply my strengths and experience.

I’d also like to thank everyone who’s given me advice, offered a variety of compelling opportunities, or welcomed me back into the Microsoft fold. I am immensely grateful for all of this. To all my Microsoft friends and colleagues, I’ll be seeing you around campus soon!

* = If you’d like to know more about future Zealyst developments, I suggest following @Zealyst on Twitter.
Nov 8 15

There is no mobile ecosystem

by Brandon

This morning I saw a snippet of a new blog post by Benedict Evans (of a16z) float by on Twitter that made me scratch my head. It posited that while the iPad Pro and Surface Pro “look similar”, the former is part of an innovative new “mobile ecosystem” that is on the rise, while the latter is the dying breathe of a withering PC ecosystem. I called BS.

Why? Because there is no mobile ecosystem.

The PC ecosystem is real. For decades now it has had Microsoft and Intel at its center. Orbiting them were Windows software developers, IHVs, and PC OEMs – the latter fighting over customers and spewing out dollars, most of which were sucked in by Microsoft and Intel’s immense gravity. In the early 2000s this system was growing rampantly, and was stable enough to weather storms like a string of much-publicized security problems, and the drunken stumblings misteps of the Longhorn/Vista years.

However, as time went on, and complacency set in, things started to wobble a bit. As innovation in this system essentially stopped, demand for new PCs started to slow, and OEMs started driving down prices and building more and more “disposable” machines. Then a disastrous thing happened. Apple introduced the iPhone.

Almost over night, software developers (who had become bored and disillusioned by all the unrealized promises of Longhorn) turned their attention to this entirely new category of devices. Apple didn’t even have a public native app platform, so developers created the first mobile web apps and frameworks, and then began hacking and reverse-engineering Apple’s internal API set. Apple didn’t provide an app store, so developers built their own. Thus began the emergence of the Apple ecosystem.

Apple saw the fragility in the PC ecosystem and wanted no part of it. They already built the OS and the hardware, and soon decided they’d like to control even more. They even figured out how to exert unprecedented control over the cell carriers. However, that first iPhone showed that independent developers were not something they could ignore (as they did with the iPod, for example). So what did they do? They offered those developers a tight leash from the very beginning, with an institutionalized flow of cash to the mothership included for good measure. You would only sell apps and content through the App Store. You would only develop your apps using a Mac. You most definitely would not build anything that Apple felt threatened by, or use a technology they deemed inadequate. And you would give Apple a third of your income and thank them for the privilege.

The mobile smartphone market is clearly critical to the Apple ecosystem. It’s where they first got traction, because they basically invented it and had no (meaningful) competition early on. But even with the iPad included, mobile is the beginning, not the end, of the Apple ecosystem. They’ve leveraged it (in a very 90s Microsoft way) to get the vast majority of developers onto Macs. This is really important. It creates a very difficult-to-break feedback loop. There’s significant resistance to breaking developers away from the Apple ecosystem because the Apple ecosystem is where devs *live*, even if they try an Android phone, for example.

Apple is pushing to extend this thriving ecosystem into new markets like TVs/set-tops and wearables. The iPhone is the center of gravity in Apple’s ecosystem, and their other products revolve around it. The Apple Watch requires one. The Apple TV is meant to work with one. Macs are required to develop for one. But what Apple has never had any desire to participate in is a mobile ecosystem. Perish the thought.

Now that bit from Benedict’s post that caught my eye was about the iPad Pro. So where does that fit in? I don’t think the iPad Pro is a product Apple came up with to expand their ecosystem. I think it’s a bulwark against the Surface (and similar modern tablets/PCs) encroaching on their Mac (and to a lesser extent, iPad) business. It might get traction in some nice niches/verticals, but I think its primary purpose is defending their ecosystem, not expanding it.

Google isn’t cultivating a mobile ecosystem either. They’re cultivating a Google ecosystem. The mobile part of that ecosystem is also strong for two reasons:

A) Price. Or in more words: They played the Windows game of old and let OEMs race to the bottom, flooding the market with cheap Android handsets. Except they didn’t care about extracting profit because at that time phones were not an important part of Google’s ecosystem.

B) Carrier support in the early days from everyone who wasn’t AT&T and were desperate to be in the smartphone space. Apple got too comfortable and took too long to address this, which gave Android a larger in than they might’ve had if Apple had broken carrier exclusivity sooner.

Originally, the center of Google’s ecosystem was search. They had content publishers and advertisers orbiting their search advertising behemoth, and projects like Android were just meant to feed and protect that lucrative system. Times change, though, and so have Google’s priorities. Where they once saw devices as Amazon does (places to offer their goods and services), they seem to be increasingly seeing devices (and Android in particular) as the center the Google ecosystem, with their services orbiting Android the way Apple’s watch is tethered to the iPhone. This is probably less a matter of their desire, and more a response to competitors. Apple, Microsoft, and Amazon are all reorganizing their businesses around a model that puts them at the center of their own ecosystem. Ecosystems which are much more self-sustaining than the PC ecosystem of old.

That brings us to Microsoft. Initially they were either oblivious or in denial as to ecosystem amassing around Apple. Later, they saw Apple raking in cash with their model, and Google “succeeding” with Android using the old Windows/PC model (sans the profit), and said “let’s do both of those things!”. In phone land, the result was a handful of third-party Windows Phone devices that all had identical components. With no ability to make competitive deals with component vendors, and hamstrung waiting for Microsoft to release new device class specifications, none of these OEMs stood a change of competing with Apple or Google’s partners who could do whatever they wanted. They had no userbase to offer to developers, and a severely limited platform built on, no joke, Silverlight. They even wanted to imitate Apple so badly they bragged about leaving out copy-and-paste from the first release of Windows Phone 7. That’s how seriously these people took mobile.

On the PC side, they took a slightly different approach. Being like Apple meant spinning up an in-house hardware unit to build the Surface. At the same time, they also tried the Windows Phone model of building detailed ARM device specifications and “permitting” a few vendors to build virtually identical devices. Oh, and they also tried letting other OEMs roam free on Intel hardware. Cynically I call this the “have your cake, eat it, and sell it back to them too” approach. You could also consider it the “try everything and see what works” approach. Neither conveys a high degree of focus.

To their OEM partners, this was all an experiment, an attempt to establish a “premium” tier and to motivate and inspire those partners to innovate. In reality, whether the original intention or not, this was the beginning of realigning the PC solar system. If this was the plan, it was sort of brilliant. Microsoft saw the PC ecosystem slowly collapsing, and began preparing itself for a new universe where it would need to take on a different role, with Windows at the center of an ecosystem surrounded by hardware of all kinds (including servers in an Azure datacenter). All the while keeping PC OEMs feeding them while Microsoft prepared for their inevitable demise.

Whatever the plan was back in that Windows 8/RT timeframe, the execution, obviously, did not work out so well. The real sin wasn’t the failure to burst into the mobile market, but that in doing so they destabilized the strongest part of their ecosystem at that critical moment. It’s taken years to even begin undoing that damage. In the long run maybe this will turn out to be a growing pain. Or it may turn out to have been a crucial misstep from which they’ll never recover.

In fact, I’d attribute the Windows 8/RT disaster to exactly the kind of thinking that Mr. Evans shared in his post. That’s how you get to the idea that those 1.5bn PCs in use, and the ~0.4 billion a year sold, don’t matter, and that it was “okay” if they all stayed on Windows 7. Because all that matters is some non-existent “mobile ecosystem” that everything needs to immediately be a part of. So why not bet the company on it?

It turns out, however, that mobile didn’t eat the world. PCs (at least in the traditional sense) may not be a growth market, but they are a crucial part of Microsoft’s ecosystem, and will be for some time. Mobile is a growth opportunity for them. A huge one. But succeeding there these past few years was made so much harder by the disarray of their existing ecosystem.

That brings us to today. Microsoft’s ecosystem is showing signs of stabilizing, with the Surface Pro 3 and now Windows 10 providing some much-needed energy and positivity in their PC business. The cost of this is clear: Microsoft has all but entirely exited the mobile market over the last year or two. Whatever little progress they’d made with Nokia and WP 8.1 was left to evaporate while the company fixed PCs. Sure, they have promised two new flagship Lumias before the year comes to a close. But everyone paying attention can see that these are (far too late) stopgaps while they “retrench”. The excitement their new head of hardware had for these at the announcement event was… was… what’s the opposite of “palpable”?

That’s not to say they’re giving up on mobile. Not at all. But it’s going to take more than competitive devices and a competitive platform to make a dent in that market. It’s going to take a Microsoft ecosystem firing on all cylinders, with attractive offerings for customers and developers. Developers are the hardest nut to crack. And they are absolutely not looking for a new mobile platform to support.

So what is Microsoft doing to win developers today? A few things:

  • Aggressively courting them with Azure.
  • Taking a leadership role in the evolution of the web’s technology and standards.
  • Creating the small beachhead that is Visual Studio Code (free open-source code editor for Mac, Linux, and Windows).

Notice I didn’t even mention “building a modern, universal platform”. They’ve done that. But without users or the opportunity to build something new and unique, this means nothing. It’s a prerequisite for success, not a strategy.

What can they do? I look at the problem three ways:

  1. Bring all your users to the table. They don’t have a meaningful number in mobile. But they have 130+ million on Windows 10 PCs, and it’s a fair bet they’ll march that number of up to a billion over the next few years. Find ways to get these users buying apps, and you’ll attract developers. They know this. They’ve just struggled to figure out how. Windows 10 is trying some new tactics here that they’re going to be dialing up a bit soon, and I hear early indications are that they’re having some success with this (meaning more users are buying apps on from the Win10 store). But just driving users to the store isn’t enough. They need to encourage a PC app renaissance, and I have a bunch of ideas for how to do this (perhaps for another post).

    Also, adding in 15 million and growing Xbox One users who love to spend $$ into the mix will not hurt.

  2. Let developers do something unique. This is what drew developers to the iPhone, and Apple is actually really great at this. HoloLens could be a long-term play for this, but that’s clearly not enough. Kinect might’ve been a big missed opportunity here, and Xbox might still be the key place to pull it off. That’s because letting developers do something unique generally means giving them unique hardware to play with.
  3. Find developers where they live. Microsoft is really strong at developer tools. Apple is kind of atrocious at them. So what’s the opportunity here for Microsoft? Here’s a bold vision they could adopt:

    Make Microsoft’s tools be the best way to build an iOS app.

    What could that look like? Here are some more specific ideas:

    1. Make the Surface Pro/Book the best device for building iOS apps. Make Visual Studio into the best Objective-C and Swift IDE. Make the best emulator experience (newsflash: it doesn’t even need to run iOS!). Provide the best cloud-based build environment (a la PhoneGap Build) running on some Macs in a Microsoft datacenter, to get around Apple’s licensing restrictions.
    2. Make Windows 10 on a Mac the best iOS development experience. Buy up Parallels, and give developers a VM with Windows 10 and Visual Studio to run on their Mac. Make some awesome plumbing so that VS can connect across the VM host to the iOS emulators and build tools in OS X. Bring the game to Xcode’s home turf and crush it.
    3. Build a full Visual Studio iOS development experience for OS X.

I really like the second option there, actually. It’s technically doable. Apple would be powerless to stop it. You could make developers love Windows without them having to give up their Mac. Then later you show them why they’d love it even more on a Surface with a touch screen (those phone emulators really light up when you can, you know, touch them).

Is this a plan for cracking the “mobile ecosystem”? No. It’s a plan for attracting developers into the Microsoft ecosystem. Once they’re there, Microsoft will have a way easier time directing their attention to mobile.

Jul 4 15

My to-do list for the Edge team

by Brandon

I’m very excited about Windows 10’s new default browser, Microsoft Edge. The team over there is killing it when it comes to performance, web standards, and interoperability. It also looks great in the new black theme (though I think the default white/gray one is super drab).


That said, in its current Preview form it is clearly not a finished product. With only a few weeks left until its first official release, I wanted to share my list of things that I feel are missing. So here’s my list of basic browser UI must-haves that are currently missing, as of 7/4/15 with build 10162:

  • New Window from the task bar
    • First, right-clicking the Edge icon and then selecting the “Microsoft Edge” entry should launch a new window, as it does with virtually every other multi-instance Windows app (including IE).
    • It also wouldn’t hurt to have explicit “New window” and “inPrivate” buttons here (IE had the latter, and Chrome has both).
  • Save As / Save Target As…
    • Currently, file downloads always go to the Downloads folder and always with whatever name the server provided (or the browser calculated). This is unacceptable for oh-so-many situations.
    • IE provides (as other browsers do) a context menu option on links to save the target with a different name and in a different location. IE also provided a “Save as” option in the info bar that asked whether you wanted to run or save a file.
  • Jump list integration
    • Edge currently has no Jump List on the task bar or in Start at all. This should have frequent sites listed for easy access and pinning.
  • Back-button history menu
    • There’s no drop-down or right-click menu on the Back button with the last N locations. I just hit a common problem where a redirect or JS bug on Audi’s site trapped me from going back. In IE I could right-click on Back and get the list of the last 5 or 10 pages, so I could skip past the trap or broken page to where I wanted to be.
  • “Undo close”
    • Or some way to get back to an accidentally closed tab. IE had this in the New Tab page. It could go there or in the menu. Right now the best I’ve found is to go History, but it’s actually pretty annoying to do that because History isn’t sorted by when tabs were closed, and if I have a lot of tabs open it can take a few minutes to figure out which history item is the thing I accidentally closed.
  • Deleting address bar history
    • In IE, if you mistype a URL (say “” instead of “”), or otherwise have something in your address bar auto-complete that you want to clear, you can just arrow down to it and hit the DEL key and it’s gone.
    • Maybe this wasn’t discoverable, and maybe a UI affordance for mouse, or a hint, or something should be added, but in the meantime, at least enable the DEL key to work like it did in IE.
  • Drag-and-drop
    • Dragging files from Explorer to upload them to various sites doesn’t seem to work. I’m guessing this is just a bug but figured I’d note it here.
  • Download manager
    The IE download manager, while not perfect, was better in a lot of ways, including:

    • Background downloads. Edge seems to terminate downloads if you close the browser window (and with no warning). Not cool.
    • Separate window. Having the download manager in a separate window was very useful to me. For one, I could put it on a separate monitor to watch the progress of downloads. This also helps with the background download issue I mentioned.
    • Actions and details. The IE download manager would let you delete files, show you their size, see the full URL when you hovered on the domain, or copy the download link.
  • Taskbar pinning
    • I’m not expecting this for RTM but I miss it dearly and it leads to me still using IE for many tasks. I really hope that if it doesn’t come now, that it comes in an update in the next few months.
    • Some examples of pinned sites I have:
      • Work team site / doc library
      • Work project management site
      • Windows dev centers (one taskbar icon that open both Windows and Windows Phone dev centers)
      • On my home desktop I have a taskbar entry with 4 home page tabs, for my banks and financial accounts.
      • Facebook
    • In addition to providing quick access to these (especially useful for the ones with multiple home pages), IE’s pinned site mechanism really helps by “gloaming” these windows and tabs together on the taskbar (and giving them different icons in Alt+Tab and such). This makes it so much easier to keep my tasks organized versus any other browser I’ve tried.
  • Oh, and this one is more minor I guess, but please kill the splash screen min-show timer. One of my gripes about Windows 8 was the really just awful decision redacted made to always show a splash screen on every modern app for a minimum length of time (which I think was something like 650ms or more plus a long cross-fade). It feels like maybe this has been shortened, but not enough in my opinion. On a decently fast machine, many apps are able to draw their UI fast enough that this should never be shown. I’m betting Edge on my SP3 would usually fit into this bucket, but instead I’m looking at a bright splash screen for half a second (and the OS is wasting cycles creating and drawing it) when I’m pretty confident there’s no reason for it.
    • Of course, this situation could also be improved if apps were able to dynamically determine their splash screen image and/or background color (e.g. for the next launch). Then the launch could be a lot more seamless with a theme-appropriate background and loading UI that would transition more smoothly to the Start page.

I left off Extensions as we know that’s coming later this year. And while I’m looking forward to them, they’re actually not a critical part of my daily browsing experience, whereas several of the items above are.

Sep 25 14

Why in-process OAuth is not a security vulnerability

by Brandon

A couple days ago a post by Craig Hockenberry made the rounds, leading to many blogs latching onto it with sensationalist headlines like “Developer warns of yet another big iPhone security flaw” and “In-app browsers are insecure: use Safari for sensitive browsing”. Never mind the completely inappropriate platform-specificity of these claims, the main question is… are they right?

In short, no. There’s no news here. It’s sort of like saying, “iPhone text input control is vulnerable to key logging!”. It’s just silliness. Yes, anything you type into an app is received by that app. No, this should not surprise anyone (*especially* developers!).

Here’s an exercise. Find a non-technical user, have them open an app which uses in-process OAuth (let’s say, Tinder), and ask to whom they’re giving their password (in this case, their Facebook password). How many would say anything other than Tinder? Is this a security problem? Of course not, this user trusts Tinder not to misuse their credentials. They don’t really know or care whether Tinder uses in-proc or out-of-proc OAuth. Their eyes would gloss over if you even posed the question.

Does out-of-proc OAuth have to mean launching a browser? Nope! On iOS it might. On Windows and Windows Phone, the WebAuthBroker API provides a way to do this which presents a dialog (running in a separate executable) on top of the app. That dialog then hosts the OAuth page and provides a way for the app to receive just the parameters passed to the OAuth callback URL.

Does this make an app that uses the broker (or the ridiculous Safari gymnastics which requires the user to copy and paste a code) more secure? No. Well, very very marginally. Hypothetically, if the app has a code injection vulnerability, the out-of-proc auth may protect your credentials. The chances of an app you use having such a vulnerability (which can be exploited *before* you enter your password – something most OAuth apps do on first launch), with a website the attacker knows you’re going to log into, before the app is updated to fix the problem or kill-bitted by the store, is pretty darn low. And even without this theoretical attack vector, an app with this kind of independent vulnerability can already do significant damage. You’re actually *more* likely to be affected by an exploit against Safari. Or against an app which takes your credentials directly, like the official Facebook app, for example. They’re just much more tempting targets than some small rando developer app using OAuth.

(I’m going to gloss over my suspicion that the WebAuthBoker dialog and the app’s input queues are tied since it’s almost certainly an owned window – maybe someone thought of that, but I didn’t CR it and the number of people I’d trust to catch that is small)

Why does Windows offer the WebAuthBroker then? Truthfully, the main reason that I know of was that the original Win8 release didn’t have WebView support for JS apps (which constitute most of the in-box apps like Mail, People, and the Bing apps). Without that, the only way to embed a web page was with an iframe, and most OAuth pages intentionally don’t support iframe hosting. So why did Win8.1 add WebView support to JS apps? Because installing an app is an indication of trust beyond that of browsing to a random website. Apps are installed. They’re sandboxed, yes, and user confidence in being able to try apps is important. But just as you shouldn’t type your bank info into a finance app you don’t trust, you shouldn’t type your Facebook password into one either.

Now for a very important question: Does the WebAuthBroker or Safari gymnastic routine mean you can type your password into a dubious app? Abso. Lutely. Not.

Why not? Well, first and foremost, we’re talking about opt-in mechanisms. A malicious app developer isn’t going to opt-in. A trustworthy developer like Craig opting in does not make *his* app meaningfully more secure. And it certainly doesn’t make anyone else’s safer to use!

What if Apple made out-of-proc OAuth *required*? Well, assuming they created something like WebAuthBroker so that the UX didn’t utterly suck, this would still be a logistical nightmare. You’d need some crazy well-trained reviewers to detect that an auth experience was truly out-of-proc, and how would you distinguish these from first-party apps with native auth fields (like your run-of-the-mill official Twitter and Facebook apps), or handle apps with built-in navigable browser controls (like news readers), or apps which turn on this functionality remotely after being approved? Or hell, a third-party browser like Chrome, or a password-management app like 1Password? The answer is simple: You can’t.

What if users were trained to understand the difference between in-process and out-of-process separately-sandboxed auth?

Hahahahahahahaha. You’re a funny one.

No seriously, what if you did? It still wouldn’t help. An app can spoof any of these interactions (the OS WebAuthBroker pop-up, or even the Safari app switch), trivially. Yeah, if you’re an advanced user who is *really paying attention* you could probably catch the spoofing. If you could train regular users to be this attentive and skilled at discerning spoofed app UI (particularly on devices where apps own every pixel of the display!), the world would indeed be a vastly safer place. And unicorns would dance in the streets, farting rainbow clouds of life-giving pixie dust. Good luck bringing that about.

Oh, and lest you think you’re getting off easy, you don’t just have to solve spoofing of the out-of-proc UX (whatever form it takes). An attacker can just as well spoof the actual web form (having Safari or WebAuthBroker host or which looks just like twitter’s login page). So you have to train the user or the app reviewer to detect *both* of these cases. The WebAuthBroker doesn’t display the URL or domain *anywhere* (which the IE team would not have let fly, but they didn’t own it), and last I knew Safari lets web sites hide the address bar (which IE at least explicitly shows on navigation).

So what should be done? Mainly: People should not give private information and passwords to apps they don’t trust. If they become suspicious of an app they’ve given such info to, they should change their passwords immediately. App stores should monitor reports of such apps and revoke / kill-bit them, and ban the publishers. And you know what? That’s exactly what they have been doing for years. Is there a big attack being carried out against iOS users? Or users of any mobile platform? Not that I can find.

So what’s the appropriate news headline? So far as I can tell, none. If it’s a slow news day, maybe “Apple doesn’t certify apps which make you do unnecessary app switching gymnastics to log in”. Would have to be a pretty slow news day, I’d think.

May 15 14

My new Zeal

by Brandon

zeal  (zēl)

n. Zeal of zebras: zebras collectively.

Today is a very exciting day as I finally get to share some big news I’ve been keeping under my hat for several weeks now. As of early this month, I’ve accepted the role of CTO at Zealyst.

I met the founders of Zealyst last Fall and was immediately intrigued by what they were doing. At the time, they were solving some really interesting problems for large enterprises using a combination of some custom software and live events called “huddles.” At the same event, Martina and Britta saw me demo Newseen. Apparently we began keeping tabs on each other, and a short while later I saw them announce that Zealyst was pivoting to a more technology-focused SaaS model, with the goal of creating an online version of the huddle experience.

Earlier this year we met for lunch where they told me all about their plans for the company, and their excitement for the new direction was infectious. At first I thought it would be fun to help out as a technology advisor or some similar capacity. My first advice was essentially this: “You need to find a technical leader who will be as dedicated as to what you’re doing as the two of you.” I walked away trying to think of anyone I could send their way. It was a killer opportunity so surely there’s someone I know who would fit in.

Then it hit me. They already knew that’s what they needed. The real question was: am I the right person to join them and help make their vision a reality. Since you’re reading this post, you can probably guess how we answered 🙂

Zealyst leadership team

At the GeekWire Awards with Zealyst founders Britta and Martina

I am incredibly excited to be joining such a wonderful team with a super compelling vision, and to take on the challenge of building a new product and engineering team from the ground up. I also want to give a special shout-out to Buzz Bruggeman, the master networker who arranged the event at which this journey began. He seems to have a knack for this sort of thing. If you ever see Buzz at an event, introduce yourself. You won’t regret it.

What’s next? Well, there’s a ton of exciting Zealyst news in the pipeline. I’ll be writing about it here, but Twitter is the best place to keep up (follow me at @BrandonLive  and the company at @Zealyst). I can’t wait to share all of it with you, so stay tuned!

In the meantime, you may want to check out:

Zealyst Blog – Meet Brandon, our new CTO!


A note about B-side Software and Tweetium:

I know some of you are asking: What does this mean for Tweetium, Newseen, and B-side Software in general? First let me say they are not going away, and I will absolutely be supporting these apps and even investing in Tweetium going forward. But there’s no beating around the bush here, the vast (vast) majority of my time is now focused on Zealyst. I do still plan to ship Tweetium for Windows Phone 8.1. However, I can’t currently offer an ETA for that.

I am sorry for any disappointment this causes, and my appreciation for all of Tweetium’s supporters knows no limits. But the reality of the situation is that a third-party Twitter client is by its nature a side project, and startup life sometimes leaves little room for those. Hopefully you know how much I love the Tweetium community and working on it, and how anxious I am to have it on my phone. So it’s just a matter of time before that happens. To keep up to date with the latest Tweetium developments, be sure to follow @TweetiumWindows.

Thank again for all your support!

Mar 14 14

Updates to some WinJS helpers

by Brandon

I’ve just posted important updates to two of my WinJS helpers.

Fix for dispose() in WinJS Control Template

The first is the WinJS Control template from my last post. I discovered a bug in the version I posted which prevents the dispose method from being called. This is because of some quirks to how the WinJS markDisposable and WinJS.Binding.Template code works. The fix I’ve implemented for now isn’t quite as pretty as I’d like, but it works well enough. I may look for a better option down the road, or feel free to suggest one!

For now, I fix it to ensure both versions are called via some simple monkey-patching. Here’s the relevant code snippet from the updated version of the template:

        this.initPromise = loadControlTemplate().then(function () {
            that.element.className = controlTemplate.element.className;
            // Unfortunately the template code ends up overriding our dispose method.
            // We'll monkey patch it here and ensure both are called.
            that._classDispose = that.dispose;
            return controlTemplate.render(options.dataSource, that.element).then(function (element) {
                that._templateDispose = that.dispose;
                that.dispose = function () {
                that.controlInitialized = true;

The result of this is that your dispose implementation (on the class) and that of the template both get called as expected.

Updated HttpClient wrapper

In my use of the HttpClient wrapper I posted a while back, I discovered a few problems and opportunities for improvements. This helper currently lives on GitHub in a Gist post, so you can see the changes I’ve made here.

Feb 19 14

Building Great #WinApps: Custom WinJS controls

by Brandon

I like to segment the UI components for my WinJS projects into controls, and organize them in the codebase as separate HTML/JS/CSS files. Controls encapsulate functionality and provide an easy way to reuse code throughout a project (or between projects!).

First, let me describe a few relevant facilities that WinJS provides:


The WinJS.UI.Fragments namespace provides utilities for loading fragments of HTML from separate files and rendering them into your DOM tree. Its capabilities include caching fragments in advance of their usage, and rendering copies as needed. On WinRT capable platforms (i.e. Windows 8) it will use an optimized path for loading these fragments versus other cases (i.e. running in IE, or another browser/platform).


The WinJS.Binding.Template namespace allows you to use a block of HTML as a template for new block. This is similar to the templating facilities in other JS libraries. Rendering a template is a lot like rendering a copy of a fragment and then running WinJS.Binding.processAll on it. However, it’s more efficient than that, especially in WinJS 2.0 with its template compilation feature.


WinJS also provides WinJS.UI.Pages.PageControl, which essentially builds on the Fragment Loader and adds some functionality. In particular, it integrates with the navigation functionality from WinJS.Navigation and the Navigation App template. You can also use this to create custom controls, which you can then instantiate programmatically or declaratively.

I find PageControl to be reasonably useful for actual pages, which makes sense given the name. However, MSDN also suggests this is the preferred way to implement a custom WinJS control. This is how I originally implemented controls in my apps (and some less often used ones still are this way). It certainly works, but there are several ways in which it is not ideal.

One nice thing about PageControl is it has a handy VS Item Template, which makes it easy to create a matched set of HTML, JS, and CSS files in one go. And they’re pre-populated with some boilerplate code. As we saw in my last post of this series, most of this is cruft you want to delete anyway.

Downsides (beyond the template cruft) include:

  • There are tricks to getting the Fragment Loader to cache a page fragment (because of differences in the URL format).
  • PageControl doesn’t use the WinJS template infrastructure, and thus misses out on the compilation benefit, which is valuable if you’re using many instances of the control.
  • The PageControl pattern, and the idiosyncrasies of its methods (i.e. render vs ready, when things are sync vs async, etc) can take time to master and even then are sometimes confusing.

My control template

To enable the convenience of creating those 3 files all at once I decided to create my own VS Item Template. I went a bit further though, and replaced all the boilerplate code with my own pattern. It leverages the Fragment Loader and the Template infrastructure, but doesn’t use PageControl at all.

Using the template

Once the template is installed, you use it like this:

1) Right-click on the folder where you want the control files to live.

2) Go to Add -> New Item.


3) In the dialog that comes up, select “Bside WinJS Control”.

4) Give the control a name and click “Add”.

Add New Item dialog - B-side control template

What do you get?

When you create a new control using the template, you’ll get three files just as with the Page Control template. In this example case, I’m creating a new “JokeTile” control for use in the Chuck Norris Joke DB app we started creating in the last post.

HTML file

The HTML file is a lot simpler than the one in the Page Control template. There is, however, one action item here. This template doesn’t try to mimic PageControl’s ability to reference the control by the URL of its HTML file, and this means the control’s JS file must be included before you can instantiate the control. The control’s HTML file will have a reference to the JS file, but you’ll want to cut and paste this to either the page(s) referencing the control, or your default.html file. The latter is preferable if the control is used in your usual app startup path.

<link href="JokeTile.css" rel="stylesheet" />
<!-- TODO: Move the below script reference to controls/JokeTile/JokeTile.js from this file to any page that references the control,
           or to default.html if this control is used during normal app startup (to get bytecode caching) -->
<script src="/controls/JokeTile/JokeTile.js"></script>

<div id="JokeTile-template" class="JokeTile win-disposable">
    <p>Control content goes here</p>

Anything you add to the template div will become part of the control. Any data binding directives you place on it will be populated by values from the “dataSource” property of the options parameter passed to the control’s constructor (or set via data-win-options, if the control is constructed declaratively).

CSS files

Our control has no default styling at all. But presumably you’ll want to add some sort of styling to the control’s root element, so I pre-populate a place for that.

.JokeTile {

JS file

The JS file is where things are really interesting. There’s actually a good deal more code here than the built-in Page Control template. But I think you’ll find it useful.

(function () {
    "use strict";

    var controlTemplate = null;
    var templateInitPromise = null;

    // This will load and cache the control's template.
    // This happens the first time an instance of the control is created, or when you call JokeTile.cacheControlTemplate
    function loadControlTemplate() {
        if (!templateInitPromise) {
            var controlFragment = document.createElement("div");
            templateInitPromise = WinJS.UI.Fragments.render("/controls/JokeTile/JokeTile.html", controlFragment).then(function () {
                controlTemplate = new WinJS.Binding.Template(controlFragment.querySelector("#JokeTile-template"));
                controlTemplate._renderImpl = controlTemplate._compileTemplate({ target: "render" });
        return templateInitPromise;

    var JokeTile = WinJS.Class.define(function (element, options) {
        var options = options || {};
        this.element = element || document.createElement("div");
        this.element.winControl = this;
        WinJS.UI.setOptions(this, options);

        this.controlInitialized = false;
        var that = this;
        this.initPromise = loadControlTemplate().then(function () {
            that.element.className = controlTemplate.element.className;
            return controlTemplate.render(options.dataSource, that.element).then(
                function (element) {
                    that.controlInitialized = true;
    , {
        _initialize: function () {
            // TODO: Control initialization

        ensureInitialized: function () {
            return this.initPromise;

        dispose: function () {
            // TODO: Control clean-up
            this._disposed = true;
        cacheControlTemplate: function () {
            return loadControlTemplate();

    WinJS.Namespace.define("Controls", {
        JokeTile: JokeTile,

The gist of all this is that you have a new control which:

  1. Can be instantiated programmatically or declaratively (using data-win-control and WinJS.UI.processAll).
  2. Uses a compiled template, which is particularly valuable if you instantiate many instances of the same control type (i.e. for use as a list item, for example).
  3. Has only useful markup and code.
  4. Implements the dispose pattern.
  5. Allows pre-emptive loading and caching of the control’s files and compiled template.

If you see a good way to improve any of this, please post in the comments section below!

I’ll cover basic usage of the template in the next post, where we’ll implement the JokeTile for our Chuck Norris Jokes app.

Download the template

The template will become part of my own extension library for WinJS, which I’m in the process of putting together. For now, you can get just the template here:

My WinJS Control Template


Feb 7 14

Seattle Municipal Court is a joke

by Brandon

/Begin rant

The day after Christmas, I tweeted a picture of a parking ticket I got, along with the parking receipt I was paying for at the same time. Obviously I found this kind of ridiculous and didn’t want to pay it. I tweeted the picture to @SeattlePD who responded and said I should contest it.

I knew that the time it would take would not be worth the $44 I’d save by avoiding the fine. But the principle of the thing drove me nuts. So what did I do? I responded "Not Guilty" and then when I received the hearing date, I mailed back the "contest by mail" form.

Sadly I didn’t keep a copy of the letter I wrote on the form. Here’s a recreation from memory:

On December 26th at around 10:15AM, I parked my vehicle on Wall St. between 5th and 4th avenues. I paid for a little over an hour of parking and place the receipt sticker on the inside of the curbside window as prescribed. As the hour passed, my plans changed and I decided to stay in the neighborhood for lunch. I returned to my car as the parking receipt was expiring to purchase another, as the meter said "4 hours max" and I’d thus far only paid for an hour.

Unfortunately, the same parking meter I had used an hour earlier no longer seemed to be working. It would spend a couple of minutes connecting, and then display an error along the lines of "could not contact bank for approval." After a few tries, I decided to walk to another meter on the same block and try paying there. As I walked I used my phone to confirm on the SDOT website that this was the correct thing to do when a meter was not working properly. The second machine seemed to take longer than usual to authorize the charge, but it did work. New receipt in hand, I started walking back to my car.

As I was walking I noticed a parking officer was standing on a Segway next to my vehicle. After a second I realized there was already a piece of paper on my windshield. I shouted, "Excuse me!" and started jogging toward him, but he apparently didn’t hear me and started riding away toward 5th avenue and around the corner heading north. I ran up the block past my car to the corner, hoping he’d slow or stop to look at cars on that street and I could catch him. But by the time I got around the corner, he was gone.

I returned to my car and placed the new parking receipt next to the original one in the window. I went into the coffee shop I’d been in and wrote a note that said: "You gave me a ticket while I was paying!!!" and left it conspicuously placed on the same window. When I returned from lunch, the ticket and my note were still there.

As you can see from the enclosed parking receipts, I had paid for A) the hour just prior to the ticket, and B) and additional hour beginning at the time the ticket was issued. I believe the digits to the right of the amount paid indicates the meter from which the receipt was printed (W047 versus W049). If you look these up, you’ll find that they are indeed from different meters on this same block.

I do not believe I committed the alleged violation, as I was clearly making an earnest effort to pay for the parking spot (and did indeed pay for it!). Thank you for your time and consideration.

Pretty reasonable, right? I expected that my detailed description of what happened, along with the inclusion of both parking receipts, would make this a pretty simple case to dismiss. At worst, I feared that they would cite some technicality, or maybe challenge my recount of events.

But no. Instead, after two weeks, I finally received the magistrate’s reply:


Here’s what the comment section says:

If a pay station malfunctions and you are unable to obtain a payment receipt at a particular pay station, you may use any other pay station. If you are still unable to obtain a payment receipt, you must move your vehicle. Failure to properly display a payment receipt in a pay-to-park block is a violation, regardless of the reason.

I was appalled. This "magistrate" obviously didn’t even read what I wrote. Worse, the other page of this letter says that I cannot appeal or in any other way ask for accountability regarding this decision. Remember, I included the parking receipts with my letter on their form. I did use a different machine, and I did display the parking receipt. This parking receipt:


(I thought I’d also taken a picture of the first receipt, but apparently did not)

Their response includes absolutely nothing to indicate who this "magistrate" was, or how to report their utter failure to do their job. Presumably, they don’t want such reports. They just want my money, whether the law actually says they should have it or not.

$44 is nothing. I’ve paid that for legitimate parking tickets in the past without complaint (other than grumbling to myself about how high the fines are these days). While I’d prefer the parking officer have given sufficient time after the initial receipt expired, or have looked at the other meters on the block to see if someone was paying at one, I can’t really fault him. He was doing his job, and I was the victim of unfortunate timing.

This "magistrate" however, should be fired. Or at least reprimanded. You can’t be in a position of judicial power and make a judgment based on skimming a defendant’s carefully written testimony. You can’t blatantly disregard material evidence. You can’t copy and paste a boilerplate response which is clearly not applicable to my situation. And then tell me I have no recourse.

Am I overreacting? Probably. But this is my blog so what good is it if I can’t vent when I’m annoyed? And what happens if and when this person is given judicial power over more important matters? Will they continue to be just as careless?

Anyway, that’s my rant. If you happen to know someone in the Seattle Municipal Court system, or on the parking enforcement side of things, who wants to try and make this right, send them my way. Otherwise, I guess I’ll be sending in my $44 tip on $4 of parking.

/End rant

Jan 31 14

What I want: Metro + Desktop fusion edition

by Brandon

Longtime readers may remember that ages ago I used to write occasional posts with the title “What I Want: <some topic area>.” It’s been awhile, but I’m going to try bringing that back, starting today.

I’ve thought about and wanted this particular thing for a long time, but figured that now is as good a time as any to jot down my thinking for blending the Windows desktop and Metro/Modern/Immersive environments. I guess I’m partly inspired to blog about it because of Joseph Machalani’s post “Fixing Windows 8” he published back in December. I loved his approach of laying out concept and principles, and then showing mockups of how his proposal would work.

I’m not going to spend anywhere near as much time on this post as Joseph clearly did on his. I’m also not going to draw anything as pretty or make slick videos. Sorry. I have code and app building posts to write 🙂

What I will do is try to lay out my thinking for how I would tackle the same problems Joseph discussed. And I’ll share some quick and dirty mockups of roughly how it would work. Maybe one of my old pals at MSFT (or whoever is running design in Windows now) will like something from it and be inspired. Or maybe they’ll hate it. Or maybe they’re already thinking along the same lines. Whatever the case, I think it could spawn an interesting discussion.

Disclaimer: I have not shared or discussed any of this with anyone from Microsoft, and have absolutely no knowledge of their plans other than being aware of the rumors documented on The Verge and other places in recent days. This is nothing more than my musings as an enthusiastic user, developer, and wannabe designer.

So let’s begin with a little background from my perspective…

Simplicity versus capability

By and large, the world of computing UX is dominated by two approaches.


Apple uses both approaches. They ship the iPad with a simple UX, and the Mac with a powerful one. They’re largely unrelated experiences. One is not a scaled down or scaled up version of the other. They were designed independently, with vastly different goals.

Along the same lines, Windows Phone (7+) and Windows 7 easily fit into the same respective buckets.

Windows 8 – Mashing things up

I believe the designers of Windows 8 saw value in both approaches and set out to build a UX with the best of both worlds. I think the formula they used was essentially this:


I don’t think this was a crazy idea. In fact, I think this exact concept is valuable in some situations. The problem, I think, is that it fails to address 100% of the existing “Simple” and “Powerful” buckets. And yet, Microsoft decided to pitch it (and deliver it) as the modern replacement for those concepts it decided were legacy. And frankly, I think there’s more market today outside of the segment “Simplicity First” can address, on either side.

My alternative – a scalable UX

Rather than billing a single Simplicity First UX as all you need, I think what we need is a scalable UX.


Some devices (and users!) lend themselves to simpler UX, and this should be embraced. The iPad is a great example of this. Many, many users (and pundits) find its limitations to be a feature. I think a truly unified UX needs to start here and be able to exist completely in this bucket.

At the other end of the spectrum, you have what I’ll call a “Capability First” UX. Apple has slowly (very slowly) started pushing Mac OS to fit here. Things like LaunchPad and full-screen mode give the user a way to toss off the complexity of their normal desktop environment when they’re in the mood. And the way they’re doing it involves bringing some elements of iOS into the Mac world.

Why no “Powerful only” segment at the top of the scale? I just don’t think it’s valuable. As is, each step in the scale is a superset of functionality, just prioritized differently.

Microsoft has already shown that the design language and UX model formerly known as “Metro” can scale from Simple to Simple First. Windows Phone is Metro in Simple mode. Windows 8 is Simple First.

Unfortunately, with Windows 8 and Surface, Microsoft missed two important things. First, they failed to address the market for a Simple UX on a device any larger than a phone. Second, they failed to deliver the Capability First UX that traditional PC users demand for their desktops and most laptops.

A note on Windows 8.1 and update rumors

Windows 8.1 takes some really tiny opt-in baby steps to addressing the Capability First crowd (mainly by allowing you to boot to the desktop). The benefit of that is something that, today, I find questionable. And it’s off by default, so hard to call it capability first.

The other change in 8.1 was the restoration of the Start button on the desktop. There are two small benefits to this. First, it partially solves the discoverability problem of the lower-left corner mouse trigger for getting to Start (I say partially because it doesn’t help when you’re not in the desktop!). But second, it lets users feel more rooted in the desktop, whereas 8.0 was all about Start being the root and desktop being essentially an app.

For an OS update that took a year, and has a lot of great new stuff (SkyDrive integration, vastly improved Metro window management, lots of platform improvements, etc), these changes felt more like reluctant low-hanging-fruit concessions than earnest investments.

However, rumor has it that the upcoming “Update 1” will push further in this direction. Given the timeframe, I expect there will still be a lot of seams as you move up or down the scale I proposed above. But for an update put together over a few months, the rumors seem compelling enough. More than their functionality alone (which I’m anxious to see firsthand), it’s promising to see the new Windows leadership taking real steps here, and doing it with such agility.

Of course, I still have reservations. In particular, about how they’ll pursue this apparent “back to the desktop” objective in future releases. Naturally, since this is my blog, I have some ideas to share about that…

Scaling Windows from Simple to Capability First

Here I’ll describe how I’d take Windows from Simple to Capability First. We’ll start at the top, which is where things change the most.

My Capability First model

Well let’s get the obvious out of the way. This is Windows, so our Capability First UI is going to start out like this:


I bet I know your first question. What happens when you click that Start button? Here’s where I get a little crazy. Instead of opening a Start “menu” or taking you to the Start screen, that button really becomes the “new window” button.

Quick reminder: These are quickly hacked together mock-ups to convey the idea. Don’t judge the details!


Clicking on that button gives you a new “blank” window. Well, not entirely blank. It shows you Start. In other words, all the things that window can become. It could show a revised version of Start with recently visited documents or links, but the core idea is that it’s an evolution of the Start we know from Windows 8.1 today.

Selecting an app, whether it’s a Store app or a desktop app, turns this window into that app’s window.


(Ignore the fact that it doesn’t have a taskbar entry, just another case of me being lazy with the mockups)

Reimagining windows, not Windows

Today, the user starts applications, and applications create windows. Sometimes they’re desktop windows, sometimes they’re “immersive” windows. They act differently, and the user really has no control over which sort of window they get.

What if we turned the paradigm on its head a bit and said that the user creates windows, and windows are an organizational construct for hosting apps (and documents, and web sites).

Instead of the desktop being an app inside of the immersive environment, the desktop would be a place where every window is its own immersive environment. It’s own workspace. Indeed, maybe we can distinguish this concept a bit and instead of just calling it a window, call it a workspace, or a workspace window.


That means it has its own “back stack.” It could also have its own tabs. If something about this feels familiar to you, it should. The ultimate evolution of this idea would unify the browser’s tab and navigation stack concepts with the window manager completely. I don’t see why one tab can’t have an app like Tweetium and another tab have in it. How the browser has remained its own window-manager-within-a-window-manager for so long is puzzling to me.

The idea then is that if you grab that window’s titlebar and drag it to the top of the screen, or you click the maximize button, you’re in today’s immersive mode.


Grab it from the top (as if you were going to close or rearrange it today) and you can restore it to some position on the desktop. Then you can grab another workspace window and maximize that, essentially taking you back to the “metro shell” but with just the windows in that workspace.

Since this is the same window manager we already know (and sometimes love) from the Windows 8 “Metro” environment, maybe we can do things like snap windows inside it.


Another cool feature of this would be the ability to pin a workspace arrangement to the taskbar. Then any time you clicked on that taskbar entry, you’d get that set of apps loaded into a workspace window. Maybe two are snapped side-by-side in it, or maybe you have Newseen and Tweetium in separate tabs of the same workspace window.

If we did have tab support in these workspace windows, then “New Tab” is basically Start.


(last reminder that this is about the UX concepts and interaction model, not the graphical design!)

Of course, just like the browser today, you’d be able to drag tabs between workspace windows, or out into their own new workspaces.

Could classic desktop windows participate in the tabbing and such? Maybe not. I can imagine several technical challenges there, though possibly solvable for at least some cases. But even if not, I don’t think that would be a problem.

Scaling it down

The model above shows how I’d love Windows to work on my desktop and laptop. On my tablet, though, I might want something different.

For a Simple First variation, you’d just boot to a maximized workspace showing Start. You can always take it into the desktop if you want, but that functionality is tucked away until you need it (which maybe is never).

On the simplest devices, like an 8 inch consumer-level tablet, you may want to lock the system to one workspace. Basically, today’s Windows 8.1 but without the desktop available at all.

What do you think?

I’d love to hear what others think of this UX model. Love it? Hate it? Have ideas about how to make it better? Or a better idea? Jump into the comment section and let me know 🙂

Jan 28 14

Building Great #WinApps: Your first WinJS app, part 1

by Brandon

Before I dive into the overall architecture behind my existing apps, I thought I’d walk you through how I recommend building a brand new WinJS app.

First of all, I’m going to assume you have Visual Studio 2013. You can get the free Express version here. It includes a few templates for JavaScript Windows Store apps. I don’t find the UI templates useful, but I do make use of the navigator.js helper included in the Navigation App template, so I recommend starting with that.

Our first example app will be a simple UI over an existing REST API which returns JSON. In this case, primarily due to its public availability with no API key requirement, we’re going to use the Internet Chuck Norris Database’s joke API.

This post will go into verbose detail explaining the boilerplate code you get in the Navigation App template, and I’ll point out a few pieces I don’t like and think you should delete. If you’re already familiar with the basics of a WinJS app this may not be the most interesting thing you could be reading. On the other hand, any input on the format, or corrections/additions, are most welcome!

Creating our app project

After starting Visual Studio, select the New Project option from the start page or file menu. You’ll get this dialog where you’ll choose the Navigation App template for a JavaScript / Windows Store app.


The result of using this template is that your app is filled out with a bit of boilerplate code and a basic file layout which looks like this:


What is all this stuff? Well let’s work top-down:

  1. A reference to the WinJS library. This means you can reference the WinJS JavaScript and CSS files from your project without actually including those files. The Windows Store will make sure the correct version of WinJS is downloaded and installed on the user’s machine when your app is downloaded (chances are it is already there, as most of the in-box apps use it).
  2. default.css, a file which contains some boilerplate CSS that is by default applied to every page in your app.
  3. A few placeholder images for your tile, splash screen, and the store.
  4. default.js which handles app startup and hosts the navigation infrastructure. I’ve always referred to this as the “MasterPage” in my code, though I may try to think of a better name in time for part 2.
  5. navigator.js which is kind of a funny thing. I don’t really know why it isn’t part of WinJS, especially in 2.0 (i.e. Windows 8.1). The actual navigation stack is part of WinJS, under the WinJS.Navigation namespace. What this file provides is a custom UI control (using the WinJS control infrastructure) that combines the WinJS.Navigation navigation stack with the WinJS PageControl infrastructure (which is essentially a mechanism for loading separate HTML files and injecting them into the DOM). I’ll explain this in more detail below.
  6. page/home directory. This directory contains three files which constitute a “page control” in WinJS lingo. This is the only page your MasterPage will host if you were to run this app right now.
  7. default.html – This is paired with default.js and default.css to define the “MasterPage” I described earlier. It’s the main entry point for the app.
  8. package.appxmanifest – The package manifest is an XML file which defines everything about how Windows deploys your app package when the user chooses to install it. It specifies your app’s main entry points (generally an executable or an HTML file), and also defines which permissions (or “capabilities”) your app requires, which app contracts it implements (“declarations”), and how your app should be represented throughout system UI like the Start screen (i.e. its name, tile images, etc). I will of course dive into this in more detail later as well.

So what does all this code do?

If you run this app right now, a few things happen:

  1. Windows starts wwahost.exe, the host process for JavaScript apps.
    -You can think of this process as being a lot like iexplore.exe (the Internet Explorer process) but without any UI (“chrome”) elements, and designed to host true applications instead of for browsing web sites.
  2. wwahost.exe loads the StartPage specified in your manifest, in this case, default.html from your app package.
  3. default.html triggers the loading of core files like default.css and default.js.
  4. The default.js code begins executing as soon as the reference in default.html is hit.

Scoping your code to the current file

Now, most of your JavaScript files are going to follow a pattern you’ll see in default.js. That pattern is:

(function () {
“use strict”;

// Bunch of code


JavaScript developers are likely familiar with this pattern (sometimes called the “module pattern”). There are two things to note here: the “use strict” directive, and the outer function wrapping your code. “use strict” is an ECMAScript 5 feature which tells the JavaScript engine to enforce additional rules which will help you write better code. For example, you will be required to declare variable names before you can use them.

The other piece is that outer function. Without this outer function definition, anything defined in “bunch of code” would be added to the global namespace. This encapsulation technique is widely used by JavaScript developers to scope code to the current file. You can then use methods I’ll describe shortly to expose specific things to broader scopes as needed.

Digging into default.js

When we last left our executing app, it was executing the code from default.js. So then what? Let’s break down the default.js code the template provided.

First you’ll see 5 lines like this:

var activation = Windows.ApplicationModel.Activation;
var app = WinJS.Application;

JavaScript doesn’t have a “using namespace” directive. In fact, it doesn’t necessarily have a concept of namespaces at all out of the box. Instead you have a global namespace with objects hanging off it, but some of the objects serve no purpose other than to segment other objects/properties/methods. In other word, de facto namespaces.

All WinRT APIs are exposed as a set of classes hanging off of of the Windows namespace (such as Windows.ApplicationModel.Activation in the above example). Furthermore, WinJS defines a helper for implementing the common JavaScript equivalent of namespaces, and uses that to expose all of its functionality. To avoid typing out the fully qualified namespaces all the time, commonly used ones can be referenced by defining variables as above.

app.addEventListener(“activated”, function (args) {
    if (args.detail.kind === activation.ActivationKind.launch) {

Here the app registers a handler for the “activated” event. Activation is the word Windows uses to describe entry points for when the user invokes your application from anywhere else in the system. There are many kinds of activation, but the most basic “kind” is called “launch.” This is what happens when your app is started from its tile in Start, or when you hit “Go” in Visual Studio.

if (args.detail.previousExecutionState !== activation.ApplicationExecutionState.terminated) {
    // TODO: This application has been newly launched. Initialize
    // your application here.
} else {
    // TODO: This application has been reactivated from suspension.
    // Restore application state here.

Now we find some code that theoretically deals with the application lifecycle. I don’t like this approach, and I suggest deleting all that.

nav.history = app.sessionState.history || {};

This attempts to restore the navigation stack from history data saved before your app was terminated. I don’t like this either, so we’ll delete that too.

nav.history.current.initialPlaceholder = true;

This is telling the navigation stack that the current page shouldn’t contribute to the back stack. I don’t like this here either, so be gone with it!

// Optimize the load of the application and while the splash screen is shown, execute high priority scheduled work.
var p = ui.processAll().then(function () {
    return nav.navigate(nav.location || Application.navigator.home, nav.state);
}).then(function () {
    return sched.requestDrain(sched.Priority.aboveNormal + 1);
}).then(function () {


Now things get interesting.

Okay, well, the disable/enable animations thing is an optimization to avoid unnecessary work while the system splash screen is still up. So maybe that’s not that interesting. I actually think it’s a little hokey, but we’ll leave it for now. However…

WinJS.UI.processAll is a very important WinJS function which tells it to process WinJS declarative control bindings in your HTML. In other cases you’d probably specify a root element, but in this case none is specified, so it starts at the root of of the DOM – which means processing the markup from default.html.

Essentially what this does is walk the DOM looking for data-win-control attributes, which specify that an element should host a WinJS control. For each one found, it invokes the associated JavaScript code needed to create the control.

This time, the only control it will find is this one from default.html:

<div id=”contenthost” data-win-control=”Application.PageControlNavigator” data-win-options=”{home: ‘/pages/home/home.html’}”></div>

This invokes code from navigator.js, where Application.PageControlNavigator is defined. It also deserializes the JSON string provided in data-win-options into an object and passes that as the “options” parameter to the Application.PageControlNavigator construction methods, along with a reference to the DOM element itself.

What’s all this .then() stuff?

WinJS.UI.processAll is an async method, and so its return value is a promise object. If you’re familiar with C# async, this is roughly equivalent to Task<T>. However, instead of representing the task itself, the idea is this object represents a promise to return the requested value or complete the requested operation.

The number one thing you can do with a promise object is to specify work to be done when the promise is fulfilled. To do this you use the promise’s .then method.

In this case, we tell processAll to do its thing, which results in instantiating the PageControlNavigator asynchronously. When it’s done, the code in the .then() block executes and we call nav.navigate to navigate to our app’s start page.

When that’s done, this boilerplate code requests that the WinJS scheduler (a helper for prioritizing async handlers and other work executed on the current thread) execute all tasks that we or WinJS have declared as being high priority. That’s another async task, and when it’s completed, we re-enable animations.

The args.setPromise line is really about the system splash screen. During app activation the system keeps the splash screen visible until after your “activated” handler has returned. However, we actually want to keep it up until we’re ready to show something, so the setPromise method lets you specify a promise which the splash screen will wait on. When it’s fulfilled, the splash screen will do its fade animation and your app UI will be shown.

The promise we pass is actually the return value of our last .then() statement after processAll. WinJS’s implementation of promises supports a very handy chaining feature which is relevant here. Every call to .then() returns another promise. If the function you provide as a completion handler to .then() returns a promise, then the promise returned by .then() is fulfilled when that promise is fulfilled.

Hopefully your head didn’t explode there. When first encountered, this can take a minute to wrap your head around, but I swear it makes sense =)

To try and help clarify that, let’s take another look at that part of the code with some of the parameters stripped out and a few numbers labeling the approximate sequence of events:

var p = ui.processAll().then(function () { // 1
    return nav.navigate(); // 3
}).then(function () {
    return sched.requestDrain(); // 4
}).then(function () {
    ui.enableAnimations(); // 5

args.setPromise(p); // 2

  1. So our first step is that processAll kicks off an async task and returns a promise.
  2. The very next thing that happens is the args.setPromise call. Then our activated handler runs to completion.
  3. Later on, when the processAll task completes, its promise is fulfilled, and we run the handler that invokes nav.navigate. That call itself returns another promise, which bubbles out to the promise returned by the .then() it handled.
  4. Only after that task is complete, do we run the next handler, which calls requestDrain. Again, this returns its own promise.
  5. When that completes, we’ll run the code to re-enable animations.
  6. When that returns, the whole chain will finally be complete, and “p” will be be fulfilled. Only then will the splash screen dismiss.

Re-read that if you need to. If you haven’t been exposed to promise-based async development before, I can imagine it taking a few minutes to process all that. Once you figure out the promise model, you’re pretty much good to go.

If you want to go read more about promises, some helpful links @grork suggested are:

MSDN / Win8 App Developer Blog: All about promises (for Windows Store apps written in JavaScript)

MSDN: Asynchronous programming in JavaScripts (Windows Store apps)

MSDN Blogs / The Longest Path: WinJS Promise Pitfalls

Got it. What about the rest of default.js?

Our default.js file has just a little more code we should deal with:

app.oncheckpoint = function (args) {
    // TODO: This application is about to be suspended. Save any state
    // that needs to persist across suspensions here. If you need to
    // complete an asynchronous operation before your application is
    // suspended, call args.setPromise().
    app.sessionState.history = nav.history;

This is using the “oneventname” shorthand for registering an event handler for the “checkpoint” event. As the template comment suggests, this event indicates the app is about to be suspended, and that it should immediately release any resources it can, and persist any information it may need the next time it’s started, if the system decides to terminate it while suspended.

I’ll cover more on suspension and the app lifecycle later. For now, I suggest deleting the boilerplate code in this handler, but keep the handler itself around as it will be useful later.

Finally, we come to the last bit of default.js code:


Up until now, the code in this file has been defining functions but not actually executing them. This line kicks off WinJS’s app start-up infrastructure, which ultimately results in the “activated” handler we described above being invoked, after the rest of the default.html page has been loaded.

Our trimmed down default.js

If you followed my suggested deletions, and also delete the comments inserted by the template, your default.js should now look like this:

(function () {
    “use strict”;

    var activation = Windows.ApplicationModel.Activation;
    var app = WinJS.Application;
    var nav = WinJS.Navigation;
    var sched = WinJS.Utilities.Scheduler;
    var ui = WinJS.UI;

    app.addEventListener(“activated”, function (args) {
        if (args.detail.kind === activation.ActivationKind.launch) {
            var p = ui.processAll().then(function () {
                return nav.navigate(Application.navigator.home);
            }).then(function () {
                return sched.requestDrain(sched.Priority.aboveNormal + 1);
            }).then(function () {


    app.oncheckpoint = function (args) {


Okay, I cheated and also removed the “nav.location || “ and “, nav.state” parts of what was being passed to nav.navigate. Since we deleted the code that restored that from sessionState, we don’t need them.

Onto home.js

Now that we’ve gone over the basic bootstrapping done in default.js, we can take a look at our home page. The only interesting part right now is actually home.html.

lt;!DOCTYPE html>
<meta charset=”utf-8″ />

<!– WinJS references –>
<link href=”//Microsoft.WinJS.2.0/css/ui-dark.css” rel=”stylesheet” />
<script src=”//Microsoft.WinJS.2.0/js/base.js”></script>
<script src=”//Microsoft.WinJS.2.0/js/ui.js”></script>

<link href=”/css/default.css” rel=”stylesheet” />
<link href=”/pages/home/home.css” rel=”stylesheet” />
<script src=”/pages/home/home.js”></script>
<!– The content that will be loaded and displayed. –>
<div class=”fragment homepage”>
<header aria-label=”Header content” role=”banner”>
            <button data-win-control=”WinJS.UI.BackButton”></button>
<h1 class=”titlearea win-type-ellipsis”>
<span class=”pagetitle”>Welcome to ChuckNorrisJokes!</span>
<section aria-label=”Main content” role=”main”>
<p>Content goes here.</p>

Again there are some things I think you should delete. They are:

  1. The outer html, body, charset, and <title> tags are just utterly unused. The reasons will become clearer when I get to describing the fragment loader in a later post. In essence this code is dead on arrival and just shouldn’t be here.
  2. The WinJS references are redundant. They’re already loaded by default.html, and serve no purpose here. At best this will be optimized to a no-op, at worst it’s going to run redundant code.
  3. Default.css is the same story. No idea why the template puts this here, even MSDN advises you not to do this exact thing.
  4. The back button. This may seem odd, since I did tell you to choose a Navigation app. The reasons for this will become more clear as we evolve the app template. Suffice to say that having the navigator capability can be useful regardless of whether you actually expose a back button. And it’s nice to have the option to expose later if you want to, or on specific pages where it’s more useful.

When we boil it down to the functional parts, the entire file looks like this:

<link href=”/pages/home/home.css” rel=”stylesheet” />
<script src=”/pages/home/home.js”></script>
<div class=”fragment homepage”>
<header aria-label=”Header content” role=”banner”>
<h1 class=”titlearea win-type-ellipsis”>
<span class=”pagetitle”>Welcome to ChuckNorrisJokes!</span>
<section aria-label=”Main content” role=”main”>
<p>Content goes here.</p>

An important thing to remember is that this is not meant to be a complete HTML file. We never intend it to be. It’s a fragment of HTML which will get loaded into the document described in default.html. That’s why that outer code is superfluous. We already did that stuff in default.html.

What’s left should look fairly straightforward. We load the mostly empty JS and CSS associated with this page, and then define a header and body with some placeholder content.

Let’s make this an app!

We’re going to start very simple and build out from there. For this first part of the mini-series, our goal is simply to display a random joke from the Chuck Norris joke database.

To do that, we actually need very little code. Let’s start by changing home.html to provide us a place to render the joke text:

<link href=”/pages/home/home.css” rel=”stylesheet” />
<script src=”/pages/home/home.js”></script>
<div class=”fragment homepage”>
    <header aria-label=”Header content” role=”banner”>
        <h1 class=”titlearea win-type-ellipsis”>
            <span class=”pagetitle”>Chuck Norris joke of the day!</span>
    <section aria-label=”Main content” role=”main”>
    <p id=”jokeText”></p>

The only spots I changed are in bold. The first is just a cosmetic change to our header. The latter removes the placeholder text, and assigns an id to the paragraph element so we can reference it later.

Now if we jump over to home.js, you’ll find this:

(function () {
    “use strict”;

    WinJS.UI.Pages.define(“/pages/home/home.html”, {
        // This function is called whenever a user navigates to this page. It
        // populates the page elements with the app’s data.
        ready: function (element, options) {
            // TODO: Initialize the page here.

Again, you can delete the template comments after you’ve read them once. To display our joke we’re going to do three things:

  1. Make a request to the API endpoint at
  2. Parse the response to find the joke text.
  3. Assign that to the innerText property of our jokeText element.

To make our request we’re going to use the standard JavaScript XmlHttpRequest mechanism, but we’ll call it via the handy WinJS.xhr wrapper. WinJS.xhr is great because it takes a simple property bag of options and gives you back a promise for the result of the request.

When you type WinJS.xhr( into Visual Studio you’ll get a handy IntelliSense description:


As the default request type is GET, we only really care about the url field, so that’s the only option we’ll populate.

(function () {
    “use strict”;

    WinJS.UI.Pages.define(“/pages/home/home.html”, {
        ready: function (element, options) {
            var jokeTextElement = element.querySelector(“#jokeText”);
            return WinJS.xhr({
                url: “”,
            }).then(function (response) {
                // response is the XmlHttpRequest object,
                // ostensibly in the success state.
                try {
                var result = JSON.parse(response.responseText);
                catch (e) {

            if (result && result.value && result.value.joke) {
                jokeTextElement.innerText = result.value.joke;
            else {
                jokeTextElement.innerText = “The server returned invalid data =/”;
        }, function (error) {
                // Error is the XmlHttpRequest object in the error state.
                jokeTextElement.innerText = “Unable to connect to the server =/”;

As you can see, making an HTTP request is super simple. Once we have the response text, a simple call to JSON.parse will turn it into a JS object we can inspect and make use of. If the response text is missing or not in valid JSON format, the parse call will throw an exception, and we’ll print a message that the server has returned invalid data. We also inspect the returned object for the fields we’re looking for. If we didn’t do this, and just used result.value.joke where “value” was missing, that line would throw an exception (essentially the JS equivalent of an Access Violation). If “value” were there but its “joke” property were missing, that would result in printing the text “undefined” to the screen. Since that’s not pretty, we check for the presence of those fields and print a slightly nicer error, if that case ever were to occur.

The second function we pass to .then() is an error handler for the promise. If anything in WinJS.xhr throws an exception, it will get captured by the promise and handed to us here. To keep this example simple we don’t bother inspecting the error. But in the real world you’ll often want to have more elaborate error handling than that.

Now when we run the app, we get this!


That’s the first one I got. Seemed appropriate enough 🙂

What’s next?

In part 2 we’ll look at using WinJS templating and databinding to display more than one joke at a time. So check back soon! Oh, and please use the comment section to let me know if this is helpful, if the format works for you, and if you have any questions about the content of the post. I fully understand that this first post spent a lot of time on some rather basic concepts for anyone already working with WinJS (and likely for many using similar JS libraries). I promise the content will get more interesting for you folks soon, after I’ve hopefully helped get the less experienced folks up to speed.