We have prepared a brief compilation for our clients to raise awareness regarding the new possibilities and challenges that are brought by emerging iPad platform and new iPhone development SDK which is already available. So publishing this list here with a bit of delay
Also please feel free to add to the list.
- there are certain technology/interface improvements/changes which need to be taken into account when planning new / porting existing projects for iPad
- it is worthwhile to start the development now at least using the simulator, to be prepared to launch your app in March when device starts shipping - this should help to win a bigger market share presumably
- Injoit has learned the new SDK and is ready to develop 100% iPad compatible apps from this very moment, so contact us for iPad software development
In most cases the iPad version of existing iPod/iPhone app would require new images which you may want to start preparing now and the options are:
- full size images prepared for iPad’s full screen of 1024×768
- bigger images but not full size and use the rest of screen for additional interface elements
We tried a few iPhone apps on the iPad, as well, and they worked just fine. You have two choices when running iPhone apps on the iPad: first, you can run them “actual size”, as a pixel-for-pixel match for the iPhone’s screen. In this mode, the iPad screen goes black, and the app runs in the centre of the screen, surrounded by the image of a bezel that shows you where the iPhone screen border would be. To be honest, it’s a really weird experience, and it’s kind of a pain to have to reach all the way to the centre of the iPad in order to tap.
If you prefer, you can tap the small 2X button in the bottom-right corner of the screen, at which point the iPad will double the size of the app. This scale-up basically doubles every pixel on the screen, so what you end up with is a somewhat chunky, blocky version of the iPhone app. And at iPad sizes, all the interface elements on iPhone apps are enormous. You start to feel like you actually are using an oversized novelty iPhone.
Neither approach is likely to be good for many uses other than gaming. Developers of iPhone apps will want to download that new software-development kit and get those iPad versions ready for the product’s release in late March.
http://features.techworld.com/personal-tech/3211450/hands-on-with-the-apple-ipad/
We have also tried the 1:1 and 2X modes in simulator and it’s really not very usable at the moment:
1:1 mode just displays your app in the middle of screen, same iPhone virtual keyboard (not so usable on iPad), no device orientation detection. 2X mode: graphics looks really pixelated as in old games.
So it really looks like new larger images should be prepared for those applications that are supposed to be 100% iPad compatible.
Status bar - impossible to hide - looks like in iPad versions we won’t be able to hide the status bar (carrier, signal, time).
New UI elements - new SDK introduces new elements allowing to build better user interfaces:
- ToolbarSearch - native SDK supported search toolbar
- Popover views - basically they allow to display pop-up windows which allows you to build interfaces which are able to show more data without user having to change the screens, for example one main view with a list of messages and one sub view with a message opened.
Popovers and Split Views
Across the iPad system, Apple has introduced a new UI element, which they’re calling popovers. It’s a perfect name. Popovers are like a cross between dialog boxes, drop-down menus, and inspector palettes. One example is the list of mailboxes in Mail when in vertical mode. When iPad Mail is in horizontal mode, you see a split view with two panels at once: accounts/mailboxes/messages on the left, and an always-present message detail panel on the right. When iPad Mail is in vertical mode, you just get one panel, but you can tap a button at the top left to show a popover of messages in the current mailbox.
They’re very well thought-out. As their name implies, they appear on-screen “over” existing views. But you can’t drag them around. They aren’t windows. They’re in a fixed position, always with an arrow pointing to the button or other control (like an event in Calendar) that the user tapped to open the popover. To close a popover, you just tap away from it — tapping anywhere other than within the popover closes it. Perhaps conceptually, it’s more like tapping the view under the popover to make it disappear. So popovers don’t have an “X” button in the top-left corner, or anything explicitly labeled “Close” or “Cancel” or “Done”. You just tap away. This is one of those aspects of the iPad UI that you just have to feel to get. It feels perfect.
According to the iPad Human Interface Guidelines (which, alas, are only available to registered iPhone SDK developers), there is a modal variant:
Popovers and modal views are similar, in the sense that people typically can’t interact with the main view while a popover or modal view is open. But a modal view is always modal, whereas a popover can be used in two different ways:
- Modal, in which case the popover dims the screen area around it and requires an explicit dismissal. This behavior is very similar to that of a modal view, but a popover’s appearance tends to give the experience a lighter weight.
- Non-modal, in which case the popover does not dim the screen area around it and people can tap outside its bounds to dismiss it. This behavior makes a non-modal popover seem like another view in the application, not a separate state.
I don’t recall encountering the modal variety during my all-too-brief iPad spelunking expedition; the non-modal ones seem far more prevalent.
The overall effect of popovers is that you do far less view switching in an iPad app than you do an iPhone app. Things that slide an entirely new full-screen view on screen on the iPhone — like say going back from a message to a list of messages, or displaying your Safari bookmarks, or showing the details of a calendar event — on the iPad instead appear as popovers on a main view.
So imagine, say, an iPad Twitter client in horizontal mode. You could have a split view with a list of tweets running down the left. On the right, you could have a web view for reading web pages linked from tweets. Rather than sliding over and replacing the tweet list, they could exist side-by-side. And then a popover could provide an interface for switching between different accounts.
http://features.techworld.com/personal-tech/3211450/hands-on-with-the-apple-ipad/
New interface / usage behavior:
It is necessary to understand when designing UIs that iPad users will be using it an a way different to iPod / iPhone:
- because of its size, they won’t be able to hold it in two hands and use both hands’ fingers at the same time for interaction
- most likely users will have the device on their lap or on the table or placed on special iPad case (look under Accessories)
- many users will have the hardware keyboard and possibly other devices wirelessly attached to their device
6 Default screens:
Default screens are custom static images that we can show to users during app loading into memory and starting (splash image with app name / company info usually). It is now introduced a possibility to have 6 different default screens for different device orientation:
|
Default-PortraitUpsideDown.png
|
Specifies an upside-down portrait version of the launch image. The height of this image should be 1024 pixels and the width should be 768. This file takes precedence over the
Default-Portrait.png
image file for this specific orientation. |
|
Default-LandscapeLeft.png
|
Specifies a left-oriented landscape version of the launch image. The height of this image should be 768 pixels and the width should be 1024. This file takes precedence over the
Default-Landscape.png
image file for this specific orientation. |
|
Default-LandscapeRight.png
|
Specifies a right-oriented landscape version of the launch image. The height of this image should be 768 pixels and the width should be 1024. This file takes precedence over the
Default-Landscape.png
image file for this specific orientation. |
|
Default-Portrait.png
|
Specifies the generic portrait version of the launch image. The height of this image should be 1024 pixels and the width should be 768. This image is used for right side-up portrait orientations and takes precedence over the
Default.png
image file. If a Default-PortraitUpsideDown.png
image file is not specified, this file is also used for upside-down portrait orientations as well. |
|
Default-Landscape.png
|
Specifies the generic landscape version of the launch image. The height of this image should be 768 pixels and the width should be 1024. If a
Default-LandscapeLet.png
or Default-LandscapeRight.png
image file is not specified, this image is used instead. This image takes precedence over the Default.png
image file. |
|
Default.png
|
Specifies the default portrait launch image. This image is used if a more specific image is not available.
It is recommended that you do not use this launch image for your iPad applications but that you use the more specific launch images instead. That way, you can continue to use this image file for the version of your application that runs on iPhone and iPod touch devices. |
leave a reply