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.
Related
I am building an app where I need to add a TabBarController on a particular screen, Lets assume maybe on second or third screen.
I have gone through several blogs but everyone says UITabBarController can be added as an initial view controller only.
But I want it for some few screens only. How can I accomplish it?
Need guidance!
The answer is "you shouldn't."
From the Human Interface Guidelines:
"In general, use a tab bar to organize information at the app 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.
Don’t use a tab bar to give users controls that act on elements in the current screen or app mode. If you need to provide controls, including a control that displays a modal view, use a toolbar instead (for usage guidelines, see Toolbar). "
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
So I'm just starting developing an iPhone application and I've been told to not use Storyboard. I've read that the alternative is using xib files - can anyone recommend good tutorials using xib files?
Thanks
Storyboards are a relatively new feature to Xcode and Cocoa. Arrived with Xcode 4.2.
For decades (see history), NeXTSTEP/OpenStep/Cocoa programmers have been building individual nib/xib files, loading them with ViewControllers. When the user does something to cause the app to move to the next nib/xib, the current view controller instantiates another view controller that loads its desired nib/xib. That new view controller is then shown on screen.
Storyboards are not magic. They just reduce your programming load a bit, handling that loading and displaying of one view controller from another. They still use the same nib/xib technology underneath, you are just less aware of it. Think of a Storyboard as an automatically managed collection of xibs. A superset of nib/xib, rather than a replacement.
In iOS, we often get the new view controller on the screen by pushing it onto a UINavigationController's stack. The Back button automatically appears to close the current view controller and return to the previous one.
There are pros and cons to Storyboards. For relatively simple apps with a certain flow of views, they can be handy.
But there are reasons to not use them. One reason is if moving from view to view is somewhat arbitrary and not easily laid out in a Storyboard. Another reason is that some views are more easily done programatically on-the-fly rather without defining any nib/xib. Typically such views have only one, or very few, components. UIListView and UIWebView are two examples of single widgets that may fill the screen and can therefore be more conveniently created in code.
Tutorial and books abound. Some show both Storyboard and non-Storyboard ways of doing things. Look for some older iOS 5 or 6 books to see more non-Storyboard ways.
Some new articles and Apple docs may push Storyboard because they are the new fresh thing. I suggest taking a more measured approach. Rather than saying Storyboards are the greatest thing or saying Storyboard are terrible, consider them as yet another tool. Sometimes you may want to use them, sometimes they not fit your needs optimally. Also you can mix them, doing part of your app with a Storyboard, and part without.
You can use storyboards (.storyboard files), use older interface builder (.xib files) or do everything programmatically.
I recommend to use storyboards, makes many things easier and less writing, storyboard is similar to interface builder and my opinion, when creating iOS app, it's better choice than older interface builder. And you still can do many things programmatically, e.g. change properties of objects created in storyboard etc.
So if someone says, don't use storyboards, it's his/her opinion and I suggest that you try it out and make your own opinion about it.
I want to design a page with tab bar on top of it.In some articles of this site.(i missed urls) i found that this is not a common way and the question gets some down rate.
The question is this: whethere having a design like this may cause that apple not approve the application on his store?
Even if it doesn't make Apple reject your app, think of the users not being used to the tab bar being at the top and how that is going to affect how well the app does in the Store.
Every platform has its own design patterns and there is a reason for that. If you stick to them there is a higher chance that the first-time users have an easier time using your app, which results in a higher chance that they keep using it. If they don't know how to use it or find it hard, they will move to another one.
Take a look at the Human Interface Guidelines and apply them. It will do good.
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).
I have developed an app that has work successfully for the last 4 months using iOS 4.3 and under. Since iOS 5 however the tightening of view hierarchy has left my app dead in the water. The app starts with a tab bar as its main view with 5 tabs. When the user selects a row on a tableview on the first tab it pushes onto another tabbar with 3 tabs which gives specific information about that selection. This structure worked fine but obviously broke when testing on iOS 5.
My question is: Is it bad design to utilize 2 or more tab bars in one application? I don't mean "bad design" in the grand scheme of things because that is subjective. I mean in a practical sense where it is specifically forbidden or not recommended.
have a look at this:
iOs Human Interface Guideline
Yes, I think that it's not recommended.
For example:
Use a tab bar to give users access to different perspectives on the same set of data or different subtasks related to the overall function of your app. When you use a tab bar, follow these guidelines:
Don’t use a tab bar to give users controls that act on elements in the current mode or screen. If you need to provide controls for your users, use a toolbar instead (for usage guidelines, see “Toolbar”).
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.