Georg,
I’m seeking clarification on a point you had made with regard to
your own experience designing accessible software. Below, you say:
Based on these experiences, and on my thoughts about MD
patients, I honestly see no way how one could make the IB accessible - no
matter of the amount of efforts on Apple's side.
Are you strictly referring to physical disabilities in that
instance? I have seen UI design software (cf. Visual Studio from Microsoft) be
made usable by blind and visually impaired people (in fact, I WORK at Microsoft
and have had no trouble, or minimal trouble, using its designers, with the exception
of those that are used for the new Windows Presentation Foundation, and this is
entirely due to third party adaptive technology manufacturers, and to politics with
which no gentleman need concern themselves). In your estimation, as I
amunfamiliar with Interface Builder, what would be the issues in adding increased
accessibility? Josh, without violating too many nondisclosures, can you disclose
whether what we would need would be an interim solution, to what extent any
issues may be fixed, and an approximate timeline (taking into account, of course,
the general looseness given any release date in the software industry)?
-C-
From: accessibility-dev-bounces+tallin32=email@hidden
[mailto:accessibility-dev-bounces+tallin32=email@hidden] On
Behalf Of Georg Tuparev
Sent: Tuesday, October 14, 2008 7:52 AM
To: Carol Clark
Cc: Accessibility-Dev Mail
Subject: Re: Accessible development
Hi Carol,
In my company we would like to open few positions for people
suffering from various forms of muscular dystrophy and since few months I am
thinking about the questions you are asking.
One general advise. Most of the problems you are talking
about will disappear if you work together with colleagues. This is an
advise I always give to all my trainees and colleagues, and it has nothing to
to with physical abilities or limitations. Working in pairs makes the quality
of the work much better, and speeds up the entire development process. This is
one of the corner stones of the Agile development, and its benefits are
often enormous. So the best I could suggest is to find a coding buddy.
Way back when I was at the university and instead of
programming on Apple I was using a nice stylish NeXTstation, I developed few
gadgets for visually impaired people and also an interface to control a virtual
keyboard by monitoring mu-waves. Based on these experiences, and on my thoughts
about MD patients, I honestly see no way how one could make the IB accessible -
no matter of the amount of efforts on Apple's side. Here it is not the place
though to explain why.
I would strongly discourage you of going the Java way. Apple
support is limited and deprecated, and it seams to me this is a dead-end. James
Dempsy perhaps could comment on this more. Better (then Java) alternative could
be Ruby or F-Script Cocoa bindings (depending on your ability to use the
keyboard at least in a limited way). These technologies are also interesting
for debugging and testing and in general - a good investment.
Simson Garfinkel and Mike Mahoney (I hope I spell Mike's
name correctly) wrote a NeXT programing book back in 1993 (I believe) that has
a very nice chapter or two on building applications without IB. Later when
Apple bought NeXT O'Reilly published a new version of the book that was
slightly fixed by Simson. I believe it is out of print, but I am sure one can
find second-hand copies. With the current version of Cocoa I believe it is
unreasonable effort to have a IB free UI, but this book could help you limit
the dependancy on IB to certain extend.
While I was helping the porting of few very large projects
to Cocoa where the UI (for other platforms) was coded in XML config files, I
used effectively a small trick. I had an offscreen view that had all UI
elements I needed already pre-configured (in a raw form) and while
building the UI (runtime) I was copying them to where they were needed, and
then configuring them with few lines of source code. In Apple
HIG there is a chapter that discusses how to position UI
elements correctly. It is described in a very algorithmic way,
and based on this I developed quite a complicated method for auto-layouting. It
worked ok, although it never could produce a wow or delicious experience. This
could also work for you.
Please feel free to ask for details. But again, my advise is
to work in a team. And if you cannot find one, we are always interested on
getting new intelligent people on board :-)
On Oct 13, 2008, at 10:40 PM, Carol Clark wrote:
I an also in a similar situation, albeit with a different
disability. My problem is that I have very limited use of my hands and arms, so
must do most of my work by voice.
I've also found Interface Builder inaccessible, and have
turned to Java as a result. But I am working on a speech recognition
application for handling command and control, so both the speech recognition
and the command and control are platform-dependent. I'm currently considering
an architecture that would use a Java interface, with the real work done by
native Cocoa libraries accessed through JNI.
Can someone tell me how to get access to the information
Josh mentioned about writing Cocoa interfaces by code?
Apparently, there are a few of us in this position. If
appropriate documentation of the techniques for coding Cocoa interfaces were
available, might we develop some libraries we could share that would make it
more practical to develop this way? Comments, anyone?
On Oct 11, 2008, at 6:44 PM, Chris Meredith wrote:
I also find myself in a similar situation (minus, of course, the
development of audio games, but that’s mostly due to a lack of knowledge of
where to get a sufficient number of sound effects). In my case, one of
the problems that I’ve had with actually acquiring a Mac was the sheer
impossibility of developing GUI-based apps, and the attitude amongst the
developer community that vision was a requirement for such things (something
which, I am glad to see, is becoming a thing of the past, and more rapidly than
was the case in Windows development (though I could make the argument that the
strides made in Windows development might have helped this process move more
quickly)). Thus far, the only solution that I’ve found for reasonably
rapid UI development without Interface Builder is GNUstep Renaissance, and
that tends to suffer from the same problem that any cross-platform GUI
framework tends to run into—that of having the lowest common denominator of
widgets available to all supported platforms, not to mention the fact that it
appears to be in perpetual beta. At any rate, I would also be curious to
find a solution to this, or, at the very least, be keen to add my voice to
those that might find such a project useful—particularly as, if I’m remembering
correctly, Apple’s Human Interface Guidelines are strict enough that adhering
to them could be made an automated process, which would eliminate the old
chestnut that certainly used to be given in response to this question, that
being how a blind developer could possibly line up their controls appropriately.
BOY that was long.
I hope this question is enough on
topic here that someone may be able to offer some suggestions or assistance.
I'm a visually impaired software
developer and have worked in Windows for many years. I've been a
Mac/VoiceOver convert for several years now as well, but have continued to
develop for WIndows for several reasons, which will become apparent shortly.
I've had two separate threads I've
been following to try to make the leap to Mac development in an accessible way,
both with very little in the way of results.
1. Developing apps with a
traditional GUI by the accepted methods is not currently possible. Interface
Builder is not accessible enough with VoiceOver yet to allow any meaningful
development with that tool. (IB team is aware and working on a solution.)
I've managed to scrounge up, thanks to some other Cocoa developers, some very
minimal examples of building Cocoa interfaces by code, but the process appears
to be ridiculously time consuming to do that way, (not to mention impractical
for long-term support). Even if I chose to go that route, the lack of
documentation and/or examples on that method of UI development could leave me
floundering for quite some time.
Because of all of that, I
continued to pursue another option. I delved into Java development for
Mac, having noted previously that Java Swing apps were supposed to be
accessible. Much to my frustration, while there is some access, there are
also a great many limitations. Text fields were not reading correctly,
and there seemed to be no access to the contents of cells in JTable controls.
Is there another, more accessible
way of developing these sorts of applications on the Mac?
2. On a separate thread, I've been
looking at porting many of our Windows products to Mac. These apps are
audio games for the blind, and have no GUI, save for an empty window to allow
the user to give the application focus while playing. The interface is
otherwise audio-based. I chose GLut for these projects, only to come up
short there as well, as the glut timer functions don't seem to work properly
under OS X, which is unfortunate, as we were hoping that by employing GLut in
C++ apps, we could make porting between Windows and Mac a relatively painless
process.
Ideally, I need a way to
practically create Cocoa GUI interfaces, mostly separate from the C++ code of
the apps I intend to produce and port between platforms. I'd rather not
use GLut at all, if I can avoid it, especially now that much of its basic
functionality seems to be questionable.
This does not seem like it should
be such a problem, but every time I come close to a solution, I hit another wall.
Josh de Lioncourt
...my other mail provider is
an owl...
_______________________________________________
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
_______________________________________________
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
Georg Tuparev
Tuparev Technologies
Klipper 13
1186 VR Amstelveen
The Netherlands
Mobile: +31-6-55798196
|