[brailleblaster] Re: Thoughts on the Specification
- From: Alex Jurgensen <asquared21@xxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Fri, 10 Dec 2010 08:45:02 -0800
Hi John B.,
I think that I could easily write a converter based on the Daisy Pipeline for
converting the documentation into the formats expected by the various platforms.
Regards,
Alex,
On 2010-12-10, at 8:26 AM, John J. Boyer wrote:
> Well, I've read lots of Daisy documents, both in raw form and in braille
> translations. Using BrailleBlaster you would be able to navigate through
> a Daisy document without even knowing it was such. It would be just like
> using any other word processor to read a document, except that it would
> be hopefully more accessible.
>
> What I would like to see is BrailleBlaster being used to create the help
> documents. These could then be translated to html using xslt or evet to
> pdf, using other tools.
>
> John B.
>
> On Fri, Dec 10, 2010 at 04:12:35PM +0000, Michael Whapples wrote:
>> I would say the HTML version is necessary, daisy is in my mind a marginal
>> format. What I mean by this is that even as someone who probably falls in
>> the group of people daisy was aimed at I have never read a daisy document
>> therefore this would impose a heavy learning curve for me just to read
>> BrailleBlaster's help if no HTML version was included.
>>
>> As I remember this was discussed before on this list and the outcome of that
>> was HTML would be the format for the help documents.
>>
>> Michael Whapples
>> On 10 Dec 2010, at 16:16, Alex Jurgensen wrote:
>>
>>> Hi John B.,
>>>
>>> I also agree with you as far as distributing Braille Blaster's help with
>>> the applciation. However, I suggest that we also provide an HTML version,
>>> packaged as the operating system's help system requires, in addition to a
>>> DAISY formatd coy.
>>>
>>> This would allow us to take advantage of the built-in help systems found on
>>> the various platforms and would require very little work on our behalf.
>>>
>>> Just my thoughts.
>>>
>>> Regards,
>>> Alex,
>>>
>>>
>>> On 2010-12-10, at 7:58 AM, John J. Boyer wrote:
>>>
>>>>
>>>> Another thing I don't like is putting the help online. I think it should
>>>> be part of the BrfailleBlaster distribution and should be in the form of
>>>> simple Daisy xml files. These can be edited and even created in the
>>>> Daisy view and translated into braille and embossed. The only advantage
>>>> to opening them in the default browser would be that users could follow
>>>> links to other sites. The tutorials are already supposed to be
>>>> distributed with BrailleBlaster, so why not the entire help. The user
>>>> will be able to follow links to other parts of the documents, so there
>>>> will be no problem with an active table of contents.
>>>>
>>>> John B.
>>>>
>>>> On Fri, Dec 10, 2010 at 07:19:09AM -0800, John Gardner wrote:
>>>>> So the spec needs to be trifurcated with separate pieces for the three OS?
>>>>> Maybe John B should accumulate a list of UI items that need to be
>>>>> different,
>>>>> and then I'll write up a new draft with these changes.
>>>>>
>>>>>
>>>>>
>>>>> John G
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> From: brailleblaster-bounce@xxxxxxxxxxxxx
>>>>> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Alex Jurgensen
>>>>> Sent: Thursday, December 09, 2010 9:26 PM
>>>>> To: brailleblaster@xxxxxxxxxxxxx
>>>>> Subject: [brailleblaster] Re: Thoughts on the Specification
>>>>>
>>>>>
>>>>>
>>>>> Hi John G.,
>>>>>
>>>>>
>>>>>
>>>>> As I have said before, in my opinion, there is a fine line when it comes
>>>>> to
>>>>> creating a user experience that users will be familiar with.
>>>>>
>>>>>
>>>>>
>>>>> Would it not be better then to do the recent items item differently for
>>>>> the
>>>>> different platforms.
>>>>>
>>>>>
>>>>>
>>>>> We will already have to make several changes to the UI, if we are going to
>>>>> account for differences on the various platforms.
>>>>>
>>>>>
>>>>>
>>>>> If the work on customizing the UI experiences for the different platforms
>>>>> is
>>>>> carried out, would it not be easy to incorporate the recent items menu
>>>>> structure into the changes we make while creating the various UIs?
>>>>>
>>>>>
>>>>>
>>>>> Let me know what you think.
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Alex,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2010-12-09, at 9:04 PM, John Gardner wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hmmm, this is the way it is specified now. And there are certainly
>>>>> Windows
>>>>> aps that put recent documents into a sub-menu, including ViewPlus IVEO
>>>>> software. I don't think that consistency with the majority of Windows aps
>>>>> for this usage is particularly important, so unless I hear a good reason
>>>>> to
>>>>> change, I propose to leave this spec as-is.
>>>>>
>>>>>
>>>>>
>>>>> John G
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> From: brailleblaster-bounce@xxxxxxxxxxxxx
>>>>> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Alex Jurgensen
>>>>> Sent: Thursday, December 09, 2010 8:58 PM
>>>>> To: brailleblaster@xxxxxxxxxxxxx
>>>>> Subject: [brailleblaster] Re: Thoughts on the Specification
>>>>>
>>>>>
>>>>>
>>>>> Hi John,
>>>>>
>>>>>
>>>>>
>>>>> Native Mac apps seem to put recent documents in a menu item called "Open
>>>>> Recent" that comes after the "Open" menu item.
>>>>>
>>>>>
>>>>>
>>>>> I am not sure about Linux.
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Alex,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2010-12-09, at 5:09 PM, John Gardner wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hello all, sorry I've been pretty quiet lately. But I guess I still need
>>>>> to
>>>>> take responsibility for the spec. You are right that the spec doesn't
>>>>> mention context menus. It does give a menu item for recent documents, but
>>>>> your proposal to include it at the end of the file menu is indeed the
>>>>> common
>>>>> way to do it in Windows. I'm happy to change that if it's also the way
>>>>> it's
>>>>> done in Mac and Linux aps. Advice please.
>>>>>
>>>>> I apparently missed the conversations about context menus. I'm also happy
>>>>> to expand the spec to include context menus too. Do we have a consensus
>>>>> on
>>>>> what should go there?
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: brailleblaster-bounce@xxxxxxxxxxxxx
>>>>> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of qubit
>>>>> Sent: Thursday, December 09, 2010 9:02 AM
>>>>> To: brailleblaster@xxxxxxxxxxxxx
>>>>> Subject: [brailleblaster] Re: Thoughts on the Specification
>>>>>
>>>>> Yes, JohnG and Yuemei -- are you there???
>>>>> Who owns the spec? JohnG was the original author. Is he also the one
>>>>> to
>>>>> update it or did he hand it off to JohnB?
>>>>>
>>>>> I agree about the context menus. On windows that would go without saying
>>>>> as
>>>>>
>>>>> context menus are pervasive and very useful. In windows, there is a
>>>>> "recent
>>>>>
>>>>> documents" option in the global start menu, but it lists almost
>>>>> everything
>>>>> anywhere that is either a document or music or video. Brailleblaster's
>>>>> recent documents option could be limited only to the docs that have been
>>>>> edited by brailleblaster, right?
>>>>> An alternative is to just tack the recent brailleblaster documents at the
>>>>> end of the file menu, like what happens in many windows apps I have seen.
>>>>> Is this also prevalent on linux or mac? What will go in the recent
>>>>> documents?
>>>>>
>>>>> Another point: what should happen when a document has been transcribed
>>>>> but
>>>>> edited in the braille window by the user? Are those changes marked in
>>>>> such
>>>>> a way that a retranslation of the file won't undo it? What if the daisy
>>>>> document has changed and there needs to be a retranslation? Just
>>>>> wondering.
>>>>>
>>>>> I need to review the spec.
>>>>> --le
>>>>> The idea of putting me
>>>>> John and Mike,
>>>>> ----- Original Message -----
>>>>> From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
>>>>> To: <brailleblaster@xxxxxxxxxxxxx>
>>>>> Sent: Thursday, December 09, 2010 5:29 AM
>>>>> Subject: [brailleblaster] Re: Thoughts on the Specification
>>>>>
>>>>>
>>>>> I guess I've revealed my ignorance of GUIs. I'm really a command-line
>>>>> guy and find GUIs difficult to understand. But I'm learning.
>>>>>
>>>>> After thinkikng things over I came to about the same conclusions. The
>>>>> top window should have a title bar, the menus and the status bar. The
>>>>> braille and Daisy windows would be child windows. Switching from one
>>>>> document to another would replace these windows. The print and emboss
>>>>> previews would be dialog boxes. The "Welcome screens" would also be
>>>>> dialog boxes. I think the specification might be reworded to make things
>>>>> clearer.
>>>>>
>>>>> The specification is quite detailed about the keystrokes to be used.
>>>>> These may have to be modified to conform to the usage of different
>>>>> platforms. I think this is something that we should provide for now,
>>>>> like internationalization. Putting it in later could be much more work.
>>>>> How might this be done? I think SWT provides for specifying keystrokes
>>>>> for functions.
>>>>>
>>>>> The specification says there will be an item inn the file menu for
>>>>> opening a list of recent documents. I think this would be acceptable in
>>>>> Windows.
>>>>>
>>>>> I like the idea of a "context" menu for different views. Perhaps this
>>>>> should be added to the specification.
>>>>>
>>>>> What happened to the ViewPlus people? Wehaven't heard from them for a
>>>>> loing time.
>>>>>
>>>>> John
>>>>>
>>>>> On Thu, Dec 09, 2010 at 09:59:06AM +0000, Michael Whapples wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> I don't think having the Braille and daisy views as top level windows
>>>>>
>>>>> with there own menus would be very natural. Firstly it doesn't really
>>>>>
>>>>> fit with any other GUI application I can think of, normally they either
>>>>>
>>>>> modify available menu options depending on the current view or they grey
>>>>>
>>>>> out unavailable options. So as greyed out options are fairly "normal" to
>>>>>
>>>>> encounter I don't see why they would be confusing. Then there is the
>>>>>
>>>>> case of platforms where menus aren't actually in the window but get
>>>>>
>>>>> placed by applications in a system menu bar like in Mac OSX (NOTE: SWT
>>>>>
>>>>> will automatically handle this for you). As an example of the Mac
>>>>>
>>>>> situation, in safari the web browser, even when I go to its preferences
>>>>>
>>>>> all menu options are still there but ones which are irrelevant to
>>>>>
>>>>> preferences (eg. the option to show/hide the status bar) are greyed out.
>>>>>
>>>>>
>>>>>
>>>>> Also the idea of two top level windows being present in one application
>>>>>
>>>>> at the same time just seems odd to me, I couldn't imagine it would look
>>>>>
>>>>> right (it would probably look like two separate applications). Then what
>>>>>
>>>>> happens when there are more documents opened, your description seems to
>>>>>
>>>>> give me more top level windows and more clutter of the desktop. Then
>>>>>
>>>>> there is the situation of "I am working on a document in BrailleBlaster,
>>>>>
>>>>> I have finished on that document so I close the document but keeping
>>>>>
>>>>> BrailleBlaster open as I want to work on another document", what do I
>>>>>
>>>>> encounter at the point when BrailleBlaster has no open documents? Having
>>>>>
>>>>> the document views as child elements of a "BrailleBlaster appliccation
>>>>>
>>>>> top level window" I would be left with an empty BrailleBlaster window
>>>>>
>>>>> containing only the menus and toolbars (IE. no sub windows), allowing me
>>>>>
>>>>> to go to the menu and choose open document or new or whatever task I
>>>>>
>>>>> want to do. Also with my idea of the view, multiple documents would just
>>>>>
>>>>> lead to more sub views, the desktop only ever has one BrailleBlaster top
>>>>>
>>>>> level window.
>>>>>
>>>>>
>>>>>
>>>>> Now one thing which might be desired is a shortcut pop-up menu specific
>>>>>
>>>>> to each view. What I mean is one of those context menus which are
>>>>>
>>>>> activated by right clicking the mouse of a UI element (use the
>>>>>
>>>>> applications key or may be shift+f10 and on Mac with voiceover
>>>>>
>>>>> vo+shift+m). In these context menus only the options relevant to that
>>>>>
>>>>> element would be shown.
>>>>>
>>>>>
>>>>>
>>>>> Michael Whapples
>>>>>
>>>>> On 09/12/10 04:55, John J. Boyer wrote:
>>>>>
>>>>> This sounds good. My understanding was that the Daisy and Braille
>>>>>
>>>>> windows would each have their own menus. The specification doesn't say
>>>>>
>>>>> so explicitly, but it seemed reasonable, since some things would be
>>>>>
>>>>> possible in one window and some things in another. If the Daisy and
>>>>>
>>>>> Braille windows are embedded in a top window with the menus, status bar
>>>>>
>>>>> and toolbar, the grayed-out options could be confusing and frustrating
>>>>>
>>>>> for the user. Is this actually the way it will be?
>>>>>
>>>>>
>>>>>
>>>>> So the print and embosser previews are basically big dialog boxes. I
>>>>>
>>>>> don't remember anyone saying they should be open continually. They are
>>>>>
>>>>> opened when needed.
>>>>>
>>>>>
>>>>>
>>>>> I don't think BrailleBlsster should display multiple documents
>>>>>
>>>>> simultaneously, since it already has two views for each document.
>>>>>
>>>>> Rather, when a user switched to another document these view would be
>>>>>
>>>>> changed for that document.
>>>>>
>>>>>
>>>>>
>>>>> The Daisy and Braille windows should prbably be called views instead,
>>>>>
>>>>> especially if they don't contain their own menus.
>>>>>
>>>>>
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Dec 08, 2010 at 08:45:53PM +0000, Michael Whapples wrote:
>>>>>
>>>>> We seem to be getting a whole jumble of things here. A window is a very
>>>>>
>>>>> generic thing. A dialog is a type of window, normally used to show
>>>>>
>>>>> messages or let users select options. A dialog is not embedded in the
>>>>>
>>>>> top level window but can be such that it prevents the user going back to
>>>>>
>>>>> the main window. A dialog might not cover the main application top level
>>>>>
>>>>> window. Then there are child windows (they may have another name) which
>>>>>
>>>>> usually is embedded into the top level window. These may be used for
>>>>>
>>>>> multiple documents (eg. MS Word has been known to work like this I don't
>>>>>
>>>>> know about their latest version). Finally then there are what I am
>>>>>
>>>>> calling a top level window, these don't have any other window containing
>>>>>
>>>>> them.
>>>>>
>>>>>
>>>>>
>>>>> My feeling is:
>>>>>
>>>>> * BrailleBlaster will have a top level window containing the menus and
>>>>>
>>>>> such like which are common to all situations.
>>>>>
>>>>> * The daisy viewer and Braille viewers will be child windows or may be
>>>>>
>>>>> even panes within a child window or may be this will all work on the tab
>>>>>
>>>>> idea. Anyway the main idea is these will be embedded into the top level
>>>>>
>>>>> window.
>>>>>
>>>>> * Print and preview will be dialog boxes as these are both actions (IE.
>>>>>
>>>>> I go to print/emboss a document or I go and view how it will be
>>>>>
>>>>> printed). I see no reason why print preview would need to be open
>>>>>
>>>>> continually.
>>>>>
>>>>>
>>>>>
>>>>> Michael Whapples
>>>>>
>>>>> On 08/12/10 20:13, John J. Boyer wrote:
>>>>>
>>>>> I've never actually looked at a print preview window. Has anyone seen
>>>>>
>>>>> an
>>>>>
>>>>> embosser preview window? I would think that programs would handle
>>>>>
>>>>> preview by opening a temporary window that either hides the existing
>>>>>
>>>>> window or minimizes them.
>>>>>
>>>>>
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Dec 08, 2010 at 12:27:33PM -0600, qubit wrote:
>>>>>
>>>>> Regarding What happens to the windows when a print preview is active:
>>>>>
>>>>> I wonder if opening a new window is a good idea.
>>>>>
>>>>> I am growing to like one feature in eclipse's UI: eclipse will cycle
>>>>>
>>>>> through
>>>>>
>>>>> all the various windows if you hold control and type F7 repeatedly.
>>>>>
>>>>> It has a lot of rather busy windows. I wonder what it looks like to a
>>>>>
>>>>> sighted person.
>>>>>
>>>>>
>>>>>
>>>>> As for print preview, I have no idea what to do if you are embossing a
>>>>>
>>>>> document. The image in the braille window doesn't necessarily look
>>>>>
>>>>> like
>>>>>
>>>>> the
>>>>>
>>>>> output of the device. Do the various embossers provide any kind of
>>>>>
>>>>> API
>>>>>
>>>>> for
>>>>>
>>>>> knowing what the braille will look like?
>>>>>
>>>>> Also, if viewing it on screen, you are further limited by the display
>>>>>
>>>>> capabilities.
>>>>>
>>>>>
>>>>>
>>>>> Interesting question. But do you really want there to be a hard coded
>>>>>
>>>>> window for print preview, print and emboss? Couldn't it just be like
>>>>>
>>>>> most
>>>>>
>>>>> apps that put a command for print and emboss and print preview in the
>>>>>
>>>>> file
>>>>>
>>>>> menu? That could bring up a dialog.
>>>>>
>>>>> Just wondering.
>>>>>
>>>>> --le
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>
>>>>> From: "John J. Boyer"<john.boyer@xxxxxxxxxxxxxxxxx>
>>>>>
>>>>> To:<brailleblaster@xxxxxxxxxxxxx>
>>>>>
>>>>> Sent: Wednesday, December 08, 2010 9:24 AM
>>>>>
>>>>> Subject: [brailleblaster] Thoughts on the Specification
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I have just reread the specification carefully. It certainly hangs
>>>>>
>>>>> together better for me than at the beginning. Here are some thoughts.
>>>>>
>>>>> There is a menu item for opening a list of recent documents. These
>>>>>
>>>>> documents should be on the menu, just below the exit choice, as they
>>>>>
>>>>> are
>>>>>
>>>>> ikn most word processors.
>>>>>
>>>>>
>>>>>
>>>>> The ability to open recent documents means that the users will want
>>>>>
>>>>> MDI.
>>>>>
>>>>> Fortunately, this is not hard to implement.
>>>>>
>>>>>
>>>>>
>>>>> We may need a third window for each document for print and embosser
>>>>>
>>>>> previews. What happens to the Daisy and Braille windows when a preview
>>>>>
>>>>> is chosen? Are they minimized?
>>>>>
>>>>>
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Alex Jurgensen,
>>>>>
>>>>> VoiceOver Trainer,
>>>>>
>>>>> ASquared21@xxxxxxxxxxxxxxxxx
>>>>>
>>>>>
>>>>>
>>>>> Visit us on the web at: www.vipbc.org <http://www.vipbc.org/>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Alex Jurgensen,
>>>>>
>>>>> VoiceOver Trainer,
>>>>>
>>>>> ASquared21@xxxxxxxxxxxxxxxxx
>>>>>
>>>>>
>>>>>
>>>>> Visit us on the web at: www.vipbc.org <http://www.vipbc.org/>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> John J. Boyer; President, Chief Software Developer
>>>> Abilitiessoft, Inc.
>>>> http://www.abilitiessoft.com
>>>> Madison, Wisconsin USA
>>>> Developing software for people with disabilities
>>>>
>>>>
>>>
>>> Alex Jurgensen,
>>> VoiceOver Trainer,
>>> ASquared21@xxxxxxxxxxxxxxxxx
>>>
>>> Visit us on the web at: www.vipbc.org
>>>
>>
>
> --
> John J. Boyer; President, Chief Software Developer
> Abilitiessoft, Inc.
> http://www.abilitiessoft.com
> Madison, Wisconsin USA
> Developing software for people with disabilities
>
>
Alex Jurgensen,
VoiceOver Trainer,
ASquared21@xxxxxxxxxxxxxxxxx
Visit us on the web at: www.vipbc.org
Other related posts:
