[brailleblaster] Re: Thoughts on the Specification
- From: Alex Jurgensen <asquared21@xxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Thu, 9 Dec 2010 06:07:40 -0800
Hi,
Well, you saved me a great deal of typing.
I was going to point out the menu bar situation on platforms like OS X which
have a system menu bar. I've seen this talked about fro some setups of Ubuntu,
althought I've never seen the latter in practice.
Thanks for getting to this task first.
Regards,
Alex,
On 2010-12-09, at 1:59 AM, 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
>>>>>
>>>>>
>
>
Alex Jurgensen,
VoiceOver Trainer,
ASquared21@xxxxxxxxxxxxxxxxx
Visit us on the web at: www.vipbc.org
Other related posts:
