Mobile Web Apps (GDL-IL)

Mobile Web Apps (GDL-IL)


MALE SPEAKER: Shanghai
GDG is a very interesting developer community. FEMALE SPEAKER: I’m
glad somebody has asked this question. MALE SPEAKER: This is where
the magic happens. FEMALE SPEAKER: This is
primarily a question and answer show. So if any of you out there would
like to ask questions. IDO GREEN: Hello and
welcome to GDLI– Google Developer Live Israel. Thank you for joining us. Today we are going to speak
about mobile web apps and what, as a font developer, we
should think about when we are coming to develop a new product
or a new service or a new layout to our website
or web app. And of course, we want it to be
available in all the mobile devices that are out there. One common denominator of this
we see again and again in all the devices that we have today,
and certainly in the near future in new devices, is
one great piece of software, which is the browser. On most of the devices today,
we have Chrome. And that’s really good news in
the sense that you have the latest and greatest
in terms of HTML5 APIs that are supported. And in this short presentation,
I’ll try to go over the different main points
that you want to think about when you are creating a new
mobile web app in terms of the design, the building blocks,
and the tools or libraries that you might want to
leverage, and not reinvent the wheel. Without further ado, let me
jump into the slides. And if you’ll have any
questions, I’ll be more than happy to try and answer them
at the end of the show. So here in the first slide,
of course, we are using geolocation. And just do view source, and
you’ll see how easy it is to tap into the special ability
that we have today with mobile devices, and then just to get
from the browser, the location of the user, and offer them
immediately more relevant information based on
the geoinformation that we have on them. If you have any questions during
the show or after it, you’re most welcome to come and
Ping me on G+ or Twitter. All the slides that I’m going
through are now live under ido-green.appspot.com. And of course, we’ll have a
summary with a transcript in my blog after the show. If you have some hashtags,
those are one of the most popular ones that I’m using in
order to see what’s new there and to keep myself up to date
with new things that are coming very rapidly into
the ecosystem. So what we’ll try to cover in
the next 25, 30 minutes will be just to give a short
brief of the state of the mobile web today. Then we’ll talk a little bit
about design philosophy, what are the main things that we want
to consider and evaluate when we are coming to design
a new mobile web app. Then we’ll give some best
practices and tips about how to build a mobile web app. And here is a link of a very,
very cool new game that Chrome Experiments launched. And the beauty here is that
basically we’re having the remote control in our
phone, in our Chrome on the mobile device. And we’re using the
larger screen. It could be Chrome on
the TV or Chrome on your laptop or desktop. And the game is running
on the bigger screen. But the remote control for the
game is on your phone. And that’s, in a way, just
starting to gain the best of both worlds in terms
of slickness. Last but not least, we’ll try
to give some tips and best practices to save you time and
effort and make you more productive. One little warning, many things
that we are speaking here– and yeah, that’s a very,
very cool new effect that we’ve been using for the
past two years, actually– is just to tell you that we are
on the bleeding edge here in terms of some of
the features. So if we’re thinking or talking
about certain things, please go to places like
caniuse.com, or any other site that’s giving you a nice set
of things to see which browsers, in terms of your
users, are using them. And then you could evaluate
if you want to use this specific API. For instance, let’s take
drag and drop. You can see immediately which
browser are supporting it, and which mobile browsers aren’t
supporting it. So you’ll know exactly
what users could enjoy it or whatnot. Another really nice way to
think about it is to use libraries like Modernizer and
then have feature detection and not browser sniffing,
which is not good. And with the feature detection,
basically you will know exactly what are the set
of features or capabilities that certain mobile
app is giving you. And then based on that, you
could use responsive design and progressive enhancement in
order to make sure that some of the users will be able to
be productive, even if they are working on older phone,
while if your user is coming from the latest greatest in
terms of the hardware, you could offer them more, and your
app will work smoothly, better in terms of performance,
and maybe have some nice set of features
that aren’t supported on older devices. We jumped into some
mobile trains. Well, the main outcome
from this slide is that mobile is big. And mobile usage is actually
going to overtake desktop. Basically we see the pace
growing rapidly. And it might be even before
we reach 2014. Another important thing here
is we have already nice research from third party
companies– so take it with a grain of salt– about seeing that actually
the mobile web is here. It’s here to stay. And lots of users
are using it. Here’s a specific case
that Chitika did. We see it happening in the ISO
world, happening right now pretty rapidly. When we’re speaking about mobile
browser, the good news is that most of them got very
nice elegant browsers that are supporting quite a lot
of HTML5 features. In terms of the coverage, it’s
around 95% of web kit. And that’s including
iOS, Android, BlackBerry, and some others. The main features that we are
still missing are WebGL, Web Audio API, that probably is
coming really soon in some of the browsers, and Shared
Web Workers. In progress, we have today
nice cool things like the Camera API and IndexedDB which
is a full blown NoSQL database that we have today in
Chrome for Android. For other ecosystems,
like iOS, you’ll want to use Web SQL. But since this spec is
deprecated from 2010, you might want to use something like
launcher, and then have the ability to switch on the fly
between the database that you’re working. So if you’ll use launcher, and
we’ll have the link to this library at the end of the
slides, you could work with both Web SQL IndexedDB. And if other browser are
supporting, let’s say, local storage, you’d be able
to work with that. So that’s a nice way to approach
things, and then enjoy both worlds in supporting
several ecosystems, just to make sure that you’ll
be able to work with offline first and offer your users the
best environment and best experience with your
search and app. This is just a quick graph to
show how quickly we’re seeing Android going up, and how WebKit
is supported on all the major platforms, as I mentioned
before, Android, iPhone, BlackBerry, iPod
Touch, et cetera. When we come into the old debate
between web and native, it’s always refreshing to
think about using and leveraging the best
tools for the job. So in terms of being close to
the metal and using all of the great features that you have
today, let’s take, for example, on Android platform,
you probably want to create native apps so it will work as
close as possible to the metal, and will give you
all the full range of different APIs. The web, on the other end,
is a unified platform. As we mentioned before, you
have it on different ecosystems. In all of them, you’ll
have the browser. And even on all the forms, you
do have the browsers that will be able to read your HTML and
show the user what you want them to consume. Native, of course, is
a moving target. And we’re seeing it being
improved very rapidly, although we’re seeing
the web pushing the boundaries again and again. And the APIs guys are getting
closer and closer. This standardization on the web
is moving a bit slowly. But the good news, or the half
full part of the cup is that it’s catching up. And the pace is getting
better and better. Here there’s a link to a Scott
Jason presentation about what he thinks mobile web will look
like in the next few years. And I highly encourage
you to check it out. It’s really worth
your 45 minutes. Here are some really nice
examples, just to see what others are doing there. “Financial Times,” it’s, of
course, a media company. And their app is really a nice
way to show you how you could tap into the offline
world with a full blown mobile web app. Workflowy, it’s to do list on
steroids, or actually a way for you to organize your things
and thoughts on lists, also working very nicely. And of course, mobile Twitter,
which is another good example. And we have plenty of
other examples. I’ll have links to how you could
gain more ideas in the next slide. Here’s a link that shows us
another research company that basically users want to work
with the mobile web. They are using the browsers
more and more. And in some cases, it makes
perfect sense for them to open the browser, launch your
dedicated web app to a specific task or goal, achieve
what they wanted, and move on. Some bold, good examples,
we mentioned Twitter. Gmail, of course, it’s a full
blown mobile web app that are working really nicely and giving
you really nice special features in terms of the
capabilities, the offline features, and all the
other great benefits that we have in Gmail. Another nice way to think about
this, like with this app for Footspotting, where you have
a limited real estate, try to do your best to tap into
what the user is wanting to achieve with your
dedicated app. So in that example, we certainly
don’t need any footer, header, sidebar,
or things that will clutter the app. Very clean approach. And you can see more and more
way of thinking in those words, in apps like
[INAUDIBLE] and other really
nice examples. So let’s try and speak
briefly about design. First, in the old days, we have
this notion of going to the designer. He’s or she’s working
with the Photoshop, giving us the assets. Then we need someone to
cut the HTML and CSS. And very cluttered, not truly
elegant or agile methodology. Today, I tried to break it here
into pieces that actually allow us to work much faster,
iterate faster, and see how we’re prototyping and getting
ideas out there as soon as we can, just to validate them
before we are going to the last phase of production. So today, you’ll see more and
more people doing design through wire frames, or even
trying to mock up how it will look like pretty quickly. And there’s plenty of online
tools that make you productive with it. The basic asset is to put the
ideas on paper, on board, on a napkin, or on any platform that
you want, and then quite quickly to sketch it with HTML
and a bit of CSS, just to see how it will look like,
how it will feel. Then we want to achieve a bit
of responsiveness and logic. And probably those cases will
go to the upper right block here, and add some JavaScript
to add our own magic to the prototype. And from there, basically we’re
going to the polish phase, which I call that the
important phase that separate the true professional one’s from
that amateur ones, where we want you to work as slick as
we can as fast as we can. And this is actually a place
where we are going back to the scheduled prototype, but
want to iterate over it as fast as we can. Of course we want a test-driven
development in a way, or to have a final phase of
continuous integration, and to do some really testing on
real devices, just to make sure that we have a nice
coverage with the 28-year rules, or any other rules that
you want to do in order to make sure that the vast majority
of your users will be able to be productive
and enjoy your app. And last but not least, of
course, we want to push it to production, have our alpha beta
release candidate, and, of course, the first
version out there. But as we all know, today, the
end of the trip is just one stepping stone in it. We’ll want to iterate again
and again and have more features over time. When we’re coming to speak about
it, basically the one fundamental shifting in thinking
is that we’re not speaking about pages anymore. We’re more working on this
one page application. And we want to make sure that
we do the best with the limited real estate and give a
set of guidance or a set of tools for users to achieve
their goals with maximum efficiency. We’ll want to use components. So we don’t want to reinvent
the wheel. And the web as a platform,
actually, is going to give us just that in the near future. So now, if you want to check the
water, just try AngularJS with directives, which basically
giving you a really nice way to think about reusing
your code, don’t repeat yourself, and just
leveraging things that you already did in the past. As we mentioned, in mobile and,
of course, in mobile web, less is more in most
of the cases. Because we don’t have a lot of
real estate and the user got some fat fingers in most of
the cases, we’ll want few buttons, few words, just to make
sure that we are aiming or making the life of our users
as easy as possible, as efficient as possible. Here is just a nice example of
[? Path ?] and what they did with their menu button. And if you’ll search on GitHub,
you’ll find lots of repositories that give you just
that, nice interactions of collapsing the different
options from the bottom left corner back and forth, a very
nice way to think about. And another two tips here to
remember, that on mobile devices we do have the landscape
that is changing. So we want to do the best in
order to use media queries and just be able to communicate
it to the user. And of course, using just
Photoshop is not as efficient as we wanted to see. And in lots of cases, we
probably could do less with Photoshop and mobile. We’re just prototyping
and using HTML, JavaScript, and CSS. Here are some really nice bold
examples, that you really don’t want to reinvent
the wheel. You want to be inspire. And pttrns.com and
mobile-patterns are just those two sites that give you the
ability to go and see what others did when they needed a
map application or a long list, or any other things
that they wanted to do. And it just will save you time
and efforts, and make sure that you’ll be able to do
nice things with them. Let’s just, for the sake of
argument, open it so we’ll be able to see. So here are some
recently added. But let’s say that we want to
see what interesting things people have done with lists. You have a very nice collection
of things here just to inspire you and to
take it from there. And of course, the nice
example of a path. So we wanted to do this quick
sketch-up to see how things are working. And here are a few nice
online tools. I will just add that on top of
these tools, you could go today to jQuery mobile site,
and you’ll have basically [INAUDIBLE] there that lets you
mock up real quickly and get even the structure of the
HTML from your mock, really nice and easy to use. Balsamiq is, of course, a very
popular, nice web app that gives you the ability to do
those things efficiently, and others, modern web apps
that are there. And you could retrieve them
from the Chrome Web Store. One thing to remember after we
did our sketching is that you want to make sure that what you
designed is doing the best for the phone or
for the tablet. They are not the same. And one thing that we could
probably save ourself is the notion of let’s aim and do
whatever we can with all the devices that have 4″ by 3″
screens or 16″ by 9″, just to make sure that we are not going
too crazy with the media queries to adjust our app to
each and every device. But a nice example that you see
here with Flipboard, check their app on a tablet
and on a phone. It’s completely different. Even the ability to do the flip
itself, they didn’t use the muscle memory that users
have in the tablet, which is horizontal reason flip. And they choose on the phone
to do it vertically because it’s just a better experience. And that’s a great example to do
what is best for our users, and, of course, validate
it with testing. When we’re speaking about
adaptive apps, apps that are less bind into a specific
screen, we’re talking basically about doing a re-paint
and refresh of our DOM, of our structure based on
the real estate that we’re getting in the app itself. And we know that one of the
main pitfalls is that it’s really hard to use the same DOM
tree for all form factors. So we’re seeing today a nice
interesting debate between, OK, let’s have one DOM and
just use different media queries with different CSS. Or let’s do some sniffing in
advance to see which device is coming, and then just make sure
that we are sending back the dedicated HTML CSS and
JavaScript that will do the best for this specific medium. When we’re speaking about all
those adaptive apps, we want to use some sort of a temperate
library, in order to make sure that our DOM
refreshing and repainting will be as efficient as possible. And we’ll see in the next slides
how we could do that. And of course, when we’re using
responsive design, we want to use things like read
box, Flexbox, and not, of course, absolute position or
relative position, because it won’t work nicely on the
different devices as we have today, not to mention
future devices. When we’re using the CSS3 new
grid layouts or Flexbox layout, we could do ourself a
favor and just focus on those form factors, which will make
our life a bit easier, and are still very good for the vast
majority of the users. Here is the link
for [INAUDIBLE] site, which contains a huge
amount of really nice information. And of course, media queries,
which is letting you see different examples in the wild
and getting some ideas how your web app or website should
look on a desktop, tablet, and a mobile device. Let’s jump real quick
to building. Of course, when we’re shifted
more and more logic to the client side, we want some clear
separation between our data and our views. And that’s why we see a
flourishing in all the MV-star frameworks today. And if in the past we used to
have this logic in the server, and just sending to the client
HTML pages that represent this logic, we’re seeing more and
more movement of a thicker client that contain more
and more knowledge. And that’s come with the notion
of offline first, when basically we want the user to be
productive, even when there is no connection or a
flaky connection. Just a clear scanner to see what
we’re talking about when we’re speaking about model view
controller framework, and specifically in the case of
mobile web app, we do want our views to have the dedicated
view for each form factor. So we’ll have one view for
desktop, maybe another one for TV here on the right
side, and of course for tablets and phone. We could share the same
controller to hold our data and to update our view. And here is a link to what
[INAUDIBLE] did, which is a great, great thing in terms of
comparing the different MVC frameworks that are out there. Another nice code snippet that
you could take here is to do something like that in order
to understand which form factor the user is using, and
then make sure that your code and other goodness
is bring to them. And I see here people
are saying dedicate view for Glass. Absolutely. I can’t agree more, actually. In terms of the products
of choice, basically we’ll see it again. We had it in the service side a
few years back, when you see a huge flourishing in all
the MVC frameworks in Java, for instance. And now we have the same with
JavaScript and the client side MVC frameworks. Here we don’t jump into
it, because we don’t have too much time. I’ll just mention those three
really bold examples. And with five seconds promotion
to Angular, I really encourage you to check it, not
because it’s an open source project that started in Google,
of course not, just because it’s a true passion of
mine to see how people are thinking about dynamic HTML, not
static HTML, and how you have dependency [? injection ?] and test-driven development
in a JavaScript framework. Really, really cool stuff. This is one of the compression
tables that you’ll see if you’ll go to the link and the
work, the hard work that [INAUDIBLE] did. I highly encourage you to see. And basically even here, don’t
take my word to AngularJS or to the wisdom of the crowd,
quote unquote, that’s going with Backbone. Just do small research for
yourself and choose the best tool for the job. The TodoMVC, of course, what we
mention, the link is here. When we want to run our complex
app, and we want to do some DOM manipulation, we know
that we need to do it as efficient as possible. And here the big secret, which
is basically not a secret at all, is to use a JavaScript
templating mechanism. Nicely, we have it now baked
into Chrome and hopefully other modem browser
real quick. So this is the link
with [INAUDIBLE]. So you’ll be able to tap
into it and to read. It’s a very good tutorial
that Eric Bidelman did on HTML5 Rock. But here we’ll just show you how
you could do it even today that will basically support
all the browsers. We’re using an embedded and a
certain new type to make sure that our templating engine
will work with it. And we’ll bundle it
into the HTML. And then we could use several
templating engines. So here I use mustache.js, which
is a very popular choice of the logic-less templating
engine. And you could see the example,
even if you never saw it in advance, that what we have here
is basically three parts. One is the templating. And if you’ll move your head to
the right, you’ll see why they call it mustache, because
of these little guys. And here we’ll just declare
what we’re going to have in each spot. Then we’re using a payload
of our JSON. And the result, what the
templating engine will put in our page will be this mark-up
that the browser will know how to render. Another cool thing that we
should leverage today when we are approaching the world of
mobile web app is some new CSS3 products. And basically I’m talking
about [INAUDIBLE] which giving us some goodies,
not really a synthetic sugar but more of real tools to work
with, like variables, like nesting, and mixing and
inheritance in CSS. So your ability to work more
efficiently with CSS will gain you more hour of sleep
and happy users. And one nice thing to remember
is that when you’re working with it, basically it’s easy
today even to debug it because you have the ability to go
quickly in Chrome Dev tools and tap into the source itself
of the CSS or the source code, with Map Source, of course. Some best practices
for the layout– of course avoid the horrible
tables that have been with us in the late ’90s. No absolute position, not
even relative position. We do want to use something
like the Flexbox. Why? Because we basically are able
to communicate the browser exactly what we want
it to achieve. Things like, OK separate now
those boxes and make the middle boxes twice the size from
the other boxes, or make all of them in a row or
a column, et cetera. It’s all trivial with Flexbox,
and just challenging you to do it with the regular CSS. It will be much, much harder,
and more code for you to read later when you’re coming to
maintain the web app. This little example is just to
show you how you can control here on the orientation. So here it’s horizontal. If the user is flipping the
phone, you could do it vertical as well. And very easy to control
the different components of your Flexbox. The one caveat here is
that we’re talking about the new Flexbox. And there are relatively really
few changes that you need to pay attention to. This is just to show you how you
could easily control them. And really nice talks on
developer.google.com/live showing you more how
to work with it. Some tips to remember is that
if you want to have a fixed position for your head or
footers, it used to be a big no-no in all the browsers. Now both on Mobile Safari and,
of course, Chrome for Android, you just need to do
position fix. If you have an element that you
want to scroll elements inside it, just do
overall scroll. And last but not least, if you
want this nice responsive acceleration, deceleration
scrolling in WebKit, and as we mentioned at the beginning, 90%
plus of the browser are supporting it, just do WebKit
overflow scrolling touch, and you’ll be able to gain
this nice ability. One important thing to note
about touch is that it’s very different for our mouse. We need to make sure that
we are listening to the right events. And one common pitfall is to
bind events to the click. On mobile and touch screens,
of course the browser will wait 300 milliseconds, because
it needs to distinguish one click to two clicks. And this is why I put the link
here to Fast Click Library that the “Financial Times”
did, actually [INAUDIBLE] that was bought by the
“Financial Times,” and which basically listened to the touch
start in making sure that it’s much smoother and
much more responsive. And the other good link here is
just to best practices of developing for multi-touch
blog posts that Boris Smus wrote. When we’re coming to the world
of offline, and specifically mobile web apps, we want to make
sure that our app will work even when there’s
no connection. Why? Because in the cases where we
have a flaky connection, or on an airplane or submarine, the
user could be productive. And a great example is
[INAUDIBLE], of course. And today, lucky for us, we have
all the building blocks. So I know that they are not
perfect and they could improve over time. And I see the guys that are
mentioning and trying to point their fingers to some
known candidates. But here they will get better. And actually we are able to work
with them today, so why not tap in to them? To storing [? updates ?] of course, we have all
the good things here. And to know when to do the sync,
basically the main API that we want to use
is Navigator online or Window online. As I mentioned before, Lawnchair
is one good library to use when we want to make
sure that we all doing the best with the certain app or
certain browser that our app have to use, which will
basically give us the ability to enjoy all those nice APIs,
depending on what the different browser on the user
device is supporting. And here is a short tutorial
that I wrote a while back to help people converge from WebSQL
to IndexedDB, just because WebSQL is a
depricated API. So you don’t want to start
a new project with it. One thing that held mobile
web apps was the ability to debug them. It wasn’t too easy. Of course, for Chrome for
Android, your life is good. And you could do lots of things
immediately and have basically Chrome Dev tools
and work with them very efficiently on your
mobile as well. But for other platforms, we
have JS Console that Remy Sharp wrote, and all the other
good links here that you are most welcome to check, and
other nice things. I don’t know how many people
know, but basically in Chrome browser we have a
server as well. So you could run it with this
remote debugging port, which is basically part of WebKit,
and have the ability to tap and run Dev Tool, or connect
your Dev Tool to client browsers, and again, gain all
the capabilities and the benefits that we have
in Chrome Dev Tools. Testing, MVC or the clear
separation between our data and our views allow us,
basically, to test our models. And QUnit is one
great example. When we’re coming to test our
views, it’s much more challenging. And here are some good
links to help you achieve that as well. Speed– [INAUDIBLE] all the recent studies shows
form all the big names, like Amazon, Facebook,
Google, Yahoo, every millisecond count. And you do want your users
happy and smiling. And that’s why you need
to focus on mobile web performance, and web performance
as a whole. And luckily for all
of us, [INAUDIBLE] on developer.google.com/live is
doing great shows about web performance and pushing
the web faster. And I highly encourage
you to see his shows. Really, really quality,
great stuff there. When we’re coming to
optimization, there are a few tools that are helping
us today. Blaze.io, that is part of Akamai
let us know exactly what’s going with our
apps from different places in the world. And this other link here is
Mobile Perf for bookmarketlet that Steve Souders did to enable
you to tap into a lot of information from your mobile
web app, and then analyze it, of course,
on the desktop. And SPDY. SPDY is basically a new
experimental protocol designed by Google to reduce the
latency of web pages. And it’s in Chrome. So you could use it today. It will work much faster
for your users. And you have mode
SPDY in a patch. So if you have control of your
servers, I highly encourage you to check it out. The link here will show you how
easy it is to install it and customize it. Last but not least, some
tips and tricks. We have today few tech stocks
that choose the route of convention over configuration. And some really brilliant people
with lots of experience on their hands choose the best
tools out there to make your life more productive. And Yeoman and Thorax are just
two bold examples that I highly encourage you to check
out when you are coming to start a new project. If you are developing on
iOS, there’s a new– it’s not new, actually– but a
nice way to be able to see more loggin, and that’s by
setting Safari developer and then just opening the console. To simulate touch events,
you have it today in Chrome Dev Tools. And let me showing you
how you could do it. If you’ll come here to the
bottom right corner and click on the setting, you’ll
be able to open the setting of the Dev Tools. Probably for you it will
open in general. But if you’ll go to Override
here, you’ll need to click here on Emulate Events. Let me make it bigger. And once you do that, you’ll be
able to listen to all the different touch events and make
sure that your mobile web apps is answering them. It’s not a replacement to
testing it on simulator or on a physical device. But it’s just making the
developer life more productive when they could use it while
they’re developing it, and make sure that at least you’re
answering all the right events in the right DOM and using the
audit and performance tab in the Chrome Dev Tools to make
sure that you are optimizing even before you are reaching
the physical device. Privatization, of course, it’s
very, very important. And like any app, we want to
focus on the MVP or the task that you want to user to
achieve with maximum efficiency. Take advantage, of course, of
mobile specific functionality, like the geolocation, like the
camera, things that are very important for users. And of course, not
to mention touch. When you’re building to the
mobile platform, always think about speed, because it’s
really, really different from what users are expecting or
getting when they’re using their desktops or laptops. And of course, optimization
don’t start it before you need to. But do pay attention and
do it as the last step. So to keep yourself updated with
Chrome as a platform, we have Chrome today on mobile
devices, tablets, desktops, laptops, and TVs, that’s
a great site to check Chrome status. All the latest and greatest in
terms of HTML5 APIs are there. And you could see exactly which
Chromium browser will support them, or supporting
them already. Another great site to keep
yourself updated, it’s updates.html5.rock. As you can see, we’re keeping
it fresh all the time. And here are just a list of
resources that you might want to check and leverage
after our show. So that’s basically
what I had. If we have any questions, this
is a great time to ask them. Just feel free over the chat
or through the handout. So I see one question here
from [INAUDIBLE] is for newbies, “what would you
recommend to start with for mobile web development?”
So let’s go– I see [INAUDIBLE] already answered him
about slide 34. Let’s see. So I will actually answer
it in two ways. One is, of course, you want to
check Yeoman or Thorax in terms of the full stacks
that you want to start from the ground up. Those stacks will give you the
best practices in terms of the libraries, the tools, and the
ability to compile and optimize your app itself. By as a newbie, I will go and
just check what jQuery Mobile or [INAUDIBLE] are doing. And those are really good
frameworks slash libraries to start working with them. And of course, you have Twitter
Bootstrap Responsive as another great
starting point. They’re basically giving you
a nice CSS template, a responsive template to start
your mobile web app. An in Twitter Bootstrap, for
instance, you have also a nice range of jQuery plug-ins that
allow you to have all the common functionality that
you might need. jQuery Mobile is a really nice
one, because they already did lots leg works for you by
checking and making sure that the platform itself will
work on a really wide range of devices. And [INAUDIBLE], of course,
are doing lots of fun nice things in terms of the touch
library that they have. It’s more complicated,
I agree. But if you are building a
complicated app that your users will spend a lot of time
in it, it’s a really nice library that will serve you in
the end of the day lots of wheels that you’ll probably
need to reinvent yourself. [? Dodger ?] Mobile is another
good candidate. And I’m sure there are
plenty of others that I’m not aware of. Those are the ones that
I played in the past. But you are most welcome to
check and let me know. And I’ll be able to update
actually those slides and the blog post that we’ll have as
a summary for this talk. Any other questions
or comments? OK, guys, so thank
you very much. Oh, how did I create
this presentation? Just do view source. It’s all HTML, HTML5. You are most welcome
to take it. The structure of the
presentation itself is sitting on code.google.com. Just have fun. OK, guys, thank you very much. And be strong. Until next time, bye-bye.

Danny Hutson

4 thoughts on “Mobile Web Apps (GDL-IL)

Leave a Reply

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