Metapackages for accessibility

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Metapackages for accessibility

Andreas Tille-5
Hi,

at LSM in Bordeaux I talked with Samuel about metapackages as they are
builded in the Blends framework for Debian Accessibility (see my talk at
LSM [0]).  He also told me that Mario is fine with this idea (Mario it's
a shame that we did not talked to each other -  I was once passing you
when you were sitting on a booth but I was in a hurry and then I have
not seen you any more.

The current work in the direction of metapackages is done as so called
tasks files in the Debian Pure Blends svn[1].  These tasks files are
quite simple dependency lists and can be rendered into so called tasks
pages[2] and bugs pages[3] which you hopefully like for your comfort in
maintaining accessibility related packages in Debian.

Because I'm not personally involved in accessibility programs I have
done the categorisation with the help of Samuel.  I would like you to
have a look at the categorisation [2] and if you have any remarks or
enhancements I'm keen on hearing your opinion.

I wonder whether you might like to give me some input on this (patches
to the tasks files or even unformatted comments are fine) and whether it
might make sense to also generate some metapackages which can be used to
simplify the installation of accessibility software easily on a Debian
machine.

I would consider it as a good idea to do so because this might enable
pointing to the Debian Accessibility project in the release notes for
Squeeze which will probably increase the popularity of the Debian
Accessibility project amongst Debian users and makes Debian more
attractive in this field.

Kind regards

     Andreas.

[0] http://people.debian.org/~tille/talks/201007_lsm_acc/index_en.html
[1] svn://svn.debian.org/blends/projects/accessibility/trunk/accessibility
[2] http://blends.alioth.debian.org/accessibility/tasks
[3] http://blends.alioth.debian.org/accessibility/bugs


--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20100720151555.GB19217@...

Reply | Threaded
Open this post in threaded view
|

Re: Metapackages for accessibility

Mario Lang-2
Andreas Tille <[hidden email]> writes:

> at LSM in Bordeaux I talked with Samuel about metapackages as they are
> builded in the Blends framework for Debian Accessibility (see my talk at
> LSM [0]).

[...]

> The current work in the direction of metapackages is done as so called
> tasks files in the Debian Pure Blends svn[1].  These tasks files are
> quite simple dependency lists and can be rendered into so called tasks
> pages[2] and bugs pages[3] which you hopefully like for your comfort in
> maintaining accessibility related packages in Debian.

The webpages are a nice thing to have, I agree.

> Because I'm not personally involved in accessibility programs I have
> done the categorisation with the help of Samuel.  I would like you to
> have a look at the categorisation [2] and if you have any remarks or
> enhancements I'm keen on hearing your opinion.
>
> I wonder whether you might like to give me some input on this (patches
> to the tasks files or even unformatted comments are fine) and whether it
> might make sense to also generate some metapackages which can be used to
> simplify the installation of accessibility software easily on a Debian
> machine.
Regarding metapackages I see some useful categories
like "braille-transcription", "development-tools", "ocr", and maybe
"X11".

The rest, I am actually not so sure about:

 * "applications" looks like too generic to be useful.
 * "console-screen-reader" has several solutions which
   the user is not likely to use at once.  More likely is that
   they pick one and use it.  But installing all of them might
   lead to conflicts maybe?
 * "emacs-extensions" is the same problem.  People are going
   to use either emacspeak or speechd-el but definitely not both at
   once.
 * "gnome" looks neat but the problem is already solved in a better way.
   GNOME actually considers accessibility a core part of its
   infrastructure which means that pkg-gnome is already pulling most of the
   required stuff at least via Recommends.  I consider this a great
   thing and the way to go, thanks GNOME!
 * Most of what is in "speech-synthesis" is going to be pulled via Depends.
   I am not sure how useful it is to just install everything there is.

> I would consider it as a good idea to do so because this might enable
> pointing to the Debian Accessibility project in the release notes for
> Squeeze which will probably increase the popularity of the Debian
> Accessibility project amongst Debian users and makes Debian more
> attractive in this field.

Well, we can already point at these nice webpages, can't we?

--
CYa,
  ⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/>
  .''`. | Get my public key via finger mlang/[hidden email]
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-      <URL:http://delysid.org/>  <URL:http://www.staff.tugraz.at/mlang/>

attachment0 (195 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Metapackages for accessibility

Andreas Tille-2
On Tue, Jul 20, 2010 at 09:29:34PM +0200, Mario Lang wrote:
> The webpages are a nice thing to have, I agree.

:-)
 
> Regarding metapackages I see some useful categories
> like "braille-transcription", "development-tools", "ocr", and maybe
> "X11".
>
> The rest, I am actually not so sure about:

Well, the reason to send this mail was to make sure everything makes
sense and I really have to relay on your input.
 
>  * "applications" looks like too generic to be useful.

Well, it has only one dependency anyway, perhaps we can move this to
some other task and drop the applications task.  Suggestions?

>  * "console-screen-reader" has several solutions which
>    the user is not likely to use at once.  More likely is that
>    they pick one and use it.  But installing all of them might
>    lead to conflicts maybe?

Could somebody check the chance of a conflict?  We can also implement an
or relation for the metapackage and it remains listed equally on the
tasks web page.

>  * "emacs-extensions" is the same problem.  People are going
>    to use either emacspeak or speechd-el but definitely not both at
>    once.

So the or relation seems to make sense here as well (just implemented
in this task as an example).

>  * "gnome" looks neat but the problem is already solved in a better way.
>    GNOME actually considers accessibility a core part of its
>    infrastructure which means that pkg-gnome is already pulling most of the
>    required stuff at least via Recommends.  I consider this a great
>    thing and the way to go, thanks GNOME!

OK, so a accessibility metapackage seems to be redundant here.  It is
nice for the tasks pages anyway and does not really harm to have another
way to advertise pkg-gnome, right.  The question would probably be:
Would it be reasonable to just depend from pkg-gnome in the
accessibility-gnome metapackage or should we also list all the pkg-gnome
dependencies - if we would decide to keep this metapackage instead of
droping it. I'm in favour of keeping it for consistency reasons: If we
want to maintain all accessibility packages (which should be listed for
instance on the bugs pages and other QA means, perhaps building a live
CD or dedicated installers) we need to keep track of these packages.

>  * Most of what is in "speech-synthesis" is going to be pulled via Depends.
>    I am not sure how useful it is to just install everything there is.

We can use Suggests instead - just tell me what you prefer.
 
> > I would consider it as a good idea to do so because this might enable
> > pointing to the Debian Accessibility project in the release notes for
> > Squeeze which will probably increase the popularity of the Debian
> > Accessibility project amongst Debian users and makes Debian more
> > attractive in this field.
>
> Well, we can already point at these nice webpages, can't we?

Sure we can but installation wise metapackages (or tasks for tasksel,
which will be in the package accessibility-tasks) ae IMHO quite handy.
I agree you had some points above but IMHO the advantages are higher
compared to your concerns above which are in my opinion no real
arguments against this approach.

Kind regards

    Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20100720213706.GB2220@...

Reply | Threaded
Open this post in threaded view
|

Re: Metapackages for accessibility

Samuel Thibault-8
In reply to this post by Mario Lang-2
Mario Lang, le Tue 20 Jul 2010 21:29:34 +0200, a écrit :
>  * "console-screen-reader" has several solutions which
>    the user is not likely to use at once.  More likely is that
>    they pick one and use it.  But installing all of them might
>    lead to conflicts maybe?

We talked a bit more with Mario on IRC. In a lot of cases, it indeed
doesn't make sense to run several screen readers at the same time. It
would then make sense to not start them by default. But then it's a pain
for people who'd just expect apt-get install brltty to be enough to get
started. This looks to me similar to the xdm vs gdm vs kdm issue: only
one gets started, according to the user preference. I'm not sure whether
we really want to go into that complexity, however.

Now, what such package would be useful for?  Mario thinks that a pitfall
would be to make people believe that merely installing those will be
sufficient to be accessible, which is clearly not the case: making a
workstation accessible means starting and configuring a precise set of
tools that the user will be able to use and combine, as well as
configuring some system parameters, etc.  A mere meta-package doesn't
help at all here, but might even hurt in that people would think it's
sufficient.

Actually, I'd tend to think that it raises the question I've discussed a
bit in LSM 2010's OS session: ideally, somebody with disability should
be able to go to a public box, plug some USB stuff or press some
shortcut, and get accessibility tools to let him use the box. This might
sound as a too idealistic example, but that's what should really ideally
happen.  And that's what should happen for accessible liveCDs (be it a
standard system, or some teaching material, etc.).

So maybe instead of these meta-package there should be some packages
which provide tools that have these dependencies, and provide some tools
to choose and configure accessibility tools. Like a control panel,
shortcuts, etc.

>  * "gnome" looks neat but the problem is already solved in a better way.
>    GNOME actually considers accessibility a core part of its
>    infrastructure which means that pkg-gnome is already pulling most of the
>    required stuff at least via Recommends.  I consider this a great
>    thing and the way to go, thanks GNOME!

I think it's probably better to let gnome do its own integration rather
than trying to follow what's happening in the gnome world.

>  * Most of what is in "speech-synthesis" is going to be pulled via Depends.
>    I am not sure how useful it is to just install everything there is.

It might make sense in the same way as locales-all is used for: just
provide speech synthesis for as many languages as possible, served via
speech-dispatcher.  Ideally that should be available on all liveCDs, but
there's still the same issue: it should probably not be started by
default due to its heaviness?

> > I would consider it as a good idea to do so because this might enable
> > pointing to the Debian Accessibility project in the release notes for
> > Squeeze which will probably increase the popularity of the Debian
> > Accessibility project amongst Debian users and makes Debian more
> > attractive in this field.
>
> Well, we can already point at these nice webpages, can't we?

That's already a good point, yes.
I'd even say Meta-packages are not so much useful compared to that.

Samuel


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20100721194629.GB6485@...

Reply | Threaded
Open this post in threaded view
|

Re: Metapackages for accessibility

Andreas Tille-5
[CC to debian-blends because of some general ideas]

On Wed, Jul 21, 2010 at 09:46:29PM +0200, Samuel Thibault wrote:

> Mario Lang, le Tue 20 Jul 2010 21:29:34 +0200, a écrit :
> >  * "console-screen-reader" has several solutions which
> >    the user is not likely to use at once.  More likely is that
> >    they pick one and use it.  But installing all of them might
> >    lead to conflicts maybe?
>
> We talked a bit more with Mario on IRC. In a lot of cases, it indeed
> doesn't make sense to run several screen readers at the same time. It
> would then make sense to not start them by default. But then it's a pain
> for people who'd just expect apt-get install brltty to be enough to get
> started.

That's perfectly true.  BTW, I'm normally not on IRC but I would happily
join an IRC meeting in evening hours.
 
> Now, what such package would be useful for?  Mario thinks that a pitfall
> would be to make people believe that merely installing those will be
> sufficient to be accessible, which is clearly not the case: making a
> workstation accessible means starting and configuring a precise set of
> tools that the user will be able to use and combine, as well as
> configuring some system parameters, etc.  A mere meta-package doesn't
> help at all here, but might even hurt in that people would think it's
> sufficient.

I think I understand now a bit better what Mario tried to tell me last
year.  However, you perhaps might call me stubborn, but don't you see
any chance to really make it sufficient?  IMHO we have the tools which
are needed in Debian to aproach this.  If every screen reading package
would provide a virtual package screenreader (and perhaps - I can not
tell how much sense this makes conflicts to other screenreaders to make
sure there will not be conflicting packages installed) and we design a
metapackage which

  Recommends: screenreader | <the-most-favourite-screenreader>
  Suggests: other screenreaders

we just need to define what is our most favourite screenreader.  You
might see a conflict with the freedom of choice here, but IMHO expertise
is also making a choice.  A newbee will be happy about a reasonable
choice somebody has done in advance.  The freedom is guaranteed because
nobody will prevent you from exchanging the screenreader by some other
package which provides this functionality.

> Actually, I'd tend to think that it raises the question I've discussed a
> bit in LSM 2010's OS session: ideally, somebody with disability should
> be able to go to a public box, plug some USB stuff or press some
> shortcut, and get accessibility tools to let him use the box. This might
> sound as a too idealistic example, but that's what should really ideally
> happen.  And that's what should happen for accessible liveCDs (be it a
> standard system, or some teaching material, etc.).

... which is totally in line with what I said: Somebody has to make a
choice what will happen if this person is pushing the button you
mentioned.
 
> So maybe instead of these meta-package there should be some packages
> which provide tools that have these dependencies, and provide some tools
> to choose and configure accessibility tools. Like a control panel,
> shortcuts, etc.

Well, the metapackages as they are builded by the Blends tools can carry
more than only Dependency relations.  You can perfectly design all
{pre,post}{inst,rm} scripts as well as debconf.  You also can add extra
content like scripts which might provide an easy to use (debconf-alike)
interface to select and start one of the screenreaders which are
installed by the metapackage.

The idea is: How can I make users life easier.  IMHO doing nothing and
let find out the user himself what fits best is not easy.  I think
making some reasonable decisions is better and we have two ways to
enable decision making in the Blends framework: Metapackages and tasksel
definitions.  Both are created from the tasks files by using blends-dev
packaging tools.  Tasksel is IMHO to simple because it is lacking the
"suggsts" functionality (for either not so important or
contrib/non-free) and has also not the feature of extra scripts as
mentioned above.  If you know another way to "make decisions about
installation" which might fit better - I would be interested.  Otherwise
I would suggest to dive a bit deeper into the features we really have
which might be useful or perhaps you might have ideas about features
which need to be implemented to make it easy for disabled users to get
a box running as quickly as possible.
 
> >  * "gnome" looks neat but the problem is already solved in a better way.
> >    GNOME actually considers accessibility a core part of its
> >    infrastructure which means that pkg-gnome is already pulling most of the
> >    required stuff at least via Recommends.  I consider this a great
> >    thing and the way to go, thanks GNOME!
>
> I think it's probably better to let gnome do its own integration rather
> than trying to follow what's happening in the gnome world.

My suggestion[1] was about two options: One was do mention every
accessibility related package in Gnome explicitely and the other option
was to recommend Gnome in general.  Your statement implies that you are
in favour of the latter which is fine.  In the sense what I said above:
I would iron out this decision in some code (=metapackage or other
means) ... while leaving the freedom of choice in case the user has
different preferences.

> >  * Most of what is in "speech-synthesis" is going to be pulled via Depends.
> >    I am not sure how useful it is to just install everything there is.
>
> It might make sense in the same way as locales-all is used for: just
> provide speech synthesis for as many languages as possible, served via
> speech-dispatcher.  Ideally that should be available on all liveCDs, but
> there's still the same issue: it should probably not be started by
> default due to its heaviness?

If you just put it on suggests we just raise the awareness of the user
without pushing him to really install this stuff.
 

> > > I would consider it as a good idea to do so because this might enable
> > > pointing to the Debian Accessibility project in the release notes for
> > > Squeeze which will probably increase the popularity of the Debian
> > > Accessibility project amongst Debian users and makes Debian more
> > > attractive in this field.
> >
> > Well, we can already point at these nice webpages, can't we?
>
> That's already a good point, yes.
> I'd even say Meta-packages are not so much useful compared to that.

Again, just call me stubborn, but IMHO you are underestimating the power
of metapackages.  I can not exclude that you are finally right but you
seem to understand that installing a metapackage is a simple process
where everything which is in the list of dependencies will simply be
installed and fullstop.  You have not discussed the usage of virtual
packages, the differentiation between Depends/Recommends/Suggests, the
default {pre,post}{inst,rm} and config scripts as well as the extra
workload we might add for other means.

In my eyes a metapackage is some kind of technically realising a
decision some knowledged people (you, the accessibility team in this
case) have made and will be ironed out in recommendations of different
strengthes to the uneducated user.  IMHO it is just a question how
clever you design the metapackage to fullfill this purpose.

Kind regards

        Andreas.

[1] http://lists.debian.org/debian-accessibility/2010/07/msg00015.html

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20100722070159.GA10150@...

Reply | Threaded
Open this post in threaded view
|

Re: Metapackages for accessibility

Samuel Thibault-8
Andreas Tille, le Thu 22 Jul 2010 09:01:59 +0200, a écrit :
> In my eyes a metapackage is some kind of technically realising a
> decision some knowledged people (you, the accessibility team in this
> case) have made and will be ironed out in recommendations of different
> strengthes to the uneducated user.  IMHO it is just a question how
> clever you design the metapackage to fullfill this purpose.

The problem with accessibility is that you can not make such decision.

It's an area where you can not define a default value, as the possible
combinations of disabilities are numerous, and thus the combination of
tools to be used by a user are even more numerous (since it also depends
on taste, workflow, etc.).

Samuel


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20100722084452.GA5982@...

Reply | Threaded
Open this post in threaded view
|

Re: Metapackages for accessibility

Andreas Tille-5
On Thu, Jul 22, 2010 at 10:44:52AM +0200, Samuel Thibault wrote:
> The problem with accessibility is that you can not make such decision.
>
> It's an area where you can not define a default value, as the possible
> combinations of disabilities are numerous, and thus the combination of
> tools to be used by a user are even more numerous (since it also depends
> on taste, workflow, etc.).

This is what Mario told me and what I not really forgot.  What I wanted
to say is that you can even present a list of recommendations to enable
the user selecting from this list (perhaps enhanced by a short
explanation of the options to choose from).  It seems perfectly doable
in a debconf script to tell the user that the metapackage will install
screen readers A, B and C with the features ... and he has to select one
of them which will be activated later.  To switch to a different
screenreader dpkg-reconfigure could be used.

Giving the user an educated advise is actually is a decision.

Kind regards

       Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20100722090922.GE12400@...

Reply | Threaded
Open this post in threaded view
|

Re: Metapackages for accessibility

Andreas Tille-5
In reply to this post by Andreas Tille-5
On Thu, Jul 22, 2010 at 07:01:07PM +0200, Jonas Smedegaard wrote:

> Above Samuel says that in a *lot* of cases multiple screen readers do  
> not make sense.  But does not go as far as claiming that in *all* cases  
> is that true.
>
> I therefore do not like conflicts here.
>
> Perhaps a mechanism like the XDM/GDM/KDM/NODM one would make sense here?
>
> That is, allow multiple packages to be installed concurrently, but have  
> them coordinate to only by default enable one of them.  That way in  
> esoteric cases[1] where it might make sense to use multiple screen  
> readers, it is possible to hack the startup script (and evolutionary  
> convince package maintainers to instead improve that script) instead of  
> being forced to hack the binary packages.

When I wrote my mail about using a debconf question in the metapackage
I've thight about something like putting a configurable variable into

  /etc/defaults/screenreader

which contains lines like

  SCREENREADER_A=yes
  SCREENREADER_B=no
  ...

and use something like

test -f /etc/default/screenreader && . /etc/default/screenreader

if [ "$SCREENREADER_A" = "yes" ] ; then
        startupcode
fi

(or something a bit more sophisticated, but you see the principle).

That should be quite easy to implement because all relevant screenreader
packages are under control of the Debian Accessibility team and this
change could be implemented quite easily.

Kind regards

    Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20100722193253.GA9265@...

Reply | Threaded
Open this post in threaded view
|

Re: Metapackages for accessibility

Mario Lang-2
In reply to this post by Andreas Tille-5
Andreas Tille <[hidden email]> writes:

> I wonder whether you might like to give me some input on this (patches
> to the tasks files or even unformatted comments are fine) and whether it
> might make sense to also generate some metapackages which can be used to
> simplify the installation of accessibility software easily on a Debian
> machine.

A few more observations and random thoughts about this (and related)
issues:

 * The "apps" tasks is very ambigious and overlaps with packages tags:
   It currently contains edbrowse, which was originally written
   by a blind user, but is not really accessibility-specific, at least
   not if seen from a certain perspective.  The interface of
   edbrowse can be appealing to everyone who likes ed-alike interfaces
   or needs scripting.  The current website of edbrowse
   actually hightlights that fact.

   It feels alot more useful to solve the application categorisation
   problem with package tags, which has also been discussed at several
   occasions in the past.  This actually also fits a lot more
   the problem of accessibility being so vague, whats accessible to one
   type of user might be inaccessible to some others, even if they
   have the same disability (speech vs. braille as an example).

   So what we really want is a nice set of tags which can be used to
   find packages which are accessible in a certain way.  Some are already
   there, like the ones which identify ncurses and command-line
   interfaces.
   We should probably add one which can be used to tag packages
   which use an accessible toolkit and have been verified to work (no
   custom inaccessible widgets and so on).
   (The Orca wiki is a good starting point for a list of apps which work
    to a certain degree.)

   I think we should drop the apps task altogether.

 * Toolkit tasks:
   1. Where do we put mono-winforms-a11y?

   2. Should we drop the gnome task since they are already handled via
      recommends?

 * natbraille is wrongly categorized, it should be in braille, not
   console.

--
CYa,
  ⡍⠁⠗⠊⠕


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/87d3ubsm2l.fsf@...

Reply | Threaded
Open this post in threaded view
|

Re: Metapackages for accessibility

Andreas Tille-2
On Sun, Jul 25, 2010 at 03:55:14PM +0200, Mario Lang wrote:
>  * The "apps" tasks is very ambigious and overlaps with packages tags:
>...

I tried to follow the categorisation in the Wiki (website??).  Just
dropped the task which seems to be in fact useless featuring only one
package.
 
>    It feels alot more useful to solve the application categorisation
>    problem with package tags,

What do you mean with "package tags"?  Do you mean DebTags?
In fact I'm considering a closer connection between DebTags and the
Blends stuff but I have not yet made up my mind about this.
 
>  * Toolkit tasks:
>    1. Where do we put mono-winforms-a11y?

I do not really understand this question.  Please be more verbose what
package to put in which category if some decision is made.

>    2. Should we drop the gnome task since they are already handled via
>       recommends?

Where is it recommended?  If you ask me I would not drop the task even
if it might add some redundency.
 
>  * natbraille is wrongly categorized, it should be in braille, not
>    console.

It was also in braille (but only as suggests) but was not showing up
there because I had the extra information for the prospective package
only in one task file.  I moved it now to braille.  We might find a
final solution once it is really available as Debian package.

Kind regards

       Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20100726072805.GA25729@...