What commonly expected user-visible design idioms need to change from an iPad app to a Mac app for an app, that is to provide basically identical functionality, to seem at least reasonably Mac OS X native?
Some of these changes, commonly expected by users, might include:
Move the Settings button and Info button to Menu selections for Preferences... and About...
Move the Settings view and Info view or popover to their own independent Preferences and About windows instead of being views in the main window.
Add some menu items and menu keys for commonly used buttons (like the forward and back buttons in a browser).
Support arrow keys for scrolling any custom view items.
Support mouse-over for help popups or dynamic menus.
If the app supports "documents", allow more than one document to be open at a time, each in their own windows.
What else? What's the minimum change required for a simple generic 2D game?
Added clarifications:
Note that I do not consider re-coding similar UI classes to NS classes (for instance UIButtons to NSButtons), with similar look, positions and behaviors, to be a significant change. Those changes are pretty much invisible to the user.
The goal is to change as little as possible so that a user who purchased app X to do Y on an iPad might purchase app X to do Y on their Mac, as a Mac application, but with as close to zero learning curve as possible. But it seems that some changes need to be made, or the app would not seem to be a Mac app (for instance, a missing About... menu item would seem a bit strange.)
to provide basically identical
functionality, to seem at least
reasonably Mac OS X native?
You've gone off the rails right there. Consider adding this to your list:
Forget everything you know about how your iPad app works. Step back and consider that a user's interaction with and expectation of a desktop application are very different from those of a tablet. Re-think what you're able to do and what the user will want to do with a faster processor, more power, significantly more available storage, less mobility, much faster text entry, and a different user interface model.
We are in the same boat and faced the same question.
Our conclusion is to start with a "fresh" real application for Mac and make it look similar, i.e. using the same or similar UI components and graphics. The app should be otherwise developed as if there was no iPad version.
First, there will be many users that don't have the iPad version. Those users expect a full-blown Mac application and it doesn't make sense to make it feel iPad in any way.
Second, users coming from the iPad version will feel ripped of if the Mac app is just a pure clone of the iPad version with no added value. Think of the first transitions from iPhone to iPad - paying again for nothing but pure upscales is frustrating and might harm your business in the long run.
Starting out designing a fresh streamlined UI and then think of what you can reuse and make similar. Functionality may differ in one direction or the other. Your model code should work in all places anyway.
Not exactly an answer to your question, but take a look at Chameleon. It's essentially a port of UIKit to the Mac. It was created by The Icon Factory to make it easy for developers to port their iOS apps to the Mac. IIRC Twitterific was ported to the Mac using Chameleon.
So here's what I did to create a Mac app from an iPad app, and have it accepted into the Mac App store.
Ignored the suggestions to completely redesign the app (users reasonably liked the iPad design).
Create a Mac app project and include a branch of all the iOS source code.
Manually recode all the UI elements with their corresponding NS elements. Resize them to Mac UI guideline sizes. Check that they all show up in some reasonable place when the main window is resized. Deleted iPad only delegates, such as rotation handlers, etc. This resulted in completely new view controller code, but almost all the code was just a parallel translation of the other paradigm.
Set the view coordinates to flipped so the Y coordinates won't have to be recalculated for any Core Graphics drawing routines. (The Model and CG drawing code pretty much ported straight over without change, except for scale factors for window size, and such.)
Remove settings and help views from the main window view controller(s). Implement a Preferences window xib and a Help window xib, and put all the settings and pref views and controls there. Add one more top level controller to show/hide the 3 windows.
Add some menu selections with hotkeys for equivalent UIButton actions that a user might want to hit without reaching for the mouse/trackpad.
Add a credits.html file.
Add an outline shape and transparency masks to the icon design, and stuff into an .icns file.
Pad the one window screen shot out to the much larger required size.
Related
I'm gonna create an app that supports both iPhone & iPad. Before proceeding, I just want to know the best practices about both app development.
Here is some points that I know:
Consider that I have a tableview that shows N number of records and say it as PAGE-1. When the user tapping on the cell, it will load the PAGE-2 to show details about the tapped record. This is more common scenario that used in every app.
For iPad, this is not the case. I can show PAGE-1 along with PAGE-2 in the same page.(Consider landscape mode)
So, iPhone's PAGE-1 will be displayed in the left panel of the iPad & iPhone's PAGE-2 will be displayed in the right side panel of the iPad.
Conclusion:
So, I can make a common class for both iPhone & iPad. That will handle the PAGE-1's common functionality to both iPhone & iPad.
The device specific functionality may separated into separate classes for both iPhone and iPad.
Other than that, network related methods, parsers, utility methods, categories, custom controllers can be written commonly for both iPhone & iPad.
The only addon to the iPad is, it should have a controller that will hold and handle PAGE-1 and PAGE-2. This make sures that the PAGE-1 does not hold PAGE-2 and they both are independent like iPhone's PAGE-1 & PAGE-2.
Refer the below attached image that will demonstrate clearly.
Questions:
Is this approach correct?
I really don't know about iPad's "Container" controller. Should I need it? Or is there any other better proposal to group the things effectively?
This may be a basic question, but I need a clarification for better code pratice.
Thanks
It doesn't sound like you need specific page 1 & 2 subclasses, though that depends on exactly what the differences are between the pages on each device. It may be that a collection view suits your needs better so you can simply set the item width and the layout will organise your content into columns where appropriate.
It sounds more like all you need is 2 different container classes for the top level which decides how to display page(s), or more specifically, how many pages to display and where they are on screen. For iPhone that's really simple, for iPad slightly more complex (mainly due to rotation handling).
Note also that if you create a new master-detail project in Xcode and ask it to support iPhone and iPad you will see that a split view controller is used, optionally, for exactly this situation. This bypasses the need for 2 container classes by having the app delegate decide whether to use a 'special' container or not (for iPad).
This is the first time I have really attempted a Project using Firemonkey, with the Target Platform been Android.
I am finding it difficult trying to understand the workflow with the use of views been somewhat trivial, I just can't seem to grasp the concept at the moment.
I have successfully managed to get the Delphi IDE to recognise my device (Xperia Z2) so when building and running the Project I can see the app on my phone (although so far I am not too impressed, long black screens before anything showing and sometimes the app wont show at all, not to mention slow compilation and linking time).
The first problem I ran into is that controls dont appear on the Android device in the correct places. I added Android 5" Phone as a view as that would be the closest thing to my device, the controls on the Form Designer are aligned to how I want them, for simple testing I just dropped a couple of buttons that are centered in the middle of the form horizontally. When running and viewing the app on my phone however, the buttons are wider than the visible area of the phone, I tried the same with other views such as Android 4" Phone and it's the same. The controls appear lined up correctly on the Delphi Form Designer, but when running and viewing them on my phone they are not lined up at all, it feels like I need to guess where the controls should appear making views seem pointless, after all I cannot test on a multitude of devices and therefore if they don't appear on my phone as they do on the Delphi Form Designer what hope do we have? I expected that how the controls appeared in the view window is exactly how it should appear on my Android deivce but this does not seem the case.
The other view related question is, what is the purpose of the Master View? From my vague understanding you need views to design the layout for each Android device, does this mean then for each device view we have to constantly reposition and move controls independantly for each view? What purpose does the master view have, other than from what I can tell you can only delete controls from the master view and from each view use the Revert to Inherited context menu.
It feels like I need to guess where the controls should appear, the device view at Design Time seems rather inaccurate, surely how you look at the device view on the Form Designer is exactly how it should appear on your Android device?
Hi I have been working on a blackberry app and developed about 90% of the app .But my client wants the app should work on blackberry touch also. So I just wanted to know what changes I will need to do to convert the same code to work on blackberry touch .Please help me I am new to Blackberry app development .
Just to confirm, we are talking about a Java application running on BB7 or earlier OS.
The short answer is, it depends.
If you have used standard RIM controls (buttons, ObjectChoiceField etc.) then these will work on the touch screen with no change. If you have used your own controls, for example an image button, then these might not work very well - for example the button might not be big enough to be hit easily with a fat finger.
The other problem is the virtual keyboard, it may appear at points when you do not want it to and not appear when you do. Not a problem on a lot of phones, but remember there are at least 2 non keyboard phones out there, so the Virtual keyboard is the only option for typing.
The best approach is work through each of your screens and try them in the Simulator. Zoom the Simulator so that it looks like the real device. And pretend you are using a finger, don't rely on the mouse because you can position the mouse very accurately.
I would raise new questions about specific Fields that you have problems with, rather than continue this with any issues you find.
I'm refactoring one of my apps from the iPhone to the iPad and this has resulted in the removal of tabs as I've been able to combine functionality onto 1 screen and use popovers to enable the user to select stuff that previously required a new tab.
I'm basically left with 2 tabs now. One (which is best viewed landscape) shows a map of the world with some overlays drawn on it plus an indication of where you are. The second is a data display with a few graphs which is best viewed portrait.
I note what Apple say about requiring apps to run in all orientations on the iPad, and of course I could do this, and keep my 2 tab bar buttons to switch views.
HOWEVER
In this case, there is 1 view that is best suited to landscape view and 1 view that is best suited to portrait view. Would be be appropriate (or even Apple permissible) UX design to drop the tab bar and switch views on an orientation change instead?
From a user perspective, you wouldn't need to be switching back and forth much, you tend to use the landscape view to change location (if you need to) and then work mainly in the portrait view - so I don't think it would be frustrating and dropping the tabs seems to make more sense to me.
What do you think? Any best practice in these situations?
Roger
London
I would say that the best practice is not to restrict the orientation of views.
The central idea here is not to force the user to hold the device a certain way. For example, a lot of people use iPads in a stand or holder and input with a keyboard. Do you want to force your users to stop and physically adjust the device in the holder/stand before they can read the view in the other orientation? Other people simple prefer holding the device one way or the other and lock the orientation (I do that a lot.) Forcing users to change from their preferred device orientation won't win you happy customers.
Apple will not penalize you for a non-standard UI unless it reflects badly on the device itself. As long as the end users can tell it's your apps non-standard behavior, Apple does not care. However, in my experience, end users tend to interpret non-standard interfaces as flawed or broken because they don't understand them.
In this case, if I launch your app for the first time, how am going to know that changing orientation changes to another view altogether and another data set? Nothing in the standard UI teaches me to expect that. I will have to discover it by trial and error. If I have the orientation locked, not even trial or error will help. At that point, I might well conclude that the app is broken.
You could try adding instructions but just the thought that they might be necessary is a red flag for a potentially poor UI.
RIM has released a new Blackberry JDE4.7 after releasing the Blackberry Storm. Does the Blackberry storm support programs created using the previous versions? I've heard there have been a lot of changes in this version compared to the old ones.
And there have been complaints about Storm having many bugs.
Should I use 4.7 or keep using the older JDE?
Thanks.
Depends what you want to do. You'll actually get the rotation for free if you've designed your application's layout to be fairly resolution independent. When the device is rotated your layout and sublayout methods will be called again (or if you've just used built-in fields and managers, it's all automatic).
The big things you'll need the 4.7 JDE to do include:
Responding to specific touch events
(events which result
in e.g. focus going to a Field, or
scrolling, are automatically mapped
to the older APIs)
Detecting device
orientation (though again, layout is
already taken care of - this is more
if you want to use the accelerometer at a low level
to e.g. control a game or something)
Bottom line: backwards compatibility is in general very good, RIM has mapped the new touch interface to older APIs in a sensible way, and since the Storm hasn't quite taken off as the iPhone has (most people believe that the Bold and Curve are still better devices), stick with an older SDK unless you're doing a very Storm-specific application.
The Blackberry Storm should support programs created using the previous versions. Occasionally, though, programs will break, whether because of a bug in the new version or a now-fixed bug in the old version.
There had to be a lot of changes in the 4.7 API to support the Storm's new features.
Really, though, you should develop with the lowest JDE you can get away with, to avoid forcing people who might otherwise try your program to update first. On the other hand, of course, if you want to do a rotating interface, you're going to need the 4.7 JDE and the Storm.
Developing with 4.7 does have some issues if you've made any changes whatsoever to the way input is handled. If you've made any custom fields, you'll need to update them and have a different build for 4.7 vs < 4.7. There are more methods on fields, for example moveFocus(int x, int y).
If there's any text input anywhere, you're going to have to ensure that the virtual keyboard doesn't cover up or remove from view anything you need to be visible.
The autorotation of views is also sometimes an issue if you've done something manually on a screen and you don't want that to change during runtime, in which case there is a way to force the application into a particular orientation.
I've also noticed some issues with the simulator at least, when using GaugeField objects, that is, if you focus on a GaugeField, the focus cannot be removed. Not sure if this issue has since been fixed or what, but at least that's the way it is with my simulator.