In my last post, I talked about some of the reasons why I started developing Android apps. The new Android 2.3 Gingerbread is even better than Froyo. I’m talking about a whole new Nerdy and the Droid factory.

With Gingerbread released and rolled out on the new flagship phone, the Google Nexus S, the developers’ wait is over. Some of the new features and functionalities baked within Gingerbread are:

1.    More power under the hood

My Nexus One lasts me about a day running Froyo. Android is now way smarter in managing its electrons with Gingerbread. With new interface design, smart process management and improved power management, it has increased the battery life significantly.

2.    Near Field Communication

NFC provides high-speed, short-range wireless communication capabilities and is responsible for most of the Gingerbread hype. NFC has introduced many new playgrounds for Android developers such as mobile tickets, mobile payment, identity documents, smart posters, electronic keys and more.

3.    Improved audio and graphics

Gingerbread now supports extra-large screen sizes and resolutions in addition to audio, graphic and input enhancements. This is a red carpet invitation for game developers to knock themselves out!

4.    Session Initiation Protocol VOIP telephony

SIP VOIP allows enhanced video and audio calling. It also supports video conferencing, streaming multimedia distribution, instant messaging, file transfer and online games.

5.    Native sensor support

Gingerbread now natively supports sensors such as the gyroscopes and barometers.

And let’s not forget new features like concurrent garbage collection, multi-touch software keyboard, enhanced support for native code, multi-camera support and new download management.

With all these new building blocks, I can’t wait to see what new apps are going to show up on my App Market!

Happy coding!

The open-source, Linux-based and hardware-independent Android mobile OS, with the new Android 2.3 Gingerbread release is giving mobile developers a whole new ball court to play in. Android is the fastest growing mobile OS among its competitors and with its share in the Smartphone user market growing, Android is attracting more and more enthusiastic developers.

Being a Java developer I jumped right into Android development about a year ago. There is a whole list of reasons why I chose to develop Android apps over other platforms and here are some of them:

1.    Low development costs and high returns

There is almost no cost to develop an Android app. There are no required licenses, specific IDEs or limited distribution channels. You may end up spending money on development and testing expertise, use of specific app stores and the purchase test devices, but the sum of all that is still a fraction of what you would pay to develop on other popular mobile platforms.

2.    Open and free

The two words every developer wants to hear are ‘Open’ and ‘Free’. Now you can have that on your mobile! This baby is license and royalty free because its underlying SDK architecture remains open source. The entire environment is available for customization, and developers and organizations can provide as detailed feedback as they want to the Android development team and watch as their issues get addressed in frequent new releases.

3.    Various distribution channels

Developers are not limited to the Android app market or any other channels to get their apps on consumers’ phones. Apps can be legally downloaded and installed from any unknown sources.

4.    The good old Java

Being Java based, Android uses a rich pool of libraries that provide extreme flexibility and room for uncapped creativity. Android’s topnotch documentation means virtually anyone with a working knowledge of Java can get Android applications off the ground.

5.    Flash Love!

Before Android gathered its well deserved power and popularity, Flash was thought to be a dying technology since it wasn’t supported by other mobile industry giants. There is obviously a ‘but’ here! The green robot embraced flash and took mobile web surfing to a whole new level.

6.    A little piece of the cloud

Android is heavily meshed with the cloud and it carries superior Google connectivity solutions. Google’s cloud tools are already soaring on the popularity list and they come right to the palms of the users’ hands with Android. One can also take advantage of browser connectivity solutions for Chrome and Firefox. In addition, Android provides open Bluetooth communication, something that is missing on some other popular platforms. Versions 2.2 Froyo and later allow the phone to become a portable hotspot. Now that is cool!

The awesome obviously doesn’t stop here. In my next post, I’ll talk about Android 2.3 Gingerbread features and what there is for us mobile app developers to play with!

Happy coding!

Yesterday we kicked off our first Medical Devices specific seminar in Boston, with our friends from SterlingTech and Vector Software. The day was all about software development for medical devices and more specifically, about managing software risk to help ensure you are compliant with all of the FDA regulations specific to software code. We had a great turnout, with over 75% of registrants showing up for this session. A couple of observations I found interesting from this event:

• The medical devices community seems to be fairly tight-knit. Everyone at the event seemed to know everyone else, and there was definitely a strong support system in place among the companies in attendance.
• And secondly, there appears to be fairly high adoption of Agile practices, particularly Scrum (albeit somewhat modified), with these Medical device companies, and the healthcare industry in general for that matter. From everything I heard, this adoption curve shows no signs of slowing down.

If IEC 62304 is important to your organization, you might want to check out this half-day seminar. The next one will be in Minneapolis in January. I’ll be packing my woolies for that one!

Do internationalization and localization take the fun and flexibility out of documentation?

And here’s the answer: You betcha, sister!

At the risk of starting a brawl in the documentation department, I’m going to respond  to my manager’s post about our new policy to facilitate the translation of our wiki . It’s a policy I refer to unaffectionately as the Stamp-Out-Fun-and-Flexibility policy.

And yeah, I know that internationalization and localization are important to humanity and, um, sales. It’s just that making things more translatable makes documentation less agile and less fun.

1.    Wikis are agile until you’re not allowed to edit them

The great thing about our wiki is that we can update it during development and post release. Customers don’t need to wait until a new version is published. It’s always current.

The policy sucks because: We’ll have to have a “freeze-by” date to get material out of translators. Changing the docs will lead to higher translation costs. So that run-on sentence and that wrong instruction will go unfixed until the next round. The PR fix that has user impacts will go undocumented until the next release.

2.    So long community

All along, we’ve encouraged customers, partners and internal teams to edit our documentation.

The policy sucks because: Now, we’re going to have to say, “No editing. Yeah, yeah, I know we said to go ahead and edit, but really what we meant was don’t edit.” Our “yes, go ahead and edit” was mistranslated.

3.    Google loves fresh meat.

For SEO, churn is great. Search engines love to have fresh material to crawl all over.

The policy sucks because: Less content churn is bad for findability.

4.    A fun, engaging tone makes documentation more readable.

A light tone, particularly in error messages, can defuse frustration.

The policy sucks because: Our writing will have to go back to being dry, dry, dry. No more “Why you’re here”.

What are the predictions on the outcome of this fight? Well, I lift weights occasionally, but Helen fights dirty. It’s anyone’s guess, but I think I’m going to lose this one. That’s okay. I’m used to it.

In a previous post, I discussed the problems we encountered when considering translating our entire MediaWiki-based documentation suite. I talked about how to get content out of the wiki for translation, and then get translated content back to our users.

In this post, I want to discuss translation and globalization requirements more generally, and how our small, agile doc team, working in MediaWiki, handles each requirement. Fulfilling these requirements results in lower translation costs and easier translation:

• Provide a medium for the translated documentation that accommodates text expansion
• Use preformatted styles
• Minimize the amount of text to be translated
• Minimize content churn
• Write in a style that allows easy translation

A medium for the translated documentation

Full marks on this requirement. Delivering the translated documentation in a Japanese sister wiki will work well. We also integrate our documentation with our software as JavaHelp, and there are no issues with text expansion in either medium.

Preformatted styles

Again, no issues here. MediaWiki provides heading and formatting styles that are preserved in the XML export, so no one needs to waste time on formatting the translated text.

Minimizing the amount of text

I didn’t have time to write a short letter, so I wrote a long one instead. – Mark Twain

Here’s where the slope gets slippery. Shorter takes longer. With a small team under constant pressure to keep up with agile development, it’s hard to find the time to write concisely. It’s also hard to find time to deal with legacy content.

Minimizing the amount of documentation makes sense for the English version as well as translations. And it makes for easier maintenance, too.

Minimizing churn

There are two opportunities for content churn: during development, and after the release.

During development. Ideally, we’d provide an initial drop to the translators at Beta, and pledge that we’re something like 80% complete. But in agile development, features are constantly refined as a result of testing and customer feedback. Features are added to the release as resources permit, and as product management becomes aware of new customer requirements. With a small team, we work on documenting features right up to the release date. Our development, test, and product management teams review the docs whenever they have time. And as perfectionists, we just can’t resist editing… and re-editing. An agile wiki is a highly flexible creature. But churn is its middle name.

After the release. We continue to fix problems we find in the English documentation, and our customers can edit too. That’s the whole point. Presto: The translation is out of date.

Easily translatable style

We’ve adopted a casual, conversational, humorous style as an attempt to engage our users. But this type of style can be difficult to translate. It can also be difficult for ESL readers to understand. And even non-North American English speakers might find our humor… unfunny.

Here are just a few things we need to do:

• keep sentences short
• simplify the grammatical structure
• avoid idioms and jargon
• create a more extensive glossary
• avoid text in graphics

So, in our spare time, we’re updating our style guide, and when that’s done, we’ll be creating a review checklist for translation and globalization requirements. Our style guide will be funny, because so far, no one has asked us to translate it.

Good reading

I found the article “Maintaining Documentation Across Several Languages” helpful in my research.

After being a PC user for most of my life, I just can’t help but feel a little bit exposed without any kind of antivirus on my shiny new Mac. I mean, I’ve heard it ad nauseum that the Mac just isn’t as prone to attacks as PCs are, but I for one just find that hard to believe.

It is a computer that connects to the Internet after all; there has to be some level of risk there. According to this site, there are regular updates to address new Trojan horses, and other security violations and threats, so obviously Apple is taking this seriously.

Many industry ‘experts’ are starting to think that maybe antivirus on a Mac is (and will continue to be) more important moving forward. Some believe that a Mac is just inherently less susceptible to viruses, while others speculate that there may be other reasons behind it. Either way, the PC side of my brain has convinced me to at least investigate this a little more.

So, do you have an antivirus protection on your Mac?

We moved all of our user documentation from Author-it to MediaWiki a few releases ago. At that point, we translated only a part of our documentation to Japanese – the help pages for detected issues. For these wiki pages, we used MediaWiki language templates to display language links at the bottom, and we copied-and-pasted the translated text.

For our most recent release, we expanded the translation effort. This meant more copy-and-paste – from the wiki to Microsoft Word, to send to the translator, and then from Word to the wiki, when we received the translated text.

We discovered that the language templates don’t work when the page title contains a backslash, so we had to change some page titles – for example, some of our page titles include “C/C++”. In MediaWiki, changing a page title means manually editing all pages that link to that page – not so fun.

Recently, one of our product managers (who’s been doing double-duty as localization coordinator – a.k.a. Copy-and-Paster Extraordinaire) said that he needed to get a quote on translating the entire wiki into Japanese. Warning bells went off in my head. I wondered:

• How do we ensure that shared content is translated only once?
• How do we get the material out of the wiki to send to the translator for a quote and translation?
• Where do we put the translated text?
• How well does our documentation lend itself to translation?

Handling shared content

We use MediaWiki templates to “single-source” documentation. Much as in traditional documentation platforms, wikis allow you to reuse content. For instance, we use a template for the current release number, so that we have to edit it only once per release. We also use templates for information that’s identical across multiple Klocwork tools – from phrases to multiple paragraphs.

Getting the content out of the wiki – attempt #1

Clearly, copy-and-paste for 435 wiki pages plus templates = carpal tunnel syndrome.

Given that we were in the last days of our release, my brain was perhaps not at its most efficient. We use the MediaWiki Book extension, so that we (and our users) can create collections of pages that can be downloaded as PDF. To get a translation quote, I decided to create a massive PDF.

This was no easy task. I don’t recommend it, so I won’t explain the torture involved. Plus, the resultant PDF did not handle the shared text, so the word count was not accurate.

Getting the content out of the wiki – attempt #2

Eventually, once our release was out the door and my head cleared, I did some more reading and investigated MediaWiki’s XML export feature.

First, I used the MediaWiki special page “All Pages” to display a list of all of the pages in the Main namespace. This list is displayed in three columns over several screens, so I pasted all of the page names into an Excel spreadsheet. Then I created a single column of page titles. Next, I copied this list from Excel into the MediaWiki page Special:Export. This page requires only a straight list of page titles, one per line, without the surrounding double square brackets, so the copy-and-paste from Excel worked perfectly. I chose to include only the current revision, not the full history. I chose to include templates (shared text). And I chose to save to file.

To my great relief, the XML file was very readable, and shared text was included only once. The translator provided a second quote and said that they felt more confident with the XML file than with the earlier PDF.

So, we’d taken care of points 1 and 2: We got the material out of the wiki for a quote and translation, and ensured that shared content would be translated only once.

A medium for translated content

Now, what to do with the translated text? The only sane option would be to use MediaWiki’s XML import feature. To do this, we’d need to abandon our current model of having the Japanese pages alongside the English in the same wiki. Instead, we’d need a separate Japanese wiki, where we could simply import the translated XML file. Changing our translation model also means changing how the Japanese documentation is integrated into our software.

Documentation style

Last and most painful: how well does our documentation lend itself to translation? My research and common sense told me that we have some work to do. For example, to make our documentation more engaging and user-friendly, we’ve adopted a casual, conversational, and (some might say) humorous style. This can make translation tricky, but it can also be problematic for ESL readers. And what we think is funny here in Canada may make no sense, or may be just plain annoying, across the pond. I’ll write more about style issues and translation in a future post.

Klocwork developer Russ Sherk sporting his mo'stache. It's hair today, gone tomorrow.

Time’s a precious resource, so the saying goes. Don’t waste it. That’s particularly true for developers, who live in the critical path lane.

And if there’s someone who knows a lot about time management, it’s Russ Sherk, an intermediate developer here at Klocwork, and the father of three young ‘uns. Russ works on our Klocwork Review and Klocwork Inspect products and handles licensing.

For Russ, these are lessons learned over his six-year tenure at Klocwork.

“These are things you need to think about or you won’t progress as a developer,” he says.

Here’s what to do if you want to waste time:

1. Code without a plan

It’s easy to get carried away with ideas about cool features, Russ says. This is how you burn through the days–by doing a lot of things that don’t need to be done.

The fix: Classic agile philosophy. “You have a story. Then break it up into a list of features that must be done. You take those features and you break them down into tasks taking less than a day, Russ explains. A task taking two to four hours is optimal. The team here uses XPlanner for project/story/task management. You can always augment with pieces of paper.”

2. Switch tasks constantly

Mental switching eats up a lot of time because you need to evaluate where you were before you switched gears, and then go through it again when you switch back.

The fix: Get to a completion point before switching (if you can).

3. Take the idealistic approach to bad or “delicate” code

Inheriting problem code makes debugging and feature work more difficult and error prone, Russ says.

“It’s tempting to want to fix it all–but that will always set you back.”

The fix: Fix what you touch to the best of your ability. Schedule larger-scale refactoring and reorganization work separately.

4. Build infrequently

This strategy goes beyond the individual developer.  There was a time here when there were only weekly builds (Egad! Say it ain’t so!). Even 15 minutes per build slows you down, Russ says. The push by development managers for frequent builds has paid dividends.

“Now, I can go through a build process in 2-4 minutes,” Russ says. That translates into 10 to 15 builds a day.

The fix: Frequent build cycles allow you to make your changes, verify them, and handle bugs quickly.

5. Optimize early and over-engineer

This is the dark side of planning. Over-planning and perfectionism can be paralyzing.

The better approach is to keep it simple, he says.

The fix: Plan the bare minimum to get your feature working. After the feature is in place, it’s time to optimize and refactor.

And there you have it. Surprisingly, World of Warcraft didn’t even make the list.