Re: Thin Client Networks was [gdm-list] Bringing back a11y
- From: "Steve Lee" <steve fullmeasure co uk>
- To: ianpascoe btinternet com
- Cc: gnome-accessibility-list gnome org
- Subject: Re: Thin Client Networks was [gdm-list] Bringing back a11y
- Date: Wed, 13 Feb 2008 10:11:57 +0000
When I looked into this before:
www.schoolforge.org.uk/index.php/Assistive_Technology_with_Terminal_Servers
It seems that LTSP works due to the great design of X and basically
adds a neat way to get it going. X provides distributed operation with
displays and various input devices but other devices like sound and
Braille (I think) aren't included so need to be handled separately.
AFAIK sound is now most sorted but the problem boils down to careful
thought about distributed operation (what is running on which
machine). Designing for deployment across machines possibly with AT on
another machine to the application and not assuming everything is on
the same machine (as Windows mostly does, even with Terminal Services
or RDP).
Steve Lee
On 12/02/2008, Ian Pascoe <ianpascoe btinternet com> wrote:
> Following on from Steve's point 3 below.
>
> With the higher availability of interconnects and CPU performance, more and
> more corporate organisations are moving to a thinner client infrastructure.
> In addition, the cost benefits are also making the thin client ideal more
> attractive to educational establishments.
>
> With this in mind, what potential problems would this type of network
> present to a user requiring AT style applications?
>
> I know that Speech Despatcher works quite happily over this infrastructure ,
> but what about the other AT applications?
>
> Using LTSP as an example for Thin Client networks, they appear to offer a
> number of different ways of logging into the network - would any development
> as a result of discussions here be useable in a similar thin client network
> setup?
>
> Ian
>
> -----Original Message-----
> From: gnome-accessibility-list-bounces gnome org
> [mailto:gnome-accessibility-list-bounces gnome org]On Behalf Of Steve
> Lee
> Sent: 08 February 2008 10:50
> To: Brian Cameron
> Cc: Matthias Clasen; gnome-accessibility-list gnome org;
> gdm-list gnome org
> Subject: Re: [gdm-list] Bringing back a11y
>
>
> This is a fantastic discussion and many of my thoughts have been
> covered already. Perhaps it is worth getting a bit more abstract and
> thinking of a few scenarios so as to cover all uses.
>
> 1) Single user: They want their AT/a11y config(s) remembered at login
> and beyond. Arguably some may don't even want to login but I think
> that would not be a good idea.
>
> 2) multi user: Each user will need a unique AT/a11y config for login
> but don't know AT requirements until user is identified and at the
> moment this means logged in.
>
> 3) clinical/education/corporate: support staff will want to configure
> AT for individual users and ideally deploy remotely. Note here the
> user is not directly responsible for selecting their AT/a11y.
>
> Once better ways of identifying people arrive (biometrics, Near Field
> Computing, RFID etc. etc.). then the problem gets simplified as a
> users custom AT config could be automatically selected before
> authentication (login).
>
> 'Till then the solution has to be to provide sets of configs that can
> be easily selected before login, as discussed. Some predefined common
> cases and the ability add more should cover the scenarios. A simple
> list of named configs should be the simplest UI, with various gestures
> to access.
>
> As a bit of blueskying a 2 level system might work but it does seem
> more complex and may be unworkable. I'm thinking of a course selection
> for vis/mobil with simple gestures or selection by device used, that
> load ATs for selection of individual config using richer gestures.
>
> It occurs to me that we really want a extra layer of gesture
> abstraction where gestures on various devices (possibly more than one)
> get mapped to actions in the OS and applications. Failing that we have
> to map the gestures to standard input (key and pointer). The trouble
> is input and output are never quite so decoupled, as in the case of
> screen readers.
>
> --
> Steve Lee
> --
> Jambu - Alternative Access to Computers
> www.fullmeasure.co.uk
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>
>
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>
--
Steve Lee
--
Jambu - Alternative Access to Computers
www.fullmeasure.co.uk
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]