[brailleblaster] Re: Thoughts on the Specification
- From: Alex Jurgensen <asquared21@xxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Fri, 10 Dec 2010 09:12:59 -0800
Hi John G.
Is there any information on this available to the public.
I have been developing something quite similar to this, a sort of highbred
format of DAISY and EPUB, which is what DAISY four is sounding like.
Regards,
Alex,
On 2010-12-10, at 9:00 AM, John Gardner wrote:
> You are all right. Next year, DAISY 4 is scheduled to be approved, and the
> new distribution format will be EPUB 3.0. The xml part of EPUB 3 is HTML5.
> So we better be prepared to read and use HTML5.
>
> John G
>
>
> From: brailleblaster-bounce@xxxxxxxxxxxxx
> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Whapples
> Sent: Friday, December 10, 2010 8:13 AM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Re: Thoughts on the Specification
>
> 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 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
>
>
Alex Jurgensen,
VoiceOver Trainer,
ASquared21@xxxxxxxxxxxxxxxxx
Visit us on the web at: www.vipbc.org
Other related posts:
