Why Google was correct in Chrome dropping H.264

” This is crazy, why drop support for {propriety tech} that works and was pretty ubiquitous? ”

Now you can replace {propriety tech} with either H.264 or Flash. So why do we laud Apple dropping Flash but call Google’s recent action a blow to the open web.

It was always surprising to me that H.264 somehow became the standard for open video, even when the license terms have been mentioned so often. To the folks who are passionate about the open web, I say you aren’t trying hard enough. Open web is a hard goal to reach, h.264 seemed like an easy out, a solution to a problem we’d deal with later.

Ubiquitous support for a proprietary technology does not make it open, no matter how hard you may wish it to be.

So why did Google do it? One theory is to take a shot at Apple. But this announcement seems like a precursor to a very expensive exercise for Google itself: If Google is really serious about WebM, which this seems to indicate, they will have to transcode all their YouTube assets to the new format, and start building support for this into their other products, like Android. Seems too much like “Cutting off the nose to spite the face” kind of action.

The move makes perfect sense for Google. Google is not a company that thinks short term. If the current trends in online content continues, video will be a ridiculously huge part of the web. Its reasonable to imagine that advertising in that world will be pretty different. Current ad insertion strategies rely on pre / post roll ads and overlays controlled by the chrome of the video player. But the future could be very different, with things like dynamic ad insertion right into the media stream itself. For example, if the ad is embedded dynamically into the video stream, you could download the video and watch it offline, and still be guaranteed the ad was viewed, even if the video was “stolen”. Maybe such ads could even get more creative, something like embedding iAds into the video stream. [update] Also I imagine there will be a huge spurt in live video and video chat, now that more and more phones are coming out with front facing cameras. This makes relying on a licensed codec hard, especially on a scale like Google’s.

This is only one concept of the future of video advertising, but it underlies the fact that the video format could evolve to be very different from what we see today. It would be easier for Google to convince a group maintaining an open spec (that Google will definitely be a big part of) to add such capabilities than suggest it to a group that they don’t really influence and wait for them to decide to accept or reject.

Dropping H.264 support is a real blow for the short term but if enough investment is made in a truly open spec, I’d say it would be worth it.

The big question now is, will Microsoft accept WebM as well ?

[update]
One of the best comment on this was on reddit:

In the short term. This is a power play. The market is fragmented (e.g., no Flash on iPhones) and things will eventually coalesce, and Google doesn’t want them to coalesce into video tag/H264. They’re gambling that they can use their position (the most-used browser by techies, plus the most-used smartphone OS in the world) to force everyone to move off of H264 and onto open codecs.

Notes on Game Mechanics

The recent explosion of “game based” apps out has led me to read quite a bit about the topic. Here are some notes on books, articles and presentations I have been reading:

Some Rules for Game-Based Systems (from the book Game Based Marketing):

  • Favor long term loyalty not short term competitions
  • Dont offer direct prizes, offer virtual points. Real world value of virtual points can be tweaked at the time of redemption.
  • Virtual points can also be used for virtual goods. Virtual Goods Economy is 5.5 Billion Dollars
  • Does redemption matter? Huge number of points are almost never redeemed
  • Top 5% of airline customers generate 40% of the revenue
  • Create opportunities for elite members to show their eliteness (like lounges in Airports open only to elite members)
  • Create artificial scarcity and rewards around it.
  • First reward should be soon
  • Casino style *random* rewards create short cycle reinforcement
  • Need both long term goals (level ups) and short term (mini games/challenges)
  • All game based systems need:
    • Large community
    • Point System
    • Simple Communication platform

Types of Players (from the book Game Based Marketing):

Four Player types based on motivation:
Achievers
Go to great lengths to get rewards
Dont care for winning in a vacuum: need an audience (leaderboards)
Need the Socializer
Socializer:
Want to build meaningful interactions
Often are more about helping others win rather than winning themselves
Explorers:
Need rich virtual worlds to explore
Love to share detailed accounts of their explorations
Long games with repeated actions bore them
Killers:
Need simulated win & lose conditions
** The Naive Player **
Fairly unaware
Need to be made aware that a game is going on
  • Achievers
    • Go to great lengths to get rewards
    • Dont care for winning in a vacuum: need an audience (leaderboards)
    • Need the Socializer
  • Socializer:
    • Want to build meaningful interactions
    • Often are more about helping others win rather than winning themselves
  • Explorers:
    • Need rich virtual worlds to explore
    • Love to share detailed accounts of their explorations
    • Long games with repeated actions bore them
  • Killers:
    • Need simulated win & lose conditions
  • The Naive Player
    • Fairly unaware
    • Need to be made aware that a game is going on

A really awesome presentation on the shallow game design that seems to be creeping into web properties by Sebastian Deterding

“Yet when I look at most gamified applications today what they do is use game elements to tie us even more tightly into our worldly toils and schemes. They are glorified report cards that turn games into work rather than life into play, and users into pawns instead of players”

Pawned. Gamification and Its Discontents

The secret to Farmville’s popularity is neither gameplay nor aesthetics. Farmville is popular because in entangles users in a web of social obligations. When users log into Facebook, they are reminded that their neighbors have sent them gifts, posted bonuses on their walls, and helped with each others’ farms. In turn, they are obligated to return the courtesies.

  • Farmville is defined by obligation, routine, and responsibility;
  • Farmville encroaches and depends upon real life, and is never entirely separate from it;
  • Farmville is always certain in outcome, and involves neither chance nor skill;
  • Farmville is a productive activity, in that it adds to the social capital upon which Facebook and Zynga depend for their wealth;
  • Farmville is governed not by rules, but by habits, and simple cause-and-effect;
  • Farmville is not make-believe, in that it requires neither immersion nor suspension of disbelief

Other links:

On Ideas, implementation and iteration

I have way more ideas than I have the capacity to execute.

That seems not an uncommon issue among my friends, and unlike that saying about ideas, I actually dont think everyone has ideas. Or rather, not everyone is passionate about ideas or seeing them through to some kind of product/feature anyway (people often mistake opinions for ideas). But there are definitely a lot of idea people out there. And in today’s hyper connected world, this has enabled a slew of services ranging from idea gathering platforms like Uservoice, Kindling to complete “idea to product” services like Quirky to emerge. [Update: Wall Street Journal has a fantastic article on Ideas that you must read, also my friend Karl Martino has just published a post with 3 other links on ideas]

One thing I have come to agree with is the thought that ideas are merely multipliers of execution, i.e. ideas are great and everything but what really counts is the execution. Occasionally, when someone shares something interesting and someone dismisses it saying “Oh I had that idea a while back”, I wince. Its that kind of thinking that often leads to people posting stuff like this, feeling cheated of success that should have been theirs because they had the idea first.

Execution is everything.

Or is it? Yesterday I read a rather awesome post by Jeff Atwood on the growth of his company (Stack Overflow) and his continued belief in what he calls “Boyd’s Law of Iteration” based on the findings of USAF Colonel John Boyd:

Boyd decided that the primary determinant to winning dogfights was not observing, orienting, planning, or acting better. The primary determinant to winning dogfights was observing, orienting, planning, and acting faster. In other words, how quickly one could iterate.Speed of iteration, Boyd suggested, beats quality of iteration.

The same seems to be true of product development. Jeff references projects like Google’s Chrome and Android and how they are getting to be really successful because of their fast iteration cycles. The official Chromium blog recently published a post on the accelerated release schedules and further mention their three goals for the accelerated releases:

  • Shorten the release cycle and still get great features in front of users when they are ready
  • Make the schedule more predictable and easier to scope
  • Reduce the pressure on engineering to “make” a release

Over the last few years, I have released quite a few projects including:

  • FlexAmp: An online mp3 player that plays audio from an online storage system like Box.net (now broken)
  • DiggGraphr: A treemap visualizer for Digg stories (now broken)
  • EspressoReader: A desktop client for Google Reader

A huge personal milestone for me was EspressoReader’s second feature release. I realized that of all my projects (not including open source libraries like OpenPyro of course), Espresso was the only project that ever had a second iteration that actually evolved the app (my other projects have had maybe one or two minor updates for bugfixes). The funny thing is, I have a lot of personal notes on features for v2 of all of  them.

So here is why I think a lot of my projects never have a significant version 2:

  • The developer itch is gone: I started a project because I was interested in a platform or an API and the part I was curious about is gone.
  • The last 10% sucks: I realize that there are so many edge cases to consider. The app is very demoable but isnt at a point where anyone can actually use it for long without hitting a bug
  • The damn codebase is a mess: To get to the part where the app proves the concept, I have taken shortcuts that have compounded on each other. So now there is a lot of work involved to get the app to a state where it has the same functionality as before but I don’t groan every time I open the project’s source.
  • There is a shiny new toy to play with: These days its iOS and Android, both platforms I am interested in and spend enough time between 9-5 on to be able to take on a project involving em (well more iOS than Android as of now). Its really hard to stay focussed on a platform that is not the shiny new thing.

I hope as I mature as a programmer, I can curb my tendencies to jump off of projects for the above reasons. All I can tell you right now is that there is definitely at least a third version of EspressoReader coming out in the next few days :).

Rethinking GUI Programming Paradigms

I have to say the current state of programming and application development do bother me. I feel after so many years of programming, making things like desktop applications and web applications should be a lot easier.  Over the last few years I have done a lot of application development in a bunch of technologies like Java, SWT, Flash, HTML/JS and more recently Objective C. And yet our development environments (or IDEs) are pretty much the same as 20 years ago with vi or emacs. I have a lot of friends who have really good ideas and yet they are pretty daunted by the idea that they could build their applications themselves, and I dont blame them. Most of the advice programmers give them is to read a couple of books and download Textmate.

Their have been a lot of “GUI builder” applications over the years and pretty much all of them have been panned by “real” developers. The usual (and often justified) reason has been that they generate crappy code. Its shocking to me why GUI development remains such an afterthought in todays world.

Did Flash get it right?

Like it or hate it, Flash was probably one of the first tools that got it somewhat right. Its success and now the reason it gets panned, is because it made it very approachable for someone who was not a programmer to get something in their mind out on the internet. The ability to draw a shape and then attach some behavior to it in code was huge.

This was my path to it too. I came to the US persuing my graduate degree in VLSI Engineering (chip design). Somehow I got a job at a University Learning Center with a very loose mandate: the director of the center had a lot of ideas on e-learning with video and had just seen some Flash video sites and was fascinated (remember Flash video only came around in version 6 of Flash). My role was to “make something cool for e-learning and video”. I had never programmed before but had some experience with Flash animation, mostly making small animated movies hoping to get on Atom Films someday.

In about 6 months I had gotten really addicted to Flash since for the first time, my animations could respond to the user. Because of Flash, I quit VLSI and moved to Software Engineering, with my final thesis in creating cross language bridges between GUI and non GUI parts of an applicaiton (using Flash and Java). The approachability of Flash back then was my gateway drug to programming. Flash has since “matured” to a real programming language but I feel at the cost of the approachability the earlier versions had.

Ugh Java

Moving to the Software Engineering team was a bizarre experience. The Graduate School was a Java school and I got started working in Swing. It was crazy! I could do any kind of UI in Flash in a heartbeat but getting Java to render a custom designed button was virtually impossible (so we always stuck to the default lookAndFeel). Actually back in the day, I don’t think there was even a Java IDE like Netbeans that we used. Everything was written in VI and then compiled by using the command line.

Interface Builder: A good idea that was never completed ?

Working with Interface Builder, the tool used to develop User Interfaces for Mac apps,  for a while, I see the thought process that must have been going on when it was being developed. The concept of laying out the UI and tying it to the application logic components is a good one. But IB feels like the team was disbanded halfway into the project. The tool as it stands right now is such a pain to understand that most new developers who get into Objective C programming try to avoid it as much as they can.

The 280 Atlas IDE for Cappuccino seems to have taken the IB concept and extended it to the web. I like this better than IB if for nothing else than gathering all application windows in one. The floating canvases on IB get annoying really fast.

http://www.viddler.com/simple_on_site/1db9bf4d

Drag and drop application development:

I love this video. I am sure to scale this to “real” GUI development would be a significant amount of work, but that would be the holy grail (at least for me)

http://vimeo.com/moogaloop.swf?clip_id=1105302&server=vimeo.com&show_title=1&show_byline=1&show_portrait=0&color=&fullscreen=1

3d physics simulation with Wiimote from Balazs Serenyi on Vimeo.

The same idea is also echoed in MIT’s Scratch project. Scratch declares its mandate as making it easy to “create your own interactive stories, animations, games, music, and art”. While the focus seems to be towards animation and getting kids to learn programming concepts, can it be extended to real world projects ?

Another interesting project that surfaced recently was Sikuli. Check the video on that below. My favorite part of this was that the “script” actually references the images that behavior is assigned to. You dont need to understand variables at this point (You may need to to write business logic if you have to, but thats a bridge you can cross later)

Human-readable “code” with Ruby and Cucumber:

Just getting started with the Ruby programming language, I have been really impressed by its focus on readable code. An open source project called Cucumber is also fascinating. I haven’t done any work with it but have attended a few sessions on it in different user group meetings. Cucumber takes the readability of code even further with a goal of having non technical folk be able to define a site’s functionality very granularly.

Final thoughts: Enough with the text editor already

Using a pure fast text editor for developing applications seems to be the badge of a real developer. But writing lines of  text to express ideas in my head seems to be a paradigm that should have evolved a while back but hasn’t. Am I overly simplifying the problem? Possibly. But after so many decades since the inception of programming there is very little to justify the high barrier to entry it presents to most newbies. To me the current state of programming feels like the state of mobile phones before the iphone and the ipad. Whatever anyone’s feeling on Apple are, its hard to deny how much they humanized computing.

Its time to do that for programming too don’t you think?

Some other related interesting stuff

  • The Adobe design team recently posted some thoughts on improving the programming experience in Flash.
  • Some good thoughts on XCode UI enhancements

On Breadth First and Depth First thinking

Great talk by Don Norman, a founder of The Cognitive Science Society, and widely considered to be the first to apply advanced human factors to design via cognitive design on The three ways that good design makes you happy:

The three ways he talks about are:

  • Visceral: How pleasant things seem to work better.
  • Behavioral: How good design lets you feel in control.
  • Reflective: How people prefer design that reflects their personality.

One interesting point he makes is how a happy state of mind is puts the brain in “breadth first search” mode and is more conducive for out of the box thinking, but tension and some pressure puts you in a “depth first search” mode (as dopamine gets added into the system). Moment of self realization here for me personally: as a programmer I have often preferred tighter deadlines (note: not to be confused with unrealistic) to open ended project timelines. I need the pressure to focus. A bunch of my programmer friends say they feel the same way. Thats why the burn down charts for closed work tickets is almost never the ideal one:

ideal_timeline2

(note the change of slope as projects approach end dates = more pressure)

There is often the temptation (by me anyway) to carry the model of deadline driven development to design, but Don Norman’s talk indicates that this would be a bad idea, especially if you are conceptualizing new experiences. How much pressure in terms of deadlines and deliverables can anyone apply on design teams before you kill lateral thinking thats absolutely required for creative teams. However its just as easy to fall into the time sink of finding the perfect experience. Voltaire’s quote about Good being the enemy of Great comes to mind again.

So concept in breadth first mode, execute in depth first.

The concept also seems applicable to application/web design around browse and consume. Browse pages/screens, where there isn’t an end goal really and a user is out looking for “something interesting”, should put people’s brains in breadth first mode, with more emphasis on visuals, etc, but when the user is in content consumption mode, like say on video consumption pages or web search, pages, a muted design may be a better idea. It certainly explains why Google Search pages, which most of us use to get to something we need and not really browse, work so well, but on all their other applications where users are more about entertainment than work, their designs feel awful.

Notes from Jonathan Rosenberg’s talk on Rules to Success

Fantastic talk by Jonathan Rosenberg, Senior Vice President, Product Management at Google on Rules to Success. The talk was so heavy with aphorisms that I ended up watching it twice and noted down his various points. They may be slightly off missing a couple of points here and there, but still pretty educational (for me at least 🙂 )

Starting note: I loved this statement at the beginning of the talk:


If you want to build a ship
don't herd people together to collect wood
and don't assign them tasks and work,
but rather teach them to long for the 
endless immensity of the sea.

Antoine-Marie-Roger de Saint-Exupery

Rules on Communication

  • Overcommunicate always all the time. You cant communcate enough.
  • Openly share everything with your collegues. Trust your people and give them this info. Trust breeds loyalty.
  • Repetition does not spoil the prayer.
  • Each word matters. Be crisp and direct and choose each word wisely. Its is not rambling: Leave out the parts that people skip. “I would have written a shorter letter if I had the time” : Mark Twain
  • Great leaders are great teachers and great teachers are great storytellers. Narrative is what that matters.
  • On Talking:
    • As leaders you learn more by listening than talking. Listening makes you humble and smart. When you listen you learn how things work, when you talk, you echo how you think things work.
    • If you must talk, ask questions. People learn more about you from your questions
    • If you actually know the answer in a business situation, talk, but back up with data.
  • Try to respond instantly. If you dont respond instantly, everything stalls.

Rules on Culture:

  • Avoid Hippos: (Highest paid person’s opinion)
  • You should not be able to read an org chart by looking at the product (for example, you cant look at the apple org chart when you look at the ipod).
  • Healthy orgs crush bureaucracy in all forms.
  • Ask for winning strategy and look for good tactics.
  • People are more productive when they are crowded. Social groups moderate bad behavior.
  • Empower the smallest of teams. Small teams accomplish more. Read the mythical man month. Create teams about the size of a family.
  • Working from home is cancer. Ban it.
  • Engineers and product managers add complexity, marketing adds management layers, sales adds coordinators.
  • Knights are knights and knaves are knaves. Tom Peters: There is no momentary lapse of integrety.
  • Focus on value rather than costs.
  • Never suggest copying a competitor. You can do better.
  • Hope is not a plan.
  • Success breeds the green eyed monster. Take away with surprise and humility.
  • Do all re-orgs in a day

Rules on Hiring:

  • Know how to interview well.
  • Gimmicks like free food, games, etc aren’t that important. People come to google to work with great people.
  • Managers don’t hire people. Committees hire people.
  • Promotions should be a peer review process.
  • Instead of laying off the bottom 10% dont hire anymore.
  • Dont hire specialists, esp in high tech. Change is the only thing permanent. “I have no special talent just passionate curiosity.” : Einstein.
  • You cannot teach passion. Nothing great was ever achieved without enthusiasm. If the enthusiasm isn’t palpable in a room, its not there.
  • Urgency of a role isnt important enough for a quick hire.
  • Identify and purge bad eggs.
  • Diversity is your best defense against myopia.
  • You cannot punt the management training program.
  • Life is not fair. Disproportionately reward risk takers and performers. Don’t tell people they did a good job if they didn’t. Real life is a meritocracy. Celebrate and reward what you want to see more of.
  • Build around the people who have the most impact.

Rules on Decision Making:

  • Decision making is about concesus and not unanimity. Dont spend hours towards unanimity. Good enough is better. Voltaire: “Perfect is enemy of the good”.
  • There is no consensus w/o dissent. Patton: If everyone is thinking alike then someone isnt thinking.
  • If there is doubt about what to do think abt customers perspective.
  • Choose your goals wisely. If the goals create conflict change the goals.
  • No-one of us is smarter than all of us.
  • Where there is harmony there is no innovation. Discuss and arguement leads new ideas and new meaning. Innovation comes from disagreement.

Rules on Fostering Innovation:

  • You cannot manage creativity to manage risks. Innovation comes from creativity.
  • Create a culture of yes based on optimism and big thinking.
  • Never stop someone from a good idea for a better one. Darwinian rule works. Best ideas win and others fail.
  • A leaders job is not to prevent risk but to recover from failures fast. Good failure happens quickly.
  • A good crisis is a terrible thing to waste. Nothing teaches like a crisis.

Rules on Humility

  • Learn something new to remember how hard its to learn. Teach something so you can learn.
  • Never stop learning. School is never out.
  • Humility is correlated with age. Arrogance is inversely correlated with age.
  • You get personal leverage from delegation and inspection. Smart people suorround themselves with smart people.
  • Judgement comes from experience and experience comes from errors. You learn more from your msitakes. At google screwups are written and archived to learn from for the future.
  • Smart ppl can smell hypocracy. Make sure you spend ur time on things you say is important. Culture is set from the top.
  • Don’t burn bridges.
  • Would you work for yourself?
  • Write a self review and be critical about yourself.
  • Communicate and confess when you make a mistake.

Final note:

Develop your own style.Styles that worked for others may not work for you (ends with the story of Cortez’s burning the boats, which may have worked for him, but Johnathan prefers the way of the Isreli tank commanders who lead by shouting “Follow me”)

Value vs. Revenue

I have been working for Comcast Interactive Media for over 5 years, thats a lot by some measures and barely anything by others. This is my first full time job and as those go, not particularly shabby. Off late I have been involved in more R&D/labs/prototypes kinds of projects ever since my move to the UX Technologist position. Sometimes I still struggle with the amorphous nature of this position. Things were a lot clearer when you executed on someone else’s plan. I am closer to product development now which is great and gives me a new look at how some of the things we build get concepted. And you have these interesting conversations around things like ROI on User Experience, the importance of time invested in design vs the need for getting features out of the door quickly, the love/hate feelings towards 300×250 ads of dancing polar bears on our sites. Its fascinating to see the camps erected on either sides of these debates.

Trying to pitch a concept to a friend of mine recently, our conversation moved towards revenue models. Usually these are answered by either “well, there is slot for an ad here…” or “We’ll increase user engagement by x “. However, I realized for that at the core, I didnt really care for the rev model immediately. I was really trying to work on something valuable. Something I can look back in my later years and be proud of, not because it would help my career but because I would have made a difference (in as significant a way as a web programmer can I guess) and people would use it.

The thought of course had been crystallized by the book I have been reading: Daniel H Pink’s “Drive”, I haven’t finished it yet, but its a great read so far on what motivates people to do what they do.

Looking back, I realize I have been making these distinctions for a long time, just not realizing it: why I was glad I didn’t write an app like “iFart” even if it made a lot of money and why working on projects that I perceive no value irritates me like crazy. “Drive” says this is a fundamental human characteristic. Nothing kills morale than knowing you are working towards revenue oriented goals and not value oriented ones. That morale is hard to substitute even by money. And you can get a lot of people working on something if you convince them of the value of that. Value and revenue don’t have to be in opposition. Something valuable can and will generate revenue, but the goal of your project cannot be to make something revenue-able, it has to be to make something valuable. If your goal is revenue targeted only, your success if any would be pretty small.

Apple lost someone today too, Director Jerome B. York, and they showed it by changing their entire homepage to pay respect to him:

apple

Bet they lost some revenue on that one, but I bet it makes them a lot more valuable a company

Collected links from the whole Apple/HTC lawsuit thing

So, Apple sues HTC with over 20 patents, most of them idiotically trivial, including for example, Time-based, non-constant translation of user interface objects between states, which to the lay-developer should read “transitions”. Ah so Apple patented transitions in 2001, somebody better tell all the developers who are using things like jQuery effects, Tweenlite etc.

Steve Jobs says “We think competition is healthy, but competitors should create their own original technology, not steal ours.” , which is hilariously ironic when you see an earlier video with him saying how Apple has been shameless about stealing great ideas

This time even the die hard mac-heads call the craziness: Wil Shipley, Mac developer and author of the very successful Delicious Library application, writes an Open Letter to Steve Jobs on the whole thing.

Wait, what, you dont know who Wil Shipley is? Well he has a Wikipedia entry AND has starred in his own Penny Arcade strip. Yeah, so he’s kind of popular like that:

But I digress. Die hard mac fanboy John Gruber posts a good writeup on this whole mess, and more folk have started associating Apple with Evil, as evidenced by Paul Grahm’s comment on Hacker News and Tim Bray’s recent Tweet.

Meanwhile, Android Central posts a pretty awesome infographic on patent litigation in the mobile space

while someone tries to patent the whole practice of patent trolling. How meta…!

On Innovation in big companies

These notes are from BarcampPhilly ’08 that were lost in the depths of my computer’s hard disk and I only just found again. At the event, a few of us from CIM held a round table discussion on innovation, especially developer led innovation in big companies. Here are the points that people mentioned:

  • Innovation only comes from free cycles, even the best ideas need time to be thought through
  • Leverage something thats existing rather than a brand new idea
  • Agile development can actually hurt innovation with too much transparency. Its hard to justify something that you may feel has a long term win
  • Technical managers should whet the ideas of their team members
  • Innovation comes from bottom almost never from top
  • Innovation = Risk
  • True story: At AOL, the AOL IM service was declared a risk
  • Constraints actually push innovation
  • Innovation wont happen without proper incentives/rewards.
  • How about cross team innovation. How do designers/developers collaborate to innovate?

So this has only taken almost a year to put up, with BarcampPhilly ’09 coming up soon. Since then there has been a few opportunities within CIM to push bottom-up innovation, including a labweek for all of engineering.