Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am writing my first native iPad app and I have a general UI question. I am horrible at user interface design and I'm looking for general guidance on what to use for my layout. Specifically I have a pretty simple master detail app that fits nicely into the generic app template that XCode provides. The app keeps track of inspection dates for equipment. I have a master view where the people enter info about a specific device (make, model, serial number, name, location, point of contact, email, phone, etc). The master view presents just location and name. When they click the master, all the data is displayed in the detail view.
There is an annual inspection required for each device and there is a standard form that is to be filled out. There are 20 items to inspect and I need to collect/display a label (the inspection step), status (pass/fail/whatever) and a comment field for generic text.
So I need to execute an inspection. I could just hand layout 20 uilabels, 20 ON/OFF switches (or 3 position), and 20 UITextViews but that sounds really kludgy. I could put the three items in a custom UITableViewCell but I'm not really comfortable that is the right UI approach either.
How would you map an existing paper process (this starts as a pdf that is printed) to an iPad app? Would you make it look as much like the old paper as possible?
One thing I have learned is that when people have an expectation as to how the information will be presented, then you should conform to that expectation. This is why Apple has interface guidelines for general application development. However, in your case, your guideline should be what your user is already expecting. If that differs from the Apple guidelines, I recommend you lean heavily toward your users' expectations. In this case they may be expecting something along the lines of how the paper form is set up.
Without seeing the original paper form, it's hard to advise you how it can be converted into a Master/Detail format while conforming to their expectations that were set by the paper form.
However, you may find it helpful to augment that by adding views that allow them to focus on individual devices, showing the three fields that you mentioned, with the Master/Detail arrangement. At the same time, they should be able to revert to a view they are familiar with, even if it is only to view the status (rather than to update status).
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 9 years ago.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Improve this question
I want to create a QR-Reader App that is a two page Application. Both are accessible with a tab bar. The first page should be the QR reader part. The second should store the read QR codes in images.
I have a QR-Reader already coded, but i don´t know how to test the iPhone app on my Mac. Is that even possible?
And my second question:
How can i save the result of my scanned codes in the other page?
iOS 7 now has the ability to detect QR codes and other barcodes directly. There is a sample app built right into the Xcode help system that shows how to use it. I'm on a different machine right now so I can't seem to find the app. I'll take a look on my other Mac and post an edit if I can find the sample code.
EDIT: I was mistaken. The sample App is not from Apple, its an open source GitHub project.
The link is:
Sample project to recognize QR codes
Be sure to look at the other postings from this company. They all look very good.
(A link to other projects in the iOS 7 series:
iOS 7 Day By Day
You might want to use that rather than custom QR reader code.)
As to how to test QR code scanning from your Mac, that's going to be a problem. QR scanning involves using the built-in camera, and the simulator does not let you use a Mac camera as an iOS camera. I think you will probably have to do your testing on an actual iOS device.
As to how to "...save the result of my scanned codes in the other page" that depends. Do you want to save a picture of the QR code, or the text information that comes from decoding it?
If you want to save a picture then you would need to code your QR scanner to capture the image as a UIImage, and then pass that to your second view controller. You could do that in the prepareForSegue method that links to your second view controller, assuming you're using storyboards.
The same basic technique would apply if you want to pass the text info from the QR code.
You need to provide a better description of how your app is structured and what you want to do if you want specific help with that, but that sounds like a more generic "how do I pass info from one view controller to another" type question, of which there are hundreds here on SO.
You could make your QR code reader detect if it's the simulator. If it is, it could just give you an image picker, or even just choose a hardcoded test image, and have the QR reader examine that image. However you can't fully test the functionality in the simulator, so you would basically have to test on a real device to make sure it truly works correctly. You would never want to release an app that's only been tested in the simulator anyway.
As for saving the result of the scanned codes, you just need to implement a data model (could be NSMutableArray, for example) that you have access to from both view controllers. When you switch to the second tab, it could check this array each time it is about to appear to update its state. You could probably add this array to both views in your app delegate in the - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions method. Just get your root view controller from the window, which should be your tab bar controller, and get the view controllers from the tab bar.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have been developing solely for iOS for a fair few years now and consider myself to be fairly competent with iOS and Objective C. I would like to further expand my skills and move into the realm of desktop applications for OS X.
Considering the hugely different paradigms for both platforms concerning view controllers and window controllers (to name a few), I am struggling to find a decent starting point to get my feet wet as my knowledge of the iOS SDK is causing confusion when reading through the OS X documentation.
To me, the major classes for iOS would be UIViewController (and it's variants, UINavigationController and UISplitViewController) and UIView. Getting to grips with these makes learning their subclasses (such as UIButton, UITextField) easier to understand whilst also getting something up on the screen to provide visible results.
Currently, it is my understanding that NSViewController is not necessarily the same counterpart to UIViewController. Also, considering that OS X applications can have multiple windows, UIWindowController is completely foreign to me and I do not understand how this would sit within the hierarchy of an application.
Would any seasoned OS X veterans be kind enough to suggest which classes would be the most useful starting point for me to read up on and play around with? What would be helpful to me at this point is to find which area of the SDK I should be focusing my efforts on to fully discern the differences between iOS and OS X.
Edit:
I am not asking for a list of tutorials. I would much prefer for someone to explain either the difference between paradigms for a multiple view controller hierarchy (iOS) to a single window setup of OS X and/or recommend which classes would be best investigated as a starting point to get something on screen such as NSWindow and NSWindowController.
OS X is pretty similar to iOS in the regard that it also follows the MVC concept. However, the whole user experience is different due to the fact that OS X usually works with a larger display and uses mouse and keyboard for the input, so a 1:1 mapping between let's say NSViewController and UIViewController isn't possible. Normally, you have window controller which kinda acts as you would expect your view controller to under iOS. However, instead of transitioning between view controllers, using eg. a UINavigationController, you either present a second window as a modal sheet, or you just open it as panel or similar.
Just look at your average Mac application, most things that under iOS require multiple view controllers and transitions between them, work with just a single window which contains everything. View controllers under OS X are much less useful than under iOS, however, they work great to keep different logic split up in multiple classes, or when you want to display different content within a window and change between that (think of Xcode, the left and right pane are always the same, but the content in the middle, text editor, target editor etc, changes. That would be a place to use multiple view controllers).
My advice would be to not try to iOS'fy a Mac application. While you can keep your underlying logic the same, the presentation of your application should be fundamentally different due to the fact that the whole user experience on OS X is vastly different. If you aren't sure how to work with things like NSWindowController, NSDocument, and everything, the documentation and sample code provided by Apple is in most cases pretty darn good (though, some examples are older)
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 3 years ago.
Improve this question
I'm currently developing an app for a client which makes use of a tabbar, but I'm concerned I may be violating the human interface guidelines.
My app starts with a home viewcontroller which leads to several other viewcontrollers. One of the viewcontrollers has a tabbar. The very first item on the tab bar is a home button. Clicking the button will send the user back to the home viewcontroller. The home view controller does not have a tabbar.
The question of the hour ... is this a violation of the human interface guidelines?
I know the suggested route would be to use a navigation controller and my client may certainly agree to it, but I'm concerned if the current configuration is doable.
Thanks for your advice
Firstly I would say that it violates the HIG in that this is unexpected behaviour to iOS users. In the HIG it states that you should embrace IOS UI Paradigms, which means that you should not mimic built-in apps, but follow the design patterns of those apps. What you are trying to achieve is something that the user does not expect (as this is not normal behaviour) and therefore is not really the right way to go.
It also might violate the HIG in:
In general, use a tab bar to organize information at the application level. A tab bar is well suited for use in the main app view because it's a good way to flatten your information hierarchy and provide access to several peer information categories or modes at one time.
Your application puts a tab bar inside the app and not at the application level. But as the text says, you should generally adhere to this.
However I do not think it is particularly good UI to do this, as it is confusing to the user. At one moment there is a tab bar and then when pressing a tab the tab bar is gone. I would definitely rethink the UI problem you have and use another mechanism for it (like UINavigationController) or try to use the tab bar differently by using it at the application level.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I would like to add an integrated welcome tutorial to my app that just highlights a few buttons and educate the user what some features are. I remember seeing this I the google app. Is there a tutorial on how this is done or is it simply a video file that plays to look like the app..
Thanks
I'd agree with James, that rather than a video, a user controlled help/tutorial is better. Let the user control the speed with which the online help progresses and/or is dismissed. Even better, I like integrating the help into the app itself, e.g. show the user help/tips when they first visits a particular screen for the first time or where they tap a little question mark button for the tips/help to pop up.
I have to confess, though, that I've shifted my thinking regarding integrated help/tips in an app and now tend to consider it a design failure. If the app is not intuitive and discoverable, then I've failed as a designer. I can easily imagine apps of sufficient complexity where online help is necessary, but before you invest time in help/tips, I'd urge you to consider a user interface redesign that obviates the need for it. Some of the best apps out there are intuitive and don't have any help screens at all.
If you to do online help, though, the common solutions are:
Present first time users a series of full screen help pages that they can tap through one at a time at their own pace, with heavy emphasis on visual elements rather than text description. This is the closest to your original question. You could even animate the appearance of the visual elements on this help screen if you want (to give it a bit of a video-like feel), but let the user progress to the next screen (if you need multiple screens) at their own pace. (You can do this effect by having your main view controller determine if this is the first time the user's used the app, if so, use pushViewController/presentViewController to go to the help screen (and again if there are additional help screens), and then when done, pop/dismiss back to the main view controller.)
The first time a user enters a particular screen, either have little pop up help/tips that show up. Optionally you could overlay this help on top of the screen itself, dimming the actual screen behind it, so the user knows that they're in a different "help mode", with little pointers or other visual indicator linking your help to certain design features on the screen behind the help screen. (You can do this by having the relevant screens keep track of whether they've been visited before, and if so, overlay the help tips, which will be dismissed when the user taps anywhere on the screen.)
Put a help button which will cause user help tips to popup on the screen. A good example of this approach is Apple's iPhoto for iPad, which includes not only hints/tips show up next to the various controls right there on the screen, but also with links to more substantive descriptions where needed.
To wrap up, I'd suggest (a) redesign your app so help is not necessary; but if you can't (b) pick an app that does a particularly elegant presentation of online help and see if you can reproduce that effect yourself. I don't know of any good tutorials on how to do this, but frankly none of this is terribly complicated, so you really shouldn't have much of a problem reproducing the effect you want. And if you do hit a road block, come back to SO with the specific question on how to do a particular visual effect, and I'm sure we'd be happy to help.
You could play a video that looks like the app, but that's messy and looks silly if they want to stop it as it is clearly a video. A much better way would be to create your own custom overlay views which point to different buttons and give them info. With this implementation, the user is able to "stop" the tutorial whenever they want instead of having to view a video for 40 seconds with no easy way out; also you could add an option to see the tutorial again much more easily this way.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I've been writing iOS apps for a while now and gradually went from doing the UI entirely programmatically to using the Interface Builder intensively. I'm now thinking about using the new Storyboarding feature for some of my new projects, but I don't have enough experience or knowledge with it to calculate the advantages and disadvantages of doing so.
Can anybody give some examples or information about when using Storyboarding payed off and when it was a waste of time?
Advantages of Storyboarding
It's cool - suave way to design interfaces
Use of StoryBoardSegues to identify navigation/modal relationships
If your app supports multiple devices, good way to organize different views (by storyboard file rather than naming, etc)
Nice for prototyping
Prototype UITableViewCell can save time
Disadvantages of Storyboarding
It's a runtime feature, so I believe it is only available in iOS 5
StoryBoardSegues are kind of rigid in my experience and you may make use of prepareForSegue a lot
Like IB, not very friendly with other display engines and toolkits
Makes it hard to share designs for a single view or set of views - you have to send all or nothing
These seem kind of superficial, I guess I haven't given it much thought... At first I was gung-ho about story boards, but now I've reverted to IB or even just programatic view configuration... The more I use them, the less I like them, and the more they feel like a gimmick/waste of time.
Edit
I wrote this answer a few years ago. I have left it the same as before for posterity, although some points are likely no longer relevant (ie the fact that it requires iOS 5+).
After some time, my opinion hasn't changed on storyboards. As others have mentioned, they're okay if you are working solo on an app with few views to manage, but they become a real pain with source control & collaboration. In addition, I prefer one-file-one-object, and storyboards obviously bundle stuff together (as does IB, but to a lesser extent).
If I were writing an app meant to be maintained for any serious length of time, I would go with programmatic view configuration over IB, but definitely IB over storyboards.
Another disadvantage with Storyboarding not mentioned is that merges can be very difficult if not impossible if there are conflicts.
Update: It also occurred to me that it puts logic in two places. If your segue is not doing the right thing it might be because of an error in prepareForSegue or it might be because you named your segue incorrectly. Doing things programmatically is, in the end, not that hard.
At the latest WWDC (2013) Apple Devs strongly recommend using storyboard and built in IB stuff to do most of your code for you instead of writing it by hand because you are much more likely to avoid deprecation and take advantage of feature updates via automated conversions.
The lone disadvantage is the difficulty in allowing git collaboration on storyboards, as there will be conflicts on virtually every commit.
If you are a solo programmer, you should always be using storyboards.
I have a similar background to you - I started with mostly building my iOS UI programmatically since IB was not really user-friendly, but lately decided to use IB more and more, since it is better for designing the UI and works fine for standard-elements.
With the new Xcode I switched to Storyboard, since they provide a full view of the application. It is possible to generate the complete UI (with all views) in a single File, which can be used for prototyping and which I can view my colleagues before writing the first code line. It is far better and easier than designing with photoshop or similar tools.
However if you use a lot of your own UI elements/controls or something using a different "engine" (cocos2d, OpenGL, etc.) it is usually better to generate the UI programmatically, since these "engines" are not really integrated with IB/Storyboards.
I have learn the storyboarding by following the tutorials from the raywenderlich's website and there is a lot of stuff about the storyboard.
Here is the link to site: http://www.raywenderlich.com/5138/beginning-storyboards-in-ios-5-part-1
Advantages of storyboard:
1) Before you start developing app you can see all the screens of the app.
2) You can visually see the relationship between each screen.
3) It can help to reduce the amount of the code specially in case of UITableView you can use prototype cells and static cells to design your TableView in storyboard.
4) In case if you have to work on someone else code you can get the better understanding of the flow of the app by viewing storyboard in short time.
5) You can setup the user interface for iPhone 4 and iPhone 5 by applying the retina form factor from storyboard, without running the app again and again.
6) If you are doing client based work then some clients want to see the prototype of the app before start developing it, here storyboard helps you a lot.
Disadvantages of storyboard:
1) For storyboard you will need a big screen specially in case of iPad.
2) I also experience a difficulty while copying views from other apps to storyboard.
3) I also experience problems in storyboard when multiple developers work on the same project by using git repository.
By reading and understanding the advantages and disadvantages you can judge your self when to use storyboard.
One Word (DON'T)
One of the biggest disadvantages of storyboard aside from the git conflicts that make it impossible for two or more persons to work on it. but also if the project went so big and you have +40 screens , if you insane enough to move anything just one pixel in any view controller you have in the storyboard, you'll have a very huge compilation time, that you can build your app and make it run in more than 5 minutes, and of course don't let me start with archiving to give some one adhoc of the app .
after this painful experience I totally fell back to the oldy goldy great xib files and deleted the storyboard file in a huge fire celeberation .