[brailleblaster] Re: Thoughts on the Specification
- From: Alex Jurgensen <asquared21@xxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Fri, 10 Dec 2010 09:46:40 -0800
Hi John G.,
Sorry. I misread the E-mail the first time.
I thought that you had lumped the placement of "Exit" along with the other
items that you did not think were important.
However, the preferences item seems to have a distinct placement in GnOME,
according to the E-mail from Michael Whapples, and it for sue has a distinct
placement in Mac OS X, so I suggest that that be considered an important item.
Sorry for the misunderstanding.
Regards,
Alex,
On 2010-12-10, at 9:25 AM, John Gardner wrote:
> Go back and read my e-mail and you will discover that you do not disagree.
> John G
>
>
> From: brailleblaster-bounce@xxxxxxxxxxxxx
> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Alex Jurgensen
> Sent: Friday, December 10, 2010 9:19 AM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Re: Thoughts on the Specification
>
> Hi John G.,
>
> I disagree. As an OS X user, I expect "Exit" to be called "Quit Braille
> Blaster" and be located in the "Braille Blaster" menu. As a Linux user, I
> expect "Exit" to be called "Exit" and be placed in the "File" menu. If I were
> a Windows user, I would expect "Exit" to be in the "File" menu.
>
> It is all about where things are expected to be in my opinion.
>
> If I wanted to have it all the same, I wouldn't care what environment I was
> using. However, I do, as do most end users. It is what differentiates one
> platform from the next.
>
> Why would I eat an orange when I could eat a Grapefruit. They both have peals
> and are round, but they have different flavours. I see the same with the
> layout of an OS.
>
> Just my opinion.
>
> Regards,
> Alex,
>
>
> On 2010-12-10, at 9:03 AM, John Gardner wrote:
>
>
> I agree completely. It’s just that I’d like to keep those tweaks to a
> minimum of things that are clearly important – like where Exit is. Where
> recent documents and the preferences menu are is not important imho.
> John G
>
>
> From: brailleblaster-bounce@xxxxxxxxxxxxx
> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Alex Jurgensen
> Sent: Friday, December 10, 2010 9:09 AM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Re: Thoughts on the Specification
>
> Hi John G.,
>
> I agree with having a user friendly site for updating tutorials. However,
> Windows and Linux help systems may have a feature like we have on the Mac,
> where the help system is self-updating.
>
> About UI changes, while Eclipse handles a lot of the UI changes that we would
> need to make to make the UI look native, I have sited several examples where
> we may need to make adjustments, such as the "Exit" menu item, which exists
> on the Mac in a menu that does not exist on any other Platform to my
> knowledge, unless you cont some distributions of Linux.
>
> Eclipse may handle some of this by default, so I do think that we can safely
> use SWT to handle most of the UI differences automatically.
>
> My point was that we should integrate the small tweaks that Eclipse does not
> handle automaticallly into Braille Blaster.
>
> Regarding Key Bindings, should we not taylor those to the various platforms.
> The OS's system-wide keyboard shortcuts should be respected in my opinion.
>
> Let me know hwat you think.
>
> Regards,
> Alex,
>
>
> On 2010-12-10, at 8:48 AM, John Gardner wrote:
>
>
>
> I propose answers to the first two of John's questions.
> 1. I do believe that the user should be able to change key bindings, for
> lots of reasons. And the ones in the spec wiykd be the defaults. None are
> cast in stone - I undoubtedly made a few mistakes.
> 2. If I understand correctly, the "look and feel" on the different OS
> platforms are controlled to a large extent by SWT, so why not just use it
> without a lot of tweaking?
> 3. I really don't understand much about changing the appearance of
> applications, so I won't give an opinion on how much the user can/should be
> able to do. However I hope that we won't agree on anything that is a major
> complication.
>
> A few other comments. I agree more or less with John B that we should keep
> UI changes to a minimum. As a Windows user I know that many applications do
> not put recent documents list at the end of the file menu, and it would
> hardly be a problem for anybody if there were a "recent documents item there
> instead. Preferences are not at all standard. In fact I don't recall ever
> seeing preferences in the edit menu. I've seen it in the file menu, in the
> help menu, in the tools menu, and in other places too. If it is more
> standard in other OS, I'm happy to follow their lead.
>
> Finally I am also happy to have help file as part of BrailleBlaster. It
> would be good if we could have a user-friendly update site so that people
> could easily get updates to tutorial and help files.
>
> John G
>
>
>
> -----Original Message-----
> From: brailleblaster-bounce@xxxxxxxxxxxxx
> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer
> Sent: Thursday, December 09, 2010 11:24 PM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Re: Thoughts on the Specification
>
> We have three questions that need to be resolved.
>
> 1. Should the user be able to change key bindings? If so, the keystrokes
> given in the spec would be the default.
>
> 2. What aspects of BrailleBlaster's appearance should be changed from
> one platform to another.
>
> 3. How much should the user be able to change BrailleBlaster's
> appearance?
>
> I think it would be helpful to look at how Eclipse deals with these
> matters.
>
> The idea of context menus was that there should be a context menu for
> the Daisy view and the Braille view, with things peculiar to that view.
>
> I think the spec should be reworded to make things clearer. The Daisy
> and Braille views should be called that, not windows. It should be
> stated that the welcome "screens" will be dialog boxces. It should also
> be stated that the print and emboss previews will be large dialog boxes.
> Finally, it should be stated explicitly that BrailleBlaster will have a
> top window containing the title bar, the menus and the status bar and
> that the Braille and Daisy views will be child windows of this top-level
> window. If the user has more than one document opoen, The views will
> change according to which document is being viewed. Various menu items
> may also be grayed out or inversely.
>
> BrailleBlaster will use the printing widget of SWT. This works with CUPS
> on Linux and the Mac and with the printer dialogs on Windows. Embosser
> dirvers, including the ViewPlus drivers, should interface with the
> printing widget, not print directly on the platform. This may require
> some revision of the drivers, but it is necessary for platform
> independence. Some Java code may be written to manage the interface.
>
> The Mac is used with all kinds of proprietary software that does
> printing. I don't think we have to worry about paying for CUPS.
>
> John B.
>
> On Thu, Dec 09, 2010 at 09:11:44PM -0800, Alex Jurgensen wrote:
>
>
> Hi John,
>
> Apple aquired the CUPS project, so the requirements for using it in paid
> drivers may have changed.
>
>
>
> The Mac also uses CUPS for its printing system.
>
> Regards,
> Alex,
>
>
> On 2010-12-09, at 5:34 PM, John Gardner wrote:
>
> The specs say that a user should be able to maximize either the DAISY or
> Braille view to cover the other. Or put them side by side.
>
> On another topic - there has been some discussion about printer drivers.
> It
>
>
> should be straightforward to use ViewPlus printer/embossers with the
> Windows
>
>
> version of BrailleBlaster. All ViewPlus printer/embosser users have
> Tiger
>
>
> ttf fonts installed, and it should be easy to set up a template so that
> the
>
>
> right ones are being used to tell the ViewPlus machine which character
> to
>
>
> print and which to emboss. Otherwise, BrailleBlaster is just another
> Windows ap and should print/emboss just fine. However I personally
> don't
>
>
> know much at all about printing with Mac or Linux. I have been told
> that
>
>
> CUPS is what one should use for Linux. I remember reading about CUPS
> many
>
>
> years ago, and all I remember is that it is GPL-licensed and that the
> license fee for use in a commercial non-GPL printer driver is many
> thousands
>
>
> of dollars per year. So what is another way?
>
> John G
>
>
>
> Original Message-----
> From: brailleblaster-bounce@xxxxxxxxxxxxx
> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of qubit
> Sent: Thursday, December 09, 2010 9:09 AM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Re: Thoughts on the Specification
>
> I think that the daisy and braille windows/views/whatever you call them
> should be resizeable and draggable, like the spec said. As long as the
> dialog windows are accessible, there is no need to customize them.
> The main window should be as large as it can be on each platform.
> My opinions.
> I think that since the user can resize and drag the D&B windows, he/she
> should be able to maximize one of them to cover the other, so as to see
> the
>
>
> full context in that document.
> Anyone comments?
> --le
>
> ----- Original Message -----
> From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
> To: <brailleblaster@xxxxxxxxxxxxx>
> Sent: Thursday, December 09, 2010 8:33 AM
> Subject: [brailleblaster] Re: Thoughts on the Specification
>
>
> Another question we need an answer to: How much should the user be
> allowed to customize the appearance of BrailleBlaster?
>
> John
>
> On Thu, Dec 09, 2010 at 06:07:40AM -0800, Alex Jurgensen wrote:
> Hi,
>
> Well, you saved me a great deal of typing.
>
> I was going to point out the menu bar situation on platforms like OS X
> which have a system menu bar. I've seen this talked about fro some
> setups
>
>
> of Ubuntu, althought I've never seen the latter in practice.
>
> Thanks for getting to this task first.
>
> Regards,
> Alex,
>
>
> On 2010-12-09, at 1:59 AM, 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
>
>
>
>
>
> Alex Jurgensen,
> VoiceOver Trainer,
> ASquared21@xxxxxxxxxxxxxxxxx
>
> Visit us on the web at: 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
>
>
> --
> 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
>
Alex Jurgensen,
VoiceOver Trainer,
ASquared21@xxxxxxxxxxxxxxxxx
Visit us on the web at: www.vipbc.org
Other related posts:
