[schooltool-dev] foo > manage or manage > foo ?
David Welsh
rdavidw at gmail.com
Mon Feb 25 16:49:26 EST 2008
OK. I (Welsh) read the log of today's SchoolTool dev mtg, with a lot of
discussion about the SchoolTool UI.
Welsh's main thoughts:
1) Totally uninitiated users should be able to look at the SchoolTool
screen, when logged in as a teacher, and figure out what the application
basically is about and what it does.
So I would put a row of tabs across the top that say:
Calendar Attendance
Competencies<http://www.careercenter.arlington.k12.va.us/cando/developers/ui_schtool/cando_admin.html>
Gradebook Resources
I also would put a phrase somewhere at the top that says: "web-based,
open-source software for managing school operations" (Jason thinks it just
should say, "web-based, school operations software"). Whatever, you get the
idea.
2) Start by writing the interface and navigation for TEACHERS. Students
will be a (simpler) subset of that. I agree that you don't have to touch
the management interface. Those users are super-users who don't need much
help, and there are not that many of them anyway.
3) When in a module, like CanDo, I think that there should be a SECOND ROW
of tabs under the first row of SchoolTool tabs. The SchoolTool tabs should
probably stay up so that users can switch quickly from competencies to
attendance. CanDo can serve as a good example of how these rows of tabs
might be designed.
4) MOCK-UP is everything. I do not think that these are super big
changes. But having an html, navigable mock-up allows all the developers to
shoot for the same target.
I think it's very important to pause and remember the main goals of
improving the UI:
1) A good UI makes clear what the app is and what it basically does
2) A good UI makes it fairly obvious (intuitive) where to go to accomplish
tasks
An amazing thing happened once we got the CanDo UI redesigned: WE NO LONGER
HAD TO TRAIN USERS HOW TO USE IT!!! And this is a really good thing,
because there is no one around to train the users, anyway. In fact, the
CanDo UI is good enough that that has been NO DEMAND for contextual help.
I really believe that SchoolTool can accomplish the same with some basic
improvements to its UI, along the lines I've enumerated here.
--David Welsh
On Mon, Feb 25, 2008 at 1:58 AM, Alan Elkner <aelkner at gmail.com> wrote:
> 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
> > >
> >
> _______________________________________________
> Schooltool-dev mailing list
> Schooltool-dev at schooltool.org
> http://lists.schooltool.org/mailman/listinfo/schooltool-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.schooltool.org/pipermail/schooltool-dev/attachments/20080225/5a39d5eb/attachment-0001.htm
More information about the Schooltool-dev
mailing list