[brailleblaster] Re: Thoughts on the Specification
- From: "John Gardner" <john.gardner@xxxxxxxxxxxx>
- To: <brailleblaster@xxxxxxxxxxxxx>
- Date: Thu, 9 Dec 2010 21:04:34 -0800
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/>
Other related posts:
