I had probably jumped ahead of what I wanted to express.So writing what I feel is needed for the help in more generic terms: Help should be viewable in a system standard to that platform. Standard meaning something which the user of that system would be used to using and having an instance of it provided by default as part of the operating system. The goal of this requirement is to make it that minimal effort is needed by the user to open and read help, so making it as easy as possible for new users to find out how to make the most of BrailleBlaster. A result of this would be that users will not need to request support for the routine uses of BrailleBlaster, freeing those providing support to pay attention to users encountering bugs or advanced issues.
Now help systems perfectly satisfy that requirement and is a perfectly valid option to be considered. I said browser simply because that was what first came to mind when thinking of HTML and seemed a nice consistent thing across platforms (as mentioned java has a way of invoking browsers and so I thought would be a simple thing to do).
I would be happy either way, help systems or browsers, browsers were just what came to mind first.
Michael Whapples On 10/12/10 18:00, Alex Jurgensen wrote:
Hi Michael,I agree with the fact that the help should be in HTML, but why do you suggest that we use the browser as the default place to look for help.Help systems, such as "help Viewer" on the Mac, are capable of displaying HTML files. I suggest that we use this method as the default place to look for help.This is where users will probably look for help first.I am also agreeing with the fact that we should have a support/documentation section of the Braille Blaster website.Let me know what you think. Regards, Alex, On 2010-12-10, at 9:35 AM, Michael Whapples wrote:My point was, I have not had the need to read daisy documents, I haven't read a daisy document therefore I have nothing to read such documents. Now there are two solutions should BrailleBlaster documents be only in daisy: I need to go and find out about a daisy reader get it and learn how to use it (quite a bit of work just to read some help). Now as you point out by having BrailleBlaster I would have something to read daisy documents, however you possibly end up with a circular problem, I have a problem with BrailleBlaster therefore want to read help, but to read help I need to use BrailleBlaster which is what I would have the problem with.Using HTML would be using the browser the user uses to browse the internet, therefore they would be familiar with how to use the software to read help and all platforms would have a viewer by default.I am not saying don't include a daisy version of help, but I feel the default help people would refer to would be in html.Michael Whapples On 10 Dec 2010, at 16:26, 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 likeusing 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 helpdocuments. 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 ofsimple Daisy xml files. These can be edited and even created in theDaisy view and translated into braille and embossed. The only advantage to opening them in the default browser would be that users could followlinks to other sites. The tutorials are already supposed to bedistributed with BrailleBlaster, so why not the entire help. The user will be able to follow links to other parts of the documents, so therewill 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 GFrom: brailleblaster-bounce@xxxxxxxxxxxxx <mailto:brailleblaster-bounce@xxxxxxxxxxxxx> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Alex JurgensenSent: Thursday, December 09, 2010 9:26 PMTo: brailleblaster@xxxxxxxxxxxxx <mailto: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 tocreating a user experience that users will be familiar with.Would it not be better then to do the recent items item differently for thedifferent platforms.We will already have to make several changes to the UI, if we are going toaccount 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 menustructure 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 tochange, I propose to leave this spec as-is. John GFrom: brailleblaster-bounce@xxxxxxxxxxxxx <mailto:brailleblaster-bounce@xxxxxxxxxxxxx> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Alex JurgensenSent: Thursday, December 09, 2010 8:58 PMTo: brailleblaster@xxxxxxxxxxxxx <mailto:brailleblaster@xxxxxxxxxxxxx>Subject: [brailleblaster] Re: Thoughts on the Specification Hi John,Native Mac apps seem to put recent documents in a menu item called "OpenRecent" 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'sdone 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 onwhat should go there? John -----Original Message-----From: brailleblaster-bounce@xxxxxxxxxxxxx <mailto:brailleblaster-bounce@xxxxxxxxxxxxx>[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of qubit Sent: Thursday, December 09, 2010 9:02 AMTo: brailleblaster@xxxxxxxxxxxxx <mailto: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 toupdate it or did he hand it off to JohnB?I agree about the context menus. On windows that would go without saying ascontext menus are pervasive and very useful. In windows, there is a "recentdocuments" 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 beenedited 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 <mailto:john.boyer@xxxxxxxxxxxxxxxxx>> To: <brailleblaster@xxxxxxxxxxxxx <mailto:brailleblaster@xxxxxxxxxxxxx>>Sent: Thursday, December 09, 2010 5:29 AM Subject: [brailleblaster] Re: Thoughts on the SpecificationI guess I've revealed my ignorance of GUIs. I'm really a command-lineguy 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. Thebraille and Daisy windows would be child windows. Switching from onedocument to another would replace these windows. The print and embosspreviews would be dialog boxes. The "Welcome screens" would also bedialog boxes. I think the specification might be reworded to make thingsclearer. 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 keystrokesfor functions. The specification says there will be an item inn the file menu foropening a list of recent documents. I think this would be acceptable inWindows.I like the idea of a "context" menu for different views. Perhaps thisshould be added to the specification.What happened to the ViewPlus people? Wehaven't heard from them for aloing 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 windowswith there own menus would be very natural. Firstly it doesn't reallyfit with any other GUI application I can think of, normally they eithermodify available menu options depending on the current view or they greyout unavailable options. So as greyed out options are fairly "normal" toencounter 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 getplaced by applications in a system menu bar like in Mac OSX (NOTE: SWTwill automatically handle this for you). As an example of the Macsituation, in safari the web browser, even when I go to its preferencesall menu options are still there but ones which are irrelevant topreferences (eg. the option to show/hide the status bar) are greyed out.Also the idea of two top level windows being present in one applicationat the same time just seems odd to me, I couldn't imagine it would lookright (it would probably look like two separate applications). Then whathappens when there are more documents opened, your description seems togive me more top level windows and more clutter of the desktop. Thenthere is the situation of "I am working on a document in BrailleBlaster,I have finished on that document so I close the document but keepingBrailleBlaster open as I want to work on another document", what do Iencounter at the point when BrailleBlaster has no open documents? Havingthe document views as child elements of a "BrailleBlaster appliccationtop level window" I would be left with an empty BrailleBlaster windowcontaining only the menus and toolbars (IE. no sub windows), allowing meto go to the menu and choose open document or new or whatever task Iwant to do. Also with my idea of the view, multiple documents would justlead to more sub views, the desktop only ever has one BrailleBlaster toplevel window.Now one thing which might be desired is a shortcut pop-up menu specificto 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 voiceovervo+shift+m). In these context menus only the options relevant to thatelement 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 Braillewindows would each have their own menus. The specification doesn't sayso explicitly, but it seemed reasonable, since some things would be possible in one window and some things in another. If the Daisy andBraille windows are embedded in a top window with the menus, status barand toolbar, the grayed-out options could be confusing and frustratingfor the user. Is this actually the way it will be? So the print and embosser previews are basically big dialog boxes. Idon't remember anyone saying they should be open continually. They areopened 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 verygeneric thing. A dialog is a type of window, normally used to showmessages or let users select options. A dialog is not embedded in thetop level window but can be such that it prevents the user going back tothe main window. A dialog might not cover the main application top levelwindow. Then there are child windows (they may have another name) whichusually is embedded into the top level window. These may be used formultiple documents (eg. MS Word has been known to work like this I don'tknow about their latest version). Finally then there are what I amcalling a top level window, these don't have any other window containingthem. My feeling is:* BrailleBlaster will have a top level window containing the menus andsuch like which are common to all situations.* The daisy viewer and Braille viewers will be child windows or may beeven panes within a child window or may be this will all work on the tabidea. Anyway the main idea is these will be embedded into the top levelwindow.* 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 seenan 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 asighted person.As for print preview, I have no idea what to do if you are embossing adocument. 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 displaycapabilities.Interesting question. But do you really want there to be a hard codedwindow for print preview, print and emboss? Couldn't it just be likemostapps that put a command for print and emboss and print preview in thefile menu? That could bring up a dialog. Just wondering. --le ----- Original Message -----From: "John J. Boyer"<john.boyer@xxxxxxxxxxxxxxxxx <mailto:john.boyer@xxxxxxxxxxxxxxxxx>>To:<brailleblaster@xxxxxxxxxxxxx <mailto: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 hangstogether 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 embosserpreviews. What happens to the Daisy and Braille windows when a previewis 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 <mailto:ASquared21@xxxxxxxxxxxxxxxxx>Visit us on the web at: www.vipbc.org <http://www.vipbc.org> <http://www.vipbc.org/>Alex Jurgensen, VoiceOver Trainer, ASquared21@xxxxxxxxxxxxxxxxx <mailto:ASquared21@xxxxxxxxxxxxxxxxx>Visit us on the web at: www.vipbc.org <http://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 disabilitiesAlex Jurgensen, VoiceOver Trainer, ASquared21@xxxxxxxxxxxxxxxxx <mailto: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 disabilitiesAlex Jurgensen, VoiceOver Trainer, ASquared21@xxxxxxxxxxxxxxxxx <mailto:ASquared21@xxxxxxxxxxxxxxxxx> Visit us on the web at:www.vipbc.org <http://www.vipbc.org/>