[brailleblaster] Re: Thoughts on the Specification
- From: Alex Jurgensen <asquared21@xxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Fri, 10 Dec 2010 08:16:46 -0800
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
Other related posts:
