[brailleblaster] Re: Some Thoughts

  • From: Michael Whapples <mwhapples@xxxxxxx>
  • To: brailleblaster@xxxxxxxxxxxxx
  • Date: Thu, 03 Feb 2011 00:58:11 +0000

Hello John,
Firstly what you said was very much what I was expecting, I just wanted it confirmed.

The cross platform nature is certainly important to me, but I appreciate where the majority of users will be and so possibly the greatest effort should be to enhance their experience.

Could I try and pin down what would be acceptable (IE. what is required).

I propose the following (user is very likely to mean screen reader users but this may also be applied to sighted users): 1. BrailleBlaster should work on Windows, Linux and Mac OSX (this has been stated and probably for now should be limited to these, although other unix GNOME based systems are likely to work without issue due to the Linux support, but these additional unix systems will not be specifically targeted).
2. Windows support:
2.1. BrailleBlaster should be accessible on Windows and should follow windows standards for the user interface. 2.2. Windows users, with skills which would enable them to use a word processor such as Microsoft Word, should be able to perform basic tasks such as Braille transcription without any training on the software. Advanced features may require users to refer to documentation or receive training. 2.3. Windows users (possibly a percentage could be given) will feel BrailleBlaster is efficient to use.
3. Mac support:
3.1. The Mac version should be accessible, with the minimum being a screen reader user should be able to perform all tasks. After the initial version, following releases should address efficient control while using a screen reader and how well BrailleBlaster integrates with the Mac OS. 3.2. The initial version of BrailleBlaster should allow a Mac user with basic word processing skills to be able to perform basic tasks after receiving some training on those tasks or reading documentation. Following versions for Mac should allow the user to discover how to perform these tasks without receiving training or reading documentation. 3.3. Versions of BrailleBlaster for Mac after the initial release should lead to Mac users feeling BrailleBlaster is efficient to use for Braille transcription. The initial version should not lead to more than (percentage really needed) users feeling BrailleBlaster is an unworkable solution. 4. Linux support: This should be the same requirements as for Mac, but with users being Linux users and the platform it needing to integrate with being an X desktop environment using at-spi for accessibility.

What do we think? Any thoughts on specific values (like percentage of users where I note it could be useful to have the percentage). Also note there probably are other requirements dealing with the UI, these are the ones which seem to really impact on accessibility.

Michael Whapples
On 02/02/11 22:13, John Gardner wrote:
Hello all, well I'm not sure whether I speak for ViewPlus, but I believe
that all the people who started BrailleBlaster are committed to developing
it as a multi-OS application.  Admittedly the Windows version is the most
important simply because the great majority of current users work in
Windows.  I believe that BrailleBlaster development needs to heed its
multi-platform target and make sure that it will eventually work on Mac and
Linux.  However, the first robust target must be Windows, with good Mac and
Linux versions perhaps taking more time.

John Gardner

-----Original Message-----
From: brailleblaster-bounce@xxxxxxxxxxxxx
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Whapples
Sent: Wednesday, February 02, 2011 1:56 PM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [brailleblaster] Re: Some Thoughts

I am going to be direct, you keep bringing it up and honesty may be the
only way to get to the bottom of it.

I am getting the feeling your issue is not really with SWT but rather
with Java. What is it about Java you don't like?

As an example to why I draw the conclusion above, you say use
C/C++/objective-c for logic code but possibly use SWT for the UI. The
rationale you give for this is to have the possibility of being able to
develop a native GUI for the Mac. Well having the logic code in Java
also would allow for that as I have pointed out in the past. Java can
access native code and so use the platform's native GUI libraries
directly. The example I have given before is cyberduck
http://www.cyberduck.ch, which in fact Apple have put in their list of
applications accessible with voiceover
http://www.apple.com/accessibility/voiceover/applications.html, look
under utilities.

I won't say my views on the app store again, other than to mention, Macs
only represent a small number of users, as Linux probably does, and so
technologies of one platform, particularly optional ones which the app
store seems to be, should not drive the direction of the project.

I guess the last say on all this could and probably does fall back to
ViewPlus, who are the ones wanting this project. How important is the
Mac to ViewPlus? What is the minimum acceptable standard of support for
the Mac? Oh, and I am not getting at the Macs here,the same questions
should be asked for the other platforms.

Michael Whapples
On 02/02/11 17:49, Alex Jurgensen wrote:
Hi,

If we use the web approach, we can style the applcations to look like
native Mac apps.
These are the headaches that just kill me about cross-platform stuff.

If we only wrote hte main logic in something like C, Objective-C or C++
and then did our UI's in SWT, that would at least give us the possibility to
write an alternative UI down the road for the Mac.
Regards,
Alex,


On 2011-02-02, at 9:41 AM, Chris von See wrote:

Highly unlikely - rule 2.24
ofhttp://stadium.weblogsinc.com/engadget/files/mac-app-review.pdf  seems
pretty clear:
2.24 Apps that use deprecated or optionally installed technologies (e.g.,
Java, Rosetta) will be rejected
You *may* be able to get around the rules regarding deprecated
technologies by bundling a JRE (it would almost certainly need to be
SoyLatte since you can't include anything with a third-party installer such
as an Oracle JRE for Mac).  You almost certainly will not be able to get
around the requirement that the UI adhere to the Mac Human Interface
Guidelines - Java apps that don't use Apple's enhanced JRE look nothing like
native Mac apps.



On Feb 2, 2011, at 9:29 AM, Alex Jurgensen wrote:

Hi,

I realize that.

However, I think that including a JDK might solve this.

Regards,
Alex,


On 2011-02-02, at 9:28 AM, Chris von See wrote:

Java applications cannot be included in the Mac App Store.  Java is now
considered to be an "optional" technology on the Mac, according to Apple.



On Feb 2, 2011, at 9:21 AM, Alex Jurgensen wrote:

Hi John,

I was refering more to Chris' message about using STW's browser
control as a UI. That would get us half way to having a web app, would it
not.
Now, that depends on how we end up doing the UI.

About the auto updater, I am working on it because this is where I
feel the most confident, creating a boot loader.
Here is my question.

How far along are we in the 2 year development cycle? The website does
not list a date that the project was started on.
I have also been investigating the rules for submitting the
application through Apple's Mac App Store.
I know it is a little early for this, but I have read about developers
who wrote entire applications that got rejected because of something that
was too difficult to change at the time of submission.
Regards,
Alex,


On 2011-02-02, at 9:13 AM, John J. Boyer wrote:

Alex,

Sorry about the need to modify your application bundle, but
BrailleBlaster has always been written as one word.

I think you are getting ahead of us. It is too early to include
auto-updatre, and a web application is a whold divverent project. We
have to stick to what we are doing. After BrailleBlaster is working
as a
desktop  application we can consider a Web application.

John

On Wed, Feb 02, 2011 at 08:52:17AM -0800, Alex Jurgensen wrote:
Hi,

I suppose that the Mac issues should be resolved in any case. This
would help the Mac community as a whole.
I've built my boot loader now, but I can't test it yet.

Did you get a chance to look at my mock up yet?

What do you think of it?

Regards,
Alex,

Alex Jurgensen,
VoiceOver Trainer,

Visit me on the web at:http://www.vipbc.org/


On 2011-02-02, at 12:19 AM, John J. Boyer wrote:

I've read through all these messages, and I'm convinced we should
stick
with SWT. By the time BrailleBlaster is ready for use by anybody
other
than a developer the problems on the Mac may be resolved. We can
add a
little pressure to the Eclipse developers to help things along. The
idea
of using the SWT browser to present GUI content is interesting.

The classpaths specified in the ant build.xml file go iknto the
manifest
of the BrailleBlaster jar file. This makes callinng BrailleBlaster
very
convenient on my flavor of Linux and on Windows. We could make
different
versions of BrailleBlaster for different distros, but I think that
is
something for the early adapters who use these distros to worry
about.
They will know their own flavors. And many of them won't care about
the
standard locations.

Let's learn from Alex's experience in proting BrailleBlaster to the
Mac.
Concern about various Linux flavors at this time is a distraction.

As for me, I'm concentrating on getting BrailleBlaster to work with
at
least generic embossers. Then I'll make a simple text editor using
a
GUI. the experience in doing this will be necessary to make the
real
GUI. The text editor will remain as a BrailleBlaster feature to be
used
by advanced users.

Incidentally, BrailleBlaster is a single word.  It should not have
a
space.

John

--
John J. Boyer; President, Chief Software Developer
Abilitiessoft, Inc.
http://www.abilitiessoft.com
Madison, Wisconsin USA
Developing software for people with disabilities


----- End forwarded message -----

--
John J. Boyer; President, Chief Software Developer
Abilitiessoft, Inc.
http://www.abilitiessoft.com
Madison, Wisconsin USA
Developing software for people with disabilities


--
John J. Boyer; President, Chief Software Developer
Abilitiessoft, Inc.
http://www.abilitiessoft.com
Madison, Wisconsin USA
Developing software for people with disabilities








Other related posts: