Ubuntu Wiki

• Launchpad Entry: ubuntu-education-app-bundles

• Created: December 07 2008

• Contributors:

• Packages affected:

Summary

Education Application Bundles

Provide a way for the user to select a bundle of Education Applications which are appropriate for a particular education level:

• by school level option
• by age option

The requirement is in effect a simple way to do a "bulk selection of apps" for "bulk" installation from the application list available from the repository(ies)

Release Note

This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.

Rationale

Currently, the available education applications are not categorised or described in such a way that is is simple for the average:

• teacher
• school network admin
• home user student
• home user parent

to identify which applications are applicable / suitable for their requirements.

It would be useful to have the bundle selection available:

1. in Add/Remove as selections under {Education category

2. Included as an install option when using the Ubuntu Education CD

Use Cases

1. Mr Jones : Parent

Mr Jones has installed Ubuntu on his home PC. He has a daughter who is 10 years old and attends school in Grade 4. He is aware of that the Applications menu has an Education category and decides to open Applications → Add/Remove ... to find and install more education applications. Inside Add/Remove ...  he selects the Education category and finds 4 bundle options at the top of the list:

• Pre-School Bundle
• Primary Bundle
• Secondary Bundle
• Tertiary Bundle

He then:

1. highlights Primary Bundle and reads the description, and finds that this best fits his daughter's profile.

2. selects the Primary Bundle checkbox

3. clicks Apply changes

4. is presented with a list of applications that are about to be installed as per his bundle selection.
5. reviews this list to deselect any applications he does not want
6. he is warned which applications are community supported, and not officially supported by Canonical.

2. Ms Smith : Teacher

Ms Smith has Ubuntu installed on her school PCs. The school covers Grades 1-10. She is aware of that the Applications menu has an Education category and decides to open Applications → Add/Remove ... to find and install more education applications. Inside Add/Remove ...  Se selects the Education category and finds 4 bundle options at the top of the list:

• Pre-School Bundle
• Primary Bundle
• Secondary Bundle
• Tertiary Bundle

She then:

1. highlights Primary Bundle and reads the description, and finds that this partially fits the school profile.

2. selects the Primary Bundle checkbox

3. highlights Seconday Bundle and reads the description, and finds that this also partially fits the school profile.

4. selects the Seconday Bundle checkbox

5. clicks Apply changes

6. is presented with a list of applications that are about to be installed as per his bundle selection.
7. reviews this list to deselect any applications he does not want
8. he is warned which applications are community supported, and not officially supported by Canonical.

• Note that there will be overlap of applications across Primary & Secondary

• Note that there may be applications in a bundle that are already previously installed

Assumptions

Design

The following 4 bundle options are proposed:

• Pre-School
• Primary
• Secondary
• Tertiary

The user would be able to choose one of these options, and this would select all the apps that match the level.

User can see the suggested selection list, and:

1. be warned which applications are "not officially supported" before installation commences
2. remove applications / modify the list before the install or download initiates

See attachment for categorisation of applications attachment:Ubuntu-Edu-Apps-education-&-games.ods

Requires a review of:

1. Any new Education applications for Jaunty
2. Any removed Education applications for Jaunty

3. A second eye to go over the School Classification levels to confirm 1st pass by RichEd

4. A quality check to gauge which applications should be included or excluded

Suggestions from LaserJock

Here are a few alternative approaches:

1. a whole new category in the Add/Remove window called "Education Bundles" or similar that would contain the bundles.

   • Pros: don't need to figure out how to make bundles show up first in Education, separation between "bundle" and "app" concepts.

   • Cons: new top-level category which is not in the user's menu (breaks Add/Remove design), people might expect "bundles" for other areas.

2. a new menu entry in System → Administration called "Education Software Installer". This would call up Add/Remove with a custom menu (like what we do on the Ubuntu Education CD already). This menu would have a finer categorizations for Educational software (math, science, language, teacher tools, etc.). Importantly, it could also have categorizes representing the bundles so that one can install a bundle but also see the individual apps alongside.

   • Pros: provides an education-specific tool, easiest to implement I think, allows for finer categorization.

   • Cons: adds another entry to the System → Administration menu

Other notes:

• Using actual packages for the bundles would allow us to ship bundle-specific menus, artwork, and even documentation.

• I think it's redundant to warn users about "not officially supported" as that's show in the Add/Remove UI.

Implementation

UI Changes

In the Education category of the Add/Remove window:

1. 4 new options available for selection

   1. Pre-School

   2. Primary

   3. Secondary

   4. Tertiary

2. bundle options should appear at the top of the list

   • requires a new general description against all 4

     1. what the concept of a bundle is
     2. what a bundle selection will offer the user

   • requires a new specific description for each of the 4

     1. what user school level this specific bundle is aimed at
     2. what user age level this specific bundle is aimed at

   • note that school classification varies across countries ... needs to be general

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

• data migration

  • assumption is none

  • get consensus

• redirects from old URLs to new ones

  • assumption is none

  • get consensus

• how users will be pointed to the new way of doing things

  • requires user documentation on http://www.edubuntu.org

  • suggested "feature offering" on http://www.ubuntu.com/education

  • suggested "feature offering" on press release for Jaunty
  • suggested "feature offering" on edubuntu mailing lists

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

CategorySpec CategoryEducation