Moving my blog from AWS to WordPress.com

About a year ago I moved my WordPress powered blog from GoDaddy’s shared hosting to an AWS machine. The performance of my WordPress install on Godaddy was getting from bad to worse, something I that got really obvious when I configured a Pingdom account to alert me every time the site was unreachable.  Around that time I was also getting interested in learning how AWS works and so it seemed like moving the blog on AWS seemed like a good idea. A year in, I am moving my blog again, just letting WordPress host the entire thing for me this time. I figured I’d share the reasons why:

  • Managing the traffic peaks: I ran my blog on an AWS t1.micro instance which worked pretty well on a regular day. However every once in a while if my traffic spiked (say if a post reached Hacker News or Reddit), the site would go down. I could configure AWS auto scaling but that also meant spending more money. I ultimately ended up putting a free instance of CloudFlare in front of the blog and that seemed to work well, but still left me feeling uneasy.
  • Cost: Running the blog on GoDaddy cost me around $70 a year. My AWS bill used to be around $17 a month which is around $200 a year, a definite jump from what I was spending on GoDaddy but I put it down to cost of learning. The Wordpress account with custom domain costs $99 a year, so I don’t mind the savings, especially considering I hadn’t really been doing too much server management for the last 6 months.
  • Trusting backups: I had setup a WordPress backup to Dropbox plugin to make sure if I accidentally wiped the database or something, I’d always have the data to go back to, but I never verified the backup after the initial couple of weeks. Over time I got a lot less confident if that plugin was actually working, and kept putting off verifying the backup (trying to bring up a new wordpress instance with just that data). Moving to a hosted WP instance eliminates that doubt.

All in all, the AWS experiment was fun and educational, but it made me started blogging less since I was always worried that I’d have to monitor the site each time I added a post. Moving to WP hosting feels like a good decision though I do think I broke some Google URLs during the migrations, mostly because my blog moved from a subfolder (arpitonline.com/blog/*** to just arpitonline.com/***). I am fine with that, I hated the blog subfolder anyway. If you do subscribe to my feed, you might have to update your RSS readers to the new feed link.

Announcing Artbook: An Android Client for Dribbble

I am a big fan of Dribbble. For the uninitiated, its a community for designers to share parts of their work and is pretty inspirational when you are thinking of designs for your own applications. When I released FreeFlow earlier this year, I included a sample Dribbble project as part of the release to showcase the power of layout system. Since then I recieved a couple of messages from a few folks to just complete that as an app since a lot of the work was already done anyway. It also didn’t seem like there were any really compelling Dribbbble apps on the Play Store (well none that I felt were very interesting anyway). So last week I worked a bit and finished the Artbook app

Like the original source that was included in FreeFlow, Artbook is completely open source and released under the Apache 2 license. The code for the app has some ugly parts but is generally okay. Having recently acquired a 10.1” Android tablet (the Galaxy Note 10.1 mostly for drawing), I really wanted to make sure it had a fantastic tablet experience. However unlike Google’s direction to use Fragments for multi device layouts, this app does it via just a few simple if-else blocks and conditionally loading layouts. I find this approach so much simpler than any elaborate Fragment based architectures.

Anyway, I hope you give it a shot and see if you like it. I find browsing Dribbble a lot more fun using it

 

Improving Android’s NavigationBar

One of the interesting features that were released as part of Android 3.0 HoneyComb release back in 2011 was the introduction to the soft navigation buttons. To me, the system seemed full of potential as navigation buttons adapted to better educate the user as the user used the system. For example, while using an application, if the user ended up launching the keyboard, the back button would change to indicate that back would now just dismiss the keyboard and not actually go back to the previous screen.

keyboard

 

Three years later, I am surprised that not much else was added. The back navigation while powerful still can get ambiguous at times. Below are a couple of ideas I think can really improve the user experience on Android today.

Preventing accidental over-backing

Accidentally hitting back one too many times is a problem that I encounter enough times that it really does get irritating. I am sure it happens to other app developers as well, which is why often you see developers implementing the extremely frowned upon “Are you sure you want to exit” modal alert in apps.

The soft button could really fix this problem by changing itself to indicate that you are at the last item in a stack. I am not an icon designer but here is how I imagine the soft keys changing when the user is on the only activity in the stack. The icon clarifies that hitting that button will exit the activity.

app-close

 

 

Enabling Done Discard Pattern

The constant presence of a back button causes confusion in one other place: when a user is modifying data, like adding a todo item on a list or adding a new contact. Without an explicit tap on a save button, hitting back or tapping on the Home icon now adds ambiguity to the question of whether the user wanted to save the data or not. One of the nicer patterns that emerged in Android was the Done/Discard pattern that Roman Nurik released as an Android library a while back, but because it doesn’t prevent the back button, a better way was if Android introduced a “Done Discard Activity” that would modify the back button and maybe temporarily hide the multitasking action.

done-discard

 

What do you think? How else could the the digital nature of the Android navigation bar be used to improve Android UX?

Big in China

I haven’t looked at the usage stats for PicScribe in a while. It does the couple of things I need it for and I am mostly content with the functionality. But with Material Design I was thinking of giving the app a refresh as well as add some features I had been meaning to as well.

Looking at the stats today was interesting though. Looking at my integrated Google Analytics data, it appears that majority of the app usage is happening in China where Google Play doesn’t even exist. I have no idea how they got the app, its free so it doesn’t matter, but still.

china.png
All the top phones are also local ones (mostly Xiaomi ).

Lesson of the day: Make sure you add analytics to your app.

 

 

 

Android wishlist: A different notification UI for background services

This post is first in a series around enhancements to the mobile experience I’d like to see going forward. Stay tuned for more :)

Background services are one of my favorite features on Android. As the idea of a smartphone changes from a phone to a true contextual device, background services that keep track of user context and push information to the user at appropriate times are essential. That said, the current visual treatment they get on the device to let a user know that they are running, which hasn’t changed much since the inception of Android, needs to change.

The Problem

Here is a screenshot of my notification shade right now. Note that only one of the 8 notifications I am currently seeing is actually a new event that I actually need to respond to. The flooding of my notification window with the always running service notifications numbs me to actually important actionable notification that sits there.

2014-05-10 12.59.31

 

Proposed Solution Option 1:  Notification Tabs with services tucked away

A lot of ROMs already implement Notification Tabs. Moving the background services to a separate tab so that I don’t have to look at them whenever I pull down the shade would solve the problem, though it does add some complexity to the shade.

2014-05-10 12.45.32

 

 

Proposed Solution Option 2: Collapse background service notifications into one low-priority notification:

This option may be a little better since you don’t add the cognitive complexity to the notifications shade. Simple is better usually :)

2014-05-10 13.35.20

Final thoughts:

In both the cases above developers will have to explicitly change their own notification priority to escape the “grouping”. So if a significant event occurs, their notification can be shown along with the rest of the notifications.

As notifications become increasingly more important to the mobile experience, like the coming smart watches that are all about contextual notifications sent by your phone, there is a greater need to make sure that we don’t overwhelm the user with an unorganized stream of information.

As always, feedback is most welcome :)

 

Announcing FreeFlow

This week I announced FreeFlow, a UI framework for Android, that I lead the development on at Comcast for the last 6 months or so. The project started after repeated frustrations in building truly unconventional layouts in Android. Most of the times, developers end up hacking the default Layouts in terrible ways trying to get layouts like the designers I work with come up with. Another problem with such layout nesting is that layout animations are next to impossible to get working right.

FreeFlow solves these problems by separating the layout logic from the core View containers (ViewGroups). The idea is very similar to UICollectionViews in iOS. Additionally as layouts are transitioned or data changed, the developer gets full control over the transition animations. The video below shows some of the kind of effects that FreeFlow enables:

The library was announced 3 days ago on Google+ and Twitter. Its exciting to see that in a very short time, the project has been starred over 600 times, forked over 50 times and is seeing some initial contributions back already. I also just started a Google+ community for developers looking for help or offering feedback to the the project.

Its also exciting that this is Comcast’s first Android open source project, and that we now have a process to do that. Of course that leads to some interesting comments on Twitter. The one below might be my favorite conversation thread:

freeflow

I am excited to see where FreeFlow could go in the future. Its already solving a core need in internal Comcast projects and hopefully will lead to a new breed of interactive applications on the Android platform.

I’m psyched!