[moregroupware-interface] Future plan?

[Alan J. S. <ala...@vi...>]

> On 26/01/2004, at 10:46 PM, Karsten Dambekalns wrote:
> 
> Alan, I agree with you, the second idea will take longer but give
> better results. I think time is not that critical, we have technical
> issues to solve (just look at the bug tracker...), so we won't have to
> wait for you, I fear.
> 

Hi all,

Thanks Karsten, your effort with the mailing list is much appreciated
especially as I'm unsure why my email didn't get around... :^#

It seems like the consensus is to "do the job" properly. Personally, I
like the idea, particularly as there is little pressure on us in terms
of time: this gives us a chance to try and do a bang-up job on the
package and make it better than anything else around! Ryan's help will
be extremely valuable, particularly as he has contact with end-users.
This could be fantastic in terms of requirements gathering.

So what I suggest is this:

1) We perform some kind of requirements gathering exercise to better
understand how people are using MoreGroupWare - stuff like how often
it's used, in what context, what modules they use, how often and so on.
We can flesh out the details of this later if it's acceptable.
Obviously, the depth of this would depend on realistic constraints such
as access to users which can be a bit of a political issue with
companies trying to work their staff... ;^) Even something basic like a
2 page questionnaire would be useful though of course something more
esoteric like a diary study or short protocol study would help elicit
procedural knowledge.

2) Task analysis of the current package. This would be to better
understand (for people new to it) what it does and how, and would be
described in terms of the user. I've already started such a document,
but it's very early yet! Currently, I've begun doing some quick'n'dirty
K-GOMS analysis on the modules (just bits of the calendar so far) which
shows up some interesting stuff that may be of use. Once we know the
user requirements, we can work out the ideal interface and see where the
current one deviates.

3) Once we have a measure of the 2 points above, we should be in a good
position to build the interface around the users behaviour and
expectations by drafting some detailed guidelines for the graphic
designers to go to work on and make it look even more cool and sexy (do
we have any?).

Ryan - I'd be interested in looking at the UI documentation you did a
while back if you still have it (and don't worry if you feel it's awful! 
It could be quite interesting to see other peoples opinions, and besides 
the stuff I've done recently isn't looking too wonderful either!).

If anyone has any alternative suggestions or comments on the above, or 
any bits that they would prefer to work on, then please let fly!

Alan.
-- 
Alan James Salmoni
HCI Group
School of Psychology
Cardiff University

SalStat Statistics - http://salstat.sourceforge.net