[brailleblaster] Re: Thoughts on the Specification
- From: Michael Whapples <mwhapples@xxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Fri, 10 Dec 2010 17:09:50 +0000
I would say keybindings should be platform specific, particularly for the Mac
as it has keys which other platforms don't have (eg. command and option). Also
if key bindings weren't wisely chosen if they were the same for all platforms
then there could be conflicts with platform specific ones (eg. the web mail
interface for aim.com email has ctrl+alt+d defined for a shortcut to delete
message but on gnome this is taken by the desktop for show desktop, therefore
on linux I cannot use the aim.com shortcut key).
However this is easily accommodated as if key bindings can be customised by
users then we can ship a different configuration depending on the platform the
build of BrailleBlaster is for.
Michael Whapples
On 10 Dec 2010, at 17:09, Alex Jurgensen wrote:
> 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
>
Other related posts:
