20101122 - Handling Common Tasks for iPhone - part 2

Hosting Ads In iOS 4.0 and later, you can allow advertisements to display within your application and you can receive revenue when users see or interact with them. It's essential that you plan when and how to integrate ads with your UI so that people are motivated to view them without being distracted from your application. You can host an iAd, which contains the ad content, in a specific view in your UI. When people tap an ad in this view (called a banner view), the iAd performs a preprogrammed action, such as playing a movie, displaying interactive ad content, or launching Safari to open a webpage. The action can display content that covers your UI or it might cause your application to transition to the background. The dimensions of the banner view are: ■ In portrait, 320 x 50 points ■ In landscape, 480 x 32 points To ensure seamless integration with banner ads and to provide the best user experience, follow these guidelines: Place the banner view at or near the bottom of the screen. This placement differs slightly, depending on the bars that can be in the screen: ■ If there are no bars at the bottom of the screen, put the banner view at the bottom edge of the screen. ■ If there are no bars at all, put the banner view at the bottom edge of the screen. ■ If there is a toolbar or tab bar, put the banner view directly above the toolbar or tab bar. Ensure that banner views appear when it makes sense in your application. Although it's recommended that a banner view be at the bottom of a screen, you choose which screens should contain banner views. For example, you might want to choose a context that functions as a sort of interlude in the main task of your application. People are more likely to enter an iAd experience when they don't feel like they're interrupting their workflow to do so. This is especially important for immersive applications such as games: You don't want to place banner views where they will conflict with gameplay. Comments: For games, put the banner view at the game entrance screen or game score screen, not during the gamplay screen. As much as possible, display banner ads in both orientations. It's best when users don't have to change the orientation of the device to switch between using your application and viewing an ad. Also, supporting both orientations allows you to accept a wider range of advertisements. Comments: Should design for portrait ad banner and landscape ad banner. While people view or interact with ads, pause application activities that require their attention or interaction. When people choose to view an ad, they don't want to feel that they're missing events in your application, and they don't want your application to interrupt them. A good rule of thumb is to pause the same activities you would pause when your application transitions to the background. Don't stop an ad, except in rare circumstances. In general, your application continues running and receiving events while users view and interact with ads, so it's possible that an event will occur that urgently requires their immediate attention. However, there are very few scenarios that warrant the dismissal of an in-progress ad. One possibility is with an application that provides Voice over Internet Protocol (VoIP) service. In such an application, it probably makes sense to cancel a running ad when an incoming call arrives. Note: Canceling an ad might adversely impact the kinds of advertisements your application can receive and the revenue you can collect. Managing Settings or Configuration Options iPhone applications can offer settings that define preferred application behaviors or configuration options users can specify to change some functionality of the application. Settings should represent information, such as an account name, that users set once and rarely (if ever) change. Users view application-specific settings in the built-in Settings application. Configuration options are values that users might want to change frequently, such as category types displayed in a list; configuration options should be available within the application itself. You should consider settings and options to be mutually exclusive. That is, you should not offer both settings and configuration options in your application. Comments: Put in "Settings" and "Configuration Options" in the apps to be designed. Even without setting, users should be able to use the apps. It's best when iPhone applications do not ask users to specify any settings at all. Users can begin to use these applications right away without being asked to supply set-up information. To achieve this in your application, there are a few design decisions you can make: ■ Focus your solution on the needs of 80 percent of your users. When you do this, the majority of users do not need to supply settings because your application is already set up to behave the way most users expect. If there is functionality that only a handful of users might want, or that most users might want only once, leave it out. ■ Get as much information as possible from other sources. If you can use any of the information users supply in built-in application or device settings, query the system for these values; don't ask users to enter them again. ■ If you must ask for set-up information, prompt users to enter it within your application. Then, as soon as possible, store this information in your application's settings. This way, users aren't forced to quit your application and open Settings before they begin to benefit from your application. If users need to make changes to this information later, they can go to your application's settings at any time. Unlike settings, configuration options are likely to be changed frequently as users choose to see information from new sources or in different arrangements. You can react dynamically to changes users make to these options, because users do not leave your application to access them. You can offer configuration options in the main user interface or on the back of a screen. To decide which technique makes sense, determine if the options represent primary functionality and how often users might want to set them. For example, Calendar allows users to view their schedules by day, week, or month. These options could have been offered on the back of the screen, but viewing different parts of a calendar is primary functionality and users are likely to change their focus frequently. Supporting Copy and Paste iOS provides an edit (or pasteboard) menu that supports Cut, Copy, Paste, Select, and Select All operations in text views, web views, and image views. The commands in the menu allow people to make changes to their content and copy content from one application into another. For example, you can specify the subset of commands the menu displays and you can influence where the menu appears. You have no control over the color or shape of the menu itself. Use commands that make sense in the current context. For example, if nothing is selected, the menu does not contain Copy or Cut because these commands act on a selection. If you support an edit menu in a custom view, you're responsible for making sure that the commands the menu displays are appropriate for the current context. Note that you cannot specify custom commands to display in the menu. Accommodate the menu display in your layout. UIKit displays the edit menu above or below the insertion point or selection, depending on available space, and places the menu pointer so that users can see how the menu commands relate to the content. You can programmatically determine the position of the menu before it appears, so you can prevent important parts of your UI from being obscured, if necessary. Support both gestures people can use to invoke the menu. Although the touch and hold gesture is the primary way users reveal the edit menu, they can also double-tap a word in a text view to select it and reveal the menu at the same time. If you support the menu in a custom view, be sure to respond to both gestures. In addition, you can define the object that is selected by default when the user double taps. Avoid creating a button in your UI that performs a command that's available in the edit menu. For example, it's better to allow users to perform a copy operation using the edit menu than to provide a Copy button, because users will wonder why there are two ways to do the same thing in your application. Consider enabling the selection of static text if it's useful to the user. For example, a user might want to copy the caption of an image, but they're not likely to want to copy the label of a tab item or a screen title, such as Accounts. In a text view, selection by word should be the default. Don't make button titles selectable. A selectable button title makes it difficult for users to reveal the edit menu without activating the button. In general, elements that behave as buttons don't need to be selectable. Combine support for undo and redo with your copy and paste support. People often expect to able to undo recent operations if they change their minds. Because the edit menu does not require confirmation before its actions are performed, you should give users the opportunity to undo or redo these actions. Supporting Undo and Redo iOS gives people the ability to undo and redo their typing in text views. People initiate an undo by shaking the device, which displays an alert that allows them to undo what they just typed, redo previously undone typing, or cancel the undo. Comments: Undo and Redo are important features especially for text entry, or picture editing. UIKit allows you to support undo in a more general way in your application. You can specify: ■ The actions users can undo or redo ■ When your application should interpret a shake event as the shake to undo gesture ■ How many levels of undo to support To provide a great user experience for the undo and redo capability in your application, you should: ■ Supply brief descriptive phrases that tell people precisely what they're undoing or redoing. UIKit automatically supplies the strings "Undo " and "Redo " for the undo alert button titles, but you need to provide a word or two that describes the action users can undo or redo. (Note that the Cancel button cannot be changed.) For example, you might supply the text "Delete Name" or "Address Change," to create buttons titles such as "Undo Delete Name" or "Redo Address Change." Be sure to avoid supplying text that is too long: A button title that is too long is truncated and is difficult for users to decipher. Also, because this text is in a button title, use title-style capitalization and do not add punctuation. ■ Avoid overloading the shake gesture. Even though you can programmatically set when your application interprets a shake event as shake to undo, you run the risk of confusing people if they also use shake to perform a different action. The shake gesture is the primary way people expect to initiate undo and redo, but you can also include the system-provided Undo and Redo buttons in a navigation bar, if appropriate. You might do this if it's essential that you display an explicit, dedicated button to perform these functions within the context of your application, but this is unusual. ■ Consider the context of the actions you allow to be undone or redone. In general, people expect their changes and actions to take effect immediately. As much as possible, the undo and redo capability should be clearly related to the user's immediate context, and not to an earlier context. Source: Apple Inc (2001). iPhone Human Interface Guidelines: User Experience. Apple Inc, Cupertino, California.

20101121 - Common Tasks for iPhone

Comments: Below are the common tasks of iPhone as defined by Apple Inc. It is important to understand these before going to Design Guidelines. Chapter 4 Handling Common Tasks 45 Starting 45 Stopping 46 Accommodating Multitasking 46 Hosting Ads 48 Managing Settings or Configuration Options 50 Supporting Copy and Paste 51 Supporting Undo and Redo 52 Enabling Local and Push Notifications 53 Making Your Application Accessible 56 Providing Search and Displaying Search Results 56 Using the User's Location 57 Handling Orientation Changes 58 Using Sound 58 The Ring/Silent Switch—What Users Expect 59 Volume Buttons—What Users Expect 59 Headsets and Headphones—What Users Expect 60 Wireless Audio—What Users Expect 60 Define the Audio Behavior of Your Application 60 Manage Audio Interruptions 64 Handle Media Remote Control Events, if Appropriate 66 Providing Choices 66 Providing a License Agreement or a Disclaimer 67 Starting iPhone applications should start instantly so users can begin using them without delay. When starting, iPhone applications should: ■ Specify the appropriate status bar style. ■ Display a launch image that closely resembles the first screen of the application. This decreases the perceived launch time of your application. ■ Avoid displaying an About window, a splash screen, or providing any other type of startup experience that prevents people from using your application immediately. ■ By default, launch in portrait orientation. However, if your application runs only in landscape orientation, your application should launch in landscape regardless of the current device orientation. This signals users to rotate the device to landscape orientation if necessary. ■ Restore state from the last time your application ran. People should not have to remember the steps they took to reach their previous location in your application. Comments: That's why almost all mobile phones have a Starting animation to hide the fact that the phone does take some time for the process of starting up. Stopping People quit an iPhone application by opening a different application. In particular, note that people don't tap an application close button or choose Quit from a menu. In iOS 4.0 and later, and on certain devices, the quitting application moves to a suspended state in the background. All iPhone applications should: ■ Be prepared to quit at any time. Therefore, save user data as soon as possible and as often as reasonable. ■ Save the current state when stopping, at the finest level of detail possible. For example, if your application displays scrolling data, save the current scroll position. Comments: Auto saving of data at appropriate frequency is important. iPhone applications should never quit programmatically because doing so looks like a crash to the user. There may be times, however, when external circumstances prevent your application from functioning as intended. The best way to handle this is to display an attractive screen that describes the problem and suggests how users can correct it. This helps users in two ways: ■ It provides feedback that reassures users that there's nothing wrong with your application ■ It puts users in control, letting them decide whether they want to take corrective action and continue using your application or press the Home button and open a different application If certain circumstances prevent only some of your application's features from working, you can display either a screen or an alert when users activate the feature. Although an alert doesn't allow much flexibility in design, it can be a good choice if you can: ■ Describe the situation very succinctly ■ Supply a button that performs a corrective action ■ Display the alert only when users try to access the feature that isn't functioning Comments: Three types of stopping: (1) User exits the application; (2) Application quits due to certain reasons; (3) Certain features of the application does not functions. Accommodating Multitasking Thriving in a multitasking environment hinges on achieving a harmonious coexistence with other applications on the device. At a high level, this means that all applications should: ■ Handle interruptions or audio from other applications gracefully ■ Stop and restart (that is, transition to and from the background) quickly and smoothly ■ Behave responsibly when not in the foreground The following specific guidelines help your application succeed in the multitasking environment introduced in iOS 4.0: ■ Be prepared for interruptions, and be ready to resume. Multitasking increases the probability that a background application will interrupt your application. Other features, such as the presence of ads and faster application-switching, can also cause more frequent interruptions. The more quickly and precisely you can save the current state of your application, the faster people can relaunch it and continue from where they left off. ■ Make sure your UI can handle the double-high status bar. The double-high status bar appears during events such as in-progress phone calls, audio recording, and tethering. In unprepared applications the extra height of this bar can cause layout problems. For example, the UI can become pushed down or covered. In a multitasking environment, it's especially important to be able to handle the double-high status bar properly because there are likely to be more applications that can cause it to appear. ■ Be ready to pause activities that require people's attention or active participation. For example, if your application is a game or a media-viewing application, make sure your users don't miss any content or events when they switch away from your application. When people switch back to a game or media viewer, they want to continue the experience as if they'd never left it. ■ Ensure that your audio behaves appropriately. Multitasking makes it more likely that other media activity is occurring while your application is running. It also makes it more likely that your audio will have to pause and resume to handle interruptions. ■ Use local notifications sparingly. An application can arrange for local notifications to be sent at specific times, whether the application is suspended, running in the background, or not running at all. For the best user experience, avoid pestering people with too many notifications. ■ When appropriate, finish user-initiated tasks in the background. When people initiate a task, they usually expect it to finish even if they switch away from your application. If your application is in the middle of performing a user-initiated task that does not require additional user interaction, you should complete it in the background before suspending. Source: Apple Inc (2001). iPhone Human Interface Guidelines: User Experience. Apple Inc, Cupertino, California.

20101121 - Usability & Design Guidelines for iPhone

Part II Designing the User Interface of Your iPhone Application 69 Chapter 5 A Brief Tour of the Application User Interface 71 Application Screens and Their Contents 71 Using Views and Controls in Application Screens 73 Comments: I think Apple Inc has come out with comprehensive set of usability and design guidelines for iPhone user interface. This helps ensure that iPhone apps developer come out with highly usable apps. Chapter 6 Navigation Bars, Tab Bars, Toolbars, and the Status Bar 75 The Status Bar 75 Navigation Bars 76 Navigation Bar Contents 77 Navigation Bar Size and Color 79 Toolbars 79 Toolbar Contents 80 Toolbar Size and Color 81 Tab Bars 81 Providing Additional Tabs 82 Badging a Tab in a Tab Bar 84 Chapter 7 Alerts, Action Sheets, and Modal Views 87 Usage and Behavior 87 Using Alerts 88 Using Action Sheets 89 Using Modal Views 89 Designing an Alert 90 Designing an Action Sheet 93 Designing a Modal View 96 Chapter 8 Table Views, Text Views, and Web Views 99 Table Views 99 Usage and Behavior 99 Table-View Styles 100 Table-Cell Styles 102 Table-View Elements 108 Switch Controls 109 Using Table Views to Enable Common User Actions 110 Text Views 113 Web Views 114 Chapter 9 Application Controls 117 Activity Indicators 117 Date and Time Pickers 118 Detail Disclosure Buttons 120 Info Buttons 120 Labels 121 Page Indicators 122 Pickers 124 Progress Views 125 Rounded Rectangle Buttons 126 Search Bars 126 Segmented Controls 128 Sliders 129 Text Fields 130 Chapter 10 System-Provided Buttons and Icons 133 Using System-Provided Buttons and Icons 133 Standard Buttons for Use in Toolbars and Navigation Bars 134 Standard Icons for Use in Tab Bars 136 Standard Buttons for Use in Table Rows and Other User Interface Elements 137 Chapter 11 Creating Custom Icons and Images 139 Application Icons 140 Small Icons 142 Document Icons 142 Web Clip Icons 143 Icons for Navigation Bars, Toolbars, and Tab Bars 144 Launch Images 146 Tips for Creating Great High-Resolution Artwork 148 Source: Apple Inc (2001). iPhone Human Interface Guidelines: User Experience. Apple Inc, Cupertino, California.

20101120 - TechRadar: Mobile web design: platform by platform

Comments: There is now a variety of smartphone systems, i.e. iPhone (by Apple), BlackBerry, Android (by Google), Symbian (popularised by Nokia),Windows Mobile 7 (by Microsoft), etc. The mobile landscape is a complex and sometimes confusing place to be. Here we'll take a look at the most popular platforms, operating systems and app stores and offer some quick and easy tips to making the most out of the opportunities they offer. Comments: Amount of smartphones sold are mind boggling. Smartphones may very well be more significant than notebook/netbook computers. Who knows? M-Commerce may overtake e-Commerce in the near future. Around 1.2 billion phones were sold last year, 174 million of which were smartphones. Symbian devices count for nearly 47 per cent of this market (with Nokia making up the majority of this figure), but they're losing market share to both Apple and Research in Motion (RIM), the company behind BlackBerry, which now have 14.4 per cent and 19.9 per cent respectively. The fastest growing markets last year were Apple and Android, which grew by 6.2 per cent and 3.5 per cent respectively. Smartphones enable consumers to download apps, and now there are app stores everywhere, courtesy of device manufacturers (eg Nokia's Ovi Store); OS developers (Android Market Place; Windows Marketplace for Mobile); operators (Vodafone's 360 Store; Orange's Application Shop) and Independents (GetJar; Handango). All are competing fiercely for eyeballs, clicks and sales. At the moment, the Apple App Store is the undisputed champion; in January, it announced that three billion apps had been downloaded over the last 18 months. Others are catching up, though, with Nokia now proclaiming that it has broken the 1.5million app sales per day mark as of March. The UK mobile scene According to the AdMob report on smartphone usage trends for January, 75 per cent of requests came from a combination of the Apple iPhone and iPod Touch. The next most popular were Nokia and HTC on 4.8 per cent and 4.7 per cent respectively. With Apple firmly set with the top two handset models, it's left to HTC's Hero and Dream and Nokia's N95 to complete the top five UK smartphone handsets. DROID MILESTONE: Amazing statistics released by app analytics company Flurry report higher sales for Droid than iPhone in the first 74 days of sale. This isn't the situation all around the world, though. For example in India, 17 out of the top 20 web-accessing devices are Nokia phones. Nokia here has a market share of nearly 60 per cent, whereas Apple has just under two per cent. Comments: Is Droid/Android the main rival of iPhone? Palm and the WebOS Palm has a vision that the future of mobile will be built on the web. Last summer it launched a new mobile operating system called WebOS, built using web technologies such as HTML5, JavaScript and CSS. Comments: What is the difference between HTML5 and XHTML? A JavaScript framework provides access to standardised UI elements, device hardware and services, enabling relatively rapid turnaround times for applications. Last December, Palm launched the first mobile development environment hosted entirely in the browser, Project Ares. Currently in beta, it provides you with a drag and drop interface builder, code editor, visual debugger, log viewer and source code integration. You can preview apps in the browser or launch them directly on the WebOS emulator (installed as part of the SDK). Project Ares works on the latest browsers including Safari (OS X & Windows), Firefox (OS X, Windows & Linux) and Chrome (Windows). If you'd like to have a quick peek at all the UI elements, a handy app to check out (it comes as part of the SDK) is one that goes by the name of Style Matters. It comes complete with all the lovely code for you to start digging and getting your head around the visual parts of the framework. The Palm SDK, development guides, tools and more can be downloaded from developer.palm.com. Android As a developer, you have more freedom on the Android platform compared to iPhone because you have the ability to change or replace some of the core functionality (eg a custom dialler). The Android SDK runs on Windows, OS X and Linux. Applications are developed in Java, normally in the Eclipse Integrated Development Environment (IDE), using the Android Development Tool plug-in. Other IDEs such as IntelliJ or Emacs are an option, but Eclipse remains Google's recommendation. The SDK provides you with all the tools you need, including emulators. The Google Android Market app count has more than doubled over the last four months, with the purchase rate having trebled in the same period of time. And even more manufacturers will be releasing Android-based devices this year. Comments: Android apps got potential!? However, it's not all rosy news for Android: fragmentation between devices is beginning to present an issue. Phones are being released with a range of Android firmware versions (1.5, 1.6, 2.0 and 2.1) with a variety of different software feature sets and hardware. For example, the Nexus One doesn't run some of the more popular games due to its different resolution screen. What's more, there's a range of different user experiences available, with HTC and Motorola having developed their own UIs. It's also worth noting the success of the Motorola Droid (in the UK it's called the rather less catchy 'Motorola Milestone'), which outperformed the iPhone in terms of sales in the first 74 days from launch. Google's Nexus One, on the other hand, sold very few units, which could be due to a combination of bad marketing and the fact that you could only buy it online. Apple To write an iPhone or iPodTouch app, you'll have to get used to the Objective-C programming language. This can take time for those unfamiliar with it, but having prior knowledge of object oriented concepts and the C language will be a big benefit. There are also a number of tools on the market that enable you to code in different languages and then either compile down to Objective-C or provide access to the native Objective-C calls via special bridges, such as Titanium by Appcelerator (JavaScript, HTML and CSS); Flash CS5 by Adobe, which will include a packager for iPhone; Elips Studio 3 from OpenPlug; and the open source PhoneGap project. Comments: iPhone apps seem to be popularly developed. PAY AS YOU GO: 'We Rule', a Farmville-style game by ngmoco is free, but features in-app purchasing The performance of the apps that these tools create may not be entirely 100% when compared to a totally native app, but they're getting very close in some situations. It shouldn't be forgotten that a very competent browser exists on these devices. For a web developer, it's a lovely place to be, writing mobile web apps in HTML5 and CSS3, with the ability of offline storage and advanced transitions blurring the boundary between native apps and browser based alternatives. It may only be a matter of time before the major native APIs can be accessed easily from within the browser. Check out developer.apple.com/iphone for human interface guidelines, getting started videos, sample code and the SDK. Comments: Yea! That is a website worth visiting. The Windows Phone(s) With only 693 apps in Microsoft's store at time of writing, there are large gaps for developers to fill and monetise. Its upcoming app store for Windows Phone 7 devices has been designed to reward apps that deliver a high quality of experience rather than filtering first on price (with a focus on quality, there's also a certification process to getting your app in the marketplace). Comments: Would Windows Mobile 7 be really popular? Haven't heard anything here in Malaysia…yet. There's also an optional Trial API for freemium business models, which enables the developer to program their own conditions for the 'try before you buy' experience. This is most commonly based on either time or experience, but you as the developer have the flexibility to develop your own set of custom rules, which could be quite interesting. In terms of legacy applications, developers should expect to rewrite from the ground up as so much has changed (eg UI best practices and underlying architecture). Developers will need to use either one or a combination of Silverlight, XNA frameworks and the .NET Compact Framework to develop the apps. Windows Phone 7 is being targeted to consumers for now, leaving the enterprise market with 6.5 (which has still got a few updates due), which might still be a viable market for enterprise apps for the next year or so. Although the phone has a release date of late 2010, Microsoft has already announced free development tools (Visual Studio 2010 Express and Expression Blend). To get started, visit developer.windowsphone.com. Also check windowsteamblog.com/blogs/wpdev/ for the latest blog articles. Nokia Nokia's Ovi Store is currently selling 1.5million apps a day, with growth of sales accelerating rapidly as it begins to capitalise on its market share. The latest version features a redesigned user interface and an upgraded rating system, with the new requirement that users must download an app before they can rate or comment on it. There's still lots for Nokia to do, though, such as adding functionality to push app update announcements down to your device à la Apple. At last count, the Ovi store supports 112 devices, including S40, S60 3rd Edition (N95, N73) and S60 5th Edition. Developers have reported that the S60 5th Edition phones drive the majority of the sales (N97, N97 mini, 5800 XpressMusic and 5530 XpressMusic), in part due to the Ovi store app coming embedded on more recent devices. In terms of development choices, you have a few: Web RunTime (WRT), native Symbian, Java and Flash. Very broadly speaking, Java is used if you want to support a large number of devices (including the older ones) and especially for games, Symbian has been used for utilities (due to access to low-level APIs and hardware), Flash for more graphically rich touch apps and WRT for apps such as Facebook. In my view, WRT is the future: it's got access to an increasing number of device APIs, is web standards-based (apps essentially run in a browser without the chrome) and it's relatively simple and quick to create apps using HTML, JavaScript and CSS. Comments: Interesting that Flash could be used develop Symbian apps. To create visual effects in WRT you're going to need to use a JavaScript library such as jQuery, which has a small footprint of under 20kb, making it ideal for working on mobile. There's also a jQuery-based UI library called Guarana UI specifically built for Nokia WRT devices. It makes sense to re-use existing knowledge where possible so when it comes to building WRT apps, web developers out there already have all the skills they need. Check out www.forum.nokia.com/devices and filter by 'Ovi Store' to see a list of all currently supported devices. The web store-front can be accessed at store.ovi.com. RIM BlackBerry App World has been known to be unattractive and buggy but a recent update focuses on improving the efficiency and performance (rather than adding new front-end features). Its app catalogue is far smaller than Android's or the iPhone's. Comments: Huh! That's why BB apps are much fewer that iPhone apps and Android apps. STORE WARS: The potential for opportunity on platforms other than Apple is huge. You can keep an eye on the numbers at distimo.com/report An interesting observation of BlackBerry app usage is that users are more likely to play games than use utility-based apps. This could be due to the rise of consumer market, where teenagers have chosen BlackBerry devices for their ability to text using the very usable QWERTY keyboards and BlackBerry Messenger (BBM). Comments: I personally think that QWERTY is an important Strength of BB phones. Billing at the moment is limited to PayPal, so there's an extra step for users whilst making an app purchase. Network operator billing is apparently planned for later this year. BlackBerry App World has a number of nice little features: you can flag specific customer reviews for Admin review by RIM, which helps to raise the quality of reviews quite substantially; the web storefront features unique URLs for each app; and it's also well integrated to a number of social networks, which helps when making app recommendation to each other. At Mobile World Congress this year, RIM announced that it plans to introduce the WebKit browser into its BlackBerry phones. It's a browser that gets a 100 per cent score on the ACID 3 test and provides a welcome speed boost over the current browsing experience. The BlackBerry Developer Portal contains a lot of information at na.blackberry.com/eng/developers/. Source: http://www.techradar.com/news/phone-and-communications/mobile-phones/mobile-web-design-platform-by-platform-692506