[schooltool-dev] foo > manage or manage > foo ?

[Alan Elkner]

What I think is the top priority with the UI is to get a functioning
prototype of 90% of what we want the system to look like as quickly as
possible.  This is best done using prototyping software and iterative
usage/design feedbacks.  The sprint is the ideal environment for
combining close-session design work with the type of town hall, if you
will, bounce it off everybody feedback necessary with UI design.  We
won't know it's worth anything until we have lots of people that say,
"Hey, this is really easy to use".  This can all be achieved without
writing a single line of code!

Now I understand what Tom means about sprints being about writing
code.  Jeff says the same thing to me on many occasions.  I would only
argue that industrially speaking, the amount of work that is done
successfully prototyping a software system has a measure that can be
compared to that of the effort taken to write the code.  I'm not
saying an equal measure, but no small measure either.

So may I suggest that we allow the sprint to take some (20%?) of the
resouses from its main goal, deployments and packaging, and steal them
away to some small committee design sessions and some large
participation design feedback?  David Welsh is coming, so he will be
instrumental in providing some of the design effort as well as his
expertise using a MS prototyping tool that we used at the New
Hampshire sprint.

As far as exchanging emails over design, I agree with Ignas.  Coding
the UI is something that can be just fine by email, and we will have
plenty of time to do that after the sprint.  One possible exception is
that we could have interns working on page templates near at the end
of the design cycle when we are closer to nailing it down.  But even
that is not as important as getting the prototype right.

Another point Ignas made was about adding the new UI into the release
at the last hour.  I would agree that it would be unwise to change the
UI to that extent before nailing down the releases.  That's why,
again, I say no code, just prototypes, and if we start working up some
page templates, we do it in a branch as its own namespace package that
doesn't even get included into any of the upcoming releases.  We just
add it in later when the release cycle has been stable for a while.
In the meantime, anyone who wants the new package can manually install
it.

Can we strike this 20-80% balance of the two separate goals at the
sprint?  I hope so because I really think the UI is important.

On Sun, Feb 24, 2008 at 3:34 PM, Tom Hoffman <tom.hoffman at gmail.com> wrote:
> On Sun, Feb 24, 2008 at 1:49 PM, Ignas Mikalajunas
>  <ignas.mikalajunas at gmail.com> wrote:
>  > >  Well... the idea is to arrive at the sprint knowing what we're going
>  >  >  to implement, so I'd rather talk about it now.  What's your thinking,
>  >  >  Paul?
>  >  >
>  >  >  --Tom
>  >
>  >  Oh, news to me. I kind of thought that we were not going to implement
>  >  full UI in sprint, and only discuss it, so Alan (from what I can
>  >  recall he wanted to do redo schooltool UI, as I didn't really want to
>  >  do that) would know where to go when he will do the UI work by
>  >  himself.
>
>  Apparently I need to do a better job of sending Ignas emails after
>  talking to Alan and Jeff here.  Regardless, we still have plenty of
>  time to figure this out.
>
>  What I don't want to do is spend time at the sprint talking about UI.
>  We've done that at what, three other sprints, without much to show for
>  it.  I want to be writing code.
>
>
>  >  Is it really feasible to decide upon the UI using email, and then
>  >  implement it fully during a quite busy week without some serious
>  >  consequences like a code a quality hit and work that will have to be
>  >  performed after the sprint? Especially keeping in mind CanDo
>  >  integration and schooltool instance that is used by Lyceum.
>
>  Whatever we work on, it should be a manageable and achievable within
>  the context of a sprint.  Perhaps we just need to define the scope of
>  the UI changes so that they are feasible given the time and people
>  we'll have on hand.  One reason to do UI here is that we'll have
>  interns available who should be able to wrangle page templates.
>
>  Maybe if we limit the scope of our ambition to rearranging the
>  navigation (add tabs, ditch breadcrumbs, ditch navigation menu)
>  without doing anything too complicated to the way each component works
>  (coming up with a system to register admin views) that would be more
>  reasonable.  Just get the basic tabbed paradigm into the trunk, even
>  if it isn't as completely implemented as we can imagine.
>
>  Anyhow, there's plenty of time to discuss it.
>
>  --Tom
>
>
> _______________________________________________
>  Schooltool-dev mailing list
>  Schooltool-dev at schooltool.org
>  http://lists.schooltool.org/mailman/listinfo/schooltool-dev
>