The specific approach we used for this project was to “follow” or “shadow” the workers as they performed their activities and collect observations about:
- The tasks they performed,
- The devices and applications they used to support those tasks, and
- The types of information and work products (forms, documents, etc.) they either collected or produced in course of performing the tasks.
We worked with both staff personnel and supervisor personnel, and we looked at both scenarios where customers would come into a field office and scenarios where the field staff would meet customers at a field location directly. We then followed the observation sessions with one-on-one interviews to review the observations and ask more specific questions.
Based on our experiences, we identified what we would consider to be some key recommendations for business analysts, product managers, or others seeking to elicit requirements for mobile worker applications. Read More…
Navigating this post-PC world can a frightening experience when your corporate lifeblood relies on the dominance of PCs. Compounding this is the fragmentation of the emerging market across native mobile platforms, three primary desktop browsers (exponentially more when including mobile), and varying device form factors and operating system flavors. Read More…
In part two of this series, we looked at how to implement localization of an iOS app using storyboards. Today we’ll continue with that app, and examine how to localize text that is generated programmatically. We’ll also clean up the project a bit, to bring some organization to the localized data files.
This post is the second part of an ongoing series on localization of iOS apps. Please read part one here, if you missed it.
While this post on the MacRumors Forum is a good tutorial for bringing Localization (L10n) to your iOS app, it’s a little sparse in detail, has some updates that change the process, and assumes a few steps. A couple of bugs have also been discovered that need to be worked around to successfully initiate localization in a new iOS app in Xcode.
Today I’ll attempt to clarify some of these steps, and dig into the minutiae that are important to a successful development and deployment cycle. What follows is an example of creating an app from scratch and adding localization features. Read More…
With the increased globalization of the economy, there is an obvious need to create mobile apps that handle multiple languages in a clean and extensible manner. This is known as localization (L10n) in the software development community, and various platforms deal with it in their own unique ways. We will look at how iOS manages L10n here, and the decisions that have to be made in order to stay on top of a dynamic situation.
There are several resources on iOS L10n available, both in official publications by Apple, and some articles and blog posts written by members of the development community:
- Apple provides a home page for Internationalization (I18n), with links to several additional detailed sources, including WWDC videos.
- There is an excellent tutorial on the MacRumors iPhone/iPad Programming Forum that goes into great detail on both how to convert your app to handle L10n and managing the app on an ongoing basis.
- For apps being developed to target iOS 5, using pre-Xcode 4.5, Ray Wenderlich’s blog provides a good starting point with this blog post.
This article will take a high-level look at what needs to be done to fully localize an app. Three follow-up articles will look at the nuts-and-bolts details of how to accomplish this through building an Xcode iOS app from scratch. We’ll look at creating an app with storyboards, and the process of configuring the project to localize these storyboards. Next, we’ll cover how to handle localization programmatically, if you find you have to manipulate text before displaying it. Finally, we’ll wrap the series up with a look at how to communicate with a web service and identify the language of the data you are expecting to download.
The “Mobile Worker” (like you, maybe), is growing more dependent on answering emails and working on the go with a smartphone, tablet and laptop both outside and inside the office. With so many efficient devices and capabilities allowing coworkers to touch base at once, it would only make sense to have all of your data stored in one centralized location. Additionally, most cloud services, such as Windows Azure, provide a web interface. This means you can access your data on any device or platform that has internet capabilities. Read More…
- Your code is easier to understand, maintain and troubleshoot.
- You are much more productive when you leverage the frameworks’ (WPF, Silverlight, XAML, WinRT) built-in features like Data Binding, Resource Dictionaries, Dependency Properties, Routed Events, Commands, etc.
- You can test your app’s behavior “under-the-skin,” avoiding the pitfalls and cost of testing at the UI level.
- Your ViewModels afford testability. You can have unit test coverage allowing “Test-Driven-Development” and “Automated Regressions.”
- Decoupling the View from the ViewModel in the way enabled by MVVM allows designers and developers to work productively in harmony.
Quality custom software that’s designed to meet the specific needs of a business is easy to adapt and should have minimal adoption time and training costs. Workflows that are built according to an employee’s ideal task flow should encourage thorough service calls and better communication flow in all directions.
As an employee who may have to make several service trips per day, mobility is essential. Paper can be completely eliminated, pictures no longer lost or need to be transferred by media card, forms can be filled out by simply speaking into a microphone and tapping on some check boxes. Signatures can be captured easily just by swiping a finger on a screen, bar codes can be read and captured. The possibilities for becoming more productive are expanding each day. Read More…