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

[Alan Elkner]

Tom,

I'm sorry I missed your points from your last post to this thread
before writing mine, so may I plead with your mercy to consider
overlooking the fact that we've (mind you I wasn't there) already been
down the schooltool UI road at sprints before.  I think this time, if
we remove the focus on code and continue to use those methods we used
succesfully in New Hampshire, you may find that you are very satisfied
at the end of the sprint.  Also, we're only talking about a minority
percentage of commitment of resourses and we have a much larger pool
this time.

So please consider indulging my request for what I consider to be a
vital process in making schooltool as usable as possible.

On Mon, Feb 25, 2008 at 1:37 AM, Alan Elkner <aelkner at gmail.com> wrote:
> 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
>  >
>