App Stats 20 days - Conclusion: Calling for Malay localizers :)

Let's take a look at my Android Market stats during open beta testing for Iteration I Aug 9-29 : User Interface

I have a total of 15 active users according to the Android Market, most of the users have either Android 2.2 (Froyo) or 2.3.3 (Gingerbread).

Android versions:

1.	2.2	2,084	78.17%
2.	2.3.3	381	14.29%
3.	3.1	67	2.51%
4.	2.2.1	50	1.88%
5.	3.0.1	43	1.61%
6.	2.2.2	20	0.75%
7.	2.3.4	13	0.49%
8.	3.2	7	0.26%
9.	(not set)	1	0.04%

Total active installs : 15

Naturally I have had installs in Canada and the US, but 50% of my user base is in Indonesia and Malaysia  (probably my friends from Grad school) although I'm not sure how they found out about it, since I only told a couple of people that I knew that had Androids. There were also some users from Israel,  Austria, Sweden, India, Lebanon and the UK. How they found AuBlog and why they downloaded it I can't guess :)

1	Malaysia	26.7% (4)
2	Indonesia	26.7% (4)
3	United States	13.3% (2)
4	Canada	13.3% (2)
5	United Kingdom	6.7% (1)
6	Austria	6.7% (1)
7	India	6.7% (1)

The most important thing for me was to find out what kinds of devices I should target. I have tested my app with an HTC Desire (2.2),  Viewsonic Gtab (2.3.3) and a Motorola Xoom (3.1) all of which have different user experience with my app.

1	Samsung Galaxy Mini
2	Samsung Galaxy Tab 10.1
3	Samsung Galaxy S2
4	HTC Thunderbolt
5	HTC Wildfire S
6	LG Optimus One
7	Samsung Galaxy Fit
8	HTC Desire
9	Samsung Galaxy S
10	HTC Sensation 4G

Device Testing

The HTC Desire : my everyday device.

Audio
Bluetooth works seamlessly with Aublog. This is fortunate, as this is the device I go biking with. The audio is also a much better quality using the bluetooth although it is still only 8000 hz sample rate, yielding only 4000hz sample rate which is not usable for phonetic analysis. What a 4000 hz sample rate means is that high frequency noise like the white noise in the bursts and frication of stops, fricatives and affricates is not captured.

Visual
On the visual side of things, the Javascript in the Drafts Tree consistently renders the tree and the JavaScript in the Edit Entry page also consistently saves state when I rotate the device. On the other hand, the buttons in the WebView are quite ugly, by default.


The ViewSonic GTab

Audio
It doesn't work with Bluetooth, despite having bluetooth, and successfully pairing with my bluetooth headset. It is perhaps due to a lack of a telephony system. In order to play and record audio through bluetooth, the app must actually route the audio through the telephony system in earlier versions of Android. So the fact that Bluetooth works on the HTC Desire, maybe due to the fact that it is 2.2, or that it is a phone. The Bluetooth API underwent a lot of improvements in 3.0 and beyond so hopefully it will work more consistently on the other devices. On the other hand, Android 2.3 and above allows for wide band recordings of 16,000 hz sample rate which yields a much better quality and is useable for phonetic analysis as the range needed for human speech sounds is below 8000 hz.

Visual
On the visual side of things the large screen size is fun for using the Drafts Tree! While testing I realized I started using the titles in the nodes unconsciously to document the branching test scenarios for each feature and sequence of  user actions in AuBlog. It serves as a pretty quick tree generator, especially for nodes with small labels. I was planning on repackaging it into a tree drawing app for linguists, or tree thinkers.  The WebView buttons are also quite visually pleasing, by default.

A question for the tablet users: can you record and hear audio with your paired bluetooth headset when you enable it in AuBlog?

The Motorola Xoom

Audio
The bluetooth and the audio on the Xoom has the same story as the GTab, no bluetooth but surprisingly good quality with the built in mic.

Visual
The Xoom was an interesting visual surprise for AuBlog. First of all, after testing heavily on the HTC, and once and a while on the GTab I didn't expect the Xoom to present such an unusable user experience. There are no hardware buttons on the Xoom, the buttons are created by the software. Moreover, there is no Menu button by default. Instead, menu items are rendered in "the Action Bar" if the app targets SDK 11, using the same underlying code. However, despite targeting SDK 11, and using best practices for menu coding, the menu didn't show up on the Xoom (probably because there are just words as menu items, not icons). To have the menu show up I changed the target to SDK 10, and now the software menu appears. The next problem with the XOOM has to do with the Drafts Tree. The drafts tree is generated when the user clicks on Drafts. The Activity calls the WebView with the static HTML page, and the HTML page loads the JSON (the tree).  By initializing the tree only after the page has loaded, and the JSON has finished exporting, the tree loads properly on the HTC Desire, and also on the GTab, but not on the Xoom. At first I thought it might be due to having 2 cores (one core might be still writing the JSON to file, while the other is loading the JSON into the WebView, but the GTab also has two cores. It may also have to do with having a new WebView version. A question for the testers with Android 3.0 and up, does the Drafts tree load?

In future iterations (once I'm out of the prototyping stage and the architecture has stabilized) I was also planning on localizing AuBlog for another language to put all the mechanisms in place, my candidate languages were French (since I live in Montreal) and Inuktitut (since my informants might tell their friends about it), but it seems like Malay could be fun too since its 50% of my current users :) That is not for a few more iterations, I will wait until the architecture has stabilized further.

Architecture Growth
Itteration I Graphical User Interface : v1.0 - 4 Months
Standard Activities + WebViews for graphically interesting User Interface + Settings for persistant variables and user preferences

Most of the development time so far has been devoted to reconciling the interest of a visually pleasing user interface with maintaing state and not loosing user's entries while they type and rotate the screen. It seems like it should not be such a complex operation, but rotating the screen "destroys" and recreates the activity. Since the user is typing in a webview the Javascript interface has to save the state down to the activity in order to use the built-in state saving mechanisms. Nothing is more frustrating than loosing what you have just entered because you shifted in your chair and the screen rotated. On the other hand rotating the screen is crucial for a good user experience: some times you want to read the entry in wide screen, and then rotate to edit in portrait with the keyboard on the bottom of the screen. The user interface uses a couple of open source JavaScript libraries to make the drafts tree interactive (JIT) and the blog editing WYSIWYG (MarkItUp).

Iteration II Background Services: v1.1 - 20 days
Standard Activities  + WebViews for graphically interesting User Interface + + Settings for persistant variables and user preferences + Recording and transcription server interfacing refactored into Services + Broadcasts between modules

Audio Management Services and the transcription server architecture (Node.js and PocketSphinx) was surprisingly straightforward to set up, and also the most important core of AuBlog's mission. In this iteration AuBlog supports 3 audio configurations: Bluetooth for wire-free dictation, earphones+mic for private dictation, and built-in mic and speakers for default dictation. AuBlog also supports a variety of internet connection preferences, from transcription only over Wifi, to transfers over 3G for x file sizes. In my experience dictations are between 2-4 minutes long, and result in really small files (10-15KB) so its worthwhile to send them for transcription over a 3G connection while I'm biking. I made it so that its completely configurable and users can decide what they want to automatically transcribe. I generally only send the lowest daughter on a branch for transcription since the others are drafts, I prefer to re-listen to them and reformulate them until I'm satisfied.


Iteration III Voice User Interface & Widget : v1.2 - (3 Months)
A homescreen widget for "eyes-free" bike blogging. This will encourage refactoring the code into a central "brain" which issues intents to the other components.  This will also be an interesting challenge to make it as "eyes-free" as possible and set up/adopt architecture to use Google Voice to recognize app commands
"New Entry"
"Play/Read Mother Node"
"Play/Read/Record Sister Node"
"Delete Entry"
"New Daughter"
"Stop recording"
etc

After spending so much precious dev time making sure the graphical user interface's javascript libraries is functional on an Android device, I remembered that I never really wanted a visual user interface; I wanted an "eyes-free" (meaning language only) interface. So, at this point the GUI is functional, and it will stay as it is unless there are some bugs which affect its functionality. I would love to auto-resize the nodes to fit the text but that would require a lot more dev time. I'm excited to start Iteration III, the part of the app that really interests me and is the part I can contribute to most: the VUI (voice user interface). I expect this will take me more time than Iteration II, which only took 20 days. It all depends on the existing open source modules I find and how well they integrate with Android.