Mozilla's longest-serving and top two leaders, Mitchell Baker and Brendan Eich, have some great information on where the project is going. You should absolutely follow these links:
Brendan Eich -- We (Mozilla) Fight For the User
Mitchell Baker -- Mozilla in the New Internet Era -- More Than the Browser
I'm collecting information on what people expect from and are concerned about with a 64-bit Firefox build for Win64 users. So far I've heard "improved performance" and "better security" in the pro column and "download confusion", "plug-in availability", and "memory footprint" in the con column.
Obviously improved performance and security would be great to have. And I'll bet that the download confusion, plug-in issues, and memory footprint are all solvable issues. So, am I missing anything here? Are there other benefits or drawbacks that I haven't got?
Also, if you know Firefox well enough to point out specific work that needs to happen to make 64-bit builds a supportable reality, please let me know as well. I think doing 32-bit plug-in hosting like we do on Mac might be in that list. Maybe a stub installer that can pick the right download belongs in that list. Perhaps we also need changes to our release engineering infrastructure. Are there any concerns across different Windows versions (XP 64-bit vs 7 64-bit, for example?) Anything else?
All and any help appreciated. Figuring this out is near the top of my to-do list for Firefox this summer and fall. Thanks.
Commenter Sid Roberts said in a previous post (and completely unrelated one,) "There's a reason people love native apps. I just don't think Mozilla really understands why."
I have some ideas why, but I'm OK saying that I don't claim to fully understand why. So, I'm asking Sid, and anyone else that's interested, if "there's a reason" then what is that reason.
My personal opinion is that it's more than one reason, but I'll defer to Sid, who seems quite sure of himself, that it really can be distilled down to one singular reason people love native apps.
If I absolutely had to coalesce the various special qualities of native apps (mobile, I'm talking about here) -- tossing out a few that don't fit this one theme, I think I'd say what makes people love them is that they are overwhelmingly single purpose products.
In this day and age where nearly every piece of traditional software seems to want to do everything any user could possibly want, a break from the one-size fits all app, and a chance to use something that has been designed to do one thing really well is simply a very welcome piece of Zen.
I don't know that I'm right about that being the best single reason, and I kind of want to dispute Sid on the assertion that it is just a single reason, but I think it's an interesting exercise to try to get at the most meaningful and useful aspect of a particular product or product category and so I'm very much interested in what you would say, constrained to just one thing, is the reason people love their iPhone or Android apps.
Sid, feel free to go first.
One of the big challenges in developing a great Web browser is figuring out where the browser's performance gets in the way of people using the browser. As Nicholas Nethercote notes, you lose more when you're slow than you gain when fast. That means that a top priority for Mozilla is to not just work on increasing overall performance, but to really hone in on the areas where we're slow and make sure we speed them up.
Unfortunately, the traditional tools for measuring performance, various industry standard benchmarks like SunSpider or our own "ts" start-up time tests, don't really do a very good job of measuring when we're slow. We can make lots of improvements to our already quite fast JavaScript engine and we can tune for our startup tests but those don't necessarily translate into real-world and user-perceived performance gains because they're not necessarily getting at those places where performance is bad enough to interrupt the user's flow.
What we really need to measure in order to tackle our slowest code is real-world usage and that requires an entirely different way of thinking about performance and a new set of measurement technologies from what we've grown accustomed to over the last decade or so. It's no longer good enough to optimize for the various performance tests and benchmarks available to us; we must optimize for the performance issues our users are experiencing in the real world. This is where browser telemetry comes in.
Telemetry in Firefox is a new technology that allows our developers to build performance tests right into Firefox itself and to have those tests running while users are interacting with Firefox and the Web. These little tests, also called probes, should go completely unnoticed when you're using Firefox but they make note of the time it takes to accomplish certain tasks like establishing a network connection or freeing system memory. If people opt in to sending this anonymous data to Mozilla, like tens of millions do with crash reports already, then our developers can isolate places where Firefox is slow or uses too much memory and can start to remedy them.
Telemetry makes its debut in the Aurora channel this week and we're encouraging all of our Aurora people to send the anonymous performance and resources data to Mozilla so that we can work on the problems out on the real Web rather than just the things that synthetic tests can identify.
You can read more about the development of Mozilla's telemetry infrastructure in this series of blog posts by telemetry, startup performance, and static analysis tools engineer, Taras Glek:
Firefox Telemetry
Telemetry Updates
Developers: How To Submit Telemetry Data
Telemetry is on in Nightly Firefox builds
Telemetry Status
This is just one of several new efforts at Mozilla to address performance and memory usage issues. Starting with the Aurora update, users will really begin experiencing the many Firefox performance improvements that result from telemetry data and other initiatives designed to make sure Firefox is the fastest, leanest, and most powerful browser in the world.
First, thank you to all of you who shared kind thoughts and wishes for our sick kitty, Ptolemy.
You can read the beginning of the saga here if you missed it.
After being diagnosed as diabetic and coming home from the vet, we started Ptolemy on insulin. It turns out that the initial prescription was a bit too much -- at least considering how much and how frequently she was eating, and she had a pretty bad crash as a result so we had to take her back to the vet for a few days of stabilization.
We backed off the insulin some and she seemed to be slowly getting better. After a couple of weeks we did a day of pricking her ear and testing her blood. A full day of levels showing she was pretty high convinced the vet to increase her dose some and I think we're on the right track finally.
She's eating like a horse. She's getting some strength back -- enough to hop up on the table and to sprint for the door when ever it's open. We'll do some more glucose testing in a few days and hopefully it will tell us we've got her at a good level.
Thanks again, for all the good wishes. Ptolemy's returning to health and we are certainly all happy about that.
I filed a fair number of bugs on Thunderbird last weekend calling out some of the bits of interface that were causing me aesthetic stress. I was on a loaner laptop without photoshop and my other tools. So while I could point out the ugly bits, I wasn't able suggest how specifically those bits needed to change.
Here's another quick photoshop hack-job to try to remedy that. This is the primary Thunderbird window with the alternative "vertical view" -- my primary view, and the view that I think ought to be the default given how many widescreen laptops and desktops there are these days.
The first image is what Thunderbird looks like for me with no customizations except for switching from the standard view to the vertical view. The image below that is my mock up of what I think would make a much more pleasing interface.
My primary goals in this redesign were 1) to clean up the visual clutter and disorganization. 2) to increase the relative size of the message viewing area.
This isn't an entirely new theme -- the iconography and the buttons and other widgets (with two exception) are all the same. It's just a bunch of visual alignment cleanup and hiding away a few rarely used bits to try to free up more space for reading email.
You can click on the image to get the full-sized view. Maybe open it in another tab and continue reading here :-)
I've intentionally sized the window a bit smaller than my smallest laptop resolution so that it would be easier to view the images and to show that this view can scale all the way down to screens with 1024 x 768 resolution. A larger window looks even better, IMO.
What I would change (in no particular oder):
1. Drop Aero Glass on the toolbars. It doesn't add any value and actually makes it harder to read and mouse target what ever is on those Glass toolbars. Aero Glass is nice, and it's got its place. I think Firefox's use of glass behind the tabs is actually OK. But it doesn't work everywhere and shouldn't be used just "because we can".
2. Hide the menubar and hide the statusbar. This is where Windows is going. Users know or will learn that Alt pops the menubar back into view. If a user absolutely cannot deal with it being hidden, then provide an option to show it by default just like other Windows apps. The statusbar should become transient like Firefox's statusbar.
3. Get all of the various toolbars and rows of text aligned and using the same colors and fonts. There's just no good excuse for having toolbars stacked at different heights and text or labels that don't line up and random colors that don't actually signal anything to the user.
4. Move rarely used features out of the primary UI. Users don't need toggles for every UI option in primary UI. Showing and hiding the "Filter" bar is not something users need to change every few minutes. Most users don't need to download attachments many times a day. The online/offline toggle isn't something that deserves an entire toolbar. These things can live in less conspicuous places.
5. Remove redundancy. Two search fields, even if one is technically "search" and one is technically "filter" make for confusing UI. Users don't need to see the time and date of the message in the Thread pane and in the Message pane. The unread message count is available in the Server/Folder pane. It doesn't need to also live in a toolbar.
6. Avoid strange and exotic widgets. The scroller thing for the Server/Folder pane is un-obvious and optimizes speed (single click) at the expense of clarity (which view is next in the scroll order??)
7. Maximize the viewing area for common views so users have to scroll less. The Message pane should not be mostly UI. It should be mostly message. The message headers should be scroll out of view to put more message in front of the user. The key pieces of information here, the Subject and the From fields are easily glanced over in the Thread pane if needed.
8. Primary toolbar buttons don't actually need to take up an inch of vertical real estate. Move those to the titlebar like modern Windows apps and kill the big toolbar.
With these changes, Thunderbird not only looks great, but we go from having only 25% of the app's window devoted to the email message you're reading, to almost 45%. I think that's a pretty big win.
I believe I've filed or there are already on file bugs for pretty much everything covered here.
I'm not claiming that this is the ultimate UI for Thunderbird, but I think this would be a dramatic improvement from the current look without an entire re-write or a new set of artwork. I'd be thrilled to return to a Thunderbird that was as well ordered as this mock up.
What do you all think? Have I missed any major issues? Have I hidden your "I can't live without it" features? Would you use a Thunderbird that looked like this?
update: I want to make it clear that I'm not shooting for a "compact" or "minimal" UI here. I'm trying to help the user focus on the things that matter most while making the whole thing more visually appealing. By removing and re-ordering things, Thunderbird can show more of what matters (email!) and less of what doesn't. And remember that the mock-up is at 1024 x 768 so it looks much more spacious and inviting when the window is sized larger for all of us with modern screens.
Jonathan Protzenko has just released a big update to the Thunderbird Conversations extension for the Mozilla Thunderbird email app. It's coming along really well and if I can sort out a few problems I'm having with Thunderbird's font settings, I might be able to make this my go to email client. I think the conversations capability really helps bring Thunderbird forward and it should probably be integrated as either the default view or an optional view.
In an earlier post, since pulled, I lamented some of the problems with Thunderbird aesthetics and while I did file bug reports, they were mostly complaints about what I thought looked poor without a lot of suggestions for how those concerns could be addressed. With what little spare time I have I'm going to try, going forward, to propose more concrete steps for improvement. It's not core Thunderbird, but it's something I like the direction on so here's my first proposal for simplifying, beautifying, and increasing the clarity of user interface in a Thunderbird-ish feature.
This is the Thunderbird Conversations "quick reply" feature. On the left is the current state and on the right is a hacky photoshop mock-up of some changes I think could benefit it. Click the image for a full-sized view.
I'm not saying that I've got the perfect solution here and I welcome feedback from other users and from Jonathan and other Thunderbird devs. I do think it's a decent improvement to a small feature that I intend to use regularly. More on core Thunderbird design soon.
