Are you a developer who’s passionate about Mozilla’s mission on the open Web? We need your help: We’re looking for someone to build a game to help keep the Web open as it goes mobile. There’s a Firefox mobile website testing app which we think would make a nice little HTML5 game — with scoring, achievement, levels, leaderboards — and we think you have the chops to make it fun. We’ve had some success making a game of the activity within our team, but we think you could do it better.
Here’s some context. We need lots of people looking at lots of frequently visited websites to see if they look good and work well on mobile. And if they don’t, we need to figure out how to make them better: by finding the bugs and fixing our browser or by working with the developer who built the site to make it work on the open Web. Testing Fennec matters for the future of the open Web:
Fennec, Mozilla’s mobile browser, just landed in Google Play (you may remember it as the Android Marketplace). Firefox Beta for Android is better than ever! You can download it now, use it on your Android phone or tablet and share your feedback. If you get hooked on testing, you’ll want to create a bugzilla account (if you don’t have one) and start filing bugs. By
If you’d like to do a little more directed testing, check out Aaron Train’s most excellent testing app, which sends you to some of the world’s leading websites to share your feedback. This is the app we’d like to gamify, to motivate more people in the Mozilla community to help us keep improving the Firefox mobile web experience for everyone.
What matters is mobile
It’s an interesting exercise to start viewing and interacting with the world’s most frequently used websites in a mobile browser. Any mobile browser. You realize the mobile Web has a ways to go. But there’s more to it than that. David Slater, who leads Product Marketing at Mozilla put it so well that I’m just going to share a note that he sent out internally earlier this week:
The mobile Web is under threat. For 8 years Mozilla has fought to make the Web open on desktop – and won. On mobile, it’s different – the battle is underway. In order to win, we will have to make the Web on mobile devices as compelling for developers and users as native mobile apps are today. Marketplace is about doing that. Boot-to-Gecko, ultimately, is about doing that. But first, we have to break open the mobile web and expose the issues.
Today, Apple and Google – and therefore browsers based on Webkit – are dominating the mobile Web, and as a result developers are coding for a single rendering engine. Like we did with desktop, we have to ensure developers have access to truly open standards. And that means that we need to do whatever it takes to establish Gecko‘s presence on mobile – and specifically, on the Android platform which is widely forecast to grow more than any other in the next 5 years.
There are many ways you can join us in this battle, but if you’ve been wanting to test your skills by building a Web game, there’s never been a better time to try, and never for a better cause. And if you need a little help, there are many places you can ask, like our IRC channel, #devrel, the engagement-developers mailing list, or simply @mozhacks on Twitter. And, of course, if you do, we’ll make you MDN-famous, and treat you like a hero. Thank you.
This post was originally published as A Compendium of Awesome, and is a short summary of a Firefox work week. Posted here to give an overview, with focus on some details, about things happening with Firefox developement.
Two weeks ago, the Firefox team got together for a work week in Toronto. It was amazing. Walking through a room with that many excellent people doing excellent things was inspiringhumblingunbelievable and the hits kept on rolling.
The combined mobile and graphics teams cut the beta blocker list for Fennec Native in half. The desktop team banged together a working prototype of sign in to the browser. The firefox tech leads worked with product and project management to nail down the kilimanjaro bug list for desktop. Madhava gave a great talk about the future of Firefox UX. I would have scored it as a strong success based on those outcomes alone.
Sync meet-up and discussion to evaluate how to move forward with a smaller core, by moving data handling to components and allowing the Sync team to concentrate on the real Sync functionality
Session Store meet-up and discussion on how to move forward with “Speedy Session Restore” as well as SS2 (rewriting SS).
I know I’ve missed things. I know some of it is still being written up. In fact, I’m not even the first to write a round up post. Here’s Finkle doing the same, and dcamp, and cwiiis.
FX-Team is big enough these days that it’s quite an undertaking to get us all together in one place. But man, it’s phenomenal when we do.
HTML5 needs spokespeople to work. There are a lot of people out there who took on this role, and here at Mozilla we thought it is a good idea to introduce some of them to you with a series of interviews and short videos. The format is simple – we send the experts 10 questions to answer and then do a quick video interview to let them introduce themselves and ask for more detail on some of their answers.
Today we are featuring Andrew Betts, director of Assanka.
1) You worked on the HTML5 application for the financial times. What made you go HTML5 and not native? How many people were involved at all?
The FT has an agnostic approach when it comes to the formats and technologies we can use to display our content. The choice has to suit the content, the reader, and our business model. Before we launched the HTML5 app there was already an FT native app on iOS, and it received an Apple design award, but HTML5 offered several significant benefits, the most important of which was to allow us to maintain a direct relationship with the reader. Secondary benefits include a faster update process, an investment in future cross-platform compatibility (HTML5 is yet to fully realise the dream of write-once, run everywhere), and freedom from restrictions and rules that are (or may be in future) imposed by app store operators.
2) What would you say was the easiest part and what was the thing that you had to spend the most time on to make it work?
Interactions are the hardest thing to crack. Matching behaviour to user expectations is frighteningly complex, especially when you realise that instinctive expectations of swipe behaviour is actually quite varied and inconsistent. One example of this complexity is swiping horizontally from the bottom of a section page, which takes you to the top of the next one. If you then swipe back, do you end up where you were, or at the top? So dealing with interactions is both technically hard and architecturally challenging.
Offline behaviour is also very tough. We get a lot of “User x can’t use the app offline” style support requests, and those are very hard to debug. We log every report but the priority is to figure out the scale of the problem.
The easiest thing to deal with is probably layout. We send all legacy browsers to m.ft.com so we only have to cope with the most recent major versions, and that means that generally we get good standards support for CSS.
3) How did you deal with the differences in interfaces? A mobile has much less space than a tablet and again less than a desktop. Are you using mediaqueries to give different experiences?
We group devices into one of four sizes based on media queries, and we vary which resources we use slightly based on the reported DPI, but most of our responsive layout logic is done in JavaScript. We make a few assumptions right now to make development easier, such as that the user cannot change the size of the browser window, except by rotating the device, so we only need to change the layout on orientation change, not in response to arbitrary resizing of the window. We also currently assume the user has no mouse cursor, so there are no hover effects.
4) How does input get into it? Is it simple enough to build touch interfaces in HTML5 or did you have to use some trickery?
Quite a lot of trickery is involved, unfortunately. The browser has to tread a fine line between on the one hand offering a touch API to web developers and getting out of their way to let them use it, and on the other, dealing with the fact that almost all websites are still built for keyboard and mouse, so the browser needs to help the user deal with that. We developed a polyfill called Fastclick which makes click events fire as fast as touch events, and that certainly helps us provide an experience that is as snappy as using a native app.
We also deal with swiping in a few quite distinctly different ways. Swiping between sections is an endless carousel, and we implement the tracking and sliding ourselves, by maintaining hidden page containers to the left and right of the current view and applying CSS 3D transforms. But paging through an article requires different scroll mechanics – it has a fixed length, and we have to lay out the whole article in one go to know how many pages there are. Pages that scroll vertically are a different challenge again, and there we use a combination of leaving the browser to do scrolling natively, and simulating it where we need slightly different behaviour.
You’ll also notice that the pages don’t ‘bounce’ when you hit the top and bottom of the page, despite that being the normal behaviour in the iOS browser. We’ve gone to quite some lengths to ensure that the user experience mirrors an app and doesn’t feel like the device ‘coping’ with a site that hasn’t been designed to be viewed using a device with touch input.
5) You said in your talk at Blackberry Devcon that you are using localStorage to cache your JavaScript libraries and some of the images. Why not use WebSQL or IndexDB for that? Isn’t the synchronous nature of localStorage slowing things down?
No, actually localStorage is considerably faster than WebSQL (we are yet to use IndexedDB because it’s not supported on some of our target platforms). The time required for a lookup by key in localStorage is many times less than the equivalent SELECT statement on a WebSQL table. It’s true that it’s synchronous, but if the critical aspect affecting perceived performance is the time required to fetch data, which it often is, then localStorage offers a much faster response. it’s also typically reliable and relatively stable compared to the behaviour of WebSQL and particularly the HTML5 app cache.
6) You also said that localStorage uses UTF-16 instead of UTF-8. This means you can store two ASCII characters in one UTF-16 one and thus double the storage capacity, right? Can you share some code? This would be incredible to use for everybody out there.
Both localStorage and WebSQL use UTF-16 in webkit browsers, it’s one of many aspects of the implementation of these technologies that don’t make a lot of sense! We’re experimenting with some algorithms for compressing our data so we can make more efficient use of that storage, and one of those is to combine two characters into a single UTF-16 one. We’re not using that in production yet, but when we do we’re certainly hoping to open source it.
There are simpler things to be done as well. A cursory poke and prod of WebSQL tables suggest that column names are stored along with the value in every cell, so some attempts to increase efficiency are as simple as using single character column names. Clearly we ought not to have to do all this, but it’s the price you pay for dealing with bleeding edge features in browsers.
7) What would you consider the best start for someone when they want to build an HTML5 app? What are the first things to get sorted?
Decide ahead of time what you’re trying to achieve. I could be a pedant and say that making your site HTML5 is really just a matter of changing the DOCTYPE, so an ‘HTML5 app’ is really whatever you define it to be, and having a clear idea of that is a good place to begin. Are you building something just for touch, or for keyboard and mouse as well? Does it need to work offline? Will it be crawlable by search spiders? Will it work with JavaScript disabled?
There are some great resources like MDN, but we often find ourselves reading the HTML5 specs, and sometimes even the webkit source code to find out how something is actually implemented.
8) Can native and web apps be the same thing?
Technically, I guess not – strictly speaking a native app is complied code running directly on a platform, but the hybrid model seems to be getting ever more popular, and I often see apps which are thinly veiled web browsers. If you look at it from the user perspective and say, can a web app feel exactly like a native app, I don’t see why not. The challenges are greater because of the diversity of uses that web technologies are designed for, and the diversity of platforms on which they are used. And for uses such as gaming, native code is always likely to run faster and have deeper access to the OS.
But for applications like publishing, which after all was the original purpose of the web, web technologies do provide support for most of the user experience concepts that we need.
9) What about testing? How did you approach this? Do you have an array of hardware to play with?
It’s a nightmare. We had a local electrician built us a charging station where we could store all our devices and keep them charged all the time. We have around 45 individual devices in our team (that’s around 4 times more devices than we have people). We’re constantly looking at ways of improving our testing process, and we keep revisiting automated, on device testing, but we’re not using it in our build cycle as yet. Right now we have a team of very dedicated testers who poke and prod devices all day.
10) As someone who went through the process of building a big HTML5 app, what would you like to have from browser vendors to make your life easier?
A blithe answer is ‘How long do you have’, but in practice we have to accept we’re using freshly minted technologies and there might be teething troubles. The main things on our shopping list are: more frequent and aggressive browser updates (especially on Android, where the browser is the problem child of the mobile web world), a better and more reliable app cache, and hardware acceleration of CSS transforms.
Mozilla is happy to support Facebook in forming a Core Mobile Web PlatformW3C Community Group in which to curate prioritized, tiered lists of emerging and de facto standards that browsers should support in order for the Web to compete with native application stacks on mobile devices.
So if you are outspoken and interested in taming the battlefield that is mobile browsers, head over to the Core Mobile Web Platform community group and let your voice be heard.
As you might be aware, Mozilla is working hard on making mobile development possible with purely open technologies. For this, we are defining a set of APIs to access the hardware of mobile devices called the Web APIs. John Hammink of Mozilla published a blog post on the subject on Monday outlining the current state of affairs. A good chance to have a chat about where we are and to ask what you can do to help Mozilla in this effort.
1) John, what is your involvement in the Web APIs project?
I am the lead QA. I am also assuming an evangelist role – we need to get the community involved as early as possible around testing these. Not to mention building apps around these! Wanna help?
2) What are the APIs that are ready to play at the moment and what do people need to try them out?
I’ve made a few atomic testpages around testing the webapis available. These are: Battery, Camera, IndexedDB, Vibrator and SMS. More are coming soon – but perhaps require combination with other APIs (for example, Telephony requires Audio); that and other APIs are specific to Boot to Gecko (B2G).
3) So the battery API is one of the first ones to land. Whilst interesting as an information piece on your phone, it is not quite that fascinating for developers. What uses cases can you think of? Maybe reading the battery before your massive WebGL animation and reading it afterwards?
Maybe I have a WebGL simulation or, perhaps, a game that requires a certain power output or power availability. We can, for example, trigger notifications when power goes below a certain level. If it’s a productivity app, maybe we want to trigger the user to save their work.
4) Camera APIs, now we are getting somewhere! How is the support for Canvas on Fennec and mobile devices? The first thing that would get me interested is to do an Instagram in HTML5 by changing the photos.
Canvas works identically to desktop. Taking the picture – which JS then renders – is the bulk of the use-case.
Arguably you could implement zooming so that you can check the picture in more detail. Another thing we have yet to try is checking the rendered image for EXIF metadata.
5) You mention IndexDB as an alternative to store local data as that could be dangerous to the file system. The main benefit of localStorage() is that the API is dead easy though. Is there a chance to have a wrapper to use the localStorage() API but store in the DB?
The problem is that localstorage() is sync – which makes it easy to use but, as you can imagine, introduces tremendous performance issues. As our Indexeddb is an async API – you can’t wrap a sync api around an async one.
6) Good vibrations. The vibrator API allows you to vibrate the device. I can see that working really well for games and notifications. Or with the orientation API telling you when you tilt too far. Is there a way to detect if the vibration is turned on or off? I know quite a few people that turned off device vibration.
I can’t wait to see where my name shows up in search results thanks to this one. There is no API for detecting this – it’s been theorized that you can deduce its presence using the orientation API – i.e. it would see the vibrations. But this would vary from device to device; as not all devices have vibrator.
7) Sending SMS with JavaScript is the last API you mention. This is working as far as I understand it. What is the most requested use case there? Is there a throttling mechanism to stop people from sending SMS spam or mass mailings?
Aside from the about:config setting dom.sms.enabled, there is no specific throttling mechanism. It is to be a “trusted” API, that is, we won’t expose it to all pages. As with many of these APIs there are inherent security threats – in the case of this one, you can for example, end up sending text messages to paid-for services.
8) This is all pretty cool. What do you want from people now and where can they go to get all that to play with?
Check out my blogpost and try out the testpages themselves on my people share! I’d recommend using latest XUL nightlies – for SMS, you need a phone with a sim card and a special build which is linked in the blogpost. Play around! Note that these are presently atomic APIs, each representing a single function. Make suggestions via bugzilla -and write bugs! And it goes without saying also to try to combine these (and the others as they land) into working apps of your own. Our challenge will not only be to find out how these APIs work on their own but also in combination with another. I would say that IndexDB at this stage represents a particular challenge, due to its size and complexity.
Report bugs with any of the demos and/or APIs themselves (make sure to include your device model and Android version, as well as the nightly fennec version you are using, in the bug.).
Thanks to everyone that participated in the September Dev Derby and congratulations to the winners! A special shout out to Jaume for taking 1st place after submitting amazing demos for the past three Dev Derbies. Check out spite’s MDN profile to see what he’s done in the past.
NOTE: We recently updated our Dev Derby rules to allow developers to participate in multiple contests until they win 1st place. That means if you’ve submitted awesome demos and come up short in the past, you still have a chance to win that top spot in future Dev Derbies… so keep those demos coming!
Or get ready for the joy of painting in the November Dev Derby with Canvas. We’re looking forward to seeing some creative demos next month. So hack on!
As we’ve hoped, there has been a lot of interest in the newly announced WebAPI effort. So I figured that I should explain in more detail some of my thinking around what we’re hoping to do and the challenges that are ahead of us.
Goal
The goal of this effort is to create APIs to expand what the Web can do. We don’t want people to end up choosing to develop for a proprietary platform just because the Web is lacking some capability.
The main effort, at least initially, is to enable access to hardware connected to the device, and data which is stored or available to the device. As for hardware, we want to make the full range of hardware that people use available to the web platform. From common hardware like cameras, to more rarely used (but no less awesome) hardware like USB-driven Nerf cannons. We also want to enable communication hardware like Bluetooth and NFC.
For data stored on the device, the most commonly discussed data today is contacts and calendar. This includes the ability to both read and write data. That is, we both want the Web platform to be able to enumerate contacts stored on the device, and read their details, as well as add and remove contacts. In short, we want it to be possible to create a Web page or Web app which lets the user manage his contact list. Same thing for calendar events and other types of data stored on devices.
Security and Privacy
One big reason these types of APIs haven’t been developed for the Web platform yet is because of their security and privacy implications. I would obviously not want every single Web page out there to be able to mess around with my contact list or my calendar. And being able to issue any commands to any USB device that I happen to have plugged in would likely result in everyone’s computer immediately being zombified.
So as we are developing these APIs, we always have to develop a security model to go along with them. In some cases simply asking the user, which is how we currently do Geolocation, might work. In others, where security implications are scarier or where describing the risk to the user is harder, we’ll have to come up with better solutions.
I really want to emphasize that we don’t yet know what the security story is going to be, but that we’re absolutely planning on having a solid security solution before we ship an API to millions of users.
Mozilla has always had a strong commitment to Web standards. This is of course not something we’re changing! All of the APIs that we are developing will be developed with the goal of being standardized and implemented across both browsers and devices.
But it’s important to ensure that standards are good standards. This takes experimenting. Especially in areas which are as new to the Web, and as security sensitive, as these are.
Standards organizations aren’t a good place to do research. This is why we want to experiment and do research outside the standards organizations first. But always in the open, and always listening to feedback. We’re also going to clearly prefix any APIs as to indicate that they are experiments and might change once they get standardized.
Once we have a better understanding of what we think makes a good API we will create a proposal and bring to working groups like the Device API group at W3C, WAC and WHATWG.
Throughout this process we will of course be in contact with other interested parties, such as other browser vendors and web developers. This is part of the normal research and making sure that an API is a good API.
Mozilla always has and always will be a good steward of the open Web. We are not interested in creating a Mozilla-specific Web platform. We are interested in moving the open Web platform forward.
High Level vs. Low Level
One thing that often comes up with API design is whether we should do high level or low level APIs. For example, do we provide a low-level USB API, or a high-level API for cameras?
There are pros and cons with both. High level means that we can create more developer-friendly APIs. We can also provide a better security model since we can ensure that the page won’t issue any unexpected USB commands, and we can ensure that no privacy-sensitive access is made without user approval. But high level also means that developers can’t access a type of device until we’ve added support for it. So until we’ve added an API for Nerf cannons, there will be no way to talk to them.
Exposing a low-level USB API on the other hand, means that web pages can talk to any USB device in existence, with no need for us to add an explicit API for them. However it also requires developers to get their hands dirty with the details of the USB protocol and differences between devices.
The approach we’re planning on taking is to do both high-level and low-level APIs, as well as give people the proper incentives to use the one that is best for the user. But a very important point is to provide low-level APIs early to ensure that Mozilla isn’t on the critical path for innovation. Over time, we can add high-level APIs where that makes sense.
How you can join
As with all things Mozilla, we’re planning on doing all our work in the open. In fact, we’ll be relying on your help to make this successful! As to keep discussions focused, we’re going to use the a new mozilla.dev.webapi discussion forum for all communication. This means that you can participate through email, newsgroups, or the web-based google group UI.
Today we are featuring 
