What is the difference between the "label" and "hint" property if I'm trying to make a control accessible? Moreover, what do the "traits" do? Are all of these properties spoken by VoiceOver if I fill them in?
This is all described in Apple's Accessibility Programming Guide.
But here's my random take on your question:
I would try to think of the accessibility properties in terms of how a sighted person would use your app.
They would look at the display and see stuff.
A button might have a short title, such as "Stop". A slider might have a nearby label saying "Volume". That's the type of stuff that a sight impaired person might like to find in the control's label property.
A sighted person would recognize a standard button or slider by it's shape and decoration. But a vision impaired person might have no clue about that shape. So that's the type of information that should go in the traits property for someone who can't see whether something looks like a button. "button".
If you had a short help document for your app, it might show a picture of your app, with arrows pointing at the elements, and a small bubble caption on each of those arrows saying stuff like "Stops playing annoying fart sounds" and "Changes fart loudness from silent to ear shatteringly gross". These would be your helpful "hints".
Traits and hints are optional, just as some apps in the App store have no help documentation, and weird unrecognizably shaped buttons. But every visible or active control element should have a label.
'zat help?
Related
I realized that people have been implementing their own UIButton derivates to create radio buttons on iPhone, as this blog post shows.
This question's accepted answer states you can use Picker Views or Grouped Table views with a check mark, but it seems like a poor man's solution to me. Hence, my question: what is Apple's likely reasoning?
Are radio buttons a bad UI solution for touch interfaces?
Is it so rarely used that it's not worth cluttering IB with?
Another reason I don't quite see, maybe? I believe it's important to find this out, because if Apple thinks radio buttons suck, I'd rather not use them, and rethink my interface whenever I "believe" I should use one...
Radio buttons are a bad UI solution if they are poorly implemented. i.e. too small to reliably work with touches - which is why it's usually better to either use a toolbar or segmented control of options or a tableview of options.
Actually seeing it with a different angle, Apple has neither provided Radio buttons or even Check Box and maybe not because they think that it is a bad UI solution. But instead they've empowered the UIButton control very much that we can configure it as a Radio button or a check box or a switch or anything else with few lines of code.
A UIButton object can be configured and designed in various ways. We've seen various apps using the UIButton very creatively. I personally like the versatility of UIButton rather than Apple directly providing the radio button and Check box to drag and drop it in the interface.
If you implement UITextInput on your custom view and - say - use CoreText to render the text you get to a point where you can draw your own cursor and selection/marking and have that fully working with the hardware keyboard. If you switch to Japanese input then you see the marking, but there's something curious: if you long press into the marking you get the rectangular system loupe and selection handling without having to deal with the touches yourself.
What I don't get why we would have to implement our own touch handling for the selection, draw our own loupes etc. It's working for marking! So what do I have to do to get the standard gesture recognizers added to my custom view as well?
the one sample on the dev site only has a comment about that user selection would be outside the scope of the sample. Which would indicate that indeed you have to do it yourself.
I don't think that it is in Apple's interest that all developers doing their own Rich Text editor class keep doing their own selection handling code, let alone custom drawing of the round and rectangular loupes?! Granted you can try to reverse engineer it such that it comes really close, but that might give users a strange feeling if the selection mechanics differ ever so slightly.
I found that developers are split in two groups:
1) rapes UIWebView with extensive JavaScript code to make it into an editor
2) painstakingly implements the selection mechanics and loupe drawing themselves
So what is the solution here? Keep submitting Radars until Apple adds this missing piece? Or is this actually already existing (as claimed by the aforementioned engineer I met) and we are just too stupid to find how to make use of it, instead resorting to doing everything (but marked text) manually?
Even the smart guys at Omnifocus seem to think that the manual approach is the only one working. This makes me sad, you get such a great protocol, but if you implement it you find it severely crippled. Maybe even intentionally?
Unfortunately the answer to my question is: YES. If you want to get selection mechanics on a cusrom view you have to program it yourself.
As of iOS 6 you can subclass UITextView and draw the text yourself. According to an Apple engineer this should provide the system selection for you.
I am pretty new to iPhone development and currently working on an application which includes a view that performs a simple numerical calculation. In particular, the user enters 3 or 4 values into text fields and the view displays the result. Something along the lines of http://www.moneychimp.com/calculator/compound_interest_calculator.htm
What is the nicest way to achieve this? I am currently using simple UITextFields and a UILabel for the result but it doesn't look nice or "native-like". What UI object would be best to use?
Thank you!
It's entirely up to you. You're using the right classes for actual input- it comes down to how you choose to style those classes. I'd suggest looking at the documentation for UIView and CALayer (youView.layer, and include QuartzCore framework in your project).
A good start might be to choose a color scheme, a background for your app, and the look and feel you're shooting for- this will inform your styling. Try looking for apps that you think are elegant and attractive, and boil down what they do and what you like about them.
I'd say;
use a grouped table style (with the white tables with round corners on a blueish striped background)
embed settings values directly in the cell (aligned to the right) as much as possible
you can show a relevant keyboard (text, numbers) or picker view to let the user pick values, directly when they tap the cell. Use sliders and switches where relevant.
You may want to take a look at http://www.inappsettingskit.com/, we are currently investigating it for the same purpose and it seems to do the job
You can use either a UISlider or a UIPickerView if some of your values have limits.
You can use UISwitch for toggles.
You can also switch the default keyboard for your textfields to be numeric.
Other than that you seem to be on the right track.
Also, sometimes putting a view inside a scrollview makes things seem cooler even if its only one page. The auto bounce on scrollviews is kind of cool.
When I've learned that I have to write some code to make the iphone keyboard go away. I was quite surprised. I was surprised even more when it become apperent that it is just the top of the iceberg.
What are the expected UI behaviors that aren't provided by system OOTB?
Is the list below complete?
The expected UI behaviors:
Focusing next text field when [done] is hit
Hiding the keyboard when background is hit
Using Touch Up Inside to fire a button action. (To give user opportunity to change his/her mind)
Supporting the screen rotation.
Some of that is silly, but some of it has uses as well.
Focusing next text field when [done] is hit
Which field is "next"? If you have a large form with fields both next to and above/below each other, next might not be so obvious. Even if they are in some linear layout, the iPhone would have to work to figure out which one is next. Do you want to wrap around at the end of the form, or dismiss the keyboard, or submit the form?
Hiding the keyboard when background is hit
I mostly agree with you here, though there are a few cases where this is useless. For example, adding a new phone number in the contact app.
Using Touch Up Inside to fire a button action
This one I really don't get. I can only guess that it's designed to allow you to use buttons instead of the touchesBegan/Moved/Ended methods. I guess it could be useful, but I've never used anything but Touch Up Inside.
Supporting the screen rotation
Many apps just don't work in any other orientation, such as games. If you want to use rotation, you only have to add two lines of code assuming you've done your layout well.
I hope this helps explain some of the strangeness. Aside from the keyboard dismissal, I've never really found anything too annoying. The one thing I wish they supported was using the highlight state of UIButtons for the set state. It would be a quick and easy toggle button, but I've taken to screenshotting a highlighted button and using that for the background image of a selected button.
Want a rounded rectangular button that isn't white? Since that one uses a background image, you can't just click something somewhere that makes it the color of your choice. You have to create your own image or you could even use CSS (WTF!?) to do it.
Unfortunately, the iPhone SDK lacks a lot of helpful things one would think would just be there. However, many people have taken the time to write wrappers for many of these kinds of things to help facilitate development - a quick google search into the functionality you are expecting may turn up a lot of useful answers!
For example, you could make the keyboard go away when you tap outside of it by creating a new view when it appears, and placing that view behind any user-interactable views on the screen. When that new view is tapped, it will become first responder and cause the keyboard to slide away (because the UITextField is no longer first responder).
Such a thing could be easily implemented as a drop-in fix for pretty much anything you'd need it for with very little code.
Still should have been included in the SDK in the first place, though!
I'm working on an iphone application (not web app) and I'd like to build a form asking a user to indicate a price range. Instead of using two text fields, I would prefer to use a double slider to set the minimum and the maximum price. I know that it is possible de use a simple slider (sound control for exemple) but i've never seen a double one. Can anyone help ?
This is not possible without creating a custom control. You'll need to inherit from UIControl or UIView and provide a custom drawRect method. You'll also need to respond to touch and drag events to update the state of the control. I have not done this myself, but I would be prepared for a fairly significant amount of work to get everything to respond and display as expected.
I'm curious as to why you need to have both values specified on a single slider? Why not use two sliders either side-by-side or stacked? It would not require any more input steps than a double slider, and would conform more to standard UI guidelines.
I think you can specify multiple thumbs for a single slider if you subclass UISlider, at least I vaguely remember that being possible in MacOSX. But Code Addict is right, you'll probably be better off using the standard controls - a double-thumbed slider seems like it'd be pretty difficult to deal with in the touchscreen environment.
I built such a control and added it to GitHub so feel free to have a look and if you like the control extend it and contribute.
GitHub page: http://github.com/doukasd/DoubleSlider
Blog post (showing a video of how it works): http://dev.doukasd.com/2010/08/double-slider/