Tag Info

New answers tagged

2

How many inputs should be presented on each page? And does this depend on categorisation of inputs? My thought is the grouping of the inputs is more important than the number. For example, the workflow for setting up an iOS device is divided into screens for language, Wi-Fi, location services, etc. The number of inputs for each grouping is less ...


0

The UX here depends on the type of input , user have to provide. Radio button [ 1 ] Check-box [ 1 ] Selection from a drop-down [ 1.5 ] Text inputs small ( 3 or less word in single field ) [ 2 ] Text inputs big ( 4 or more in single field ) [ 2.5 ] Now check your form pages, and try to use the elements in such a way that the sum stays less than 6-8 ...


0

I'll stay away from the "general opinion" on this pattern and try to answer your question on if it is suitable. As pictured in the Yelp app, the items that "pop out" (Check In, Review, Photo) do not seem like sequential steps (if they are, it is not well represented.) It is also my understanding that they do not all need to be completed. Those are "Big" ...


0

I can add that involving the developer in design discussions early would help you identify "brick wall" problems like you are facing early. For example, customizing the navigation bar title or logo can be pretty hard, because it is not a drag and drop, but configuring an "attributed string" to go there. Ask your developers if something will be hard to ...


0

iOS calls them pickers Visually, instead of a drop-down select, it's a spinner of options on small devices. On larger devices (such as an iPad) it may render a more traditional drop-down. Aternatively you can use a table view as miller columns.


0

Why do you need a dropdown on iOS? Dropdowns are incredibly hard to interact with on mobile (iOS or Android). I'd suggest an alternative pattern like a picker or as Paul mentioned, Drill Down Lists (a series of Table views, for multiple selection)


1

iOS makes it much easier to use Drill Downs or "Pickers". These may work depending on what you need the "Dropdown" to do. See: https://developer.apple.com/library/iOS/documentation/userexperience/conceptual/mobilehig/Controls.html#//apple_ref/doc/uid/TP40006556-CH15-SW1


1

You could have a text message containing the pin, and a link to a web page (with a tinyURL so it doesn't look messy). The web page can then contain the full installation guide, including relevant links to the app store.


1

If you think about it, the default iOS guidelines somewhat reflects Jef Raskin's idea about zooming interfaces: As you work your way deeper into the navigation hierarchy transition animations will slide you towards right and if you move back they will slide you to the left. If there is some sort of contextual popover it will always slide in from the ...


0

Although the usage of bottom bars is encouraged, it doesn't seem like you would need them for your application. A 'plus' icon at the top right would serve as an add button. A delete could be implemented by swiping the item to the side. You could replace the more button in the image below to share instead. You could always display a short tutorial to ...


0

I would suggest a Back icon in both scenarios. It will provide a consistent look. Also, I don't feel anything wrong with displaying a Back icon on a screen where you move through Navigation icon.


0

The use of play and pause buttons is linked to audio and video files (i.e. items having a time extension) in users minds. Given the nature of your items, you should rather use a check-box like representation. Your first option looks very appropriate and nice with the round boxes. I will take advantage of the iOS users' habits because it builds upon Apple's ...


2

According to Apple's official iOS Human Interface Guidelines, page 147, "A toolbar always appears at the bottom edge of a screen or view on an iPhone". Therefore, I would recommend following their recommendations.


1

After much soul-searching and many mock-up screenshots, I have to agree with funkylaundry that more than a single button on the same side of a navigation bar looks non-standard in an iOS application. Thus, I decided to stick with Apple's idea of a functionality-bound "Add..." row inside a table view, in a separate "+" section at the bottom of it (which ...


1

It is a bit tricky without the context - a sketch would help, but in general I would not recommend having three buttons in the navigation bar. Partly because it might take up too much space, depending on how you are planning to design the buttons and partly because it would "feel" inconsistent according to the UI guidelines. If I should choose between your ...


0

You mean the iOS 7 menu bar at the bottom of Safari, Mail, Phone, app store, iTunes... Yeah, it' still a thing. A bottom menu bar isn't necessarily a 'best practice'but it is a standard method of giving access to features and functionality within an application.


0

Most modern default mobile browsers support tabs in such a way that would mirror the current workflow of your existing desktop users. I would take another look at developing a mobile site rather then an app. I understand the desire to keep users inside your app, but your users may have the expectation that clicking links will take them to the browser, ...


5

In iOS, they use a "Picker" Check out the documentation. Edit: In context you have a couple options. On iPhone, if the selection is part of a table view, then the picker can appear in the list like so: If the selection item is standalone, then the picker should appear at the bottom of the screen, similar to the keyboard. (I couldn't find a good iOS 7 ...


0

I agree with Steppenwolf above that we need to know more about your use cases and context to make a truly informed recommendation. But I am not sure I agree about hiding the "add new item" feature. From my perspective, you are displaying a list for the user. The user can view that list, and perhaps look at individual line items on the list by touching one. ...



Top 50 recent answers are included