GitHub

Offline Web Apps on GitHub Pages

Service Workers are a response to the problems of Application Cache, and they’re a powerful and elegant way to offline your web app. But they’re also more complex to implement and maintain.

Meanwhile, GitHub Pages is a great, simple static host for offline-first apps. But deploying apps to GitHub Pages requires manual configuration, especially if you develop with a team, utilize some variant of the GitHub Flow, and want to set up continuous deployment.

Oghliner is an npm package that simplifies both offlining an app with Service Workers and deploying the app to GitHub Pages (including continuous deployment using Travis CI). Oghliner’s goal is to make it as simple as possible to offline and deploy a web app.

To start using Oghliner, install it globally:

> npm install --global oghliner

If you have an existing app in a GitHub repository, invoke the integrate command to configure it. That command copies an offline-manager.js script (which registers the service worker) into your app and reminds you to load that script in your app’s page(s)/template(s) (one of the few steps that Oghliner doesn’t yet automate).

> oghliner integrate
Integrating Oghliner into the app in the current directory…

? Copying offline-manager.js to ./… done!

Oghliner has been integrated into the app!

The app needs to load the script offline-manager.js in order to register
the service worker that offlines the app. To load the script, add this line to 
the app's HTML page(s)/template(s):

<script src="offline-manager.js"></script>

And commit the changes and push the commit to the origin/master branch:

git commit -m"integrate Oghliner" --all
git push origin master

Then you can offline and deploy the app using the offline and deploy commands.

? For more information about offlining and deployment, see:
    https://mozilla.github.io/oghliner/

If you don’t yet have an existing app, start a new app by creating a new repository on GitHub, cloning it to your local machine, and invoking the bootstrap command from its working directory.

> git clone git@github.com:mykmelez/offline-app.git
Cloning into 'offline-app'...
…
> cd offline-app/
> oghliner bootstrap
Bootstrapping current directory as Oghliner app…

Your app's configuration is:

Name: offline-app
Repository: git@github.com:mykmelez/offline-app.git
Description: A template app bootstrapped with oghliner.
License: Apache-2.0

Would you like to change its configuration (y/N)? 

Creating files…
? Creating README.md
? Creating .gitignore
? Creating gulpfile.js
? Creating package.json
? Creating app/favicon.ico
? Creating app/fonts
? Creating app/index.html
? Creating app/robots.txt
? Creating app/images/apple-touch-icon-114x114.png
? Creating app/images/apple-touch-icon-120x120.png
? Creating app/images/apple-touch-icon-144x144.png
? Creating app/images/apple-touch-icon-152x152.png
? Creating app/images/apple-touch-icon-57x57.png
? Creating app/images/apple-touch-icon-60x60.png
? Creating app/images/apple-touch-icon-72x72.png
? Creating app/images/apple-touch-icon-76x76.png
? Creating app/images/favicon-128x128.png
? Creating app/images/favicon-16x16.png
? Creating app/images/favicon-196x196.png
? Creating app/images/favicon-32x32.png
? Creating app/images/favicon-96x96.png
? Creating app/images/mstile-144x144.png
? Creating app/images/mstile-150x150.png
? Creating app/images/mstile-310x150.png
? Creating app/images/mstile-310x310.png
? Creating app/images/mstile-70x70.png
? Creating app/scripts/main.js
? Creating app/scripts/offline-manager.js
? Creating app/styles/stylesheet.css

? Creating files… done!
? Installing npm dependencies… done!

Your app has been bootstrapped! Just commit the changes and push the commit
to the origin/master branch:

git add --all && git commit -m"initial version of Oghliner app"
git push origin master

Then you can build, offline, and deploy the app using gulp commands.

? For more information about building, offlining and deployment, see:
    https://mozilla.github.io/oghliner/

Finally, commit the changes to complete the configuration.

> git add --all && git commit -m"initial version of Oghliner app"

Now that your app is configured, you can build, offline, and deploy it. Bootstrapped apps include a gulpfile.js build script. To build them, install Gulp globally:

> npm install --global gulp

Then simply invoke gulp:

> gulp

To offline your app, invoke the offline command to generate the service worker that offlines your app, specifying the directory containing the files to offline.

> oghliner offline dist/
Offlining dist/ to dist/offline-worker.js…

? Caching "dist/favicon.ico" (384 B)
? Caching "dist/images/apple-touch-icon-114x114.png" (278 B)
? Caching "dist/images/apple-touch-icon-120x120.png" (285 B)
? Caching "dist/images/apple-touch-icon-144x144.png" (321 B)
? Caching "dist/images/apple-touch-icon-152x152.png" (320 B)
? Caching "dist/images/apple-touch-icon-57x57.png" (242 B)
? Caching "dist/images/apple-touch-icon-60x60.png" (242 B)
? Caching "dist/images/apple-touch-icon-72x72.png" (247 B)
? Caching "dist/images/apple-touch-icon-76x76.png" (247 B)
? Caching "dist/images/favicon-128x128.png" (298 B)
? Caching "dist/images/favicon-16x16.png" (216 B)
? Caching "dist/images/favicon-196x196.png" (380 B)
? Caching "dist/images/favicon-32x32.png" (232 B)
? Caching "dist/images/favicon-96x96.png" (269 B)
? Caching "dist/images/mstile-144x144.png" (323 B)
? Caching "dist/images/mstile-150x150.png" (316 B)
? Caching "dist/images/mstile-310x150.png" (411 B)
? Caching "dist/images/mstile-310x310.png" (610 B)
? Caching "dist/images/mstile-70x70.png" (246 B)
? Caching "dist/index.html" (3.08 kB)
? Caching "dist/robots.txt" (102 B)
? Caching "dist/scripts/main.js" (151 B)
? Caching "dist/scripts/offline-manager.js" (1.1 kB)
? Caching "dist/styles/stylesheet.css" (107 B)
Total precache size is about 10.41 kB for 24 resources.

To deploy the app (including the service worker) to GitHub Pages, invoke the deploy command, again specifying the directory containing your app’s files.

> oghliner deploy dist/
Deploying "initial version of Oghliner app" to GitHub Pages…

? Cloning git@github.com:mykmelez/offline-app.git into .gh-pages-cache… done!
? Cleaning… done!
? Fetching origin… done!
? Checking out origin/gh-pages… done!
? Removing files… done!
? Copying files… done!
? Adding all… done!
? Committing… done!
? Pushing… done!

All Oghliner commands are also available via a module interface, so you can integrate them into your Node-based build scripts using tools like Grunt and Gulp. If you bootstrapped your app using Oghliner, its gulpfile.js already has offline and deploy tasks (which you can also use as an alternative to the previous commands).

Finally, invoke the configure command to configure an app to automatically deploy to GitHub Pages using Travis CI whenever you merge a change into your app’s master branch (provided the build completes successfully and tests pass, of course!).

> oghliner configure

Configuring Travis to auto-deploy to GitHub Pages…

Your repository has a single remote, origin.
Ok, I'll configure Travis to auto-deploy the origin remote (mykmelez/offline-app).

To check the status of your repository in Travis and authorize Travis to push
to it, I'll create GitHub personal access tokens, for which I need your GitHub
username and password (and two-factor authentication code, if appropriate).

? For more information about GitHub personal access tokens, see:
    https://github.com/settings/tokens

Username: mykmelez
Password: 

× Checking credentials… error!

You're using two-factor authentication with GitHub.
Please enter the code provided by your authentication software.

Auth Code: 123456

? Checking credentials… done!
? Creating temporary GitHub token for getting Travis token… done!
? Getting Travis token… done!
? Deleting temporary GitHub token for getting Travis token… done!
  Creating permanent GitHub token for Travis to push to the repository…
? Creating permanent GitHub token for Travis to push to the repository… done!

? You had an existing token for this app, so we deleted and recreated it.

? Checking the status of your repository in Travis… done!

Good news, your repository is active in Travis!

? Encrypting permanent GitHub token… done!
? Writing configuration to .travis.yml file… done!

? You didn't already have a .travis.yml file, so I created one for you.
  For more information about the file, see:
    http://docs.travis-ci.com/user/customizing-the-build/

You're ready to auto-deploy using Travis!  Just commit the changes
in .travis.yml and push the commit to the origin/master branch:

git add .travis.yml
git commit -m"configure Travis to auto-deploy to GitHub Pages" .travis.yml
git push origin master

Then visit https://travis-ci.org/mykmelez/offline-app/builds to see the build status.

Travis will then deploy successful builds (on the master branch):

Travis auto-deploys to GitHub Pages

A few caveats to note:

  • Deployments sometimes take a few minutes to show up on GitHub Pages.
  • Service Workers require that you load the app over an encrypted (HTTPS) connection. All GitHub Pages can be loaded over such a connection, even though GitHub does not officially support it.
  • Service Workers are available in Chrome, Opera, and the Developer Edition of Firefox. They’ll ship in Firefox 44.

Mozilla’s Web App Developer Initiative engineering team built Oghliner because we think Service Workers are a great way to offline web apps, and GitHub Pages are a great way to deploy them, so we wanted to see how much better the combination could be.

We’ve used Oghliner in our own projects, like this presentation and Platatus, and we hope you find it delightful. So learn more about it, try it out, and let us know how it works for you!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

The CSS Androids you were looking for – Mozilla Hacks on GitHub + interview

In Firefox, we offer various content in our about:home page – the start page for many Firefox users – to make people aware of new features and possibilities. As you might have seen recently, we have some animations with the Android robot and Firefox, highlighting that Firefox is available on Android. For you developers out there, we’d like to talk more about how these animations were made.

We have three different animations:

Make sure to interact with the Android robot by moving the mouse over him!

Please note that these about:home snippets have been created specifically for in-product use in Firefox, and one vital factor there is to keep them as compact as possible. This means that there is, for instance, -moz specific CSS prefixes without fallbacks for other web browsers (since that has never been the target), because the goal was to make them optimal in a closed and controlled environment.

Making them work in other web browsers is easily tended to, though, by adding necessary CSS prefixes.

Introducing Mozilla Hacks on GitHub

Since we have a number of demos, code testing and using APIs examples, we wanted to have a more unified approach both to how we share these with you, but also making it as easy as possible to fork, play and build on top of the code we share.

Therefore, I’m happy to announce that we now have a dedicated GitHub repository for Mozilla Hacks demos and we’ll have blog post specific demos available!

As part of that, these about:home snippets are on GitHub with some boiler plate code, where you can see them in action.

Interview with Bruce MacFarlane, snippet creator

Bruce MacFarlane is the lead programmer at Particle for this project with the Android/Firefox about:home snippets, and helped develop the creative abstracts into actual animation. In this interview, with Mozilla’s Barry Munsterteiger, he goes through aspects of the process of creating these animations:

Thanks for helping us with the animations again, it looks like you really had some fun with these. Can you walk us through the process on how these were made?

Of course! Probably the best place to start is with the creation of the Android character in CSS. This was done as a separate piece and at a scale large enough so we could use it in a number of different animation scenarios, just adjusting it’s scale to whichever size worked best in a particular setup.

To use as a reference we were given an image of the green Android character. This image was added to the html file as an overlay at a low opacity as we were building so we could make sure we were matching our css design as close as possible.

Before we began, we had to consider the sort of movements the android would (or could) make during it’s animation, then adjust our layout accordingly. The easiest way to break this task down was to list out what could move on it’s own separate from the other parts of the android and then set up a container div for each that we knew we could apply the animation to:!

  • The entire Android in x/y/z space
  • Head (possibly)
  • Arms able to move and rotate individually – Legs able to move and rotate individually – Eyes able to blink
  • Antennas able to wiggle individually

Example Code:

#perspective-container { position: absolute; top: 0px; width: 264px; height: 336px; background-color: rgba(0,0,0,.05); -moz-transform-style: preserve-3d; -moz-perspective: 800px;}
 
#android { position: absolute; top: 0px; width: 264px; height: 336px;}
 
#android .body { position: absolute; top: 110px; left: 48px; width: 168px; height: 152px; border-radius: 0px 0px 30px 30px; background-color: #96c03c;}
 
#android .head { position: absolute; top: 30px; left: 48px; width: 168px; height: 68px; border-top-left-radius: 50% 100%; border-top-right-radius: 50% 100%; background-color: #96c03c; }
 
#android .eyes { position: absolute; top: 25px; width: 168px; height: 20px;}
 
#android .eye {position: absolute; width: 20px; height: 20px; border-radius: 10px 10px 10px 10px; background-color: white;}
 
#android .eye.left { left: 38px; } #android .eye.right { right: 38px; }
 
#android .antenna { position: absolute; top: -22px; width: 6px; height: 32px; border-radius: 15px 15px 0px 0px; -moz-transform-origin: 50% 100%; background-color: #96c03c; }
 
#android .antenna.left {left: 56px; -moz-transform: rotate(-32deg); }
 
#android .antenna.right { right: 56px; -moz-transform: rotate(32deg); }
 
#android .arm { position: absolute; top: 110px; width: 36px; height: 114px; border-radius: 18px 18px 18px 18px; background-color: #96c03c; -moz-transform-origin: 50% 20%;}
 
#android .arm.left { left: 0px; }
 
#android .arm.right { left: 228px; }
 
#android .leg {position: absolute; top: 262px; width: 36px; height: 60px; border-radius: 0px 0px 18px 18px; background-color: #96c03c;}
 
#android .leg.left { left: 86px; }
 
#android .leg.right { right: 86px;}
<div id="perspective-container">
	<div id="android">
		<div class="body"></div>
 
		<div class="head">
 
			<div class="eyes">
				<div class="eye left"></div>
				<div class="eye right"></div>
			</div>
 
			<div class="antenna left"></div>
			<div class="antenna right"></div>
		</div>
 
		<div class="arm left"></div>
 
		<div class="arm right"></div>
 
		<div class="leg left"></div>
 
		<div class="leg right"></div>
	</div>
</div>

Do you have any new coding tricks that you employed on this round?

When running a long animation with many moving parts sometimes I find it helpful to set an animation duration a little longer than the entire length of the sequence on all the individual parts. The benefit of this is avoiding animation delays of varying lengths, and just working with percentages.

So say the entire animation duration is ten seconds, then moving the android across the screen at two seconds within the sequence for a length of one second would mean moving the #android element starting at 20% and completing at 30%, then have the Android wave from 30% to 35%, etc.

What were the biggest challenges with these animations? and how did you get around these challenges?

In looking over the animation specifications another issue we discovered early on was trying to figure out how to best handle how to have the Android rotate to it’s side. The problem being we can’t curve elements back into Z space, so if we just rotated the Android on it’s Y axis (the Androids profile) we would just be looking at a flat 2d rendering which would all together disappear when rotated 90 degrees towards us. The solution turned out to be a little complex.

Since the body was supposed to be cylindrical we didn’t have to worry about how that would animate since it’s profile would look the same wether from the front or the side. For the rest of the body (antennas, arms, and legs) we moved those elements into a separate container from the body that would be able to move on the Y axis. When this containing element was rotated, we had to do a counter rotation on all the items within tricking the eye into believing these elements had depth in each direction. To handle the eyes, during the rotation they are animated to the side within a container that has it’s overflow set to hidden.

Once the heavy lifting of setting up the Android was complete, the rest was relatively easy.

Example code:

body {margin: 0; padding: 0; }
 
#perspective-container { position: absolute; top: 0px; width: 264px; height: 336px; -moz-transform-style: preserve-3d; -moz-transform: translate3d(0,0,0); -moz-perspective: 800px; background-color: rgba(0,0,0,.05);}
 
#android {position: absolute; top: 0px; width: 264px; height: 336px; -moz-transform-style: preserve-3d;}
 
#android .rotating-container { position: absolute; width: 264px; height: 336px; -moz-transform-style: preserve-3d; -moz-transform: translate3d(0,0,0); }
 
#android.spin .rotating-container { -moz-animation: spin 400ms ease-in 500ms forwards; }
 
#android .body { position: absolute; top: 110px; left: 48px; width: 168px; height: 152px; border-radius: 0px 0px 30px 30px; background-color: #96c03c; }
 
#android .head { position: absolute; top: 30px; left: 48px; width: 168px; height: 68px; border-top-left-radius: 50% 100%; border-top-right-radius: 50% 100%; background-color: #96c03c; }
 
#android .eyes-overflow-wrapper { position: absolute; top: 25px; left: 8px; width: 152px; height: 20px; overflow: hidden;}
 
#android .eyes { position: absolute; width: 152px; height: 20px; -moz-transform: translate3d(0,0,0); }
 
#android.spin .eyes { -moz-animation: slide-eyes 400ms ease-in 500ms forwards; }
 
#android .eye { position: absolute; width: 20px; height: 20px; border-radius: 10px 10px 10px 10px; background-color: white;}
 
#android .eye.left { left: 30px; } #android .eye.right { right: 30px; }
 
#android .antenna { position: absolute; top: 8px; width: 6px; height: 32px; border-radius: 15px 15px 0px 0px; -moz-transform-origin: 50% 100%; -webkit-transform-origin: 50% 100%; background-color: #96c03c;}
 
#android .antenna.left { left: 104px; -moz-transform: translate3d(0,0,0) rotateZ(-32deg); -webkit-transform: translate3d(0,0,0) rotateZ(-32deg);}
 
#android.spin .antenna.left { -moz-animation: reverse-spin-left-antenna 400ms ease-in 500ms forwards; } 
 
#android .antenna.right { right: 104px; -moz-transform: translate3d(0,0,0) rotateZ(32deg); -webkit-transform: translate3d(0,0,0) rotateZ(32deg);}
 
#android.spin .antenna.right { -moz-animation: reverse-spin-right-antenna 400ms ease-in 500ms forwards; }
 
#android .arm { position: absolute; top: 110px; width: 36px; height: 114px; border-radius: 18px 18px 18px 18px; background-color: #96c03c; -moz-transform-origin: 50% 20%; -webkit-transform-origin: 50% 20%; -moz-transform: translate3d(0,0,0) rotateY(0deg); }
 
#android .arm.left {left: 0px; }
 
#android .arm.right { left: 228px;}
 
#android.spin .arm { -moz-animation: reverse-spin 400ms ease-in 500ms forwards; }
 
#android .leg { position: absolute; top: 250px; width: 36px; height: 72px; border-radius: 0px 0px 18px 18px; background-color: #96c03c; -moz-transform: translate3d(0,0,0) rotateY(0deg);}
 
#android .leg.left {left: 86px; }
 
#android .leg.right { right: 86px; }
 
#android.spin .leg { -moz-animation: reverse-spin 400ms ease-in 500ms forwards; }
 
@-moz-keyframes spin {0%{ -moz-transform: translate3d(0,0,0) rotateY(0deg); } 100%{ -moz-transform: translate3d(0,0,0) rotateY(-180deg); }}
 
@-moz-keyframes reverse-spin {0%{ -moz-transform: translate3d(0,0,0) rotateY(0deg); } 100%{ -moz-transform: translate3d(0,0,0) rotateY(180deg); }}
 
@-moz-keyframes reverse-spin-left-antenna {0%{ -moz-transform: translate3d(0,0,0) rotateZ(-32deg) rotateY(0deg); } 100%{ -moz-transform: translate3d(0,0,0) rotateZ(-32deg) rotateY(180deg); }}
 
@-moz-keyframes reverse-spin-right-antenna {0%{ -moz-transform: translate3d(0,0,0) rotateZ(32deg) rotateY(0deg); } 100%{ -moz-transform: translate3d(0,0,0) rotateZ(32deg) rotateY(180deg); }}
 
@-moz-keyframes slide-eyes {0%{ -moz-transform: translate3d(0,0,0); }100%{ -moz-transform: translate3d(-280px,0,0); }}
<div id="perspective-container">
	<div id="android" class="spin">
		<div class="body"></div> 
 
		<div class="head">
			<div class="eyes-overflow-wrapper">
				<div class="eyes">
					<div class="eye left"></div>
					<div class="eye right"></div>
				</div>
			</div>
		</div>
 
		<div class="rotating-container">
			<div class="antenna left"></div>
			<div class="antenna right"></div> 
			<div class="arm left"></div>
			<div class="arm right"></div>
			<div class="leg left"></div>
			<div class="leg right"></div>
		</div>
	</div>
</div>

How do you see animation progressing as more and more developers pick up these techniques?

The real interesting thing is going to the blurring of the line between WebGL and CSS.

It is far more commonplace to build WebApps that have a native app feel through the use of transitions and views that typical web experiences didn’t have a couple years ago.

Great, Thanks again for such great work.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Firebug is now on GitHub – go learn and contribute!

There is probably not a single web developer out there who haven’t used Firebug over the years to debug their own code. And now here’s the next step in the evolution!

Firebug on GitHub

As outlined by Firebug developer Jan Odvarko, who truly knows the ins and outs of Firebug, Firebug is now available on GitHub which offers you the possibility to learn from and tinker with the code. But not only that, you can create your own version of Firebug, do pull requests, fork it, learn how to develop Firebug extensions and much more (having developed a couple of Firebug extensions myself, this is great news and a good learning ground).

Working with the Firebug repository

In Hacking on Firebug, Jan outlines the most common things you can do, like:

  • Run Firebug From Source
  • Build Firebug XPI
  • Push to the Firebug repository

Especially the last one there is really interesting and a very simple way for you to contribute to improving Firebug!

This is, in Jan’s words, how the process looks for pushing to the Firebug repository:

  1. First, you need a GitHub account. It’s simple and all the cool kids are already there. 🙂
  2. Fork Firebug repository (see how to fork a repo).
  3. Clone your fork onto your local machine (your URL will be different):
    $ git clone git@github.com:janodvarko/firebug.git
  4. After you made your changes, you can stage/add modified files (e.g. firebug.js) and commit:
    $ cd firebug/extension
    $ git add content/firebug/firebug.js
    $ git commit -m "New API for my extension"
  5. Push to your public fork:
    $ git push -u origin master
  6. Send a pull request. We’ll review your changes and accept if all is OK!

Go learn and contribute!

Now, what are you waiting for? 🙂

Go play around with, learn from and start contributing to Firebug!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)