Summarizing menu wishlist design
Hi,
Shaleh and others were very helpful in hashing out with me what we want in
a menu system. Thanks to everyone who contributed.
The design we'll go with for the Debian Jr. menu is as follows:
- Make a separate hierarchy for Debian Jr. which can be categorized
into groups that make sense for children.
- We considered at first just making the Debian Jr. menus a subset
of the main menus and not restructuring them at all. This approach
fell out of favour when we realized that categories such as "Graphics"
and "System" aren't necessarily sensible for children. Instead,
we might want "Coloring" (or "Drawing" or "Art"), "Writing", and
eliminate meaningless abstractions like "Apps" and "System",
preferring more concrete, "what can I *do* with this" categories
instead.
- The separate hierarchy requires, we believe, support not presently
in the "menu" package. Namely, the automatic generation of multiple
root menus by update-menus, one per user "class". Initially, there
would be two user classes, "full" and "debian-jr". A user's account
can be set up to use one or the other.
- Stick with one menu for children age 8 and under rather than creating
one per subgroup.
- While one menu per subgroup may make sense in a school computer lab
stituation, at home siblings interact a fair amount when they are
learning to use the computer. It is helpful, therefore, to have
the same navigational aids present on the older children's accounts
as well as the younger. That way, an 8 year old big sister can help
her 5 year old little brother while he is on his account, as she will
be familiar with where everything is. Besides, making materials that
are beyond a child's level available means she can choose to try them
out whenever she is ready to and explore them instead of requiring
the sys admin's intervention to enable that exploring experience.
- While this may work for children between ages 5 and 8, for the very
small children, menus are going to be of limited use anyway. There
is little point in suppressing the menus, though. We will simply
provide a different navigational aid, such as a button bar, wharf,
or other "geographical" organization of programs for the child.
- Put the menu hierarchy in a debian-jr-menu package instead of tagging
individual packages.
- We rejected the "tag the individual packages as 'debian-jr'" approach
because it involves touching too many packages.
- Besides, having a separate -menu package opens up the possibility
for other groups to provide their own menu hierarchies to suit
the needs of different "classes" of user sharing the same Debian
system (e.g. a computer lab that has a different "class" of user
for each age-range or grade, and hence a different menu hierarchy)
- Leave out a rating system for now. Inclusion in Debian Jr. menus is
a simple yes/no decision made by the Debian Jr. project.
- This is simplest from our point of view as developers. Ratings take
time to maintain and are subjective (read, prone to lengthy and
unproductive disputes). If user groups with specific needs want
ratings in future and take the initiative, we can look at that point
at providing technical support for them. It shouldn't be too
difficult to implement one or more foo-ratings packages along the
same lines as the debian-jr-menu package, only including ratings
on various different scales.
I'll present this design to the "menu" developers as a wishlist for the
"menu" package at the end of the week unless we have other things to add
or amend by that time.
Thanks,
Ben
--
nSLUG http://www.nslug.ns.ca synrg@sanctuary.nslug.ns.ca
Debian http://www.debian.org synrg@debian.org
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
Reply to: