[brailleblaster] Re: Thoughts on the Specification
- From: Alex Jurgensen <asquared21@xxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Thu, 9 Dec 2010 20:57:45 -0800
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
Other related posts:
