Off the Electronic Grid: Into the Grand Canyon

Check-out some of the great shots we got of friends and family in the canyon.  Then head past to read a description of the trip and some thoughts on why trips like these are important.

Quick stop at Trail View Overlook.
Left to Right - Lindsey, Nathan, Nick, Xheni

A view out from Trail View Overlook.

Starting down New Hance
Front to back: Nick, Dennis, Xheni, and Nathan

A view of the trail hugging the rock formation on the right with the red rock to step around.

Good view of the canyon a few hours into our hike.

A break on the way down with the
rain spitting on us.
Left to Right - Nick, Xheni, Dad, Nathan

Xheni and my Dad getting close to Red Canyon

Some ominous clouds just north of us in the canyon.

A shot of the cactus flowerers with a cloudy canyon backdrop.

Red Canyon and what looks like heavy rain.

Dad traversing a tricky section of the trail while I watch.

Looking down the canyon at our tents (Dad's is the grey one on the left, Xheni and I's is the yellow one).

Looking back up trail at Nathan and Lindsey's tent.

The last mile of the hike to the river was in a dry creek bed.

Big boulders lining the creek bed on our way down to the river.

Brining up the rear, my wife and I make it to the river banks.

A shot of the Colorado river.

Xheni and I getting back into camp, ready for dinner.

Lindsey getting started on over an hour of water filtering while Nathan cooks, Dad enjoys the best Raman he's ever had, and Xheni stares off into space.

A fabulous morning as we exited Red Canyon.

First real break on the climb.
Back to Front - Nathan, Nick, Dad, and Xheni

Beautiful shot of the clouds, sky, and the canyon.

A view up the canyon and of a false summit.

Nathan stopped to get a shot of the flowers
against the Juniper tree as we hiked past.

Nathan and I relaxing on a rock shelf that was almost the perfect bench.

The view off to the left from our rock shelf.

Nathan graciously stopped to get a picture of the
wild flower for Xheni.

Nathan was being a mountain goat as he tried to capture the steepness of the trial.
Left to Right: Dad, Xheni, Nick

One of our last looks at the trail.

Relaxing after the hike by Duck on a Rock.

As a passionate Microsoft employee, it should be no surprise that I am a big fan of technology and how it can help people do more.  But what may come as a surprise is that I am increasingly becoming more convinced that taking the time to unplug from tech and to connect with real people – one human to another human – is critical for managing stress, improving performance, and enriching lives.   Back in 2012, Doctoral student Sara Thomée and her research colleagues at the University of Gothenburg’s Sahlgrenska Academy published their thesis on the effect of computer and mobile phone use on stress, sleep disturbances, and symptoms of depression.  They showed some interesting findings that help support my growing beliefs:

Frequently using a computer without breaks increases the risk of stress, sleeping problems and depressive symptoms in women, whereas men who use computers intensively are more likely to develop sleeping problems.

“Regularly using a computer late at night is associated not only with sleep disorders but also with stress and depressive symptoms in both men and women,” says Thomée.

4,100 people aged 20-24 were included in the studies that included questionnaires and interviews to generate these findings and more.  I will share more of thoughts on my growing unplugged philosophy in an upcoming post, but in the mean time, I thought I would share my latest trip off the electronic grid.  It was a great foray into unplugging and connecting with close family and friends as we headed off on an adventure into the back country of the Grand Canyon, where cellphones and laptop are virtually worthless.

The Warm-Up – Bright Angel Trail


Left to Right: Lindsey, Nathan, Nick, Xheni

After our calming drive through the Desert of Arizona, we arrived at the Grand Canyon a little after 5:00pm.  Our good friends took us out for a quick walk down some stairs to Trail View Overlook where we were just in time to catch some amazing light.  The walk back up the stairs helped to remind us that we were far from the sea level elevation we are accustomed to.  The South Rim’s elevation is 7,000ft after all, which is higher than Denver the mile high city.  After quickly checking my dad in to his lodge, we headed back for some pork roast, good conversation, and the start of what seemed like an endless marathon of Bruce Springsteen.
The next day we had our warm-up hike on Bright Angel Trail.  With the trail head being right off the village loop, it is the canonical trail that people think of hiking at the canyon.  It’s well maintained, has covered rest houses, and has potable water.  The only downsides are that you do have to share the trail with the mules carrying people down to Phantom Ranch and there is a real crowd due to the popularity of the trail.  However, we were lucky enough to time our hike where we didn’t encounter any mules and the people hiking were all good natured.  We only went down a short way to the Two Mile Corner and hiked a few yards up off the trail to see the petroglyphs.  It was cool to see something so old and yet so accessible that you could actually walk up and touch it.  Although, if you actually touched it would land you a $250,000 fine.  We enjoyed the hike up while unbeknownst to us, Nathan our virtual trip leader was completing his evaluation of our physical fitness and altitude acclimation.

The Main Event – New Hance Trail

Near the top of New Hance Trail

Near the top of New Hance Trail

So why exactly would Nathan be observing our skill level and physical readiness?  Well the National Park Service’s trail description sheds some light as it claims that the new Hance Trail’s reputation is similar to the original, which prompted the 1904 travel writer Burton Homes to speak of it as follows:

There may be men who can ride unconcernedly down Hance’s Trail, but I confess I am not one of them. My object in descending made it essential that I should live to tell the tale, and therefore, I mustered up sufficient moral courage to dismount and scramble down the steepest and most awful sections of the path on foot …. ‘On foot,’ however, does not express it, but on heels and toes, on hands and knees, and sometimes in the posture assumed by children when they come bumping down the stairs …. The path down which we have turned appears impossible …. The pitch for the first mile is frightful … and to our dismayed, unaccustomed minds the inclination apparently increases, as if the canyon walls were slowly toppling inwards ….

From the National Park Service’s Trail Description


The New Hance Trail is by far the most difficult trail that I have ever tackled.  But, the fear for my life had an unexpected benefit.  It is impossible to hang onto work  stress and to stay “plugged in” when every foot fall needs to be carefully managed to avoid plummeting to one’s death.  I definitely returned to work relaxed and refreshed.  Between the combined beautiful views and the requisite careful hiking, it is easy to see why it took 7 hours to go down the 5.5 miles to where we set up camp.


Left: Looking down trail at my Dad’s grey tent and Xheni & I’s tent.
Right: Looking up trail at Nathan & Lindsey’s tent.

As you can see, the weather started to turn on us.  We still had a mile hike to get down to the Colorado River and the rain was starting to spit.  Just past camp, the trail itself joined up with what appeared to be a creak bed for when it really rains and the waters flow.  The creak bed made for a relatively smooth trek down to the river and back, despite the slowly increasing rain.  While the picture doesn’t show it, the rain reached its heaviest about the time we got to the river.  Though even then, we lucked out and it was still only slightly more than a trickle.

The Colorado River

The Colorado River

As we got back to camp, the small stream down in the ravine coming from a natural spring had picked up the pace making it much quicker to filter and fill our ~20 liters of water bottles.  Nathan started cooking dinner – a concoction of canned chicken, Ramen Noodles, garlic powder, and just a touch of red chili flakes.  The meal was delicious as Xheni and I plowed through over a quart of the soup.  This is once again confirmation that every meal tastes better in the backcountry.  As we finished up dinner it was nearing “Hikers Midnight”, roughly 8:00pm this time of year.  After a few pulls and passing the flask of some “Kickin’ Chicken” (Nathan’s found nickname for his favorite whiskey Wild Turkey), we finished up our conversations and set off for bed.

Looking back at the Red Canyon

Looking back at the Red Canyon

We awoke to a fantastic morning, which you can see here about an hour into our hike.  At this point, we had already traveled far enough that you can no longer see the walls of the canyon that were next to our camp site.  The morning also greeted us with a bit of stiffness, both from the strenuous hiking the day before and from sleeping on the ground which we are unaccustomed to.  After gobbling down some blueberry bagels for breakfast and drinking as much water as our bellies would hold, we packed up camp and set out.  It was a fantastic hike out and was very enjoyable, especially since going up was technically much less difficult then the hike down.  We must have been timid and fearful on the way down, since we were able to climb out almost 20% faster completing the hike in roughly 6 hours.  We enjoyed our post hike glow over a few beers, some hot-wings, brats and some more friendly banter.  It’s hard to imagine a better way of spending a few days.

If you found this interesting or useful, please help spread the word:

The Challenge of Managing the Whole Product as a Feature Owner

I recently had a conversation with someone who co-managed a healthy sized organization at Microsoft (~50 program mangers and engineers).  The goal of the chat was to explore some customer development techniques her team had been using to try and learn how they could be applied to the work my team was doing.  But right off the bat, the conversation took a turn I hadn’t expected.  Some of the work she had been doing was pulled in the 11th hour and she seemed disenfranchised with her lack of control and autonomy over the product.  Her argument was, that even as a PM Lead, you are basically only the owner of a feature and not of a product.  Therefore, you don’t have enough span of control to effectively employ customer development.  This disempowered line of reasoning runs completely counter to my personal philosophy.  As such, I have spent the last couple of weeks mulling over the conversation and pondering the relationship between span of control, influence, customer advocacy, and sense of responsibility.

My Philosophy of Program Management

shutterstock_242043958 (3)

Back when I was a junior developer, I enjoyed tinkering with and building new things.  Coding was the ultimate playground.  Simply think it up, imagine how it works. and suddenly it does.  As a person who enjoys problem solving, the job of a junior developer was great.  Someone would bring me a puzzle (a spec for a feature) and I would go solve it.  Success was fairly black and white, the code either worked as the spec said or it didn’t.  But when I switched to being a program manager, the problems shifted.  I was shoved into a world of grey.  I have a buddy who summarized the difference nicely.  When his developers were teasing him about the length of time to write his spec vs the amount of time it took them to write theirs, he replied:

“You were handed a spec that says what needs to be built.  Then you wrote a spec that said how to build it.  But, who writes the spec for me?”.  

With my background as a developer, I found it easy to write the spec that describe the technology that needed to be built.  But, as a new program manager, the hard part for me was figuring out what needed to be done in the first place.  My manager at the time beat a few principles into me that helped me navigate the waters.

Be the expert on what’s best for the customer – it’s the ultimate trump card.

shutterstock_256530070 As engineers, our first instinct to help a struggling customer is to add a new feature to make it easier.  We naturally want to solve it with more code.  Sometimes adding yet another feature is the worst thing you can do.  The challenges that your customers face can have many causes, but only some warrant more code and new features.  For example, a customer may be overwhelmed by the complexity of the UI.  Another may be trying to do something with the product that it was never intended to do.  Figuring out the right next move can only be done by stepping back and taking the time to have a crystal clear picture of exactly who the target customer is, what they are trying to accomplish, how they do their work, and where the pitfalls and challenges lie in their path.  With that deep knowledge it becomes clear how to shape your product to help them achieve their outcomes.


shutterstock_264221285It’s an extremely cheesy statement, but it does hit the mark.  Once a program manager deeply understands what their customer needs and know what needs to happen, they are ready for the fight to bring it to life.  A great program manager has a thick skin, an entrepreneurial spirit, and even a bit of stubbornness.  For others will build the product but they will it into existence.  Many roadblocks always get thrown in the way.  A great program managers tears them down and makes stuff happen anyway.  Only that drive keeps a project alive long enough to become a product.

Feel responsible for more than you own.

shutterstock_376050667 (1)The number of things that you truly own and have control over is extremely small.  Unless you are the most junior of program managers, the real job is to work across teams and convince people to do the right thing.  By caring about the full story and what matters to customers, the level of impact a program manager has grows exponentially.  Often I hear people bellyaching that “they [some other team] don’t get.”  It’s a terrible excuse and those people are being lazy.  Jocko & Leif tackle this directly in Extreme Ownership (a fantastic book on leadership) where they make the point that it is their job as leaders to help others, even other more senior leaders, understand the real situation and therefore make the right call.  The same principle applies to the program manager, who necessarily is a leader.  Whether its a superior, a peer, a direct report, or a partner, it’s your job as the owner to help them get it.  Remember, it’s not about you.  It’s about the person that needs to be convinced and framing and reframing the conversation until it makes sense to them.  Everything a program manager does is around influence.  In fact, you are kidding yourself if you believe you own a feature.  After all, its the developers who, at the end of the day, type the code in and have the final say.

Nothing counts until it is in the hands of your [happy] customers.

shutterstock_386551540So often I see teams celebrate when the API and the technology finally works (if they haven’t already celebrated and declared victory when the prototype started working).  Heck, even when you start to get adoption, you are still miles from what most customers really want.  I love the way that Simon Sinek phrased it in his TED Talk:

I love asking businesses, “What’s your conversion on new business?” And they love to tell you, “Oh, it’s about 10 percent,” proudly. Well, you can trip over 10 percent of the customers.

The real mass of customers don’t want to be on the bleeding edge of what’s new.  Dev’s are the same.  They want easy to consume, well supported, safe, almost brain dead ways of consuming your APIs.  Anything less, and they would rather build it themselves since they know how to support it.  If that wasn’t the case, then why are there so many string libraries floating around?  Documentation, Samples, Tutorials – all are things many engineering teams view as a tax.  Yet these are some of the things required to drive adoption across the chasm.  Now, don’t confuse me with Ebenezer –  of course you should celebrate when the prototype works, when the feature is complete, and when it is first shipped to customers.  However, its important that when the party is over you set your focus beyond your toes and the immediate technology you are working on and instead focus on the horizon and delivering the whole product.


Influencing the Whole Product

I recently read Crossing the Chasm (which, I let it sit on my shelf for way to long).  In it, Geoffrey introduces the concept of the whole product – the real set of products and services that a customer will need to employ to accomplish their ends.  The idea is that the product that any one company typically produces is only a subset of what is really required.  For example, even Microsoft, who has a massive array of products compared to all but a small handful of companies, can’t build the whole product of Windows.  A big part of what people buy is the apps and services that thousands of other companies have built on top of the OS.  In all but the rarest of situations, the whole product is out of reach of any one entity.

This brings us back around to the original conversation and the argument around span of control.  Of course I don’t have the autonomy and control to employ the techniques and use the results to dictate every detail of the product.  It would be naïve to think otherwise.  Just consider, if the Apple’s, Google’s, and Microsoft’s of the world are all dependent on others to deliver the whole product, then why should any given feature owner think they are different.  These companies all need to partner with other companies in order to deliver the results customers expect.  Indeed, the life of a program manager or a feature owner is no different.  They need to think through the end to end usage of their features and what customers will really need in order to be able to effectively use it.  Landing a feature can’t be done alone.  It requires partnering with a number of different people creating the other aspects of the product, some within and some outside the company.

So, do I have the span of control to employ the techniques?  Certainly, not.  But, do I have the responsibility and the scope of influence to do it?  You better believe it.

If you found this useful, please help spread the word:

I always love connecting and hearing about what creative people are able to accomplish.  So leave a comment with what you hope to go do or connect on Twitter. Or better yet, share what you have already been able to change or create.

Understand what’s possible with the Windows UI Animation Engine


In November of 2015, the Visual Layer was introduced as a series of new APIs in the Windows.UI.Composition namespace.  These new APIs marked the first opportunity for app developers to get direct access to many of the capabilities that have underpinned the UI Frameworks since Windows 8 (e.g., IE/Edge, XAML, & the Windows Shell).  One key aspect of the new Visual Layer is its new animation engine.    But after spending a bunch of time talking to developers at //build this year, it became clear that devs are still not clear on how the pieces of the animation system fit together.  To shed some light on what you can do with the animation system let’s walk through two questions:

  • Who’s responsible for starting animations?
  • What drives the animation to change values?

Implicit vs. Explicit – Who’s Starting the Animation?

The key difference between explicit and implicit animation is around who is responsible for triggering the animation.

Long story short: Explicit animations you trigger. Implicit Animations you configure.

Explicit Animations

Explicit animations are what most people think about when they think of animations, so they are likely familiar to you.  With explicit, you set up the animation and then you, as the developer, trigger the animation.

For example, in XAML you typically create the animation in your markup and trigger the animation in your code behind.


Code Behind:

The animation system in the Visual Layer also supports explicit animations – though only in your code behind.  This should help you to take what you know and use it to get started right away.

Code Behind:

In both cases, the model is the same.  You define your animation (i.e., the duration, shape of the motion, the target property and the value) and then you explicitly trigger it with start/begin.

Implicit Animations

In contrast to explicit animations, an implicit animation is triggered by the platform.  For example, the following code illustrates how to wire up the EntranceThemeTransition to a button via XAML:

This is all the code that is needed. When the button first appears, it will trigger the EntranceThemeTransition to animate it into its location.  Prior to the Visual Layer, you only had a handful of implicit animations  to select from (namely, the XAML Transitions) and virtually no ability to configure them.  The Visual Layer also supports implicit animations, but you get way more control:

This code sets it up so that anytime the Offset gets changed on myVisual, the _offsetKeyFrameAnimation will be triggered by the platform.  Notice that an ExpressionKeyFrame was used in the definition of the implicit animation.   It allows you to set up mathematical formula that will be calculated on each frame in the animation system via ExpressionAnimations,.  In our case, we used a trivial expression of “this.FinalValue” which simply evaluates to the value that triggered the animation in the first place. The animation was pretty basic for illustration but you have the ability to define any animation that you want.

The flexibility of the Visual Layer’s implicit animations let you separate the logic of your app from the motion and provides a powerful way to customize your experience.    For example, one great way to use implicit animations is to set up a trigger on “Offset”.  By doing so, you can create animated transitions from one layout to another that are triggered automatically when XAML’s layout engine runs.

A good place to start learning more is by watching this //build talk on Implicit Animations.

Tools of the Trade – What Drives the Animation?


Time Driven Animations

These are the classical animations that devs know and love.  The previous code snippets showed XAML Storyboards and Composition KeyFrameAnimations, which are both time driven animations.  The idea behind KeyFrame animations (the defacto standard) is that you specify what the value of the animation should be at specific points in time and describe how to transition between those values (often referred to as interpolation or easing functions).  XAML provides a bunch of built in easing functions to help you get aesthetically pleasing results fairly easily.  In the Visual Layer, the workhorse for easings is the CubicBezeirEasingFunction which takes two control points to shape the motion.  The control points allows to have you fine grained control and, since Beziers are so commonly used across animation engines, you can get pre-defined controls points that look good.  I typically head over to to get the control points for the standard Penner’s Easing Functions.

Reference Driven Animations (Math Driven)


In the 10586 November Update to Windows, ExpressionAnimation were introduced in the Visual Layer’s animation engine.  ExpressionAnimations allow you to create a mathematical relationship between properties in the animation system that will get updated frame over frame.  The canonical ExpressionAnimation is the parallax animation:

The first thing that this snippet does is create the mathematical expression used to describe the relationship between some inputs and the resulting output of the animation.  It does this by defining a few parameters and references that are then filled in later.  Parameters help you to configure the relationship, but references are the thing that makes expressions interesting.  A parameter (e.g., “MyParallaxRatio”) is filled in by calling a type specific function (e.g., SetScalarParameter).  This informs the animation engine to evaluate all instances of the parameter to the value that you pass in.  This evaluation occurs once, prior to marshalling the animation over to the engine, so it is a good way to specify constant values.  In contrast, a reference (e.g., “MyForeground”) is actually evaluated inside the animation engine on each frame.  It’s the magic that actually makes ExpressionAnimations interesting.

There are a couple of other things to note.  First, you’ll notice that we are able to access the members of “MyForeground” and the “Y” sub-channel.  The expression syntax supports both member access as well as ‘swizzling’ or swapping components of a vector/matrix.  For example:

The other thing to note is that all animations in the Visual Layer are actually templates.  This means that you can use them to set the exact same animation on multiple objects or just reuse the structure of the animation and update parameters/references before starting the animation on the next object.  For example, if we wanted to extent the canonical parallax with multiple levels of depth we can do it with a single definition of the animation:

ExpressionAnimations are a powerful new way to express how things should move relative to one another.  They take away the pain of having to setup a series of complex animations in order to get different objects and properties to move in concert.  Go check them out and learn more with this build talk:

P486: Using Expression Animations to Create Engaging & Custom UI

Input Driven Animations

With touch going mainstream roughly five years ago, the need to create low latency experiences has become prevalent.  With a finger or pen moving across the screen, the human eye now has an easy reference point to evaluate the latency and smoothness of interactions.  To make these interactions smooth, the major OS companies have been moving more processing to the system and to the GPU (e.g., Chrome and IE).  In Windows, this was done via DirectManipulation, which is more or less a purpose built animation engine.  It solved the key latency challenge as well as how to naturally transition from input to time driven motion.  But with virtually no support for customizing the look and feel of inertia, the downside was that it was just like the Model T – “You can get it in any color you want so long as it is black.”

ElementCompositionPreview.GetScrollViewerManipulationPropertySet was the first step into letting you play with input driven motion.  It still didn’t allow you any additional flexibility to control the look and feel of the content being scrolled, but it did let you wire up secondary content via ExpressionAnimations.  For example, we can finally complete the canonical parallax code snippet:

With this technique, you can implement various forms of goodness: parallax, sticky headers, custom scrollbars, etc.  The only thing missing is customizing the look and feel of the interaction itself…

Enter the InteractionTracker.  It has been designed from the ground up to preserve the latency for stick to the finger experiences, while giving you the flexibility to control every aspect of the look and feel.  On the Window’s UI Platform, we often talk about Easy vs. Possible.  Common UX and calling patterns are often wrapped up into easy to use higher level controls and features.  This makes them really convenient to use, but at the cost of loosing some flexibility and control.  At the other end of the spectrum are things like the Graphics Layer.  Here you can literally control the very pixels being put on screen, but it comes at the cost of being much more complex.  In the schemes of input handling, the InteractionTracker lives more towards the possible end of the spectrum.  For the first time in the Windows UI Platform, you declarative map input to output to specify motion.

A simple illustration of the new flexibility is around how you can modify where inertia ends.  Previously, you could modify the XAML ScrollViewer’s inertia using snap-points by specifying one of four options.  With the InteractionTracker, you use ExpressionAnimations to define where inertia will end with InteractionTracker allowing you a much wider set of possibilities.  Here is an example of creating 3 different snap-points based on where the inertia will naturally come to rest:

Not only can modify where inertia will end like we showed here, but you can also modify the shape of inertia as well. The InteractionTracker enables you to get the precise look and feel you want for your signature experiences.  To learn more about what’s possible and how to use it, check out:

P405: Adding Manipulations in the Visual Layer to Create Customized & Responsive Interactive Experiences

Where to go next?

If you haven’t found your way to the WindowsUIDevLabs, you should certainly go check it out.  Here is how it describes itself:

Welcome to the Windows UI Dev Labs repository for the latest code samples, demos, and developer feedback for building beautiful and engaging Universal Windows Platform apps using Windows UI.

As the next flights come out, it should be a really interesting place to get samples of what can be done with the platform and get the accompanying code.

If you found this useful, please help spread the word:

I always love connecting and hearing about what creative people are able to do with using these new tools, so leave a comment with what you hope to go build or connect on Twitter. Or better yet, share what new things you have been able to create.