[brailleblaster] Re: Thoughts and questions on views
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Tue, 15 Jan 2013 10:55:17 -0600
This sounds good to me.
If one view makes a change how are the others to be notified? An event
seems to be the natural solution. However, I don't think an event can be
received by more than one listener at a time.
John
On Tue, Jan 15, 2013 at 02:37:51PM +0000, Keith Creasy wrote:
> That being the case, why don't we all come up with scenarios like the two
> described below, call then "use cases", and use them as a guide for designing
> the document interface. This interface is critical to any further progress on
> BrailleBlaster, possibly more important than styles, translation, UTD, or any
> other spect because if we don't get it right then nothing else is really
> going to work either.
>
>
>
> -----Original Message-----
> From: brailleblaster-bounce@xxxxxxxxxxxxx
> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer
> Sent: Tuesday, January 15, 2013 9:19 AM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Re: Thoughts and questions on views
>
> Thanks. This helps me think about what services the DocumentBase class has to
> provide.
>
> John
>
> On Tue, Jan 15, 2013 at 02:09:59PM +0000, Keith Creasy wrote:
> > Well, yes, there's not much other way you could do it. I guess I'm getting
> > more down to the "brass tacks" of just what gets called, how Document knows
> > what gets updated and how, and how the other views find out about it. In
> > fact, I don't even currently see how the Braille and Text views get what
> > they are supposed to display. One thing I'm going to be pretty stubborn
> > about, the view asks for what it needs, the document does not need to know
> > anything specific about any of the views or the document manager. The
> > document just needs to have methods for any view to request the content it
> > wants to know about.
> >
> > I don't see that what we have now is sufficient for the task. Here are some
> > items to consider:
> >
> > 1. User presses page-down three times, then arrows to a sentence they want
> > to break into a paragraph, and then presses return. Several things have to
> > happen for things to go well:
> >
> > . When the user moves the cursor, by any means, the view has to send a
> > message to document that informs it that the insertion point has changed
> > . Document has to know, based on something, what XML node is now the
> > context node and what text offset is the current insertion point and/or
> > selection.
> > . a new paragraph node has to be inserted, actually one gets split.
> > . All other views have to be updated about the new context node and
> > insertion point as well as the change in the XML tree.
> >
> > 2. User clicks on a new node in the Tree View.
> >
> > . The tree view notifies Document that the new node is now the context
> > node.
> > . Document makes that node the context node.
> > . The text and braille views have to be notified and scrolled to the
> > new position with the insertion point at the beginning of the braille
> > or text for that node. (How do we keep track, in the view, of what
> > text corresponds to the current context node?)
> >
> >
> > These are just two examples. There are a lot more.
> >
> > -----Original Message-----
> >
> > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J.
> > Boyer
> > Sent: Tuesday, January 15, 2013 8:53 AM
> > To: brailleblaster@xxxxxxxxxxxxx
> > Subject: [brailleblaster] Re: Thoughts and questions on views
> >
> > The general idea is that the views will call methods in DocumentBase to
> > request information from the document or to pass information to it. For
> > example, if the transcriber creates a new block of text the view will use a
> > method that passes that block and an indication of whether it is a header,
> > paragraph, transcriber's note, etc. Such an indication is what I mean by a
> > style.
> >
> > Just what methods DocumentBase will provide depends on what the views need.
> >
> > If the transcriber choses to emphasize a black of text the view will use a
> > method that passes that block and an indication of what emphasis is
> > intended, such as bold or italic.
> >
> > John
> >
> > On Tue, Jan 15, 2013 at 01:19:39PM +0000, Keith Creasy wrote:
> > > I'm not asking about interleaving, what are your plans to communicate
> > > between the views and the document in Semantics? How do they update each
> > > other? We haven't solved that, or at least I haven't seen the solution.
> > > We really can't move forward until it's solved. If Semantics hands off
> > > nice, pretty text and braille that's fine but what happens when someone
> > > edits something?
> > >
> > > Text Styles really aren't a problem. The TextView can show the text
> > > styles but the lines match the braille lines. The text in XML doesn't
> > > have hard line breaks except for block text boundries. Block text, as far
> > > as I know, in braill and text matches; i.e. paragraphs, headings, list
> > > items, etc.
> > >
> > >
> > > -----Original Message-----
> > > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J.
> > > Boyer
> > > Sent: Tuesday, January 15, 2013 7:50 AM
> > > To: brailleblaster@xxxxxxxxxxxxx
> > > Subject: [brailleblaster] Re: Thoughts and questions on views
> > >
> > > These are just my thoughts on interleaving. It just seems like a
> > > possibility.
> > >
> > > John
> > >
> > > On Tue, Jan 15, 2013 at 12:29:00PM +0000, Keith Creasy wrote:
> > > > Ah, and just what do you have in mind for that? I proposed a model for
> > > > doing it but since you've nixed my architecture I'm interested in what
> > > > you have in mind. If we don't have a plan for this we need to stop and
> > > > come up with one.
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > > > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J.
> > > > Boyer
> > > > Sent: Monday, January 14, 2013 7:08 PM
> > > > To: brailleblaster@xxxxxxxxxxxxx
> > > > Subject: [brailleblaster] Re: Thoughts and questions on views
> > > >
> > > > Yes, the biggest problem is updating the document from the views.
> > > >
> > > > Interleaving print and Braille displays might not be too difficult
> > > > using FormLayout. The two StyledText controls would be assigned the
> > > > same screen area, except that the print one would be a little higher,
> > > > so that its lines would appear between those of the Braille one. Line
> > > > spacing would have to be appropriate. One of the controls would have to
> > > > have a transparent background. I don'tknow if SWT can do this.
> > > >
> > > > John B
> > > >
> > > > On Mon, Jan 14, 2013 at 07:20:55PM +0000, Keith Creasy wrote:
> > > > > Well, I expect we'll just get everything working with the
> > > > > synchronization in place and go from there.
> > > > >
> > > > > The biggest hurdle in my opinion at this point is the mechanism for
> > > > > updates from the view to the document, in the XML context, and
> > > > > vice-versa. If we can get that worked out everything else seems
> > > > > pretty easy.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Keith Creasy
> > > > > Software Developer
> > > > > American Printing House for the Blind KCreasy@xxxxxxx
> > > > > Phone: 502.895.2405
> > > > > Skype: keith537
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > > > > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John
> > > > > Gardner
> > > > > Sent: Monday, January 14, 2013 2:16 PM
> > > > > To: brailleblaster@xxxxxxxxxxxxx
> > > > > Subject: [brailleblaster] Re: Thoughts and questions on views
> > > > >
> > > > > Sounds pretty user-friendly! However, a number of possibilities will
> > > > > work, so I suggest you propose the spec for this based on what can be
> > > > > made to work at reasonable effort. I hesitate to write down a spec
> > > > > and then discover that something that works just as well would be
> > > > > fifty times easier to implement.
> > > > >
> > > > > John G
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > > > > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Keith
> > > > > Creasy
> > > > > Sent: Monday, January 14, 2013 11:12
> > > > > To: brailleblaster@xxxxxxxxxxxxx
> > > > > Subject: [brailleblaster] Re: Thoughts and questions on views
> > > > >
> > > > > Just some ideas...
> > > > >
> > > > > Maybe we can make it so you can turn the line-by-line synchronization
> > > > > on and off.
> > > > >
> > > > > Also, since you hopefully can close or hide any of the views, if you
> > > > > aren't showing the braille view then there's really not much point in
> > > > > trying to synchronize. So, if you're just working on composing text
> > > > > in a large document you could just hide the braille view, maximize
> > > > > the text view and write in something that is more like a word
> > > > > processor. Then, when you want to see the braille, you could show the
> > > > > braille view and the synchronization would become active.
> > > > >
> > > > >
> > > > > Keith Creasy
> > > > > Software Developer
> > > > > American Printing House for the Blind KCreasy@xxxxxxx
> > > > > Phone: 502.895.2405
> > > > > Skype: keith537
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > > > > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John
> > > > > Gardner
> > > > > Sent: Monday, January 14, 2013 2:03 PM
> > > > > To: brailleblaster@xxxxxxxxxxxxx
> > > > > Subject: [brailleblaster] Re: Thoughts and questions on views
> > > > >
> > > > > Hi Keith, it would be a bit annoying to me, because the formatting
> > > > > would make the lines really short. But this is a minor annoyance,
> > > > > not anything that should change the direction you are going.
> > > > >
> > > > > John G
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > > > > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Keith
> > > > > Creasy
> > > > > Sent: Monday, January 14, 2013 10:56
> > > > > To: brailleblaster@xxxxxxxxxxxxx
> > > > > Subject: [brailleblaster] Re: Thoughts and questions on views
> > > > >
> > > > > John.
> > > > >
> > > > > Explain why it might be a bit annoying? Sounds like something I need
> > > > > to hear.
> > > > >
> > > > >
> > > > >
> > > > > Keith Creasy
> > > > > Software Developer
> > > > > American Printing House for the Blind KCreasy@xxxxxxx
> > > > > Phone: 502.895.2405
> > > > > Skype: keith537
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > > > > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John
> > > > > Gardner
> > > > > Sent: Monday, January 14, 2013 1:18 PM
> > > > > To: brailleblaster@xxxxxxxxxxxxx
> > > > > Subject: [brailleblaster] Re: Thoughts and questions on views
> > > > >
> > > > > Interesting, this is getting closer and closer to where conversations
> > > > > on BrailleBlaster started. If BrailleBlaster is being used to
> > > > > translate and make small corrections to an existing document, this
> > > > > functionality should be just fine. If one is authoring a long
> > > > > document in BrailleBlaster, it could be a bit annoying.
> > > > >
> > > > > We didn't expect BrailleBlaster to be a full-featured authoring
> > > > > application, so personally I think the functionality you describe is
> > > > > just fine.
> > > > >
> > > > > John G
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > > > > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Keith
> > > > > Creasy
> > > > > Sent: Monday, January 14, 2013 10:09
> > > > > To: brailleblaster@xxxxxxxxxxxxx
> > > > > Subject: [brailleblaster] Re: Thoughts and questions on views
> > > > >
> > > > > See my comments, KC-, below.
> > > > >
> > > > > -----Original Message-----
> > > > > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > > > > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J.
> > > > > Boyer
> > > > > Sent: Monday, January 14, 2013 12:36 PM
> > > > > To: brailleblaster@xxxxxxxxxxxxx
> > > > > Subject: [brailleblaster] Re: Thoughts and questions on views
> > > > >
> > > > > How will the browser view get the information to show things in their
> > > > > original context?
> > > > >
> > > > > KC- That's a good question and one we need to solve. Basically it
> > > > > contains the original document (DOM) with a CSS and XSLT applied.
> > > > > There is an update method to move the browser selection to the
> > > > > context element.
> > > > >
> > > > >
> > > > > I've always thought that print editing would be done in a
> > > > > wordprocessor view. The layout would not mimic that of the Braille
> > > > > view. I just want to be clear on where we will be doing editing.
> > > > >
> > > > >
> > > > > KC- The short answer is, at least in this first cycle, editing is
> > > > > done in the text view. Right now there is no "word processor" view. I
> > > > > think in the long term we are going to want a browser-style view that
> > > > > is editable. We can talk about whether or not we want some kind of
> > > > > text view that does not place line breaks at the same places as those
> > > > > in the braille view. If we design it right then adding views is easy.
> > > > > I suggest we start with the text and braille views in line-by-line
> > > > > synchronization. In XML documents line length is based on the view
> > > > > window anyhow so there are no hard line breaks in the print to
> > > > > conflict with the ones in the braille view.
> > > > > .
> > > > >
> > > > >
> > > > > John B
> > > > >
> > > > > On Mon, Jan 14, 2013 at 05:27:01PM +0000, Keith Creasy wrote:
> > > > > > John.
> > > > > >
> > > > > > Yes, it is a Browser view. Sorry for the confusion. It's just
> > > > > > to allow
> > > > > users to see everything in its oribinal context.
> > > > > >
> > > > > > View Plus has just mentioned a time or two that they'd like to
> > > > > > overlap
> > > > > text and braille. Beyond that there isn't much more to say. I'd just
> > > > > like to keep things open to do that if they want to at some point.
> > > > > For now the text and braille views accomplish the same thing just in
> > > > > side-by-side views rather than them being overlapped.
> > > > > >
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > > > > > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J.
> > > > > > Boyer
> > > > > > Sent: Monday, January 14, 2013 12:23 PM
> > > > > > To: brailleblaster@xxxxxxxxxxxxx
> > > > > > Subject: [brailleblaster] Re: Thoughts and questions on views
> > > > > >
> > > > > > Hi Keith,
> > > > > >
> > > > > > There are a lot of things in your original reply that I will
> > > > > > be thinking
> > > > > about. I agree that it might be best to srart over with
> > > > > Documentmanager (or DocumentClient).
> > > > > >
> > > > > > What is ViewPlus doing about editing print and Braille? If
> > > > > > this is
> > > > > proprietary information we might discuss it in the steering committee?
> > > > > >
> > > > > > I can understand a tree view, but why do we need an html view?
> > > > > > Isn't it
> > > > > more properly a browser view?
> > > > > >
> > > > > > John B
> > > > > >
> > > > > > On Mon, Jan 14, 2013 at 05:04:29PM +0000, Keith Creasy wrote:
> > > > > > > Hmmm, that would be an interesting approach, make one of the
> > > > > > > views
> > > > > transparent so the content could overlap in a clever way. It might
> > > > > work.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Keith Creasy
> > > > > > > Software Developer
> > > > > > > American Printing House for the Blind KCreasy@xxxxxxx
> > > > > > > Phone: 502.895.2405
> > > > > > > Skype: keith537
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > > > > > > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of
> > > > > > > John Gardner
> > > > > > > Sent: Monday, January 14, 2013 12:01 PM
> > > > > > > To: brailleblaster@xxxxxxxxxxxxx
> > > > > > > Subject: [brailleblaster] Re: Thoughts and questions on
> > > > > > > views
> > > > > > >
> > > > > > > Hi Keith, John B mentioned a text+Braille view. This is
> > > > > > > something that
> > > > > was discussed in the early planning stages of BrailleBlaster. But we
> > > > > dropped it in favor of separate views. It would be nifty if the text
> > > > > view and the Braille view could be superposed to show a
> > > > > "text+Braille" view - ie the translation right above the Braille,
> > > > > something our users like. For ViewPlus printer/embossers it would
> > > > > also be more or less what the final output is.
> > > > > > > As long as you are working on views, is it difficult to
> > > > > > > design them so
> > > > > that this is possible? Ie to make the top view semi-transparaent and
> > > > > easy to drag on top of the other?
> > > > > > >
> > > > > > > John G
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > > > > > > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of
> > > > > > > Keith Creasy
> > > > > > > Sent: Monday, January 14, 2013 08:20
> > > > > > > To: brailleblaster@xxxxxxxxxxxxx
> > > > > > > Subject: [brailleblaster] Re: Thoughts and questions on
> > > > > > > views
> > > > > > >
> > > > > > > Hi John.
> > > > > > >
> > > > > > > Interesting. I'm working on views today. At least I'm
> > > > > > > reading through
> > > > > the code and coming up with some strategies.
> > > > > > >
> > > > > > > I do like the idea of moving views to a package. Initially
> > > > > > > we have
> > > > > potentially four views:
> > > > > > >
> > > > > > > TextView
> > > > > > > BrailleView
> > > > > > > TreeView
> > > > > > > HtmlView
> > > > > > >
> > > > > > > I still want to attach the views to the document
> > > > > > > (DocumentBase) in some
> > > > > way with a common interface so that new views can be added easily.
> > > > > That way we can document exactly what someone would need to create a
> > > > > text/braille view.
> > > > > > > We don't plan to do that but View Plus may.
> > > > > > >
> > > > > > > Optionally we can attach DocumentManager to DocumentBase and
> > > > > > > let
> > > > > DocumentManager manage connecting views. Document Manager also
> > > > > handles a client view that represents the window area for a single
> > > > > document. WpManager is going to create each of DocumentManager and
> > > > > hand off the client area that DocumentManager and it's view widgets
> > > > > occupy. If we want to enable an MDI then WmManager just changes wich
> > > > > instance of DocumentManager is displayed in the client area.
> > > > > > >
> > > > > > > Also, because it's such a mess, I'd suggest that someone
> > > > > > > rename the
> > > > > current DcocumentManager class DocumentManagerOld or something and
> > > > > start over.
> > > > > > > There's a lot in there that can be copied and used in the
> > > > > > > new
> > > > > DocumentManager but in trying to comb through it and decide what
> > > > > should stay and what should go I think starting over with the
> > > > > original as a reference is simpler. In fact, what about renaming it
> > > > > DocumentClient? It is mostly a view of sorts.
> > > > > > >
> > > > > > > Here are my notes so far, they are not complete:
> > > > > > >
> > > > > > > WpManager class:
> > > > > > >
> > > > > > > This is the main entry point for BB. It doesn't do much
> > > > > > > right now but
> > > > > I'm proposing that it do a bit more.
> > > > > > >
> > > > > > > 1. Sets up main application window, menu, toolbar, andclient area.
> > > > > > > 2. Handles File/New and File/Recent command, most Window commands.
> > > > > > > 3. Creates a DocumentManager instance when a new document is
> > > > > > > created.
> > > > > > >
> > > > > > > DocumentManager class (maybe renamed to DocumentClient?):
> > > > > > >
> > > > > > > 1. fills the client area of WpManager. The client frame
> > > > > > > contains any
> > > > > views to the document.
> > > > > > > 2. Creates an instance of DocumentBase and any views that
> > > > > > > need to be
> > > > > attached.
> > > > > > > 3. Handles most file commands; i.e. Open, Save, Save
> > > > > > > As,Export, Import,
> > > > > etc.
> > > > > > >
> > > > > > >
> > > > > > > Views:
> > > > > > >
> > > > > > > All views are derived from AbstractView. This is so that all
> > > > > > > can have
> > > > > certain methods that are required for interfacing with the document
> > > > > and so that the document can update them when necessary. Does it make
> > > > > sense for each view to create it's own font? We definitely want to
> > > > > avoid code in DocumentManager that is specific to a particular view;
> > > > > i.e. DocumentManager knows how to create a BrailleView and put it
> > > > > somewhere but nothing more.
> > > > > > >
> > > > > > > Keith Creasy
> > > > > > > Software Developer
> > > > > > > American Printing House for the Blind KCreasy@xxxxxxx
> > > > > > > Phone: 502.895.2405
> > > > > > > Skype: keith537
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > > > > > > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J.
> > > > > > > Boyer
> > > > > > > Sent: Monday, January 14, 2013 10:42 AM
> > > > > > > To: brailleblaster@xxxxxxxxxxxxx
> > > > > > > Subject: [brailleblaster] Thoughts and questions on views
> > > > > > >
> > > > > > > First, whatever APH and ViewaPlus want to do about view is fine
> > > > > > > with me.
> > > > > > >
> > > > > > > It seems that we are considering four views, a tree view, a
> > > > > > > browser or
> > > > > htmml view a combined Braille-and-print view and a word processor
> > > > > view.
> > > > > > > Do we want the last view? Editing can be done in the
> > > > > > > braille-and-print
> > > > > view.
> > > > > > > If we don't want a wordprocessor view we con't have to worry
> > > > > > > about
> > > > > styles, because the layout of the print in the print-Braille view
> > > > > will mimic that of the Braille. Perhaps we should change the
> > > > > architecture to have an org.brailleblaster.views package and within
> > > > > this package subpackages for each view, brailleprintview, treeview,
> > > > > browserview and wordprocessorview.
> > > > > > >
> > > > > > > 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
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > John J. Boyer, Executive Director GodTouches Digital Ministry,
> > > > > Inc.
> > > > > http://www.godtouches.org
> > > > > Madison, Wisconsin, USA
> > > > > Peace, Love, Service
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > 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
> > >
> > >
> >
> > --
> > 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
>
>
--
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:
