[brailleblaster] Re: The current controversy
- From: François Ouellette <braille@xxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Tue, 16 Oct 2012 09:41:26 -0400
I think that this is a good round up of what most users will expect.
At the user experience level, things should remain simple for the
casual user. For example, prompting to assign a style to a block of
text may be something outside of many users' understanding or
requirement. Perhaps the default style should automatically apply
unless a user uses a menu item to specify an alternate style instead?
For advanced users dealing with structured documents like NIMAS or
ePub, or wanting to apply international Braille presentation
standards, then styling will be a nice way of controlling how the
Braille gets displayed in a specific way.
F.
On Tue, Oct 16, 2012 at 4:45 AM, John J. Boyer
<john.boyer@xxxxxxxxxxxxxxxxx> wrote:
> Michael,
>
> I haven't wanted to answer this message, because I want to stop arguing.
> At the same time the sugestion that we list the features we want in
> BrailleBlaster is a good one.
>
> One goal is that BrailleBlaster should have a decent visual appearance.
> After all, sighted users will be a major source of tactile documents.
> The print window will also have to present images, as Keith has pointed
> out.
>
> Another goal is that people who know little of Braille shouldn't have to
> worry about it. The print window should therefore not be formatted to
> imitate the Braille window. In fact, people with little knowledge of
> Braille would probably make bad formatting decisions.
>
> The print window will have a means of assigning styles to blocks of
> characters. This was discussed im many previous messages.
>
> What other features do you think BrailleBlaster should have? I want to
> see a simple list, not arguments for this or that.
>
> John
>
> On Tue, Oct 16, 2012 at 07:27:56AM +0100, Michael Whapples wrote:
>> I am not sure if comparing to wordpad is a good thing, surely they have
>> very different goals. It may even be unhelpful.
>>
>> WordPad is aimed for sighted people viewing "print" documents, with the
>> only intent being for it to be used for "print" documents. They want the
>> document to look how it will on paper, they want documents they are sent
>> to look the way the author intended, they want to be able to send people
>> documents and for it to look the way it did on their screen.
>>
>> In contrast, as I have said before, BrailleBlaster is focussed on
>> creating documents which will translate into Braille. The print view is
>> purely so they know what the document contains, this includes what the
>> structural elements are. Does it visually need to be accurate to the
>> visual presentation of the authoring tool? I am probably thinking of the
>> separation of structure and presentation, a similar thing might be html
>> and CSS, does BrailleBlaster really need to be concerned with the
>> presentation (CSS if going with the HTML example) side of the document?
>>
>> Wordpad will have features not needed by BrailleBlaster, setting font
>> size being one example. How would setting font size actually contribute
>> to BrailleBlaster's goals?
>>
>> Equally BrailleBlaster might benefit from features not in wordpad, for
>> example a feature like "insert heading" or "Mark selection as heading".
>>
>> I feel it may be much more productive if we actually agree what features
>> should be present rather than using a comparison which may not be fully
>> relevant.
>>
>> Michael Whapples
>> On 14/10/2012 16:09, John J. Boyer wrote:
>> >Yes. Something like WordPad is what I have in mind.
>> >
>> >liblouisutdml already implements the formatting rules for U.S> Braille
>> >through the preferences.cfg file. Peoplein other countries have probably
>> >tweaked it for their own rules. They are not standard across countries
>> >and languages.
>> >
>> >As discussed somewhere in the thread on the block diagram, it turns out
>> >that most of the things I thought should go in BrailleBlaster
>> >configuration files actually belong in the UserSettings file or in the
>> >semantic-action file for a particular flavor of xml. I'll be revising
>> >the block diagram acordingly.
>> >
>> >Michael pointed out that somebody might misuse the facilities of an xml
>> >flavor by indicating a heading with a font change, for exxample. That is
>> >something we will have to watch out for. Another example is documents
>> >containing more than one language, where authors usually don't use
>> >markup to indicate which language is being used.
>> >
>> >The specification does need to be updared with what we have learned form
>> >experience and what APH requires.
>> >
>> >Let's take a rest on this Sunday.
>> >
>> >John B.
>> >
>> >On Sun, Oct 14, 2012 at 07:49:46AM -0700, John Gardner wrote:
>> >>Hello all, I am in the middle of an actual vacation and am trying to spend
>> >>as little time as practical doing anything else for a few weeks. I have
>> >>skimmed the BrailleBlaster communication and think it is time to go back
>> >>to
>> >>the specification document and update/expand it. That document was
>> >>written
>> >>largely by me with contributions from John Boyer and severl others. It is
>> >>intended to say what BrailleBlaster should be from the point of view of
>> >>the
>> >>end user. It does say that one should be able to create simple documents
>> >>and to import a variety of document types. It does not say that it should
>> >>be a full-featured word processor, but it does list a number of standard
>> >>functionalities it needs. Crudely speaking, it does not need to mimic MS
>> >>Word, but it does need to have most features of WordPad. So let's go back
>> >>to that spec document and work through it line by line until we all
>> >>understand the goals.
>> >>
>> >>John G
>> >>
>> >>
>> >>________________________________
>> >>
>> >>John Gardner | President | ViewPlus
>> >>541.754.4002 x 220 | www.viewplus.com
>> >>________________________________
>> >>
>> >>PRIVILEGED AND CONFIDENTIAL: This message and any files transmitted with
>> >>it
>> >>may be proprietary and are intended solely for the use of the individual
>> >>to
>> >>whom they are addressed. If you are not the intended recipient, any use,
>> >>copying, disclosure, dissemination or distribution is strictly prohibited;
>> >>please notify the sender and delete the message.
>> >>ViewPlus Technologies, Inc. accepts no liability for damage of any kind
>> >>resulting from this email.
>> >>
>> >>
>> >>
>>
>
> --
> 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:
