(Duplicate of this question, but I figured I could try again, since that one wasn't answered...)
The UISearchBar on the iPhone has an option showsSearchResultsButton. When you turn it on, it shows a button with horizontal lines inside the search bar, and you can implement a callback that will be called when the user presses it.
The thing is, I can't find a single place on the Internet where it says what the intended purpose of this button is. I know I could make it do anything, but I'd like to know what it's actually for. Should it show a history of searches, or all items without filtering, or what?
It's simply to show search results when tapped.
Where Apple uses this is in their iPad App Store application. If you go to the Categories tab you'll see various app categories. Search for an item, you'll get a list of results, and when you press "Done" you are shown the categories screen again. Your previous search term is still listed in the search field, but now the Search Results Button appears in the field. After tapping this, a UIPopOver is displayed, showing a text list of the results from your last search.
Related
I've seen how iphone users delete from lists - its generally a swipe action and then shows some minus/remove button.
I realize that it is counterproductive to implement iphone things on android because android users don't know this stuff.
I don't want to do that, I just don't know of a better/intuitive way to delete from a listview.
I've previously opted for doing "longclicks" on listview items, which will show an alertdialog asking if you want to delete or do other things, but this is never an obvious thing to do.
I've seen delete buttons that are shown in each view, but that messes with the layout of the listview, in a way that wasnt' considered in the wireframes.
What is a good intuitive way to allow the user to remove items from listviews on android?
Here's my two cents before I pitch my answer. Any one who has an android phone is going to know or eventually find out that longclicks often lead to another menu. Yes, it's not immediately obvious but they are going to figure it out just as iphone users have figured out the swipe action is to delete.
If you really want a fool proof way for a user to know how to delete, I would implement checkBoxes. (More on check boxes here)If the user checks the item, bring up a "soft menu" at the bottom that has a bunch of options normally associated with long clicks.
If you look at the gmail application and check a box, you'll see what I mean when I say "soft menu".
Another way you could go would be to implement check box, then have "menu options." Every android user should be able to see and figure out the menu button on their device, all devices have them. Make one of the menu options delete and you're all set.
http://developer.android.com/guide/practices/ui_guidelines/menu_design.html#options_menu
I agree that long click is horrible, but it is the standard on Android; people are more likely to be able to discover using this than any alternative gesture.
Also, put in a delete menu item on the Activity you get to after selecting something from the ListView.
In my view you should add checkbox to your list view and give a separate button for deleting items from list I mean to say that add a delete button in the layout in which your list view is also present and when user checks the item which he/she wants to delete and click on the delete button,the item which is checked by the user gets remove from list.
After the right '+' button is pressed the item in that view is added to favorites and an UIAlertView is shown on screen saying "Added to Favorites". After it is added to favorites I make the '+' button disappear so the same item doesn't get added again to favorites. I am not sure if this ok with Apple's Human Interface Guidelines instead should the '+' remain there and if pressed again say "This item is already in favorites"?
Any help will be appreciated! Thanks
I wouldn't use the AlertView for this. By showing the alert, you force the user to confirm reading some confirmation message and taking action (by pressing the OK button). It is a good idea to provide feedback that the favorite was successfully added, but this should not be an intrusive alert. Perhaps you can use other design patterns for favorites, such as a star that lights up when pressed to indicate that the item is listed as a favorite, or perhaps an animation effect that 'moves' the selected item to a visible 'favorites' category.
The Human Interface Guidelines have this to say about the Alert view (in relation to your question):
Avoid creating unnecessary alerts.
These alerts are usually unnecessary
if they:
Merely increase the visibility of some
information, especially information
that is related to the standard
functioning of your application.
Instead, you should design an
eye-catching way to display the
information that harmonizes with your
app’s style.
Why not have two states for the button ? A "selected" state (for example negative contrast) showing the item is in favorites, and a "normal" state indicating it can be taped.
This way you can add/remove from favorite using the same button, and in a less obstructive way than with a UIAlertView.
I also suggest you use a ★ instead of a +
I have a UITableViewController which lets the user drill down into different records. On the second level/view, the user can add and edit new records. But, I am not sure what to do, since the back button is on the top left, and I need to put the "Add" button on the top right, so there is no room (keeping to HIG) for the edit button, which would normally go where the back button is. (I am using a tab bar, so can't put it at the bottom.)
Do you think that it is logical, to expect users to know to swipe to delete a record? Or, do I need to have an edit button? If I DO need an edit button, where should I put it if I am following HIG?
Swipe to delete is a firmly established iphone UI interaction, so yes I would be comfortable expecting users to know that. We've run into the same problem a few times, and yeah you only get two nav bar buttons so you've got to make a choice. If you're already using the bottom for a tab bar, I don't see many other options.
I have a similar situation in my app.
When the user taps the edit button I show an extra table cell at the end of my table which lets them add a new record. Not sure if that's feasible in your case.
Maybe add it at the beginning, or insert a button just above the UITableView? You could then also label the button "Add/Edit" to make it clear that that's how they can add new records, although I haven't done that.
Another option would be to have that extra button or table cell always visible.
I'd like to implement a search into my app. I'm planning to use a left swipe, like the Spotlight search. Would that violate anything with Apple?
My app is tableview based. The user can drill down a few levels before reaching a detail view. I'm considering two options for implementing the search:
1.) From the search results, I display lower level topics. Meaning, once a user clicks a search result, they will open a detail view. Should I back the user out of the search, navigate the UI down to the detail view...or just show the detail view (option #2)?
2.) If I just popup the detail view, it will be out of context. Once finished with the detail view, the user will not be able to navigate backwards to the top level. They will basically already be there (search results). Or is that how it should be - just put the user back on the search results view?
I don't know if it'd get rejected, but it sounds weird as I've never seen it in an app before. Why not just put the search bar in the first row of the table as in the iPod app?
You probably could also mimic the iPod behavior when "backing out" of Search results.
But yeah, this isn't really programming related.
How would one implement a search field like the one used on the iPhone Mail application. When you attempt to search it shows up 4 buttons under the search bar with the fields you can search. The search bar actually moves up to cover the navigation bar and exposes those buttons.
I'd like to do something similar in my application where you can specify what exactly you are searching for. I think the mail search is a little difference since it also has a cancel button?
How would you accomplish this and what components would you use?
Do you mean the so called ScopeBar? Use a SearchDisplayController and there you could set the scopes of the ScopeBar.
Or drag a normal UISearchBar on your view, and the with the inspector you are able to set the scope items.