The training plan below, assumes that you’ll have the following skills to speed your iPhone development:

• Knowledge of C/C++/Java
• Design patterns like MVC-2, Delegate
• Event delegation model in core java

Having knowledge of a server side programming language like J2EE, PHP, or ASP.Net will certainly help as any reasonably sophisticated iPhone app will require communication with third party services for data. Knowledge of web services like Restful (for communication) and JSON for data interchange is an added plus.

This training plan if properly implemented can help you create productive and utility kind of applications. To create immersive kind of application like games you will need to know OpenGL ES programming, which is another matter altogether.

The post Training Plan For iPhone Application Development first appeared on The Upside Learning Blog.

While going through the session list, I noticed one session on SCORM Implementation Strategies for Mobile. Being a hard-core techie and a follower of mobile SCORM, it caught my interest.

Covering some interesting use cases, common technical challenges and the best practices, it is a great resource for anyone who wants to implement SCORM for mobile devices.

• Notable Use Cases where SCORM has been implemented for mobile devices
  You will find information on –
  1. Number of devices supported. You can get more information about how to implement SCORM for blackberry here.
  2. Some technical details regarding development
  3. Support available for SCORM 1.2 and/or SCORM 2004
  4. Current active clients
  5. Features available in each implementation
• Common Technical Challenges
  It provides information on technical challenges like small screen, multiple OS support etc.
• General Best Practices
  You will learn about the best practices like creating prototype, identifying target devices support, deciding native or web app, SCORM considerations etc. For additional information, you may also like to read IPhone human interface guidelines and things to consider before implementing SCORM.

The presentation sure is a great help and I would highly recommend you run through this before attempting SCORM implementation for mobile devices.

The post SCORM Implementation Strategies For Mobile: mLearnCon first appeared on The Upside Learning Blog.

Table Views, Text Views and Web Views:

• Table View: It displays information in single column multiple rows format.  Rows can be divided into sections or groups. Each row can contain image, text and controls. Each row or cell can be style in different ways like plain, grouped, subtitle etc.

  Table views are normally used for:

  • Selecting Options: As multiple select dropdown is not available
  • Navigating Hierarchical Information: Mainly in productive type of application
  • Viewing Conceptually Grouped Information.
  • Looking-up Indexed Information: Rows are indexed from a-z. The index key is displayed at right hand edge.

  Table view elements:

  • Disclosure Indicator: User taps anywhere in the row to see next level in the hierarchy or associated choices
  • Detail Disclosure Button: User taps this element to see meta data about list item
  • Switch Control: Presents user with two mutually exclusive choices like yes/no or on/off. At any given time only one choice is displayed.

  Some other elements are Delete button, Row insert button and Row reorder control button.

• Text Views: It displays multiple line of text and supports scrolling when text overflow occurs. It can be made editable. You have control over font, color and alignment but it applies to entire text.
• Web Views: It’s specifically used for displaying html contents.  If you want variable font, color or alignment within a view’s text then you can use web view instead of text view.

Application Controls:

• Activity Indicator: Shows progress of a task having unknown duration
• Progress View: Shows progress of a task having known duration
• Detail Disclosure Button: Gives metadata/additional information about something
• Info Button: Provides a way to show configuration information about an application
• Label: Variable sized static text
• Page Indicator: Displays a dot for each currently open view
• Picker: Single select dropdown. User spins the wheel (or wheels) of a picker to select desired value.
• Rounded rectangle button: Button to perform an action
• Segmented Control: Linear set of segments, each segment functions as a button
• Text Field: To accepts user input
• Search Bar: Accepts text input from user which can be use for search
• Slider: Allows user to make adjustments to a value or process within allowed values.

System Provided Buttons and Icons:

IPhone OS provides standard buttons for navigation bar, toolbar and icons for tab bar to promote consistent look and feel.
E.g. Buttons like done, edit, cancel, refresh, trash etc.

It decreases your development time plus it brings stability to your application in case tomorrow Apple decides to change the appearance of standard icons and buttons.

Creating Custom Icons and Images:
For all icons and images PNG (32 bits) format is recommended. Each application mainly needs an

• Application icon size: 57X57 (without alpha transparency)
• App Store icon size: 512X512

The guidelines document provides detailed information which you should check before creating graphics for your application.

I hope this series helps you create various publications for your iPhone. Do remember to share your experiences too.

Happy iPhone development!!!

The post IPhone- User Interface Guidelines – Part III first appeared on The Upside Learning Blog.

Application Window: Each IPhone application contains an application window. It is at the top of the application hierarchy. Every other control resides within the application window.

Views: Provides content regions. There are different types of views available like tableview, textview, webview. Each view has a distinct set of functionality. An application window contains more than one view.

Controls: These are graphics object with which a user can interact with. A view can contain multiple controls. There are some controls which belong to specific view only (e.g. disclosure indicator in table view) while some controls can be used in variety of views.

Screen: It is a logical entity whose instance you cannot create programmatically like a window, view or control. You can visualize it as a state in your application. Each screen contains combination of views and controls.

Using views and controls in application screen:

Each view and control provides some level of customization at look and behavior level. Always try to use standard views and controls with their default look and behavior as user is familiar with it, except in the case of immersive application type. In an immersive application you can create customize controls to form a unique environment and discovering that environment is a part of user experience.

Bars:
Bars are views that are placed either at the top or bottom of the screen. They have defined appearance and behavior.

• Status Bar: It appears at the top of screen. It gives device and carrier specific information to user like signal strength, carrier name, battery charge, current network connection. You can customize its appearance and to some extent its behavior. You can hide the status bar (may be in immersive application) but you should seriously consider this design decision as user expects it to be always available.
• Navigation Bar: It appears just below the status bar. It displays the title of the current view, controls to act on current view and navigational controls. Navigation bars are specifically used in productive applications as they arrange information in a hierarchy.
• Toolbar: It appears at the bottom edge of the screen. It contains buttons to manage the current context/view. It should not be used to switch between different modes or tasks of an application. It can contain five buttons with each having 44*44 hit area.
• Tab Bar: It appears at the bottom edge of the screen. It is used to mange tasks or modes in an application. Each tab bar contains tabs having image and text. In case there are more than five tabs, iPhone OS displays four of them with additional “More” tab. Tapping the more tab displays additional tabs available in a separate screen. It can contain edit button to configure tab bar to display most often used tabs. Each tab can contain a badge to give additional information to user in a nonintrusive way.

Modal Views:

They are analogous to alerts in JavaScript i.e. unless you dismiss them you cannot move forward. They are normally used to give some critical information to user which user is not expecting or additional choices or functionality to be offered. But it is important to avoid overusing them as they break the normal flow of user.

• Alert: Give important information to user which may affect their use of the application. Its timing of arrival is unexpected. It contains text and buttons. It should have maximum to buttons.
• Action Sheet: Give additional choices to user corresponding to current action. It always opens from the bottom of the screen and hovers over current view. It displays multiple buttons from which user selects appropriate one. It normally contains more than two buttons.
• Modal Views: Provide extensive functionality corresponding to current task. It always opens from the bottom of the screen and covers entire view. It displays combination of controls and accepts multiple user inputs.

I would soon be posting the concluding part of this series, so stay tuned.

The post IPhone- User Interface Guidelines – Part II first appeared on The Upside Learning Blog.

The document is divided into two parts:

• Planning Your iPhone Software Product: Covers types of applications, fundamental human interface design principles and the iPhone OS environment.
• Designing the User Interface of Your iPhone Application: Covers available components to develop IPhone application interfaces.

This blog post intends to summarize both parts in separate posts. This is the first.

Planning Your iPhone Software Product

1. 1. Types of application: Based on implementation method
      • IPhone application: Native application, build completely in Objective C. User needs to download it from the App store and install it on the iPhone. It can use all the native features of the device provided the API is available in SDK.
      • Web-only Content: Build using HTML. It runs in safari browser. The application is deployed on some other server and not on actual IPhone device. It can use limited native features of iPhone device provided you build your application using HTML5
      • Hybrid application: Combination of Objective C and HTML. It primarily uses UIWebView component to render html content. User needs to download it from App store and install it on iPhone. It can use all native features of IPhone device provided the API is available in SDK. You can also use varied available frameworks to build this kind of application. One of the applications we developed falls into this category – get more information about it here.
   2. Types of application: Based on application style(visual and behavioral)
      • Productivity Applications: primarily deals with managing information. The user interface is simple and uses standard components available. It primarily uses UITableView control to display information in list form. E.g. Mail
      • Utility applications: primarily deals with checking quick summary of information or performing quick task. In this style, same information is presented using different views. It frequently requires configuration changes which you manage using info button available on main view. The user interface is simple and uses standard components available. E.g. The Weather application
      • Immersive applications: Offers a visually rich environment to user. The user interface experience may not be standard as in other styles. Game falls in this category. We have developed a soccer quiz application (available free on App Store) in this style. You can get more information about it here.

It is not necessary that each application should fall in one of these categories. An application can be combination of multiple styles depending on functionality and information you want to present to user.

1. 1. Fundamental human interface design principles
      • Metaphors: Map your application’s entities i.e. class/object/method to real world.  E.g. Folders
      • Direct manipulation: Managing the application’s object directly using Multi-Touch interface/gestures as opposed to keyboard or mouse.
      • See and Point: Using list form to get user input instead of asking user to input data in text area.
      • Feedback: Provide feedback for each action. Proper feedback enhances application’s usability. Animation can also be used for giving feedback.
      • User Control: Allow user to initiate and control actions. Keep actions simple so that user can remember them. Whenever possible, use standard controls and behaviors.
      • Aesthetic integrity: it defines how well your user interface integrates with your application’s functionality. An application having a visually rich but illogical interface is hard to understand and use.

Principles are primarily based on how user thinks and works.

1. IPhone OS environment:
   • Screen size is compact: It is a challenge to design an interface for small screen size. Keep the focus on displaying important functionalities.
   • Memory is limited: As the iPhone OS does not include swap space, you must avoid allocating more memory than is available on the device.
   • People See One Screen at a Time
   • People Interact with One Application at a Time: Only one application can run at a time i.e. multitasking is not possible. Note: A recent update has just made multitasking available on certain devices running iPhone OS 4.0.
   • Onscreen User Help is Minimal: Mobile users don’t have time to go through help manual or context help and a developer also doesn’t want to devote space and memory for help contents. So use standard controls and behaviors a user is familiar with to minimize onscreen help.

More in my follow-up post, coming soon.

The post IPhone- User Interface Guidelines- Part I first appeared on The Upside Learning Blog.

1. Identify the target device(s) like IPhone, Android based devices, Blackberry, J2ME based device(s) etc,
2. Identify the Device OS version. e.g. Blackberry 4.6 and 5.0 has very different browser implementations.
3. Does your targeted mobile device browser support the popup window functionality?
4. Does your targeted mobile device browser have iframe or frameset support?
5. Identify the implementation method of SCORM.  e.g. we considered –
   1. JavaScript plus Google Gears API
   2. JavaScript plus HTML 5 database
   3. JavaScript plus native device language
   4. JavaScript plus MIDP profile i.e. J2ME
6. Consider the application’s running mode; will it be
   1. Online: Requires continuous internet connection
      1. You may like to consider intermittent  internet connection while attempting a course
   2. Offline: Doesn’t require continuous internet connection
7. Are you planning for cross platform SCORM player
   1. Currently this is possibly only using a web based SCORM player.
   2. Right now it seems offline applications cannot achieve cross-platform SCORM implementation

Keep these in mind before considering SCROM implementation for mobile devices.

The post Top 7 Things To Consider Before Implementing SCORM For Mobile Devices first appeared on The Upside Learning Blog.

Again, as in implementation of SCORM for mobile devices, we encountered some interesting issues in its implementation for Blackberry.

Find our experience on the same.

Target Platform:

After a good amount of R&D and feasibility study on available device software for Blackberry devices, we selected device software 5.0+ as our target platform. Device software 5.0 has good inbuilt browser support (some of the features are from HTML 5.0) and, also has Widget SDK, which is used to create native applications in HTML.

Implementation:

1. Development tools required:

• Normal J2EE development environment like Eclipse and Java SDK.
• Blackberry Widget SDK: You can get more information about Widget SDK here.

We created a Blackberry Widget, which is a combination of two parts:

• Actual Widget
• Custom JavaScript Extension

• Actual Widget
  • The complete UI of solution is defined (in HTML and JavaScript) in the Actual Widget.

• Custom JavaScript Extension
  • A JavaScript Extension is Java code that is built into a BlackBerry Widget, and can be accessed through JavaScript. This capability allows you to extend the functionality of your BlackBerry Widget application to include native BlackBerry functionality.
  • We used it as a backend of our solution to communicate with online database/LMS.

2. Solution:

• We implemented SCORM standard in JavaScript files. These files were then included in the widget.
• As mentioned before, this was an offline solution hence course content was residing in the device itself. We built JavaScript extension to download the actual course content.
• After launching the SCORM complaint course content, the communication took place with JavaScript files, as it would happen in a normal desktop browser.
• We used Google Gears API to store the tracking information of the user. Google Gears API provides ability to create database/tables which greatly simplify storing of tracking data. It uses the open source SQLite database system. (Note: Recently Google has decided to drop Gears in support of HTML 5 database and Blackberry has also decided to use Google backed webkit in their new device OS 6). To sync tracking data back to online LMS, you can use normal browser based method or you can use JavaScript extension built in Java.
• The widget name, icon image, start file etc. were defined in the config.xml file of the widget.
• The final solution was built using command line (bbwp.exe). Alternatively, you can use Eclipse to build the solution.

3. Problems encountered while trying to implement SCORM for Device software 4.6:

• Online mode:
• There was no problem in running SCORM complaint mobile LMS in Blackberry browser.

• Offline mode:
  • Device software 4.6 doesn’t have widget support, so we had to create everything in native Java language including invoking the browser instance for running the courses.
  • While running the courses we had to manually tell the browser which type of file it is rendering like HTML or JavaScript.
  • Till this point everything seemed fine, but we got stuck at a point where actual SCORM communication occurs, using frameset or iframe. We were not able to make API calls or normal JavaScript calls from one frame to another frame.
  • As yet, we haven’t been able to find any solution to this problem nor do we know if the problem lies with Blackberry.(Blackberry  browser has had a very bad reputation until Device software 5.0)

I hope our experience helps you in implementing SCORM for Blackberry devices. Have you followed some different approach? Or implemented it for Device software 4.6? We would like to hear your experience too.

The post SCORM Implementation For Blackberry first appeared on The Upside Learning Blog.

Below I share my development experience of creating the Pune Layar.

Prerequisites:

• Layar developer account: In couple of days you will get approval from Layar team.
• A Gmail account
• Server with public IP/domain where you will store actual layer content. The server can be shared one or completely owned by you.
• Mobile device having Layar browser support. Currently Android 1.5+ and IPhone 3GS supports it.
• Familiarity with Basic layar functioning.
• And some development experience in JSON programming

Development:

The development occurs at two ends:

At Layer site:

• Fill the necessary information
  • Here you will need to provide URL of server where the actual contents reside.
  • Difference between Name and Title field:
    • Title appears in actual layer on mobile device
    • Name is for reference purpose and doesn’t appear anywhere in your layer on mobile device.
  • Click on save button.
  • Click on edit button. In edit mode there are different tabs like:
    • AR view: Here you can set color scheme for your layer
    • POI Icons: Here you can upload icons for you POIs. POI can have four different icons for four states.
    • Filters: Here you can define search filters for your layer. The search filter can be textbox, radio button, checkbox, or slider.

At your server:

• The layar server sends http request to URL you have provided while defining the layer in layar developer site and it expects a JSON response containing POI details. You can find more information about JSON response format.
• You can use jsp/servlets/php/.net or any server side programming language to output JSON response. It totally depends on how dynamic your data is. You can even use simple html page having static JSON response.

Note:

The sample images of Layar browser on Layar developer site depicts old Layar browser. Latest Layar 3.0 browser has different layout.

Testing:

• Layar team has provided page where you can do basic testing of your layer. You can find it under layer listing page by clicking “your layers” link at top. The basic testing includes:
  • Receiving request from layar site.
  • Validating the JSON response.
  • Validating POI with images and information.

• Once you are done with it, the actual testing will happen on your device.
• Once installed, launched it and under settings you will need to click on “Use developer settings”. Get the required developer id and developer key from Layar developer site (by clicking on profile link).
• You may like to use fixed location (GPS) settings.
  • The required latitude and longitude format is: Decimal Degrees like 18.497916.
• Once you are done with above steps you should see your layer appearing in featured tab in Layar browser.

Publishing:

• After testing the layer you will need to send it for approval process. Under layer listing you will find “Request publication” button.
• The approval process may take up to five working days.
• Once approved you can then publish it whenever you want, may be coinciding with some event.

That’s it. Quite simple – isn’t it?. Your layer is now available for public.

The post Developing A Layar Application first appeared on The Upside Learning Blog.

I want to share some tools which may assist you in developing mobile learning applications.

On broad level those tools can be categories into tools for:

• Enterprise application like LMS, LCMS
• Games
• Augmented Reality

Tools for Enterprise application like LMS, LCMS:

Enterprise applications can be created as Native or Web based. There is a good post mentioning the difference between them here.

Tools to develop Native applications:

SDK provided for mobile device

• IPhone
• Andriod
• Blackberry
  • Using Blackberry widget SDK you can develop native application in HTML. We used it to make our LMS client on Blackberry. The Widget SDK is available in device software 5.0 onwards.

• Samsung

But the issues with them are higher development cost and no cross platform support. So your application will tied down to one platform. There is an alternative though

• Java ME
  • It requires MIDP/JVM on mobile device
  • Each mobile device has some variation in implementing MIDP profile
  • It is not available on IPhone

To lower the development cost and to achieve cross-platform (to some extent) there are some tools/framework

• Phonegap
• Titanium
• MoSync

Tools to develop Web applications:

You can develop mobile web application using any tool which you normally used for developing web application. But as IPhone has distinct UI there are some tools to achieve that effect:

• iui
• jQTouch
• iWebkit

Tools for Games:

You can always use native SDK provided for mobile devices like IPhone to develop games, but then you will have to start from scratch. To make it easier, you can use engines/frameworks which will help you in developing games.

• EDGELIB
• Unity3D
• JGame

Tools for Augmented Reality:

• Layar

Let us know what tools you are using in your efforts, we’d really be interested in knowing.

The post Tools For Mobile Learning Development first appeared on The Upside Learning Blog.

2. Real Time Language Translation Over Phone – A cool demo of technology that might eventually truly end the language barrier. The aim is to achieve reasonable cross-language communication in the absence of any means of communication. Tremendous applications in learning and development, it’ll be interesting to keep an eye on developments in this space.

3.  Ribbon Hero – Ribbon Hero is a game for Word, PowerPoint, and Excel 2007 and 2010, designed to help you boost your Office skills and knowledge. Play games (aka “challenges”), score points, and compete with your friends while improving your productivity with Office. As a concept test, this add-in is not supported, but is an opportunity for you to try out an idea we are working on and let us know what you think. A nice way to encourage learning.

4. Socialcast – Socialcast is offering a collaboration tool plug-in for MS-Outlook. Unlike Basecamp and other tools, it works right inside Outlook and works on top of Socialcast EASE – Enterprise Activity Stream Engine offered by Socialcast.

5. Bloomfire – A cool service that’ll launch middle of the month. Let’s anyone create a course, let’s anyone take it. It allows for a large number of informal, social-learning opportunities can be dedicated to any subject. Check out the videos on the site explaining their service idea, should be interesting to use when it launches.

The post eLearning: Interesting Weekly Finds #14 first appeared on The Upside Learning Blog.