Tag Info

New answers tagged

1

The position of the button depends on the use case and whether or not your toolbar is a global bar or specific to the current view of the app. The left side of the toolbar is typically reserved for actions associated with the current view of the app. In the use case you provided the toolbar is custom to this view of the app (only appears during profile ...


0

If you are developing an iOS app, you should probably use the Picker control. As detailed in Apple's iOS Human Interface Guidelines: "A picker displays a set of values from which a user picks one."


0

Check out this easy seven step tutorial - iPhone UIButton tutorial: Radio Buttons by Mobisoft. It is what I have used for the past couple of years. There is too much code to replicate here, so beware of link death in the future. The steps are below: Create a window based application in Xcode and name it “MIRadioButtonGroup”. Create new ...


1

iOS doesn't have a default radio button. You can either use a third-party plugin to create a custom radio button like this or you can use iOS other default elements: a picker a switch


0

UIPickerView You may want to use a UIPickerView for something like that. https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIPickerView_Class/index.html UITableView There’s plenty of other alternatives that could be good, it really depends on the app’s structure. You’ll notice that lots of the options in Settings use a ...


1

Usually this is done using a table view, which is basically a list of items as well, only with a checkmark instead of a radio button. Sometimes such lists are on a new 'page' in the navigation structure. How this fits in your navigational structure depends on the context.


1

Before you settle on a "Home" call to action review your task flows. If you are more than 2 levels deep and can't "cancel" or "back" out to the home screen you may have too deep a hierarchy. Try and do what you can to flatten so that you can utilize "back" or "cancel". "Home" is a non-standard action in mobile. This is a good opportunity for you to dig a ...


0

The fair share of users use assistiveTouch to not have to go to a hardware key for home and have shortcuts at hand. This is persistent in Android too. The soft touch action on a screen vs the hard press of a hardware key offers completely different feel. Hence many users, me included choose to avoid the hardware key altogether. I have shortcuts to power off ...


1

None. Assistive Touch is built so users can drag it to wherever they like on the screen to not interfere with any app. Even if you chose to make your app "support" it, that change would also cause anyone else using the app without assistive touch to suffer. It's not a function that Apple allows you to scan whether it's active or not. Just don't do it.


0

I would look to implement a similar UI pattern to Apple Mail / Messages. This involves keeping the edit button in the top right hand side of the header, but moving the add new into the footer. This pattern would work if you have just a simple list, however if your list-items are buttons that relate to more information (like in mail) you should consider ...


0

My rule of thumb (which pretty much merges with @DA01's comment), is "Do as much as you can, but don't do more than needed". Maybe, if you wanted to give each platform its different design guidelines to appeal everybody, you could simply make a native app (do as much as you can). They tend to be a better choice for users, rather than accessing a website, ...


1

Forget the "platform wars" and make the application user friendly from a touch perspective. The most important aspect you must try to achieve is to deliver a seamless experience across multiple platforms (make your app look and feel the same as much as you can on all platforms). As I see your application is not a very complicated so that shouldn't be so ...


1

You need to take in consideration the context of the UX. Is this app intended to be used frequently? What age range the average user will be? Whats the final purpose of the app? Icons can be good if there are few elements on your menu. If you have 10+ choices it might not be a good idea to include icons at all, it will be hard to read and will feel ...


-2

It is probably only necessary to include icons for the following reasons (but in no particular order of importance, except maybe for the first one): If someone's life might be in danger or affected if not included, presumably because the icon contains important information that would otherwise not be conveyed. If whoever signs off on the design insists on ...


-1

Icons allow for more meaningful associations. While text items have the potential to look very similar, different images can let the user connect the idea of the image with the idea of the part of the app it navigates to. Using icons with the same meaning as in other apps can further help the user connect them to functionality, for instance, using an icon ...


1

Best Practice: Both should be used. As a social scientist studying people from the United States and their relationships between technology, I can say that in my experience both has always been better. You wrote: This seems redundant if the app can already detect whether the user is new or existing. If you are using non-standard ways to detect if a ...


0

Two key aspects of User Interface Design are the following Make the system intuitive and easy to use for new users Dont slow down expert of familiar users to achieve 1 Considering that a bulk of your traffic most likely will be existing users coming back who already have an account I would Make Log In the primary focus, with a smaller emphasis of sign up ...


2

For social apps, one needs to sign - in to view the happenings in their circles. Who liked the posts, who tagged me or who added me in the circle etc. These are confidential with respect to user's privacy. Hence the app emphasises on Sign In in big and Signup in small ( reason as described @Majo0od) For other purposes like shopping app on other hand, ...


0

The question and response options need to be as simple as possible. Both of your options don't really relay that. They actually complicate what the user is supposed to do. That said, "Done" is the wrong term. It should be "Save" if it's a draft option. That way, when new data is input, users have two options: Save or Cancel. If Cancel, alert that displays ...



Top 50 recent answers are included