[brailleblaster] Re: Thoughts on the Specification
- From: Michael Whapples <mwhapples@xxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Fri, 10 Dec 2010 17:03:19 +0000
Regarding preferences in the edit menu, that is very much a Linux thing, or at
least a gnome thing. The main points of different user interfaces on different
platforms seem to be very much minor layout things.
Michael Whapples
On 10 Dec 2010, at 16:48, 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
>
>
>
>
Other related posts:
