RE: Testing iPhone applications
RE: Testing iPhone applications
- Subject: RE: Testing iPhone applications
- From: Bryan Smart <email@hidden>
- Date: Tue, 9 Feb 2010 11:47:42 -0500
- Acceptlanguage: en-US
- Thread-topic: Testing iPhone applications
Everett, just a warning that there is currently a large roadblock against a blind developer creating a Cocoa or Cocoa Touch user interface. Most developers design their interfaces with Interface Builder, and Interface Builder has some important accessibility problems. There are workarounds for most all of them, but the amount of effort involved makes using Interface Builder a burden rather than a tool to speed up development.
When adding interface objects to a design surface, you're supposed to drag controls from the library to the appropriate location on the surface. Also, you're supposed to arrange objects on the surface by dragging. VoiceOver drag and drop support is broken in IB, though.
If you want to add an object to a surface, you must be showing the outline view for the surface. Then, open the library, enter the scroll area where the objects are located, find the object to add, move the mouse cursor to the VO cursor with command-shift-VO-F5, select the object with VO-shift-space, and finally press enter to insert an instance of the control in to the outline. This won't place the object on the surface, but will create an instance at the bottom of the outline. In order to establish the correct parent relationship, you need to switch back to the outline view, arrow to the new instance, press command-x to cut, arrow to the desired parent of the instance, and press command-v to paste.
If you'd like to position or size your objects, you need to select an object in the outline, and then open the size inspector. Of course, entering object coordinates and dimensions numerically is an incredibly tedious way to position and size controls, and I'm not aware of any information that will provide you with firm rules for manually calculating these values in order to get a pleasing visual outcome. The normal tools for aligning objects spatially aren't available to a VO user, or, at least, I haven't known of anyone that has discovered a workaround that would make it possible to use them. And, as I said, VO's drag and drop support isn't able to move objects on the design surface. This is really too bad, since, with a multitouch track pad, it is possible for a VO user to feel the layout of the controls on the surface. Since drag and drop is broken, though, you can only use VO as a proofing tool to see if the numerical values that you entered produced a result that is, at least, marginally acceptable.
The other major area where Interface Builder's accessibility is broken involves interface object connections. There is an inspector that will allow you to view the connections that are already established for an object, but you can't, for example, use VO to setup outlets. You can do that in your code, and, once you do, Interface Builder will recognize them, but, if you're working in this way, why bother with Interface Builder?
If this looks like too much effort, that's because it is. The only accessible approach is to kick Interface Builder out of your toolbox, and write code to generate your interface. Some people will tell you that's the better way, since you have greater control over how your interface operates. That's true, but you'll still need to calculate all of the coordinates and dimensions of controls manually, as far as I know. The whole thing is beyond tedium. If you're blind, there is no such thing as rapid prototyping of anything on the Mac or IPhone. I know of blind developers for the IPhone, but all of the ones that I know need to partner with someone sighted to carry out the interface design work in Interface Builder. The drawback is that, as a blind developer, you can't modify or update your own interface.
As an alternative, I think that it might be possible to build a class library that would automatically generate some basic interface layouts, given a few basic layout classes.
In a high level approach, you might have a layout class like SimpleEditor, that is already setup to produce a window with a layout including a small text editor and a separate area for buttons. the particular list of buttons for the area would be configured in the instance of SimpleEditor. The layout class would automatically adjust the size of the window, the button area, and the buttons, depending on how many buttons were requested and the length of their titles.
Beyond serving as an aid to blind developers, being able to automatically generate interface layouts might be an interesting tool for rapidly generating Cocoa interfaces for shell tools, or for automatically generating interfaces based on some basic information received from another program or from a file. For example, a shell command might support, as input arguments, a list of file names, some flags (of which some are mutually exclusive), and some flags that specify a strictly enumerated list of options. SO, instead of needing to write graphical front-ends for every tool, you could just parse the spec at the top of the man page (or a sanitized version), put that through your engine, and generate a window where the various parameters and flags were displayed.
Anyway, as far as I know, that's a dream at this stage. I've thought about sitting down with the Apple User Interface Guidelines and trying to write a library that would create some of these generic, but standard-looking layouts, but one obstacle that I face is that I don't have a good debugging tool for my work. VoiceOver will happily read UI objects, even if they all overlap each other and are sized so that none of the object's text is actually visible. *smile* So, I'd need to produce lots of test case interfaces, and have a sighted person to test and report back with details.
Anyway, this is probably way more than you wanted to hear, so I'll wrap this up.
There is a Google group called mv-dev, where other blind Mac developers commiserate. Actually, its not all bad. A good bit of work goes on, but the popular interface is either the terminal or self-voicing programs. Not that those are the preferred interfaces, but they're just the only ones that are available.
Bryan
-----Original Message-----
From: accessibility-dev-bounces+bryansmart=email@hidden [mailto:accessibility-dev-bounces+bryansmart=email@hidden] On Behalf Of E.J. Zufelt
Sent: Tuesday, February 09, 2010 10:30 AM
To: Alexander von Below
Cc: email@hidden
Subject: Re: Testing iPhone applications
Good morning Alex,
Thanks for the quick response.
Can you point me to a resource that provides information about testing an iPhone app on an iPhone? The only information I have been able to find regarding this seems to involve my paying $99 to join the developer program.
I would be happy to join if I determine that iPhone application development is reasonably accessible for a blind developer, but obviously would prefer not to pay just to find out that it is more effort than it is worth.
Thank you again,
Everett
Follow me on Twitter
http://twitter.com/ezufelt
View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt
On 2010-02-09, at 10:20 AM, Alexander von Below wrote:
Hello Everett,
you can always debug and test your applications on the device. If VoiceOver is enabled, it will be used.
Hope this helps
Alex
The following text is your original eMail
Am 09.02.2010 um 16:09 schrieb E.J. Zufelt:
Good morning,
If this is the incorrect list to ask this question I would appreciate someone pointing me to the proper resource.
I am a blind developer and I have recently started looking at iPhone development in Snow Leopard. I am obviously using VoiceOver on my Mac.
I am wondering how a blind developer can build and run iPhone applications on a Mac, considering that iPhone Simulator does not appear to be accessible with VoiceOver?
Thank you,
Everett
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden