I was looking at about:memory and noticed entries for Facebook and Google+ URLs, even though I didn’t have either open. I figured they were probably from the social buttonry that decorates the web these days. No big deal… except they were taking up a bunch of memory! The Facebook button was using over 20mb and the Google+ button was taking over 40mb!
I have never clicked either of these buttons.
So I wrote Wallflower, a simple Firefox add-on (restartless of course) that removes these buttons from any page your browse to, saving your precious memory, CPU and battery life for the content you actually want.
View the source code on Github.
The new app tab feature in Firefox is great. I use it a lot… which has starkly illustrated how apps and tabs have very different use-cases and usage patterns. Often I will check my Gmail app tab because I see the glowing notification that a new email has arrived, do something (or nothing), and then pop back to where I was browsing… in one of those 78 tabs I have open?!
The windowing model in operating systems allows me switch back and forth between contexts with ease. But app tabs do not:
- If I’m using my Gmail app tab and I didn’t open any links while there, I can still see the last tab I was at, and click on it. But I have to use the mouse if I want to get directly back there.
- Out of sheer muscle memory and mouse-averseness, sometimes I can traverse tabs via the next/previous-tab keyboard shortcuts to get back to where I was. Sometimes it’s a *lot* of tabs, so either I’ll hold the arrow key down, speeding past the tab I wanted (and back and forth a few times), or I’ll just hit the arrow key a bunch of times in quick succession. Both options are frustrating, slow and RSI-inducing.
- Or I could expend mental energy to search in the awesomebar and switch to that tab, which often looks like this: “hm, type ‘bug’ and then try to remember some words in the bug summary, but those words match a bunch of other bugs, and i don’t know the bug number, and also I’m on an attachment page because I’m reviewing a patch on the bug, so the summary won’t be in the page title…” and on and on. Now add the fact that switch-to-tab rarely even shows up in the awesomebar for me, and well, a generally high level of fail with this option.
Then there’s link opening:
- Links opened in app tabs are put at the beginning of your tabs, and the tab strip is animatedly scrolled there. Boom, instantly lost where I was before checking my email.
- We tried an experiment where they open at the end of the set of open tabs. I found that to have serious “out of sight, out of mind” problems. That experiment was rolled back. And it doesn’t necessarily solve the context problem anyway.
- Both approaches cause excess amounts of whizzing animations, either when you want to “go around the horn” to get to the tabs you just opened from app tabs, or when you want to go to them and then get back to where you were.
- There’s no right answer! Sometimes I see a link to a recipe in my Seesmic app tab that I’d like to open in that series of tabs related to food that I have open somewhere in the middle of my open tabs. The user is not in control of *where* these links are opened. I can’t choose whether to open them at the beginning or end of the tab strip, or in a new tab group, or new window, etc. Part of me thinks that I actually might work best in a world where each app tab is bound to a single tab group, so that tab growth is bound to the source… but that’s a vision for another day (and blog post and add-on).
So I’ve made Peek, an add-on that’s a hybrid solution: Instead of making you go to your app tabs, your app tabs will come to you. Peek allows you to open your app tabs in a floating panel that opens on top of wherever you are in your tabs. Links open to the right of whatever your current active tab is, and in the background, so that when you’re finished peeking, you are exactly where you left off.
To use Peek, first create some app tabs. Then you can peek at them using the keyboard shortcut ALT+SHIFT+1-9 where the number corresponds with the order your app tabs are in. To stop peeking, hit escape (or switch apps or anything else that takes focus away from the panel).
INSTALL. Peek is a Jetpack add-on that does not require a restart of the browser. User beware: This is an experimental add-on – I’ve been using it on Nightly builds, but haven’t done much testing elsewhere.
- Interact with your apps, and when you’re done, be exactly where you left off browsing.
- Links are opened in the context of wherever you’re peeking.
I’ve been meaning to blog about this for a while, and Singularity Hub’s article about the explosive sales of low-cost Android phones in Kenya reminded me to actually do it.
I was lucky enough to attend a bunch of different tech events outside of the USA in the last year. I went to events in Thailand, Cambodia, Laos, Vietnam, Indonesia and Kenya. I also visited Malaysia and China, and briefly crossed the border into Burma.
Everywhere I went I found Android.
As the article mentioned, Huawei’s IDEOS phones are selling fast in Kenya at ~80USD. These were on sale in the airport in Nairobi, and in many of the mobile shops I went into. Nexian is a manufacturer in Indonesia, with a bunch of Android phones aimed at the mid- to low-end market. In Thailand, HTC is the big Android purveyor (and always *one* Windows phone on offer!). Their low-budget phones in the US are the mid-range phones in Thailand, such as the Wildfire and Tattoo. There were a bunch of other brands and models, I really should’ve taken pictures. The advertising was everywhere. Google was holding Android dev days in major cities. The presence was constant and sometimes unavoidable – like when I rode a tuk-tuk into Siem Reap from the airport and we drove under a Google/Android banner that crossed all 6 lanes of traffic.
Anyways, everywhere I went I was asked why Firefox wasn’t in the Android Market, or if it was, people said that it wouldn’t install, or crashed before starting up.
Well, the explanation is that not all Android devices are equal. The Android devices that are selling well in these countries are very low cost devices. They’re selling in places where 40% of the population lives on less than 2USD per day (Kenya, according to that article), or where >80% of the populace is not even online yet (less than 20% of Indonesia is online, according to Internetworldstats.com). The ARM CPUs that these Android phones have are not very powerful, and they usually have little memory. Often these devices are running 1.x versions of Android. Their screens are small and have the best resolution you could get in a phone in 2002.
But that’s only part of the explanation. These phones all come with browsers! Why can’t they install Firefox instead?
- Firefox on Android doesn’t support the ARM CPUs commonly used in these phones.
- Firefox is not realistically usable given the amount of memory many of these phones ship with.
There’ve been bugs filed about supporting Android devices with weak CPUs, little memory and poor screen resolution, but no traction. The mobile team has explicitly not targeted these phones. Maybe this is because Firefox as it exists today is too far away from being able to run under these conditions. If that’s the case, maybe we need to look at other options, like radically cutting down the feature set, even further than Fennec did.
I don’t think we can wait for decent hardware to become affordable in these markets. They are growing fast, and turning to the Android they can get, and taking the only Web they can get: The one they can afford. There’s not much choice in that scenario, and choice is a key part of the Mozilla mission. When the other 80% of Indonesia comes online for the very first time, Mozilla and Firefox should be there, ready to provide that choice.