Not enough bits in this byte

Why ultimate players should move heavy things

This is a quick post to collect some thoughts on how strength training applies to ultimate frisbee.

A good place to start is a take by runners world on strength training for runners. https://www.runnersworld.com/training/a20074772/strength-training-for-runners/

They lay out some good arguments for the basics of strength training and how it relates to an activity that is primarily lower body locomotion centric. Here are my thoughts on the specific movements we choose to start with in our ultimate frisbee strength training class:

Front Squat:

Front squats to a great job of building lower body strength and flexibility with a quad bias. We use our quads to decelerate (think the hollywood squares drill or anytime you are making a cut) so having a strong base including quad strength is important. Additionally front squats require good ankle flexibility and strength. Because the ankle is put into dorsiflextion (https://www.healthline.com/health/fitness-exercise/dorsiflexion) the achilles and calf are stretched and strengthened reducing the risk of achilles tendonitis or injury.

Shoulder Press:

A lot of frisbee players injure their shoulders laying out, or even just extending to catch a frisbee in a contested space. Improving shoulder strength and flexibility enables us to survive contact with the ground or other players with reduced risk of dislocation or fracture. Strict pressing or overhead pressing is more beneficial than bench pressing because it requires overhead flexibility and strength. If we struggle to press weight overhead often it is due to shoulder inflexibility first and lack of strength second. Gain the flexibility, build the strength, keep the arms in the sockets.

Kettlebell Deadlifts:

Kettlebell deadlifts are the first in a series of progressions intended to strengthen the posterior chain. We can be more explosive as sprinting athletes if we have a strong posterior chain. Learning to brace and engage your core, transferring power placed into the floor from your posterior chain all the way to your hands/arms through your core train and strengthen your body in the application of force to move a heavy object. 

Thoughts on strength, to power, to speed to endurance:

The goal is to progress through a sequences of movements that enable us to accomplish three things over time:

1. Build muscle activation/strength within our existing flexibility, improve flexibility (range of motion available to us), and increase strength in the new range of motion we’ve gained. 
2. Transfer that strength into explosive power, moving from slower movements (press, squat, deadlift) into faster movements, moving similar weights over similar distances but faster. Squat to a jumping squat, wall ball or box jump. Deadlift to a kettlebell swing, power clean, or jumping trap bar deadlifts. Strict press to a push press, push jerk. Explosive power, that is applying a force quickly, is what really enables us to move faster on the field. Explosive power requires and is built on top of a strength base through a long range of motion.
3. Finally building the muscular endurance and cardiovascular endurance while retaining the strength, flexibility and power we’re now able to operate with allows us to move faster over longer periods of time, like over 3 days…

You aren’t your users

I really enjoyed this most recent Under the Radar by Marco Arment and David Smith. It made me think of a lesson I learned earlier in my career as a developer/designer. When you are building an application that meets a need you have, it’s easy to use yourself as a proxy for the product user when designing/developing.

In the best case this approach helps you to develop an application that can delight users by meeting not just their vocal needs but also their unarticulated needs. Because you know yourself and your needs more intimately than anyone else, you can build really cool solutions to problems that your users wouldn’t be able to put into words. Your intuition will guide you to spend more time polishing areas that others wouldn’t and often times that pays off with a better product experience. This is possible for teams that are solving problems they themselves don’t understand, but it requires much more UX/UI spend, lots of prototyping and lots of user testing. Sounds expensive.

So while this approach can be a great time/expense saver for smaller teams or independent developers, it can unfortunately also lead you to a substandard product/market fit. It sounds obvious to say but it’s easy to forget that you aren’t the only type of user your product will have. I can hear echos of this in Marco’s description of his aversion to prompting users by sending push notifications to point out new podcast arrivals for new users. Marco finds those things annoying and maybe a bit needy. Do I find it annoying when a new app prompts me to come back and check out some feature I haven’t used? Yes, but that’s also because I’m a tech nerd and when apps try to tell me how to use them I get annoyed either because “shut up I already know that” or “You think I can’t figure this out on my own”. The much much more common user reaction to a helpful notification is going to be “oh, hey that’s handy I didn’t know that” or worse case “I’ve already given up on that app so this doesn’t matter”.

It’s very easy for us to transpose too many of our own needs and traits onto our pretend users if we aren’t able to be introspective about why we care about the things we care about in the products we are creating. A small amount of time creating personas for some of your anticipated users and where and how you fit into them can go a long way to improving your product.

You can’t redefine someone else’s problem

Walt wrote an interesting line in a recent think piece on the Verge. He makes a lot of interesting points as usual, but one little quote got me thinking about an easy and frequent mistake we can all make. In the process of looking for solutions and making commentary we often times subtly redefine the problem someone else is having.

But there are other paths. For instance, that HP Spectre I mentioned earlier is actually a tad thinner, but manages to add a couple of additional ports on the back edge of the machine, and to use full-fledged processors, even if they required a cleverly designed fan.

In the emphasis I added above you can see Walt doing this with the design of the MacBook (non-pro) that Apple has been shipping for the last few years. I used the first design of that machine and agree with all of Walt’s criticisms.

What I don’t agree with is the idea that you can hold up another computer that makes different design trade offs as a direct comparison to the trade offs on this particular computer. The design brief for the MacBook probably read something like “needs to be able to email, browse the web, use office class applications, road warriors dream, long enough battery to last cross Atlantic flight”. Walt would rather have a computer that makes different trade offs. To call this a symptom of “overdesigning” a product isn’t really accurate. It’s a symptom of designing a product for a different set of trade offs than the ones you prioritize. Walt is right, this happens all the time, and I see it as a positive thing.

The uncharitable usage of the word Design implies frivolity. But I think what is happening more often is that companies are being very focused, and in the process eliminating a lot of use cases from their product. This isn’t a bad thing, it allows products to be brought to market faster and with less budget, however it does eliminate possibilities, and in my experience reading the tech press, there is nothing that riles a tech journalist up more than a product that could do something if only the product designer had made the product the way the tech journalist thought it should be made.

Technical Journalists do their best work when they put themselves into the role of a user of a product and seek to understand how the company creating the product has done the work of designing the product trade offs to fit that use case.

Product designers do their best work when they are able to capture a clear picture in their head of how a new thing can be created by questioning the assumptions under which we all operate, and integrate some novel thinking into a product in a way that feels like a natural consequence of problem solving.

The challenge of defining what people want

I think John Gruber has issued a somewhat oversimplified argument when he says:

…people want more different native apps than ever before.  via daring fireball

I think any designer needs to be careful to not conflate the mechanism used to achieve a desired result with the result itself. Gruber’s assertion here is that users want native applications. I believe that what he is really saying is that users want responsive applications, that work while disconnected from centralized services, and that show up on their home screen. Those are not web apps as they are available to us today, but as in anything in the software world that is a flexible assumption.

My point here is a relatively minor one, but one that can be a common roadblock for creative problem solvers. If we don’t question the assumptions of the underlying mechanisms we will unnecessarily limit the potential solutions available to us. Sometimes the most obvious and straight-forward solution to a problem is found by questioning the underlying assumptions. Technology problems are sometimes solved by changing the personnel around them, or personnel problems can be solved by augmenting the situation with technology. Emotional problems can be solved with exercise, and your exercise limits can be overcome by understanding that your current limitations are psychologically imposed.

If we assume that the solution to responsive disconnected applications can be nothing other than compiled Objective C delivered through a curated app store we cut ourselves off from a wealth of potential solutions to the problem. Only in redefining and clarifying our users unarticulated needs are we able to break through creative barriers and deliver truly ground-breaking technological innovation. Granted I love native applications and “want more different native apps than ever before”. I think John’s statement is true for today, but that it’s an assumption that should constantly be challenged and revisited. We can’t simply condense the current failure of web apps to deliver on users needs to be a condemnation of the entire pursuit.

Solve problems the way they want to be solved

via flickr user origamijoel

Most folks have a preferred problem solving method. Some know this, and stick to those well worn forumulas. Some don’t, or forget, or let the fear of missing out trick them into going after opportunities they shouldn’t. One of the keys to successful problem solving is to understand your natural approach and when that approach does or doesn’t fit the problem you are considering addressing.

Let’s look at Apple Maps as an example. With almost unlimited resources and skilled/motivated workers why couldn’t Apple seem to make Maps just work? I believe the primary reason is that their culture doesn’t value the type of work it takes to create a killer solution to that problem. Apple is very good at giving designers time and space to come up with brilliantly innovative solutions to problems. Elegant solutions are coveted. Wherever possible a solution is simplified rather than made more complex.

Unfortunately Mapping is not a simple problem, nor is it one that can be reduced. (see the traveling salesman problem) Instead of one single elegant solution to a large problem, mapping requires many small imperfect solutions. Google is willing to embark on a massive, inelegant solution to a complicated problem. (Remember their company was founded on the premise of “downloading the internet” so you could easily search it)

Finding point A on a map and getting directions from point A to point B doesn’t need to be perfect or elegant, it just needs to work. Apple as an organization has never been satisfied with making something just work (ironic given some of their historical marketing efforts). Unfortunately the solution to make maps “just work” is to add a parenthetical “even if it’s inelegant like driving around taking pictures of every street in the world” to the solution.

Hills Hills and more Hills

Seth Godin chooses the same metaphor as I did in a recent post.

Attacking only steep cliffs where no progress is made isn’t particularly effective either. No, the best path is an endless series of difficult (but achievable) hills.

via Seth Godin

It’s all about the hills…