Mark Kawakami:  Touch Football: Rebuilding Yahoo Fantasy Sports for the Modern Web

Mark Kawakami: Touch Football: Rebuilding Yahoo Fantasy Sports for the Modern Web


Jenny Donnelly: Hi, good morning everyone. I’m pleased to introduce our next speaker,
Mark Kawakami, who works on the best sports site in the world, Yahoo Sports, talking about
touch for sports. [applause] Mark Kawakami: Alright. As she said, I’m Mark Kawakami, I work for
Fantasy Sports. I’ve worked here since pretty much all the
history that Dav Glass was talking about. I’ve been here for that. That’s not actually true, but I’ve been here
since 2007. Today the talk is titled Touch Football: Rebuilding
Yahoo Fantasy Football for the Modern Web. If any of you has seen my previous YUIConf
talk you’ll think that I’m giving the exact same talk, because that was also about rebuilding
Yahoo Fantasy Football for the modern web and specifically focusing on touch devices. I promise you this is different, but yes,
if I have the reputation of being the Fast and Furious franchise of tech conference speakers,
I think that’s fair. Okay. What we’re going to be covering. I’m going to go over the goals of what we
wanted to do with this year’s Fantasy Football. Lots of changes, I can’t cover them all, but
I’ll cover the stuff that I was closely involved with. Then we’re going to talk about specifically
how we did it. Lots of use of delegating, taps. I’m going to have a little confession to make. Then we’re going to talk about keyboard accessibility
because it’s really, really important. Then after that I’m going to go insane and
I’m going to put the question to you what’s better, a rave or a clown sock, which should
you choose. And there’s a correct answer, or there is
if you’re insane. Then after that there will be questions, and
given that I will go insane in number four there might be a lot of questions. Alright. So what were we trying to do when we were
doing fantasy football for this year? Well from my perspective, from the perspective
of the interaction, we wanted an interaction for our rosters that works great on all three
screens. You might be saying wait a second, that’s
what you talked about last time, making sure that the rosters worked on touch devices. And yes, true, but what we had last time was
that it works on touch devices, and I admitted this actually in my last presentation. I had a whole section of it called I can read
minds, sort of, and it was about all the complex things we had to do in order to get drag and
drop working, where had to do it different between a scroll gesture and a dragging gesture
which involved a 25 millisecond pause, blah blah blah. But we ended up with this, the idea that you
can reduce frustration with trying to figure out what the user’s trying to do, but the
better thing is to eliminate frustration with great UI. So that’s what we tried to do this year, we
tried to create the great UI that actually really fit in touch devices rather than simply
trying to emulate the regular desktop experience. Because ESP is for chumps. You shouldn’t do it. Don’t try to read the user’s mind, try to
present them an interface that works well for them. Basically the idea is we want to go from it
works on touch devices to it works. Here’s what we came up with. This one is Firefox. This one is Chrome, there we go. I’ve got to make sure I don’t use one of my
real leagues here. Okay, so before you used to be able to drag
these things around, which is great on the desktop where the drag gesture is very different
from scrolling because you’re going to be using entirely different buttons for it. You use the scroll wheel or page up or page
down. But on touch devices scrolling and dragging
are the same. We wanted something where we could differentiate,
so we have a tap gesture which highlights what’s available. You just tap again and you can basically move
things that way. This works great because it’s very easy to
differentiate between a tap and between an actual scroll. There’s no confusion about it. And the only confusion really came about from
people who were so used to drag and drop that when they came to this, even though we threw
up a little helpful thing, people don’t read help text, they all wanted to drag apparently. They’re all like agh, it doesn’t work, until
they figured out all they had to do was tap on the row or click on the row and it would
move around. We had a few alternatives when we were working
on this. There were other things that we are likely
to bring up. Let’s see. What we’re doing right now, this is the prototype
that we built in order to evaluate… Oops. In order to evaluate the different ways. We also came up with another idea that we
had called tap and place, which is where your options just show up right below. So we experimented with a whole bunch of options. This is one of the cool things you can do
with YUI, because switching between these options was just a single attribute change. I’m not going to show you the code for that
because we’re going to move onto other things, but the most important thing that we got out
of this that I didn’t even quite realize we would get out of this was that we now have
a roster that is available so much faster. Basically it’s available as soon as the page
loads. If we just do a full page reload, the roster
is available to use, available at work, the moment the page is available. That’s partially from getting away from drag
and drop. One of the things we saw is that drag and
drop is fantastic for drags. You can create drags really fast because you
can delegate them, but you have to create the drops individually. That takes time. We were also doing a lot of work behind the
scenes. But what we do now is we are able to get this
thing to show up basically instantly and there’s a few ways we’re doing that. The most important thing is that we delegate
everything. You delegate basically every bit of code. You see we’re delegating click events, key
events. We’re going on a click outside but you can’t
technically delegate that. We delegate animation end events, we delegate
everything. I really think that delegate, YUI makes delegating
so easy to do and it works so well that that should be the default thing, that we should
teach delegate first and then teach regular events. You should never consider delegates to be
something exotic or special. Delegates are how you should first look to
assign any event handler. Does everybody here know what the delegate
pattern is, by the way, in case you don’t? We’ll go into it really quickly just in case
you don’t know. Basically delegate uses event bubbling so
that you can listen at a higher level. Say you want to attach event handlers to all
the a tags inside of a list. You can go through and search for ul li a
– that gives you all the a tags – and attach an event handler to each of them. But that’s really expensive. What delegate lets you do is basically it
essentially attaches an event handler to the ul element and just listen for clicks to the
a. YUI makes it so easy that it’s basically transparent. One just performs much better and is much
faster than the other. This means we only have to attach a couple
of event handlers when we initialize the roster instead of 30, 40, probably over 100 when
you consider all the types of things we need to listen to. So that’s one of the things we did. One of the other things we did was we started
using tap events. That’s very important for iPads. My background is so messy, I should have thought
about that before I brought this up. Pretend you’re not looking at my desktop. Except that I discovered when I was working
on this presentation that I had at one point set them from not being tap events to being
regular click events and that means that I messed up and luckily this presentation came
along. The cool thing is we get to see the difference. Click is a normal click, mouse click, we all
know what a click is. You know, mousedown, mouseup, it’s click,
auto click. Tap is something that YUI created. There are other terms for it in other libraries
– fastclick, things like that. But the issue is this: on touch devices there’s
usually about a 500 millisecond delay between when you make a tap gesture, tap, and when
it actually registers. Now they do that because they need to listen
to see whether or not there’s going to be a double tap to zoom in, whether or not that
tap is going to turn into a drag… Actually it’s mainly the double tap that they’re
worried about because the double tap has to be handled by the system, typically, because
that means zoom in, whereas the single tap is handled by the JavaScript or the web browser. As a result… Hold on a second. As a result… I just wanted to make sure I was at the right
place. As a result, the taps operate much faster. Let’s see an example of how much faster that
works. Okay. Please ignore my background. When I say click that’s when I’m actually
clicking, or tapping in this case, where this is the iOS simulator. Tap. Tap. Tap. That’s no good. Let’s see what happens, let’s just go ahead
and change this right here. Tap. Tap. Tap. Tap. Let me make sure it still actually has the… Tap. Tap. Tap. I don’t know if you can definitely see it
based on how fast I’m saying tap, but it actually reacts much, much, much sooner. It really makes a difference. The difference between tap and click on a
touch device, really one just feels just a little old school mobile-ish. But it’s just old and it feels just like every
single time you tap if you’re not using the tap event it feels like the browser’s going
wait, what? Okay. That’s really not what you want. You want something that feels like it’s eager
to pay attention to you. As I said, basically we’re using the click
event here. That’s the click. But what you really want to do is tap. The truth is, pretty much, there’s very few
places where you don’t have to be just… You can listen for tap a lot rather than click
at no cost. You might want to even consider that more
of a default, especially if you’re going to be working with a lot of touch devices. And you will be working with a lot of touch
devices. One of the most interesting facts I learned
recently was that there’s more people in this world who access the internet only with their
smartphone, that’s their only access to the internet, there are more people who do that
than people who use IE9. So smartphones, touch devices, these are a
core audience now and you have to consider them. Anyway, the tap is way better. The next thing we wanted to do is make sure
it works for everyone so I wanted to include really great keyboard accessibility in here
now. The important thing about keyboard accessibility
is that it is… Keyboard accessibility basically means being
able to operate your widget, your controls, whatever, from the keyboard and it’s very
important for accessibility. As you’re going to learn, there’s an accessibility
talk that happens later in the day which you should definitely see. But the important thing you need to know there
is that keyboard accessibility is not everything there is to accessibility. It’s a big part. But accessibility should be easy. It’s definitely something you need to think
about. But keyboard accessibility is an important
part. I’m really proud of what we came up with here. Basically you can operate the entire thing… What I’m going to do, I’m going to get into
the roster. Alright, so I can hit the down arrow to highlight
different rows and I can just hit return. That brings me into them. I can hit the down arrows and up arrows to
select if I want to bench somebody. Then I can keep going down. I can also hit tab. The tab arrow one works. And if I don’t want to do any of these actions
I can escape out of them. We have basically full keyboard control over
the roster. This is really easy to do. YUI has good keyboard event support. Let’s see how I did that. Again, we’re delegating because we can delegate
all these key events. Basically I’m saying we’re listening for the
key events, any key event is just called key. Our function handler is handleRowKey. But the important part is this – enter 30,
40, tab, escape. These are the keys in particular that we’re
going to be listening for, so that means we’re listening for the enter key, 38 and 40 are
up and down. I don’t need to worry about left and right. Tab is just the tab key, escape is just the
escape key. YUI is very nice, they don’t force you to
look up the key codes in this part of it to find out what the key codes are for these. You can just put in the equivalents. Then in the actual handler there’s obviously
more to it than this, but this one is what we did to allow the user to escape out of
the code. e.keyCode equals 27, that means we’re looking
for the escape key. And then from there we just do the same thing
we do when we’re getting out of our edit mode in the no-keyboard interactions. Basically I can just add this right on top
of what we already built. I’d already built the whole thing and then
added keyboard accessibility, and I was able to do it in a half an hour… Or nor half an hour, half a day. An afternoon. It was really easy to do and that’s probably
one of the most important things you can do. Here’s the fun part. After we launched Fantasy Football, we had
such big changes this year. I don’t know how many of you have seen it
before. There are big changes, and obviously when
you have big changes you have lots and lots of complaints, because people don’t like it
when you mess with their stuff and they think your website is theirs. You want them to think that, you want them
to be that possessive of it. That much response is in some ways a good
thing, but it’s also in some ways a bad thing because people will tell you how stupid you
are really creatively. It will happen a lot when you do a website
with big changes. But the key about these is listening for what
are real issues. One of the things we ran into was all of a
sudden people were complaining about scrolling on Firefox. By the way, my dev box has the same scrolling
issue. We investigated it. Now I’m running on a Macbook with a retina
display and a solid state drive and a really good graphics thing. I just wanted to tell you how cool my equipment
is, there was no point to that. No. The point of that story is I’m working on
really good equipment here, so it looks like the scroll is pretty good here. You have to remember that people are going
to be operating on much worse devices. Their memory is going to be a lot more constrained. So just because it works well, it might not
be. I knew instantly what the problem was that
people were complaining about, because I know this guideline about don’t use fixed position
backgrounds. You should never, ever use fixed position
backgrounds. I knew this was true. Here’s how you can know about why you shouldn’t
use fixed position backgrounds. Basically they force redraws and you can prove
that in Firefox. Here’s our quiz. We’re going to get to the fixed position backgrounds
in a second. But what’s better, if you have clown socks
or if you have a rave, or none of the above? What do you think it is? The correct answer is clown socks. Clown socks are better than raves. I’m about to show you why. By the way, I put it in hash tag form because
I really think you should tweet it out. You’re going to have a lot of fun tweeting
clown socks. No one will know what you’re talking about. It’ll be great. Let’s take a look. First of all, how many of you do this where
you’re in Firefox and you want to inspect something with Firebug so you do inspect element
and you get Firefox’s stupid web inspector rather than Firebug? How many of you do that and hate that? Yeah, yeah. Guess what, I feel your pain, Firebug’s way
better, but Firefox’s built in web inspector has something awesome. It has this little guy right down here. This shows paint rectangles. It’s this little paintbrush thing. I don’t know if you can read the tool set
there, but it says highlight painted area. What it does is it shows you the area of the
page that’s been repainted. Here you can see, oh my God, we’ve got this
crazy rave going on, and that’s not what you want, is it? No, what you want is… This is the one I like to use because there
are no ads, there’s nothing special on here, so this is the page I like to use to show
this. Oh wait, this is the one I wanted. What you want are these nice small paint rectangles
down here. Even though they’re going across the entire
page they’re very easy and small to redraw. They basically look like clown socks is what
I call them. That’s what you want to see, you want to see
clown socks. What you don’t want to see is this crazy bump
bump bumping rave. [laughter] This is the part where unfortunately sports.yahoo.com,
you see… Go past that, go past that. Clown socks. That’s the rave on Fantasy Football, and we
had the same issue on Fantasy Sports, on regular Sports, that’s the non fantasy site. Except that now I can’t really demonstrate
it. I thought we would have the same issue but
what happened was, that okay pretend this has a fixed position background behind it. This is important. They changed it, there’s no fixed position
background, it messes up my demo. They didn’t consult me on this. I would have told them I had a presentation
to give. They’re all like but the users! Anyhow, but you’ll notice that they’ve got
nice clown socks here. Even when there was a fixed background position
behind this stuff… And by the way, if you get one big repaint,
that’s fine. What you don’t want to see is the flashing. But when they had that, I was getting nice
clean clown socks and not a big rave here. I couldn’t figure that out, I was like wait,
what’s going on here? Is this just once again the regular sports
site gets to have all the fun? That’s not true, Fantasy gets to have all
the fun. Because clearly we’ve got our rave going here. I dug into it deeper and deeper and we found
out that the issue is not using a fixed position background per se, it’s that each of these
modules has a different fixed position background than the one that’s in the main background. We do that for readability. We have it be more blurry – blurrier is
the correct term – less constrasty. We had done that to make it easier to read
rather than using like an RGBA color and some other tricks. As it turns out, if you take that off… Right down here, the only reason you can see
the rave on this because obviously we fixed it is because I insisted we keep this class
name in foobar so that I could give this presentation. That changes it. It looks almost exactly the same, but now
we’re no longer using a fixed position background on the modules themselves, we’re just using
it on the background of the page and using an RGBA color. If we turn on rectangles what do we get? We get our nice clean clown socks. It’s basically the same effect but one gives
us a rave and then one gives us clown socks. You can see the difference actually when you’re
scrolling around. You can see the difference just by… It’s a little bit hard to see if you’re not
looking directly at a screen, but the scrolling here is much smoother when we’re in clown
socks mode. If we go and we turn on rave mode, the scrolling,
you can see it’s a little bit jumpier. Again, I’m on a great device here. The difference on other machines is pretty
radical. The guideline here is use fixed position backgrounds. The truth is the guideline is don’t follow
guidelines. Browsers give you so many tools now to measure
and see what you can use. There are other tools like the frames per
second meter on Chrome. I can walk you through a couple of these. In the preferences, in Chrome’s developer
tools, most of the action comes down… Rendering. You can turn on showing paint rectangles. The rectangles show what is repainted. Even though it appears to be repainting the
whole page, don’t be fooled. You can also turn on the show FPS meter. That gives you this great frames per second
meter up here. It tells you how many frames it’s redrawing
at. Right now it’s redrawing in between 30 and
60. You don’t want to really drop below 30. Ideally you want to be up at 60. It has a little gray bar to show you 60. It shows a histogram of how often you’re hitting
what. There is also enable continuous page repainting. That’s where it’s constantly repainting the
page, but that lets you find out what differences there are in… Basically every single frame will repaint
the entire page and you can see how long it takes to see if you have paint problems in
general. The average paint times here, they’re coming
in at between 9 and 15 milliseconds. Let’s turn on rave mode and when we’re scrolling… Okay, you know what, Chrome’s really good,
so sometimes… Chrome always messes me up when I do these
demos. That’s really because Chrome is genuinely
working harder here, but the effect isn’t as severe as it is in Firefox. But you can see differences, like you’ll make
one little class change or turn off one little style and all of a sudden your page repaints
will be down. So that’s a great tool. Frame profiling, that’s when you take a timeline… This is actually another great one, I’m going
to do it. You go into the timeline panel, you hit record,
and just do some stuff. It will show you things like your events,
your memory profile, but it’ll also show you each frame. Each little upward bar here is an individual
frame. This little gray line is the 60 frames per
second and then the 30 frames per second. If you have a lot of things coming in below
this gray bar here that means you’re hitting a solid 60 frames per second. If you have a lot of things coming up to the
top here you’re hitting 30 frames per second. If both of these bars are sort of way down
then that means you’re hitting well below 30 frames per second, you want to fix it. So this is a really useful thing because you
can examine each individual frame, each individual redraw frame and see what was going on. Okay, you’ve probably already seen. There is a secret Firefox frames per second
meter. For a long time I was like oh, I only wish
Firefox could show me frames per second the way Chrome does. And as it turns out there actually is one
they built in, they haven’t told you about, but I’m going to tell you about it and you
can impress all your friends. Basically you go into about config. About config is where all the secrets configs
are in Firefox, I hope you all know that. Just look for FPS. There’s draw FPS, layers.acceleration.drawFPS. All you have to do is double click it and
it’ll put this very ugly frames per second meter up here. Going back to the clown socks demo… Which mode are we in? I forgot. Oh, we are in rave mode, okay. You can see, look at these frames per second
up here. We’re coming in, you never seen that peak
above 30 right? Let’s go and let’s put ourselves into clown
socks. Then boom, we’re getting up here, we’re getting
up to 30, 60. We’re very rarely going below 30, and we usually
have between 50 and 60. Which brings me to restate the points. I’ve got to go past these guys again. Don’t follow guidelines, follow measurements. Whenever you can, when you’re doing performance
profiling, just measure rather than following these rules of thumb. We always used to have these rules of thumb
because the browsers didn’t let us see what they were doing. They’d be like oh, don’t do this or that. I don’t even remember. But basically the browser tools, even IE11
is doing amazing things. By the way, I want to mention that we are
very much hiring. I work on a great team. I love the people I work with and we’re always
looking to add more people. You can come talk to me or if you want you
can email. I should have put my email address on here. Okay, anyway. Here. Audience member: [email protected] Mark: No, no, I want the credit. [email protected] [laughter] Or [email protected] Actually no, sportsjobs is actually a better
one. But we are absolutely very much hiring. This is the best team I’ve ever worked on
in my life, I love it. I’d love for you guys to join us, especially
if you’re interested in sports at all, fantasy sports, anything. We’ve got a couple of minutes for questions. Are there any questions? [applause] Jenny: And by the way, there are flyers out
front that also have more information about sports jobs. Audience member: Alright, so Mark you were
talking about delegating and how it helps with the event handling performance system. At what point do you draw the line between
delegating… For example you mentioned the ul li a delegate,
so you put the event handlers on the ul and just listen for when it hits an a. When does that start becoming more of a hindrance
than a help? For example if you put the event handler on
the body element and then just listen for all the clicks within the page… At what point do you draw that line and say
alright, we are doing too much filtering based on what it’s clicking versus adding more event
handlers? Mark: I wouldn’t say I know the answer to
that specifically. I would say in general, put it at whatever
the lowest logical module is so that it doesn’t have to reverse up and you don’t have situations
where you’re having to differentiate between these things. But it’s going to match against the selector. The truth is I think even if you do that,
if you were to put everything on the body and delegate from there – don’t do that
because that’s lazy – but if you were to do that that’s probably still better than
attaching individual event handlers to every little thing. But this is a balancing act. If you’re going to be attaching a body delegate,
and there’s only ever going to be this one element that’s going to be receiving that
click event or something like that and you’re doing that 100 times, you’re really attaching
100 event listeners to the body element when you didn’t have to. They could have been on other elements. So maybe that’s a little bit better, but that’s
an unusual case. I can’t think of when you would do that in
general. Right now at Fantasy we’ve got several body
delegates and I don’t see any performance issue with them there. I mean there are limits to everything, but
in general, switching away from delegates for the sake of performance is usually not
a sentence you will have to consider saying ever. Anyone else? Audience member: On tap versus click you said
that generally tap is better than click because you essentially get it for free. But when do you not want to use tap? Mark: You don’t want to use tap, first of
all, if you want to allow people to do the double tap to zoom in for instance. If you don’t want that to be disabled you
pretty much have to use a click there. You don’t want to use… If there’s something you knew would only ever
be used in desktop I suppose you wouldn’t necessarily want to. For the most part I’d say you want to use
tap more, but it’s not as clear cut as delegate because there is a cost. You have the cost of losing the double tap. If your web view has those metatags that basically
prevent zooming at all, I honestly think there’s no reason why the browser should even consider
having the 500 milliseconds delay at that point because the only thing you could mean
by clicking on it is a click event and not a double tap to zoom in because you can’t
zoom in. I think the mobile browsers should disable
it then. But that’s sort of beside the point. The point is that’s the main case. The truth is that can happen a lot, especially
if you don’t have a solid mobile view. Audience member: Also, if you do a delegate
for a click on a button, it also registers events when you enter or spacebar on the button. If you change that to a tap would the keyboard
event still work? Mark: Pretty much, yeah. Okay, I’m going to take a rough… I’m pretty sure it does. This fact isn’t solidly embedded in my brain. But for desktop browsers, tap and click are
equivalent. All it does is really changes what happens
in the touch available browsers. I’m getting a nod from Jenny and Jenny would
know. Jenny: Tilo is here. Mark: Tilo, by the way, is your expert on
this. [laughter] Jenny: He gave a talk yesterday. Mark: He gave a talk about this yesterday. Actually it was an excellent talk. Jenny: Alright thanks Mark. Mark: Alright, thank you. [applause]

Leave a Reply

Your email address will not be published. Required fields are marked *