[schooltool-dev] PyCon Sprint proposal v.2

[Tom Hoffman]

This is take two of a general UI strategy for the PyCon '08 sprint.
The first version was too ambitious in scope.  Also, it is a response
to and amalgamation of points raised in the subsequent discussion.

There is general agreement that SchoolTool needs ongoing, iterative
improvement of its user interface, with regualar feedback from real
users.  This is one reason we've taken great pains to have developers
collaborate with local schools.

However, there are some kinds of changes which just aren't
incremental, and require a leap.  SchoolTool needs to make a leap away
from its "traversing the object hierarchy" navigation paradigm to a
more standard, task-oriented tabbed interface.  Essentially, we need
to figure out the least practical amount of abrupt change that we can
make at the sprint that can form the basis of the next several years
of iterative development.  That is, we are not trying to design the
tabbed interface of our dreams (see version one...) but to figure out
how to manage the first big, irreversible step in that direction.

To frame this in terms of release goals and immediate usage, I expect
Alan would make the switch as quickly as possible to roll out the
initial SchoolTool functionality at SLA using the new interface.
Ignas would not have much incentive to switch Lyceum during the school
year.  Also, it is not important that the Hardy release of SchoolTool
include these changes.  If adoption of the tabbed UI is going to
happen at different sites at different times, it is a requirement that
the overall navigation redesign not require changes to individual
components.

So why is this required at all?  Particularly now?  In October we'll
release SchoolTool 1.0 beta.  We shouldn't completely rearrange
navigation in the application after the beta.  We also shouldn't do it
for at least a year after we release 1.0, and probably two years.  At
EuroPython we'll be making final cuts and fixes to the beta, so it is
now or in 2010 or 2011.  Once we have tabs, we can get away with
improvement within that paradigm over the next couple years, but this
is the last chance for a while to make the switch.

Our medium term goals for this work are:

* a tabbed interface for SchoolTool 1.0 beta in Ubuntu Intrepid Ibex;
* all SchoolTool and CanDo sites using the tabbed interface in fall '08;
* minimal forking of code in the meantime.

----------------------

Specific Sprint Goals

Global changes:

* The red bar will go away -- no breadcrumbs, etc.  We'll have to move
the login/user info, probably to the upper right corner (and then move
the devmode menu...).

* The navigation menu will go away.

* There will be a row of tabs.  Tabs will link to (in CanDo parlance),
a "go page," which provides additional navigation.  Packages have to
be able to register a tab or tabs.

* The action menu will probably change.  I'd like to see it rendered
as a row of buttons below the tab bar, but we'll have to work through
the various possibilities.  Having it remain exactly as is for the
time being would not be the end of the world.

Tabs:

Calendar: links to the existing main calendar page.

Gradebook/Lyceum journal/attendance: link to a go page that links to
the relevant views in "sections you teach" and "sections you attend"
or something to that effect.  Other links to reports, etc. can be here
as well.

SLA tabs: ???

Cando: CanDo's shouldn't have any trouble adapting their interface to
sit under one or more SchoolTool tabs.

"SchoolTool" tab: the messy bit is everything else.  I think it is
acceptable to stuff the remaining parts of the existing interface
under a tab that says "SchoolTool" or something else cryptic and
non-commital.  The existing "navigation" menu could be the basis of a
second row of tabs for "people," sections," etc.

Let's say I click on an individual student in my gradebook; I should
end up under the "schooltool" tab and the "people" sub-tab, looking at
their demographic data.

If I want to add a section, I could select "schooltool" then
"sections" then "add section" from however the action menu is
implemented.

The go view for this tab could have a lot of useful short cuts: "Would
you like to... add a student? create a new section?" etc.

Making sure these views know what tabs should be activated when you're
looking at a given view is probably a minor to moderate pain.

Future details:  A dashboard and dashboard tab are desirable in the
future.  Setting a default tab for each user is desirable.  Both these
are outside the scope of this sprint, however.

--Tom