“I know that major API changes are always a pain for developers and they would rather not have to deal with them, but please keep in mind stats like “42% of malicious extensions use the Web Request API” when you’re considering what we’re trying to improve here.”
Google is using a large number—42% of malicious extensions—in isolation to justify a decision. This number shows that a large proportion of ‘bad developers’ use this API. But this single data point gives no clue about how big is the total pool of developers using this API.
Are bad developers a large proportion of users of this API, or are they a tiny minority? In the latter case, Google’s action to deprecate/restrict the API may be fairly justified. In the former case, they could have chosen a better, alternative approach in dealing with the bad actors, rather than punishing the mostly good users.
An analogy for case 1:
Bank decides to close all doors leading to the street because 42% of all robbers walk-in through those doors.
Analogy for case 2:
Bank decides to close all waste disposal tunnels because 42% of all robbers sneak-in through those doors.
All we know is that 42% of robbers come in through a point. We don’t know if it’s the main customer entrance, or the waste disposal.
If this statistic was a big argument for this decision’s approval inside Google/Chrome-Dev, then they really need to revisit their decision-making fundamentals.
I seriously doubt this though. Googlers are very smart. They are dealing with mostly smart people on the outside. This number is not for them or us. This number is being published solely to turn the narrative, for the common reader, from ‘Google blocking APIs that stop ads and tracking‘ to ‘Google blocking APIs that stop malicious extensions‘.
iDoneThis is a unique productivity tool that begins where normal productivity tools finish – after you complete a todo/task. The core idea is very simple – log your completed tasks in (as you go, or once daily), and then track, search, tag, discuss, share them as you want.
To log a task you can either email a specified email address with completed tasks (better: just reply to their daily emails), or go the iDoneThis website to log the tasks.
Users can be part of (and post dones to) multiple teams, say one for each project or department. Completed tasks can be #tagged for easy organisation, and team members can comment on and/or *like* each completed task.
Productivity hack: Close your email client!
The log-by-email option used to work for me till, as a productivity hack, I decided to keep my email client and Gmail tabs in a default closed state *all the time*.
The hack’s worked brilliantly! There’s no notifications, and no more quick-check-if-there’s-any-important-new-email only to spend 15 mins going through unimportant, but interesting ones. I open the email client now only when I want to send an email, or am taking a break so I have time to spare. No more interruptions!
The downside to this successful hack is that now I don’t want to open the email client, more recently the Inbox tab, or the iDoneThis website just to send a one line completed task email. And so, slowly, I stopped logging any dones at all.
I recently switched my primary twitter app from Plume to Fenix. On UI and features, both have their pros & cons, but Plume’s usability had taken a massive dive recently with long delays and freezes. Fenix, on the other hand is as fast as they get. Probably, even faster than Twitter’s own app!
While Fenix is faster, prettier, and generally more pleasant to use than Plume, it also has a few serious drawbacks – especially for users like me, with multiple Twitter accounts.
After 3 weeks of using it, I’ve even come to like some of its drawbacks (no multi-account integrated timeline – allows focus), and been desperately hunting/craving/begging for others to be removed.
This post is a list of those nettlesome issues, and my suggestions on how to remove them.
1. Easy switching between accounts
Currently, switching between timelines on two accounts requires: an edge swipe and a slightly problematic tap1. While this is an improvement from the earlier edge swipe + 2 taps, it’s still not fast or efficient enough.
Suggested solution: Swipe on action bar to switch between accounts.
Swipe on action bar to switch between different Twitter profiles.
Swiping on the list of tweets currently switches between various columns – timeline, mentions, DMs, favourites, etc. Swiping on the action bar would switch between accounts in a similar manner. In fact, this UI pattern is already used by Chrome for Android – we can switch between adjacent browser tabs by swiping on location bar / action bar2.
Swipe on the list to switch between columns of current profile.
2. Add ability to post same tweet from multiple accounts
The compose tweet function in Fenix is better than the timeline feature – user can start composing from either account and switch, with 2 simple taps, to another account. It also has the best integration of ‘drafts’ functionality that I’ve seen across any twitter app so far3.
However, it lacks a very important feature for multi-account users – ability to post the same tweet from multiple accounts in one go. Plume accomplishes this quite well (3rd screen in the image below), and it would be really great to see a similar functionality come to Fenix.
Multi-account posting
3. Better muting / filtering functionality
The changes requested so far are (mostly) UI tweaks that enhance experience for multi-users. The muting/filtering feature upgrade requests below, however, are highly relevant for all users. Also, of all the functionality in Fenix, this is one area where I feel it really needs to improve by quite a bit.
1) Apply new filters to both new tweets and the tweets already downloaded
The current implementation of muting in Fenix works by applying the set filters on new, incoming tweets. While this works for long-standing filters, it’s not very useful when you wake up in the morning to see your timeline full of tweets with a random, useless hashtag, say #ReplaceAMovieTitleWithGoat.
Now, even if add a new muting rule to filter out that #tag, it only prevents new tweets from being added to my timeline. I still need to hurdle past the 100s of unwanted tweets with that #tag already in.
Suggested solution: Every time the filter/mute list is updated, run the filter function on all the tweets in the current timeline. Just as it would be run on incoming tweets.
My hunch here is that the filter function is being run when the tweets arrive from Twitter’s backend to the app, and only the unfiltered ones are sent for storing locally to the content provider4. For filtering (and unfiltering) of already downloaded tweets to work, the code needs to be changed so that it stores all tweets, and filters them when the content resolver/adapter4 fetches them from content provider to populate the list.
2) Filter out tweets sent using specific apps
Twitter’s API provides, for every tweet, the source app used to post that tweet. Fenix uses this information in the detailed tweet display mode:
Tweet source app name
While this may be marginally useful from information perspective, it’s far more useful if the app could also provide a filter to mute tweets published using certain apps. Plume did an excellent job on this front, and prevented cluttering of timeline with automated tweets published using some very unsocial apps:
Mute/Filter tweets based on source app
3) Create filters using regular expressions, or even clear text.
Creating simple word based filters is quite straightforward in Fenix. However, that’s all it supports. There is no support for defining filters as regular expression. Furthermore, due to a possible snafu in the app code, some text-based filters don’t work either.
As an example, I have been using ‘.@’ as a filter for a while on Plume. This filters out the tweets that begin with ‘.@twitterhandle …’, which I rarely find useful or entertaining, on Plume.
It also filters out an occasional valid tweet, which could be avoided if Plume supported regex filters, in which case the filter would have been: ^.@\S
Fenix, sadly doesn’t accept either. There’s no support for regular expressions in filters. And using ‘.@’ produces a confusing result – filtering out a lot of tweets, both those beginning with, and not beginning with, ‘.@’. My guess is that the text string provided by the user isn’t sanitised by the app before being added to the filter regex in the code.
Allow regex based mute/filter
4. Better image previews in timeline
Fenix currently offers 3 options for image previews in timeline – large (left screen below), small (middle screen), or none.
Image preview needs a medium/cropped option along with the current large & small ones.
The large screen option looks beautiful! However, most images take up so much screen real estate that browsing through the list becomes a bit of a chore.
The small screen option makes the list quite nice and compact – perfect for quickly scrolling through. However, the size is so small that for most images, the preview doesn’t even offer much of a hint of the full image’s content. Result is user opening a lot more images in full view mode.
I really like Plume’s approach here:
full-column-width preview, cropped to a standard height.
Cropping by height ensures the image leaves space for more tweets, while the full-width preview gives a much better idea of the image’s content. It would be wonderful to have a similar middle-path image preview option in Fenix.
Despite ever expanding web of internet connectivity, no modern web app can expect not to work decently when offline.
Testing offline functionality, though, can be a bit of a bummer for people like me who develop almost exclusively in/for Google Chrome – unlike the old Internet Explorer, it doesn’t have a quick to access ‘Offline Mode’.
Not being a professional developer, I didn’t have extensive tools at my service to test my app in offline mode, and switching WiFi off-on was becoming tiresome. This is the solution I’ve ended up with for offline testing in Chrome:
In extension’s settings, set up a proxy to a non-existent IP Address, preferably on our local network. We could even set it to localhost/127.0.0.1 if we aren’t running a server on local machine.
Proxy SwitchySharp Extension Settings
Now every time we need to switch to offline mode, all we have to do is go to the extension’s browser button, and select the local-profile we created.
Browser Button – Select proxy to go offline.
When we want to go back on-line, we just select ‘Direct Connection’ or, if we have a corporate proxy, then that.
That’s it! No more toggling WiFi to test offline mode for our web apps.
Love the transition effects in/out of apps, but would’ve loved to have an option to switch them off.
Google’s own apps have been optimized and work really well.
Default Gallery app has been fixed – use to take ages to load albums, now is faster than even QuickPic.
Google Now works brilliantly.
Face Unlock now works despite my having encrypted the phone (in ICS, only options were password and passcode), and works really well!
Issues
While Google’s own apps have been optimised for Jelly Bean, most of 3rd party apps haven’t. This causes quite a bit of dissonance – both in appearance and performance.
Google Now works really well here in London. Wonder how it’ll do when I visit back home to my small town in India. Or even smaller towns here in the UK.
Suggestions
Matias Duarte and the Android team have done a great job on the looks and responsiveness of Android. They now need to sort the issues around wide variety in quality of apps, and of OS upgrades. I suggest they exchange notes with the Chrome team.
For homogenizing the app quality, they should take a similar approach to what Chrome team has announced for roll-out of Manifest Version 2 to apps on Chrome Web Store ( See ‘Manifest version 1 support schedule‘). Also, as earlier suggested by Abraham Williams, OS updates should be moved to a rapid release schedule, and (my input) be turned into silent upgrades – just like Chrome.
These changes might require some heavy lifting at the OS/update architecture level, but can be real game changers for Android in the platform wars.
This new extension, 
