Tip:
Highlight text to annotate it
X
Andrew: Montie Tsai and Zordius Chen. Everyone give a big hand for Montie.
Montie Tsai: Thank you. Okay, today our topic is about the code name called Bottle, because
actually at the backend we use Mojito but in the frontend Bottle can contain Cocktails
on the go, so we call it Bottle. It's actually a set of YUI modules.
Introduce ourselves. I'm Montie, and this is Zordius. We work in the Yahoo! APAC E-Commerce
team mobile team. We are located in Taiwan. I have four years experience in Yahoo!, and
Zordius has nine years.
Okay, in case anyone did not know where Taiwan is, this is Taiwan in the APAC region. Where
are we now? We are here, in Santa Clara.
First of all I will introduce our promo video for our Bottle.
[video plays]
Actually we built all of this for mobile developers. It's kind of a side product for our mobile
auction project. Now we have the essential pack contents. Now it's nine UI components
in that, and we do in this video itself just eight. This is a little bit of live demo.
We'll have more demo later. Yeah. A little more.
We do hope some of you to use that, or at least try it. That's one of the purposes we
are here. Okay, first of all we will introduce some of the UI mobile web UI trends. This
is a typical website, this is Yahoo! News. This is PC Web. I think most of you must be
becoming familiar with mobile app. Actually mobile web is to contain the web content in
a mobile device.
Actually we have nine UI components, and we can group them into four groups. The first
one is where you want to achieve the goal to provide the app-like user experience just
like a native app. We have page, shortcut, pushpop, and overlay widget. The second group
is to provide a finger-friendly experience, so we provided carousel. As you know, scrollview
also provides some function like carousel, but we have more on that. Also the slide tab.
The third one and fourth one are tools. Loader is an Ajax wrapper, and also multi-device
support kind of HTML viewer and also PhotoGrid.
I think the first idea is how you fitů This is a typical layout for a picture page, how
do you fit that into a small size screen being mobile devices? First I think that you would
just make the header smaller, and then this column, mostly you will put some functional
link, filter, and shortcut and then you can hide it in the back. Then when you put this
in a mobile device, just like the Facebook app or past apps, there's a similar function.
You just click the button in the top left, then the hidden menu will show.
To achieve this, the page widget is the basic one. If you are ever developing mobile devices
you have always to adjust the screen size when the phone orientation changes. Also,
the header/footer, a lot of requirements are that you have to fix header. But we have a
lot of devices to support, so we take off this.
The second one is shortcut and overlay widget. We can do some animation to display the shortcut.
For example, this one's unveil, and also overlay, and you can push in some hidden content.
We also provide the user a push/pop extension. It's just like the native app behavior. You
can also back, which is to pop the view. Available for page, overlay, and shortcut.
This is the first group. We have more deep diving later. I just introduced the four groups.
The second one is to provide a finger-friendly experience. For example, you can see that
this is a common component in PG web design. Photo gallery by categories, there's a lot
of tabs. If only you just make it small, and put that in a small size screen, it turns
out the user experience will be very bad, so we have slide tab widget. We want to fully
utilize every area in the screen. You can use fingers to swipe the tabs, then the responding
content module will show up.
Also the carousel widget. Usually used for module display and photo display. We provide
other features the more you scroll your page. We have horizontal/vertical lock function,
and also you can swipe two or three modules.
Okay, this is a loader widget. It's just a lightweight Ajax wrapper. I used it for that.
It's just kind of an app experience to infinite scroll, then you can click the load more and
the content will append.
This is Photo Grid widget. We are going to provide the vertical view, just like the Pinterest,
and also the horizontal, just like the Google Images search. Also the square one, you could
see that in maybe Facebook. It's a modern UI for photo display. We also have append
support which is infinite scroll, load more things.
For Photo Grid widget, it's a multi-device concept. The idea is that the user can define
the width for each column, then we can calculate how many columns it showed up in the screen
size and display the photo modules.
The other thing we do for multi-device concept is this is auction site in Taiwan, yeah, Yahoo!
auction site. Just like eBay, the user can put a lot of custom HTML on the item page,
and sometimes it's really huge. A lot of the contents, photos. We do some special treatment
for images to provide the user better browsing experience when you want to put all of these
in a small size screen.
We provide some zoom in/zoom out features for images. You just put all the HTML in there,
then we can take care of the rest of that. The user can click the zoom button then scroll
and view the details, then back.
This is the live demo of our project. You can see we use a sliding tab and carousel
in our front page to show some items. Also the show cart on the left side. As you pushpop
inside the show cart, yeah. This is the item list page. We use overlay and events filter
function. There's also a right side show cart. Both the left side and the right side are
the same. This is a single item page. Also use the carousel to display the photos.
Okay, next I will let Zordius introduce more on the design concept and also more on how
we designed that, do some performance tuning things. Thank you.
Zordius Chen: Hello, I am Zordius. I want to discuss about mobile design concept.
First we start from desktop version. This is the typical web page. As you can see, we've
got a header, footer, and side column. If you want to fit this content into the mobile
device then you can see that we cannot see anything. Users need to zoom in, zoom out,
or scroll up, scroll down, scroll left, scroll right. We cannot just do this.
So what can we do? First up we can consider removing some content from this page. For
example, remove secondary contents and we just keep major content and remove the side
column. We do this, then we have trends to fit the rest of the content into a mobile
device. By this design, users can scroll up and down to see all the major content.
That is the best concept of a mobile design. The pros are this is really simple and fast,
but the cons, the user has not many choices. He can only do scroll up and down, and click
on the link, so we coded weak navigation. The user needs to scroll long distance up
and down to reach both sides, so it is not very good.
Then the idea is we can provide more choice with some design. The first one is we can
try to make the header in fixed position. When users scroll up and down then he can
always see the header. Then we put some additional function under it. Of course we can make the
header smaller, the user can see more content on it. Then we can put more functions on the
header.
For example, these three regions, left hand side, right hand side, we can provide more
shortcuts, then the user have more choice. For the left hand shortcut we can provide
navigation or some other popular function, for example calculate list or anything else.
At the right hand side we can provide something for personalization, for example a shopping
cart, or anything else.
With this we can provide more choice for users by persistent header and shortcut menu.
Next is another way to provide more choice toů We can make the up and down scroll one
dimension to two dimension. For example, we can provide carousel. Then your user can have
another dimension. He has a chance to view more content with carousel, just a flick left
and right. Another way is pushView. This is very traditional iOS thinking. We can just
push another view into the page.
So far we have four design patterns for mobile web page.
Thinking about customization, here are two ways to transition the shortcut in. The left
hand side is push, just like this, and the right hand side is unveil. From the beginning,
the shortcut is hidden under the page, and then we move the page. Then the user will
see the shortcut. With both these two designs we need to reposition the page, so we designed
a page widget and as you can see the shortcut widget.
So far we have four design patterns to support this, and here comes our library major requirement.
Here we have fixed position widget, and push/pop. And we need to move the content, reposition
it, and we need our library easy to use. So we put our library on YUI gallery, then it
will be easy to use. You can just write down just a quick code, initialize our library,
then everything is done.
Another design is you can initialize widgets with HTML5 tech by data-role attribute. Then
you can customize with data-attribute, and you can change your look and feel with CSS.
For example, with this HTML text, it brings you this user interface. It's really simple.
With these major requirements, here comes some design challenges. First, to support
fixed position, the most simple way is using the CSS position: fixed attribute. In iOS5
this is fully supported, but in some devices there is not any support on it. Users cannot
see the fixed header in this device. In some devices the support is partial, and the header
only shows up after the scroll is ended.
As we can see, the fixed position support cannot be done well on all devices with CSS
position attribute, so we decided to use a non-native scroll solution. The concept is
to simulate scroll behavior by touch events. For example the iScroll, it is open source
library to simulate the scroll behavior, and the other one is YUI3 scrollView. Finally
we used scrollView because we are YUI based.
The pros of this solution is that it can work on all devices, but cons, the performance
is not very well compared to the native one, and sometimes it breaks the native scroll
behavior because, for example, if a user makes a touch on the device, maybe the library will
cancel the touch so you cannot make the scroll happen by native browser.
So how can we do this? First we change our page size adjust this with mobile device so
the user cannot scroll up and down, right? Then we put a scrollView on it so the user
can do scroll on a scrollView. He can scroll the content up and down. As you can see, by
the way, the header is fixed on the top. That's our concept.
If you want more customization we can do, for example, like this. The header is not
fixed and the footer is not fixed. By the way, you can make the header fixed, or more,
you can make the footer fixed, but you get a smaller viewport. We have two attributes
for this, two options.
We align the design with YUI's standard module. You can see the header and footer, and maybe
we will put the scrollView into the body. All these three widgets have fixed header/footer
support, and we decided to support push/pop in these three widgets.
For example, we can do push/pop in shortcut, and push/pop in page, and overlay. These we
can create very complex user interactions that may be fancy.
When device orientation changes, we need to handle something. For example, for page, we
need to change height and width just like this. For shortcut we only need to change
the height. For overlay we don't need to care about the size, but we need to reposition
it.
Here comes the requirements. We analyzed the functions of these three widgets and we found
there are some deprecations. We can have one parent class to handle this. As we know, YUI:
widget support changing the size, both width and height. We extend the widget and YUI:
widget-position can have positioning function.
Finally we get something like this. By the way, this is a traditional inheritance pattern.
Maybe we can refine the function of the parent class like this. Here comes the problem: we
have two ways to make the inheritance, but these two ways are different. At the left
hand side you cannot get a pushPop class without fixed header and footer, and the other one
you cannot get a fixed header/footer without the pushPop.
We use a YUI solution. There are two ways to resolve this, and the first one is Y.extend
and the other one is Y.plug. With Y.extend we can pick one parent class then pass many
extensions. The plug method, we can add plugins on instance. This is an instance based solution.
We use extend because we want a prototype based solution.
So far we make many extensions for these functions, then finally we canů For example, we can
build our page widget with these extensions, including YUI extensions. If in the future we need another new class, we only
need the pushPop function, then we can create it by extend. This cannot be done with traditional
inheritance because you cannot create a pushPop class without these.
Here come some performance challenges. The first one is the native scroll, the scrolling
performance problem. Because we use a non-native scroll solution, it's a little bit slow. For
example, in our mobile auction home page we have 12 scrollViews in one page. That means
if we use one click to one touch, then the touch event will be triggered and then we
have 12 event handlers to handle it. In this situation, the user will feel the scroll is
not very smooth, FPS is really low.
How to resolve it? There are two ways. The first one is reduce the number of scrollViews
and another is we can fallback to use native scroll. For the first one we can disable hidden
widgets. For example when our shortcut is hidden then we can disable all scrollViews
inside it. Then we can reduce the active number of widgets. Another way is wait on the data
initialize task until a user wants to see it. Then the number of instances are reduced,
then you get fewer scrollViews. The second one, we have graceful downgrade function in
our page widget. Then we implement the scroll with native scroll. This makes the scroll
speed more fast.
Another performance issue is long initialize duration. For example, in our auction mobile
page a user needs to wait for about four seconds. The user just can see one loading icon until
our widgets are initialized. Finally, we calculate the number of widgets in our page is almost
33 widgets in 1 page. That's horrible, so we need to fix up this performance issue.
But how? There are two ways. The first one is delay the initialization of widgets. Just
like I mentioned, you can delay the initialize of hidden widgets. And the other one is lazy
load. After we use these two solutions, the number of widgets are reduced from 33 to 11.
As you can see, this is a big improvement. Finally we got about 1 second waiting time,
and that's really good.
Here comes a tricky part of our lazy loading. We use html comment and then all our html
tag inside the comment will not be rendered. For example, image tags will not be rendered
and not be downloaded. All widgets inside an html comment will not be initialized, too.
So what do we do when, for example, when the user changes the tab view, we monitor on the
tabView event. Then before the user sees the new tab we check the innerHTML to see is there
any html comment inside it. Then a regular expression to replace the innerHTML with new
one to remove the html comment. Then we put a new string back and help the user to initialize
any widget inside the html.
We get the lazy loader this way. It's really simple because you don't need to implement
anything like JS or anything else, all you need to do is add html comment text in your
template then everything is done.
Here is device orientation challenges. As I mentioned, when a user changes device orientation,
we need to handle many widgets. For example, page initial count, we need to change the
size of this widget or change the position. Maybe we can handle it with this pattern.
Every widget can listen on orientation change event or screen size change event, but it
will not work well because this may cause overhead because everything is done with YUI
event model. So it's not a good solution.
Our solution is we use only one event handler to handle everything. But not every widget.
We only handle page, shortcut, and overlay, and only working on visible ones. How about
other widgets? Here is the problem. Because if we handle all widgets in one event handler,
something like this, what will happen as we can see, first we handle page. So the page
size changes after orientation change.
And then shortcut. We cannot see shortcuts so bypass it. And then our carousels, here
we can see two carousels in this page, but only the first one carousel needs to change
its size. The bottom one, as you can see, the width is just fit to its parent so we
don't need to change it.
The problem still comes to next our viewer, so we handle the viewer. Finally we handle
the slidetabs. So this is the final situation, and we see it's buggy because the carousel
is not being handled by this order. So it's totally not work. You cannot know your user
press which widget into another, so you cannot decide the best order of this.
Our solution is we only handle these three widgets in our event handler. All others are
handled by YUI event model. That means any other widgets when it is initialized then
it will search for its parent then listen under a size change event.
Here goes the solution like this. Page, shortcut and overlay, then everything is done with
listen on parent. We just see the page size changed, so the carousel and the slidetab
got the event, then it's the size change, then viewer and the carousel. So you can see
everything is done very well. With this we handle our orientation change very well.
And this purpose can handle any kind of widget stack. For example, you can use a compress
any widget inside another widget and we don't care about it. Everything will be handled
very well.
So far we know there are many challenges, as we discussed, in coding performance, orientation
change and supporting many kinds of devices. We know a lot to implement a mobile web. You
need to handle many things. The good news is almost everything is done with our library,
so try it now. Yeah. Or just see the source code. It's on GitHub so you can try the browser
source code. Many tricky things inside it.
Links. Everything is on the net. The links are really long, so there's a simple way you
can just try to search YUI and the bottle, and then you reach there.
That's all. Thank you.
[applause]
Andrew: We can open things up for questions.
Zordius: Hello.
Audience member: Hi. I noticed that obviously you've got this nice rollup of all the modules,
and when I looked closer I noticed that you had broken out each of the individual pieces
of Bottle into separate modules. Is it possible to use one of the submodules separately, or
do you really have to load the whole bottle suite in order to get the components to work?
Zordius: Your question is is it possible to use only some components of Bottle. The answer
is that it's not possible because... For example, I just mentioned about orientation change
event. It is handled by our core function, core module, and almost all widgets are dependent
on it. So we have one core module named gallery-bottle and almost every other module depends on it.
Yeah.
Audience member: I worked on the Yahoo! Olympics app and we also experienced a lot of issues
making scrollView work. Not really problems with scrollView, of course, the application
and the performance and the platform. One thing that I never got to try that I wanted
to is just actually simply doing an iframe. I mean, it's considered bad practice traditionally
on a web page to add an iframe for scrolling, but given the circumstance, why not? It seems
like it would work. Did you guys try that?
Zordius: The answer is why not we just try the iframe solution. As we know from the beginning,
the iPhone is really support iframe or scrolling inside a div, but a user needs to use two
finger gesture to implement it to scroll up and down.
Audience member: In divs?
Zordius: Yes.
Audience member: In iframes too?
Zordius: Yes, so far, so far. As we know, yesterday we have news with a view to enabling
it with only one finger, but it's not in traditional iOS device, it's in new iOS.
Audience member: I think it's probably in at least iOS5.
Audience member: I was wondering, first of all, you mentioned you built this for use
with Cocktails, but it looks like it doesn't have to be used with Cocktails. Is that right?
Zordius: Yeah.
Audience member: Okay. And the second question is with the slidetab, which is a... I really
like that pattern, I think that's very clever, but do you have any trouble getting users
to get how that works and what it does? Or have they kind of figured that out?
Zordius: Yeah, that's a new design challenge.
Montie: I think you can notice that there's some small arrows.
Audience member: Yeah, I noticed that. You see the other tabs kind of off to the sides
you can kind of get it, but I wonder if... Because it's an unfamiliar pattern, even though
it's very clever, I'm just curious whether you might not...
Zordius: Yeah, we see this design pattern in some apps, so it's not very popular. Not
every user can recognize these. That's a challenge, but if most people use this then most of the
users can know how to use it.
Montie: Maybe it also depends on how you designed the width. Maybe we will see they have tabs,
the right tab, then they will try to swipe or something.
Andrew: Do we have any other questions?
I have one question for you. Can you animate that tab programmatically so that they can
discover that, like a carousel? The slidetab?
Zordius: Which program?
Andrew: The slidetab, can you animate that so it slides automatically?
Montie: Oh yeah, yeah. You can see, basically we use the same extension as the carousel.
In carousel we have an arrow to move to the next module, so the same function applies
to slidetab.
Andrew: Okay. Do we have any other questions?
Audience member: I actually have one more. Are there any other properties or sites that
are using Bottle right now so we can see more of it in action? Obviously there's...
Zordius: Yeah, we are dogfooding.
Montie: The idea is that actually we are from the e-commerce mobile team, so e-commerce
means the shopping sites like Amazon, auction sites like eBay so we have a store and marketplace.
Actually there are shopping behaviors, so there might be similar navigation, similar
behavior. At least we will use Bottle for all the three properties that come in here,
and we do have others who use that.
Audience member: Well, I guess what's the web address for what I'm looking at right
now if I wanted to look at it on my phone and see it in action on a full feature site?
Do you have the web address?
Zordius: Which one? You can try.
Montie: Which one did you want to see?
Audience member: No, no, I wanted to play withů
Audience member: We want to see it on our own phone.
Andrew: The question is, is there a URL they can try out demos of this? Is it available
in the gallery?
Montie: Actually we have a demo here. This component.
Audience member: What if they draw off of the Google auction site?
Montie: We're launching that next month, so some day next month you will see that, yeah.
But we do have a demo here in our library for example for carousel. This is the basic
one, yeah. Providing a very simple example here. You can see more at events one, like
the shortcut.
Zordius: How about pushPop or Photo Grid?
Montie: This is shortcut with push function. Yeah.
Audience member: Maybe you can open it as [inaudible].
Montie: You can see that the transitions also work on Firefox, Chrome, even IE10 also works.
Because we focus on the mobile devices, so IE6 and 7 is not supported.
Andrew: Do we have any other questions?
Montie: Any questions?
Andrew: Awesome, thank you very much.
Montie: Okay, thank you.
[applause]