Whatever your stance on “too PC” is, it is a good idea to think about the words we use and what effect they can have on people. And when it is easy to avoid a word that may cause harm, why not do it? That said, we’re lazy and forgetful creatures, which is a why a tool like Alex.js can help.
And lo and behold, the team listened and my ace colleagues Kiril Seksenov, John-David Dalton and Kevin Hill now made it happen: you can now download the Alex-add-in.
The add-in works in: Excel 2013 Service Pack 1 or later, Excel Online, PowerPoint 2013 Service Pack 1 or later, Project 2013 Service Pack 1 or later, Word 2013 Service Pack 1 or later and Word Online.
Spread the word and let’s get rid of inconsiderate writing one document at a time.
You probably have already read the announcement on the Web Audio API coming to Firefox, and are totally excited and ready to make your until-now-WebKit-only sites work with Firefox, which uses the unprefixed version of the spec.
Unfortunately, Chrome, Safari and Opera still use the webkitAudioContext prefixed name. Furthermore, as a result of the spec being still in flux, some browsers use deprecated properties and method names that are not present in standards-compliant browsers: Safari uses the old method names, Firefox uses the new ones, and Chrome and Opera use both. In addition, not all features of Web Audio are already implemented in Firefox yet.
What do we do!?
We don’t want to maintain two or more separate code bases, and feature detection code is cumbersome! Plus we want to write code that reliably works in the future, or at least, works with a minimum amount of changes. Is there a way to satisfy all these constraints at the same time? Probably!
Writing for today (and tomorrow)
First, get a copy of AudioContext-MonkeyPatch by Chris Wilson. This little library will “normalise” the interfaces for you and make it look as if your code is running in a standards compliant browser, by aliasing prefixed names to the unprefixed versions. And it won’t do anything if the unprefixed versions are already present.
Once you include it in your page, you can write in “modern Web Audio API” style, and do things such as:
var audioContext =new AudioContext();
everywhere, including Chrome/ium, Opera, Safari, and —of course!— Firefox.
Also, if new methods such as start are not detected in some nodes, the library will also alias them to their old names. Thus, start is mapped to noteOn, stop to noteOff, and so on.
If you’re porting moderately “old” code (say, a year old) it’s possible that it uses some methods that AudioContext-MonkeyPatch doesn’t alias, because it helps you to write code in the new style. For example, the way to create instances of GainNode used to be
var gain = audioContext.createGainNode();
but nowadays it is just
var gain = audioContext.createGain();
Since the old method names are not present in Firefox, existing code may crash with something like createGainNode is not a function, and you now know why.
There’s a section in the spec that lists the old names and their updated equivalences; be sure to check it out and change your code accordingly. You can also check this article on porting which covers more cases and has many code samples.
The node parameters you use must also be supported in Firefox too. If they aren’t, you might be able to change them into something “acceptable” for the time being, and count on the talented audio developers to implement those very soon.
For example, up until a couple of days ago PannerNode did not support the default HRTF panning model yet, and attempting to use a PannerNode with that configuration simply resulted in silence or a mono output coming out from that node, depending on the build you used.
Today the support is already present in Nightly, but not quite yet in Aurora. In the meantime, you can explicitly specify 'equalpower' instead:
var panner =new audioContext.PannerNode();
The best way to know what’s going on in the Web Audio API land is to subscribe to the mailing list. Be aware that there might be a bit of high level tech discussions from time to time, and you might not understand it all, but you will learn a lot even if only by skimming through it.
You might also want to subscribe to the umbrella bug that tracks the Web Audio API implementation in Firefox, so that you get alerts when associated bugs get updated or resolved.
Finally, there’s also a list of projects built with the Web Audio API, specifying which ones use the standard AudioContext and which browsers do they work on. If you’re a person that learns by example, it might be interesting to have a look at their source and see how they have resolved the compatibility issues.
With the introduction of Firefox OS, development of an open apps marketplace, and a push to implement powerful web APIs for closer hardware integration, Mozilla is serious about web apps. We believe that the web can deliver an experience similar to native apps, even on mobile.
We can’t forget about the most important piece, however: a good developer ecosystem. We need to provide various tools to make it easy for both beginners and experts to write web apps and deploy them.
This is why we’ve created mortar, a collection of app templates that provide starting points for different kinds of apps and tools to manage and deploy them.
A few weeks ago, Pierre Richard wrote a post here about his experiences getting started writing apps for Firefox OS. There’s some good stuff in his post, including his critiques of mortar. He felt mortar was too complex and introduced a different starting point for writing web apps for Firefox OS.
This post will loosely respond to some of his points, introduce mortar, and explain why I think it is a valuable starting point for writing web apps for both beginners and experts. A detailed walkthrough of mortar is provided at the end in a screencast.
Why Are Templates Useful?
If you’re someone who really enjoys simplicity, you might initially find mortar too complex. I’m definitely someone who wants to boil things down to its simplest form, rejecting unnecessary complexity. We’ve worked hard to make sure that we only include things in mortar that prove to be very useful when building and deploying a web app.
So I encourage you to learn about the tools mortar comes with, especially if you think you don’t need it. Mortar is our expression of good web development practices, so it’s also a chance to learn about modern tools and good ways to build web apps. Just as Django or Ruby on Rails may seem complex at first, you pay off your initial investment later on.
The Technology Within Mortar
Mortar templates are pre-built to help you write web apps quickly. These aren’t specifically Firefox OS apps. We want you to build web apps that can run anywhere the web is. Firefox OS is a good place for a web app, but the mortar templates aren’t specifically targeting Firefox OS (even if some of the more advanced templates borrow a few styles from it).
All of the mortar templates come with the following:
A project structure (folders for css, js, etc)
In addition, an installation button is provided (but commented out by default) in case you want to test your app as an installed app (or let users install it outside of an app store). All you have to do is uncomment one line of HTML. This, in combination with the pre-built manifest.webapp file, makes it easy to build an app.
Here’s what your app looks like when you start it from a template:
Volo is a tool much like grunt which simply automates tasks at the command line. We use volo because it integrates nicely with require.js. An example command is volo serve, which fires up a development server for your app. View this documentation for more volo commands available.
Volo lets you easily deploy your site to github. After customizing www/manifest.webapp for your app, simply do:
Your optimized app is now running live on github, and is ready to submit to the marketplace!
Games and Layouts
Everything described above is applicable to all apps, but we also want to help people who want to write specific kinds of apps. This is why we’ve created multiple templates, each catering to a specific need:
mortar-app-stub: a minimal template that only has a little pre-built HTML (a blank canvas for any type of app)
mortar-list-detail: a template like app-stub but also includes a layouts library and a basic list-detail type interface
mortar-tab-view: a template like list-detail but the default interface is a tabbed view
We have a blank canvas (app-stub), a game template (game-stub), and two other templates that come with pre-built layouts.
This is what the game template looks like. It looks pretty boring, but it’s rendered using requestAnimationFrame and you can control the box with the arrow keys or WASD. In the future, we might include image loading and basic collision detection.
The list-detail template is below. It comes with a pre-built layout that implements a list-detail interaction where you can touch a list item and drill down into the details. You can also add new items. This data-driven functionality is powered by backbone.js. We are still improving the design. (The tab-view template looks similar to the list-view shown here.)
The layouts library is mortar-layouts, and it’s something we came up with to make it really easy to build application UIs. To me, this might be the most exciting part of mortar. I won’t go into too much detail here, but it uses x-tags and other new HTML5/CSS3 features to bring a native-feeling application UI to the web. View documentation here and a live demo here (and the source for the demo here).
The layouts library and the two templates that come with layouts are in beta, so keep in mind there are minor bugs. The biggest problem is the lack of design, and we will be working on integrating better styles that reflect Firefox OS (but are easily customizable with CSS!).
Future Work for Mortar
Mortar is relatively new, and it needs time to be fully documented and fleshed out. We are working on this actively.
We are also fine-tuning our templates to figure out what the best starting points are for each one. Admittedly, having the big blue install button be the default screen for the app-stub was a mistake, which has been fixed. Now you get a short helpful message with links of what else you can do.
Most of the work we have left is with the list-detail and tab-view templates, and figuring out how to deliver useful layouts to developers. We don’t want to force a big framework on them, but feel strongly that we need to help them develop application UIs.
We love feedback, so feel free to file an issue to get a conversation started!
I made a screencast which walks through mortar in detail and shows you how to use require.js, volo, and other things that it comes with. Watch this if you are interested in more details!
I find, however, that there is still a lot of confusion as to what developer evangelists do, and I also find lately that a lot of very obvious marketing and PR messages get sold as developer evangelism.
What we do as developer evangelists
Developer evangelism for me started out of the necessity to have an unbiased, sane voice for developers out there. We don’t sell products, we explain them and let developers make their own decisions about using them. Our main goal is word of mouth and people using the materials we provide. This means first and foremost one thing: being honest and real about what a product does and how it is useful for developers.
We also need to be the spokespeople for developers in our companies. We should know what people use out there and what they want, what excites them and how our products match those needs.
And this is where a skill comes in that can rub people with traditional marketing and PR tasks and skills the wrong way which I call pre-emptive writing.
What is pre-emptive writing?
What I mean by pre-emptive writing is that when you for example blog about a product you do not only praise its usefulness and show what it does for people but you also slip out of your role as a salesperson. Instead think of how you as a developer would read this were you a fan of a competing technology or other products.
Then you include and answer the arguments that you would write as comments to your own post playing that devil’s advocate. Instead of taking the traditional route of not mentioning flaws that might go undetected or obvious similarities to other products you mention them with the arguments that make them interesting for you. For example:
If your product has a flaw that needs ironing out you mention what can happen and how to recover or fix the issue. You also list the obvious feedback channels people can use should that problem happen to them. As developers we know that stuff breaks – it is ridiculous to claim otherwise and let people find out the hard way
If your product is very close to a competitor’s you explain that this is the case as the other product is a very useful thing and it wouldn’t make sense to reinvent the wheel if it runs smoothly. You point out the differences and benefits your product has – for example that it ties into a larger set of products or that it is available open source or performs better in a head-to-head comparison. People make these comparisons in any case – if you anticipate and do them in their stead they see that you are one of them and that you are not blinded by your own advertising. If the similarities are very obvious it would make you look like a very uninformed person or not very skilful liar not mentioning them
Why is this important?
Three words: de-trolling your feedback. Right now our jobs can be incredibly frustrating as the feedback we get (and marketing and PR also looks at) is largely polarised. You either have fans praising what you do over the moon or fans of your competitors pointing out that they already did the same and you are catching up.
Of course you also have comments full of vitriol by people who just hate what your company does and want to repeatedly tell you that, but that is a thing you can happily ignore.
By pointing out the obvious pros and cons of your product to people you prevent a lot of obvious hateful or overly excited comments. Yes, this will cut down on the number of comments you will get but it will also start a more interesting conversation.
Another effect of pre-emptive writing is that you don’t have to prepare a counter-statement – you already did that. In a traditional marketing world this is what you do. You don’t say what’s wrong but you prepare a statement for the press when things go wrong. In most cases you prepare this statement after things went wrong with a lot of stress, phone calls and “we need to deal with this now, people are re-tweeting and re-posting the bad messages all over the place”. This is stress we can avoid.
Getting pre-emptive writing out can be tricky as it is against a lot of basic beliefs of sales and marketing. But you are a developer evangelist – this is your job. Pre-emptive writing and constantly questioning your own products makes you one of your audience and keeps you their spokesman – a developer evangelist.
Tekmark Global Solutions LLC Columbus, OH Job description: …Technical Writer Business Systems Analysis MS Access On-line Documenting Web Content Roles and Responsibilities:* Create documentation for applications developed internally within the department.o Application Access Strategy (AAS) o Application…
View full post on Dice.com – Web Application
Jd Infolabs Llc NY, NY Job description: …sets for Oracle eBusiness* Must have strong writing and communication skills; able to communicate with technical and business community.* Web development experience is preferable.* Must be able and willing to travel within the 5 boroughs of Manhattan.
View full post on Dice.com – web