It has been a busy week for Mozilla. We have seen news across the board of their technology.
First we have the news that Firefox 3 should be available to download on June 17th. They are having a download party to kick things off.
Stuart Parmenter had a proxy post that delves into the world of fonts and text:
When Mozilla developers decided to incorporate the Cairo subsystem and build a new graphics layer from scratch, they also decided to completely rework the system that renders text in the browser.
Text is an incredibly important part of the Web. While graphics, audio, and video are increasingly common, we still spend the majority of our time on the Web just reading stuff. All the words you read in a web browser are rendered using a font which contains a set of glyphs used to form individual letters. For more simple written languages there may be a straightforward one-to-one mapping of characters to glyphs, but for more complex languages, one glyph may represent multiple characters.
Ben is a huge fan (a.k.a. anal) of this type of thing. Fonts and rendering can make a big difference, and the post goes into detail on what is going on in the new Firefox 3 engine. It discusses kerning, ligatures, hinting, font smoothing, anti-aliasing, and more. After reading this post you may want to watch Helvetica the movie!
Then we go to the mobile side, where Aza Raskin has posted concept video on the new touch screen interface that they will be building for Fennec. There is a ton of detail in Aza’s writeup including design principles:
Touch. This concept prototype for Firefox mobile (code name Fennec) is being designed for a touch screen. Why not multitouch? Because Firefox should be able to run on the least common denominator of touch devices. Especially for touch-enabled interfaces direct manipulation is key. Along that line of thought, the interface should be operable with a finger. Switching between input methods is time-consuming and annoying, so the user shouldn’t have to switch to a stylus or other secondary form of input. Firefox will work on non-touchscreen devices, but that’s out of scope for this demo.
Large targets are good. The same fingertip that controls the interface takes up between 1/5th to 1/10th of the vertical/horizontal height/width of the mobile touch-screen. In other words, fingers are fat: hitting small targets is like trying to touch-type with your elbow. All actions should be represented by targets that are large enough to be fast, easy, and (at the very least) not aggravating to hit.
Visual Momentum and Physics are compelling. Nothing shouts “sexy!†like pretty animations and a physics engine. Beyond marketing appeal, there is a strong argument that such physicality helps the user build a mental model of the interface, and that interface physics yields consistency. We are wired to track the movement of things and to be able to remember where they’ve gone, as long as they don’t appear and disappear, which doesn’t happen in the real world. Of course, copying every physical metaphors blindly gets you interfaces like the multi-million dollar blunder that was Microsoft Bob, so we need to select our metaphors carefully.
Typing is difficult. This means we want to minimize the amount of keystrokes required to get anywhere or do anything.
Content is king. With restricted screen size, every pixel counts. As much of the screen as possible should always be dedicated to content, not controls or cruft.
Then we move to the server side with a Weave status update that should be shipping with Firefox 3. It includes new features around data types, bookmark sharing, and a Web client view. Check out the Wiki for more details.
It gets going by trying to show you the magnitude of mobile (3.3 billion in perspective), tells us that mobile has cried wolf for 15 years, but the time has come.
Finally, they go into detail on the results from the CloudFour mobile browser test that we posted on awhile back. Well worth a quick flip through the deck.
Jason Grigsby of Cloud Four has created a research project that needs our help.
He has created a mobile browser concurrency test to “query the number of concurrent connections your phone makes. Your phone’s browser will need to display images for the test to work.
We’ve also set up a SMS keyword to make it easier to get to the test url. You can simply text MOBILETEST to 41411 on your phone, and you will receive back instructions on how to test your phone.
With mobile devices, the speed of web pages is even more important given bandwidth, processor and memory constraints. Yet, for those trying to take advantage of the techniques promoted by Yahoo’s Best Practices for Speeding Up Your Web Site, it is nearly impossible to find how mobile browsers differ from desktop browsers.
When the results are in, they will be published under creative commons so we can all learn from then. It is interesting to see how the test itself works:
How Does the Test Work?
Designing the concurrency test was a difficult challenge. In order to have the test work for as many mobile browsers as possible, we needed to support XHTML-MP 1.0 (WAP 2.0). XHTML-MP does not support javascript which meant that all of the testing needed to occur on the server.
The basic test works by delivering a XHTML-MP page containing 64 images distributed equally across 4 domains. When the first image is requested by the browser, the server opens a connection and holds it open without delivering the image. It waits 15 seconds to see if any other image requests come in. As each image request comes in, the counter for the appropriate domain is incremented.
If this works well, maybe we can move to other browser factors. With the huge number of devices, operating systems, and mobile browsers, it will be interesting to get data on the diversity.
That test, in the same spirit as the ACID tests, combines in a single page tests for 12 Web technologies, ranging from well-deployed (but often poorly implemented on mobile devices) technologies such as HTTPS and PNG, to technologies we believe will matter in a year or two (like SVG animation and CSS Media Queries).
Tests are visualized by squares, sorted roughly in order of difficulty (first line, well-deployed technologies, second line, technologies increasingly used today, third line, technologies for tomorrow), and a browser needs to render each square in the same tone of green to pass completely the test - which as far as I know, no currently released browser (on mobile devices or elsewhere) does.
The test covers:
1. CSS2 min-width
Fluid page widths, defined in percent of the screen width, often depend on the min-width and max-width properties to avoid turning unreadable on small screens. The former property is tested here.
2. Transparent PNG
PNG, a bitmap image format, supports transparency and alpha channels, that are useful in building appealing visual effects
3. GZIP support
The HTTP protocol allows data to be sent gzip-compressed when the client advertizes its capability to uncompress them (through the Accept-Encoding header), thus saving bandwith.
4. HTTPS
The HTTPS protocol is used to establish secure and encrypted connections on the Web.
5. iframe inclusing of XHTML-served-as-XML content
Tests if the UA supports XML content-types by loading an XHTML document with the content-type application/xhtml+xml.
6. Static SVG
SVG allows authors to define vector-based graphics, that can be scaled up and down, fitting well the needs of mobile devices
7. XMLHTTPRequest
XMLHTTPRequest is at the core of AJAX, allowing to update a subset of an HTML page without requesting a new full content transfer
8. CSS Media Queries
CSS Media Queries allow authors to contrain CSS rules apply in specific context, for instance so that they only apply to screens of a given maximum width. The min-width feature is tested here.
9. Dynamic SVG
SVG also supports animations, that can be used to create very appealing interfaces
10. The canvas element
The canvas element defined in HTML5 offers a Javascript graphics API
11. contenteditable
The contenteditable attribute makes rich text editing of any element possible. Support for this attribute is tested.
12. CSS3 selectors
CSS3 introduces a number of new selectors, allowing more fine-grained styling, leading to better layouts. The nth-child() selector is tested here.
Jon Brisbin is a Java programmer doing iPhone development, and decided to scratch his own itch for a better iPhone remote debugger, creating iPhoneDebug:
The iPhone Debug Consle is meant to give greater visibility and interactivity on your iPhone/iPod Touch while doing development. I grew frustrated having to go through the “include console.log statement then reload” method of debugging. I wanted something similar to Firebug’s fantastic console and debugger.
I grew frustrated with trying to debug my iPhone/iPod Touch apps because I had no interactivity with the page. I couldn’t interrogate variable values or CSS values unless I put in a console.log statement and reloaded the page. This is far from ideal.
In trying to find something that would fit my needs, I came across Joe Hewitt’s iPhone/Firebug integration, but I wanted something more robust and that worked without firebug and requiring “console.log” in the desktop browser.
I’m a Java programmer, so naturally I thought of using COMET and Jetty to pass messages between a desktop browser and the iPhone. A couple days later, I had a workable solution. It lets you log things in your mobile JavaScript to a desktop console, but the biggest plus for my situation is that I can send JavaScript to the iPhone to be executed there, with the results logged back to my desktop console. Just like in Firebug, I can call methods, retrieve CSS values, and all manner of debugging activities I’ve grown used to doing while building apps with Firebug. There is also rudimentary UP and DOWN arrow command retrieval on the prompt.
Here it is in action, getting commands from the console:
IE may be the dominant browser on the desktop, but the mobile wars are going strong. WebKit, Opera, and Pocket IE have a lot of users, but Mozilla has been a little weak in the past.
Now though, they have a new Fennec browser that takes the great performance gains in Firefox 3, and makes a mobile oriented version.
Sullivan explained that the Fennec project aims to bring the desktop Firefox user experience to handheld devices but will focus on meeting the unique requirements of mobile computing users. “Our goal on mobile is to embody the principles that have made Firefox so successful on the desktop, but with the recognition that mobile is different—not so much in that it presents some constraints, but in that it enables new types of experiences, and people’s interaction with these devices are different than when they’re sitting at their desks,” he says. “Web compatibility, security, performance, support for rich internet apps will all be key.”
I have been curious how it can scale down, just due to the XUL overhead, but it works great.
Much of the Firefox user interface is constructed with XUL, an XML-based user interface description language. This makes Firefox very easy to customize and extend. Mozilla hopes to leverage this advantage to encourage experimentation with new mobile user interface concepts. Developers can augment or reinvent the Fennec user interface by modifying the browser.xul file in the Fennec chrome directory and the associated browser.css file. Additional functionality can be implemented in JavaScript by modifying the browser.js file. Fennec will eventually support a complete extension system like Firefox 3 that developers will be able to use for modifying the browser’s behavior and user interface.
“Another exciting thing is that we’re providing full support for add-ons,” Sullivan notes. “These will fall into three buckets: most add-ons will just work out of the box; some won’t make much sense away from a PC; and a whole new class will be created that are going to be new for mobile.”
There are other aspects of the Mozilla Mobile initiative that will appeal to developers as well. Mobile software development is hard, and Mozilla could potentially offer a novel approach to simplifying the process. The underlying XUL technology on which the Firefox interface is built can be used independently with a XULRunner runtime to create platform-neutral mobile applications with XML and JavaScript.
Apple is secretive. I normally don’t mind so much, as they always come through on yet another cool Mac product. If I could know one thing though, it wouldn’t be when the next Macbook Pro is coming out, or when we will see the 3G iPhone. Instead, I wish I knew the attentions in the battle of “what can we develop with on the iPhone”.
We started out with only being able to use JavaScript, and folks like Joe Hewitt quickly mastered the restrictive tools such as meta viewport and co.
Then we got the final word of the iPhone SDK, and the Cocoa developers rejoiced as they went from being the cool kids to the “now you will pay me to help in the land grab yO”.
Now we got a glimpse of new updates for the iPhone Ajaxians:
Safari 3.1 showed us CSS transforms, which are 2D. On the iPhone though, we can now do 3D transforms which means you can do true coverflow through the browser.
The optimist in me thinks: Wow, WebKit is going to be a first class citizen and Apple will continue to open up more and more of the innards as JavaScript APIs.
The cynic in me thinks: Yeah, they will support it, kinda like how Java is supported on the Mac. One poor bugger has to do all of the work and make people care. In this case, when Apple starts making 30% on all of the native applications, what will their incentive be to help people develop apps using the Web?
The hope is that they realize that the Web is the long term winner, and that they want to win in that market too. Please, Mr. Jobs.
We have a couple of browser updates. First, we have Firefox 3 beta 5 which has improved integration with the host system, a better places organizer, and a bump:
Speed improvements to our JavaScript engine as well as profile guided optimizations have resulted in continued improvements in performance. Compared to Firefox 2, web applications like Google Mail and Zoho Office run twice as fast in Firefox 3 Beta 5, and the popular SunSpider test from Apple shows improvements over previous releases.
Opera also released a new browser with their Opera Mini 4.1 beta. The improvements talk about “faster” a lot: performance, finding things faster, and URL completion magic. This latest mobile browser also supports JSR-75:
JSR-75 is a specification for Java applications such as Opera Mini to access device internal storage and functionality within the phone. Some of Opera Mini features like “Save Pages” and “Download/Upload Files” vary on how much JSR-75 that is supported by the phone.
As an iPhone user I am quite happy. I look forward to email / contact / calendar push. I think that the tool chain looked fantastic (debugger, simulator, IDE, GUI-builder) and I am sure that I will be seeing fantastic new applications when June comes around (waiting for June again?????). Skype. IM. You name it (as long as Apple approves!)
There are some that don’t like the 30% tax, and Russell Beattie has some thoughts too:
I was right about the sandbox, though there’s a bit more access to hardware than I thought, there’s no VoIP over cellular or ability to interact with the Dock, no ability to change the UI. So though it’s not a technical sandbox, it’s an arbitrary Apple approved one instead.
Also right about the Orwellian doublespeak: Jobs called only being able to distribute your apps via the iTunes store “the best deal going to distribute applications in the mobile space.” Uh-huh. Who wants to be able to put downloadable install files on their own websites? Exchanging the carrier-only distribution model for an Apple-only one doesn’t do much for me. I mean, imagine if you could only install applications on your computer via Apple or Microsoft… it’s the same thing, no matter how “convenient” it may sound.
Overall though, I am happy. I would love to see how many people pick up Objective-C and Cocoa now. We should keep an eye on the book sales. James Duncan Davidson will be happy :)
But what about Mobile Safari? What about some Cocoa JS love? Apple started out showing off the Web applications for the iPhone, so how about enabling more in that development stream? Some may enjoy learning something new, but others want to just stay in the growing Ajax universe. With the ability to hide the browser chrome, access to Touch APIs, and a few others…. and we can do a lot.
During the event, the VP of Phone Software told us that the next update will include new features for the web apps, so we will see (Thanks to Arn of MacRumors for letting me know).
At this point though maybe Steve wants to shut down that world a little? This is his chance to get a ton of developers on the full OSX platform. Once they learn Cocoa and the tool chain, some percentage of the developers will go on to build desktop applications too!
Interesting times. What do you think? Getting ready to use those square brackets?
I have seen the huge batches of cell phones that companies keep around to test their applications on. Companies like UI Evolution have come along to try to help out the madness of getting something that works across more than a couple of them.
Not only do you have the problems of handsets, but you also have the network lock-downs and the hoops you have to go through to get an application onto a large set of devices.
Since the iPhone, I have strongly believed that history is going to repeat itself, and the Web is going to win on the mobile.
Today we’re announcing the launch of Google Gears for mobile, a mobile browser extension for creating rich web applications for mobile devices. The first version is now available for Internet Explorer Mobile on Windows Mobile 5 and 6. It’s a fully functional port of Google Gears v0.2 that can be used to develop offline capability into your mobile web applications. You can also create slick and responsive applications by hiding latency issues through controlled caching of data and storage of information between sessions. We’re also working to bring Google Gears for mobile to Android and other mobile platforms with capable web browsers.
There are already a handful of Windows Mobile web apps that use Google Gears for mobile, such as the social payment service Buxfer and online applications provider Zoho. Read more about these applications and how they use Google Gears for mobile on the Google mobile blog.
I got to fly back home to London to talk to members of the mobile team. Below is an interview with a couple of the engineers, and there is also a high level look at the news:
I am really excited about what this means for the future of mobile development. I want to be able to develop applications using Ajax on the phone, and see tools like Gears give me access to native APIs on those devices. I really hope that the iPhone SDK also offers more on the JavaScript API side too (as well as Cocoa). How nice would it be to take your iPhone app and finally get some onPinch goodness, and camera.takePhoto.
Michael Mace, a former Palm VP, says the business of native mobile apps is dying. He includes a quote from Palm veteran Elia Freedman summarizing why some of us have found mobile application development to be a deeply frustrating experience.
From the technical perspective, there are a couple of big issues. One is the proliferation of operating systems. Back in the late 1990s there were two platforms we had to worry about, Pocket PC and Palm OS. Symbian was there too, but it was in Europe and few people here were paying attention. Now there are at least ten platforms. Microsoft alone has several — two versions of Windows Mobile, Tablet PC, and so on. [Elia didn't mention it, but the fragmentation of Java makes this situation even worse.]
I call it three million platforms with a hundred users each (link).
The second technical issue is certification. The walls are being formed around devices in ways they never were before. Now I have to certify with both the OS and with each carrier, and it costs me thousands of dollars. So my costs are through the roof. On top of that, the adoption rate of mobile applications has gone down. So I have to pay more to sell less.
Then there’s marketing. Here too there are two issues. The first is vertical marketing. Few mobile devices align with verticals, which makes it hard for a vertical application developer like us to partner with any particular device. For example, Palm even at its height had no more than 20% of real estate agents. To cover our development costs on 20% of target customer base, I had to charge more than the customers could pay. So I was forced to make my application work on more platforms, which pushed me back into the million platforms problem.
The other marketing problem is the disappearance of horizontal distribution. You used to have some resellers and free software sites on the web that promoted mobile shareware and commercial products at low or no charge. You could also work through the hardware vendors to get to customers. We were masters of this; at one point we were bundled on 85% of mobile computing devices. We had retail distribution too.
Where’s he going with this? You can guess where he’s going.
Meanwhile, there is now an alternative platform for mobile developers. It’s horribly flawed technically, not at all optimized for mobile usage, and in fact was designed for a completely different form of computing. It would be hard to create a computing architecture more inappropriate for use over a cellular data network. But it has a business model that sweeps away all of the barriers in the mobile market. Mobile developers are starting to switch to it, a trickle that is soon going to grow. And this time I think the flash flood will last.
…
I think Web applications are going to destroy most native app development for mobiles. Not because the Web is a better technology for mobile, but because it has a better business model.
Think about it: If you’re creating a website, you don’t have to get permission from a carrier. You don’t have to get anything certified by anyone. You don’t have to beg for placement on the deck, and you don’t have to pay half your revenue to a reseller. In fact, the operator, handset vendor, and OS vendor probably won’t even be aware that you exist. It’ll just be you and the user, communicating directly.
Until recently, a couple of barriers prevented this from working. The first was the absence of flat-rate data plans. They have been around for a while in the US, but in Europe they are only now appearing. Before flat-rate, users were very fearful of exploring the mobile web because they risked ending up with a thousand-Euro mobile bill. That fear is now receding. The second barrier was the extremely bad quality of mobile browsers. Many of them still stink, but the high quality of Apple’s iPhone browser, coupled with Nokia’s licensing of WebKit, points to a future in which most mobile browsers will be reasonably feature-complete. The market will force this — mobile companies how have to ship a full browser in order to keep up with Apple, and operators have to give full access to it.
As Michael points out, it’s not all gloom and doom for mobile apps, especially with the official iPhone SDK due out real soon now. For basic business apps, though, maybe we’ve already reached the tipping point.
This thesis evaluates the presentational capability and measures the performance of five mobile browsers on the Apple iPhone and Nokia models N95 and N800. Performance is benchmarked through user-experienced response times as measured with a stopwatch. 12 Ajax toolkit examples and 8 production-quality applications are targeted, all except one in their real environments. In total, over 1750 observations are analyzed and included in the appendix. Communication delays are not considered; the network connection type is WLAN.
Results indicate that the initial loading time of an Ajax application can often exceed 20 seconds. Content reordering may be used to partially overcome this limitation. Proper testing is the key for success: the selected browsers are capable of presenting Ajax applications if their differing implementations are overcome, perhaps using a suitable toolkit.
There is a large amount of detailed information here across several vectors.
Mobile device / platform differences
Mikko has gone into detailed testing on the Nokia 800, N95, and the iPhone. Within the N800 he tests Opera, Mozilla, and WebCore. On the N95 he tests Opera Mobile and the mini map interface.
Ajax libraries and their support
Here Mikko compared a large number of libraries:
Prototype
Script.aculo.us
jQuery
Yahoo! UI
Dojo
Ext JS
Gears
DWR
MooTools
moo.fx
ASP.NET Ajax
Frost Ajax library
Comparing large websites on mobile phones
Here Mikko runs up against properties such as:
Gmail
Google Maps
Yahoo! Mail
Flickr
myAOL
You can look through the study to see the details, but what about conclusions?
One can not yet assume that applications sup-
ported by the desktop browsers would be consequently supported by the mobile
browsers. Browser fragmentation seems to flow over to the mobile devices
with the shared code bases of the mobile and desktop user agents.
If we take a look at the grouping of grades for the various tests, you see that the browsers in question are across the map. All of them have issues, across the board.
Mikko does have this to say about the browsers:
By far, the fastest browser is Opera Mobile on the N95. This seems to be well in line with the overall worst capability in the capability evaluations. This combination seems to be indicative of ignored program directives, meaning that the browser gains speed by not executing some parts of the application code. Safari’s high number (14) of slow results is caused by the browser’s distinctive performance variation, specifically of pairwise high and low values. This phenomena has not yet been satisfactorily explained.
The two things that strike me are:
Mobile browsers are very different, and I hope they get closer (feels like a few years back with desktop browsers)
There is room for a mobile specific toolkit (or a mobile piece of a current toolkit) to help out like they did in desktop land. Frost is an early library here.
As you go through the thesis you will see a great set of graphs that show you the performance characteristics of micro elements of the Ajax experience on the phone. Thanks for the work Mikko!
I always wonder why the cache is so small. It is typical Apple to not allow an expert mode where you can tweak it. I would rather have a few less songs and have a large cache. But, Steve knows best ;)
The end result of the article is that you should follow this ideal rule:
Reduce the size of each component to 25 Kbytes or less for optimal caching behavior
Given that the wireless network speed on iPhone is limited and the browser cache is cleared across power cycle, it is even more important to make fewer HTTP requests to achieve good performance than in the desktop world. To reduce the number of HTTP requests, Safari on iPhone supports image map, CSS sprites, inline images and inline CSS images. Take advantage of the browser cache whenever possible. If an external component can be shared across multiple pages in the site, remember that each individual component has to be smaller than 25 KB to be cacheable. Also, the maximum cache limit of all components is 475 - 500 KB. Minify all the JavaScript, CSS and HTML. For components that aren’t shared across multiple pages, consider making them inline.
This of course is quite painful if you like to package JavaScript in One Large File for other performance reasons, or if you use a library that is larger than 25KB!
The iPhone can tell us a bunch of things about a site. If I go to TechCrunch for example, it drives me batty as it does a bunch of JavaScript to load in the CrunchBase widgets, and the iPhone keeps thinking it is loading. The blue bar keeps going, and the browser isn’t as responsive. I hate those Crunchbase widgets :)
WebKit keeps chugging away. I hear more and more developers talking about how they use Firefox for Firebug debugging, and WebKit nightly for browsing as it is so fast. In mobile, WebKit had another win as you get it with Android.
If you take a look at this video, 3:00 minutes in, you will see WebKit on Android. It looks similar to the iPhone implementation, with the touch screen interface and all. There is also hardware zooming on that particular phone (Android isn’t about one phone, it is an open mobile platform).
When you think of a mobile browser, you may first think about Opera and WebKit, but Mozilla wants to change this. We have already seen the seeds of change as Mike points out:
You can already get a Mozilla-based browser for the Nokia N800 and Firefox is a key part of Ubuntu Mobile and the new Intel Internet Project, and most recently ARM has put serious effort towards Firefox on mobile devices.
Mike announced:
Mozilla will add mobile devices to the first class/tier-1 platform set for Mozilla2. This means we will make core platform decisions with mobile devices as first-class citizens.
We will ship a version of “Mobile Firefox” which can, among other things, run Firefox extensions on mobile devices and allow others to build rich applications via XUL.
Mozilla will expand its small team of full-time mobile contributors to focus on the technology and application needs of mobile devices. In particular two new folks just joined:
Christian Sejersen, recently the head of browsers at Openwave which has shipped over 1 billion mobile browsers, joined Mozilla Monday. He’ll be heading up the platform engineering effort and setting up a R&D center in Copenhagen, Denmark.
Brad Lassey just joined Mozilla from France Telecom R&D. He’s already been an active contributor to our mobile efforts and can now focus on Mozilla mobile full time.
It seems like more and more people are looking at the number of phones out there versus computers and want to jump in.
, Firefox
