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.
Related
I'm currently trying to create a small notepad app, and i'm in need of help. I am using a Tabbed View Application. Say we had a view that has two text fields for Name and short description, and then a button beneath saying "Create Note".
How can I make this button change the view to my editor/notepad view that does not have the tabs at the bottom?
Thanks
If you are using storyboards, which I assume that you are, what you will want to use are triggered movements called segues.
To create one, right-click on the button and drag the line that appears to the second view, and then release.
It should look like this:
Then, when you release, a gray box will appear, with a list of segues. You can find out what each one does online, and as you get more advanced you can develop custom ones.
However, use Modal as a basic one to begin with.
Hope this helps,
Will.
PS. In the future, try and make your questions more specific, and do some research before you ask a question. It's important that you gain a good reputation on Stack Overflow if you want your questions answered properly.
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.
Apple's "human interface guidelines" is clear about which side (left or right) you should place certain tool-bar buttons: CANCEL (left).... and.... DONE (right).
Which side (left or right) should other buttons go on?
ADD and DONE
EDIT and SAVE
EDIT and ADD
SORT and SEARCH
SORT DIRECTION and SORT FIELD
CANCEL ADD
This is by no means an answer, just an opinion.. i wouldve commented it but for some reason it wont let me..
From what ive gathered, any thing that take you to a previous state: i.e cancel, back, etc would be on the left side..
anything that take you to a forward state, i.e save, add, done, etc would be on the right side.. now depending on the view, whether a button belongs on the left or right might vary..
for example:
consider a ui table view that contains data.. at the top of this view i dont thing id have anything on the top LEFT (unless this table view is NOT the primary view, in which case i probably would have some sort of back button)
on the top RIGHT i would probably have and edit button that lets me delete something from this table view
upon selecting a specific line i would be directed to another view specific to that piece of data.. at the top LEFT i would have a back button and on the top RIGHT i may have another button with more specific functions that were not available on the previous tableview..
this is by no means an answer just an idea to maybe help clarify your situation..
if you look at the hierarchy of your application, you'l often determine the bast place to provide a certain function and whether it actually belongs there
hope it helps
I have an application I'm working on, and I need the user to be able to add new "Shows", "Movements" and "Dots." These are all represented by classes. At the root of the application, all the shows are shown, the user can click on the show, see the movement in that show, then tap on a movement and see the dots in the movement. It works beautifully.
Now, I need the user to be able to add and edit these instances of these classes. The way I am thinking this will work is when the user clicks on the "Add Show" button (Or the "Add Movement", etc) a new view will be pushed onto the Navigation Controller. This works. When the button is pressed, a new instance of the show class is created, and passed to the new view controller. This also works. If the user wants to edit the show, then they will hit the edit button for the row, and the instance of the class (which already exists) will be passed to new view controller, and the user will be able to edit it (It should use the same view controller for adding and editing)
My question is, in the examples I have seen, it is always really dirty to create the editing view. The edit view is a table view with each row having some sort of control. Usually it is a UITextField, but it may be a slider, and it may be one where another view is popped, and the user needs to check one value. (This is similar to the address book application when adding and editing a contact)
Is there any way that is cleaner than just manually going in and creating a bunch of arrays to hold what custom table view cells need to be at what row? This gets very messy, very fast. I can do it this way, I just was wondering if there is a better, possibly faster way.
To my knowledge there's no structural solution to solve this. I'm afraid managing the cells with child UITextField or other controls yourself is the only method. This indeed gets dirty and painful very fast, I certainly feel your pain.
Although it doesn't exist, it would be very convenient if Apple added out of the box editing cells to the SDK, similar to the different normal cell styles. I haven't come across an open source project that addresses this issue, but it might exist.
If you do find a better/cleaner method to handle these situations, be sure to ping back.
as far as i know, editing mode is the only way to make the changes you describe (if i understood correctly). I agree that it doesn't seem like the most elegant approach.
http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/TableView_iPhone/ManageInsertDeleteRow/ManageInsertDeleteRow.html#//apple_ref/doc/uid/TP40007451-CH10-SW19
How would one implement a wizard style interface for the iPhone?
For instance I have a form that I would like to break down into 5
different pages or views instead of putting all the information to fill out
into one page or view.
This interface must have the ability to go prev or next in case they want
to change something on page 2 when they are on page 4.
This interface must have the ability to go to page 3 directly and still be
able to go prev and next. Seems like using UINavigationController wouldn't
work here since views 1 and 2 are not on the stack so prev would not work.
Update: Check out the "gas cubby" application. It has what I'm looking for. UITableView presents the items you can fill out. Selecting a row takes you to the detail view to enter data and prev and next to fill in other information.
UINavigationController seems like the obvious solution. It gives you nice, familiar page transitions for free, and if you need to jump to a specific page you can just set up your navigation stack without using the transition animations.
I would say use a Navigation Controller. On the 1st view, show the 5 options in a Table View. The user selects a row, and then the corresponding section is pushed onto the stack as a new UIViewController. So, if they are in view #3 and want to go back to view #1 (to be honest, I would recommend rethinking whether or not somebody in the real world will actually want to do this), they hit "back" and then select view #1 from the table.
I can't think of a better way to do this because you won't have room to do something like breadcrumbing, which Apple would recommend against anyway. You could use a tab bar but that is more like options then some sort of wizard workflow.
If you really want them to be able to skip around the process, the combination of a UINavigation controller with a UISegmentedControl to jump to sections would do what you want. You can either embed the segmented control in the nav bar or place it just below the nav bar (which seems more like what you want since you have five sections).
If the Segmented control is not quite to your taste just put up any set of five buttons to change sections and make them visually appealing.
A "wizard" UI is typically used when you have a relatively small number of steps where one step depends on the previous, at least at some steps, the results or presentation depends on previous steps. This is like a navigation tree that usually results in the use of the navigation controller, but with only one potential branch at each each step. My feeling is that the navigation UI would be perfect, but with one exception; A button on the right hand side of the navigation bar that is the left to right mirror image of the "back" button that is usually found in the left part of the navigation button. That button would navigate to the the next step, and at each step the page presented would allow the user to fill in the information for that step. The only problem then is navigating to a step not the next or previous, and this could be corrected with a custom button that includes a drop-down list of the steps in the process. And this would fit nicely with the rest of the iPhone UI, which Gas Cubby's wizard UI (as good as it is) does not.