Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2001:
[Freeciv-Dev] Re: Documentation, Usability and Development

[Freeciv-Dev] Re: Documentation, Usability and Development

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Andrew Sutton <ansutton@xxxxxxx>
Cc: Freeciv Developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: Documentation, Usability and Development
From: Justin Moore <justin@xxxxxxxxxxx>
Date: Wed, 28 Nov 2001 00:40:39 -0500 (EST)

> > It talks about what the average user wants in terms of documentation, but
> > also drifts into usability.  Freeciv may have a pretty good game engine
> > under the hood and be pretty flexible, but quite frankly the UI leaves a
> > lot to be desired.  And I'm not just talking about the dialog boxes or
> > which mouse buttons do what.  I'm talking about just getting the game up
> > and running.
> > <snip>
> actually, alot of what you're saying is some of the general principles
> behind software engineering - more focused at the gui and usability,
> but software engineering indeed - something i've learned to really,
> really appreciate in my 2 years since graduating college (are you
> taking a class or something?)

   Have taken, not taking.  I took two software engineering classes as an
undergrad, but about 60% of what I learned was more geared towards
learning buzzwords to impress managerial-types (i.e., "I can do COCOMO
estimates!"  "Ooooh.  Aaaaah.")  The other 40% was moderately useful. Most
of what I've learned about average user/computer interaction has been
through feedback of my own programs and (amusingly enough) trying to help
my fiancee navigate her way through KDE this summer (I don't have Windows
on my computer).  She learned very quickly, but at times I was reminded of
how quickly non-CS geeks tire of small problems ("I don't care if
Microsoft is or is not playing fair or breaks compatibility with its own
programs, I just want to be able to edit Word documents!").

> anyway, if you're going to start ranting about quality, requirements,
> testing, and configuration management, then don't stop there :) talk
> about problem domain analysis, solution domain, some of the real stuff
> that drives good development.

   Actually I think it's a very good place to stop.  Otherwise we enter
some pipe dream-esque world where everyone is happy, the software is
perfect, and all users are competent.  I wanted to lay out some clear,
concise goals that people can start working on now.  The bottom line is
that we need involvement from more people, and right now I think newcomers
are eyed with a bit more distrust than usual; I know I made a few stupid
posts when I started here, but in the last few months I've seen the same
patterns emerge when new blood pops up.

   Rigid code analysis and formal software development methods are not the
way to excite and motivate people into helping.  Cool features that serve
a purpose and that will draw more people in are better ways, IMHO.  But
running it through lclint never hurt anyone.

> hacking isn't everything,

   Don't say that too loud around here. :)

> and when you're trying to implement a highly complex rule-based,
> extensible game like free-civ, a good place to start is a complete
> analysis of the problem.

   Possibly.  But then we get back to the fact that it's just a game.
Perhaps a slightly modified Brooks' rule works here (if you want a
software engineering approach): Plan to throw two away.  Maybe three.  But
in order for us to make those more drastic changes, we need a development
branch (*nudge nudge*).

> anyway, if anybody's interested in doing this, i'd love to help.
> software engineering was one of my focuses in college and i think it
> would be great to sit down and do it for something the complexity of
> freeciv.

   The bottom line is that you're welcome to do this kind of thing on your
own, or with whomever you'd like.  I don't want to fall into the same
pattern of pushing people away that I just spent (now two) emails ranting
about.  Seeing as I'm just a lowly peasant here I can really only offer
suggestions, I can't say "If you do this, your changes will be accepted."
But at this point my suggestion for the most productive thing in terms of
the actual software development process is for you to write as much
documentation as you can.  Play games and write down every little thing
that's not 100% obvious or troubles you.  Make a webpage of Freeciv
grievances and post a link to it so we can check up on it (instead of
clogging down the bug reporting system or the mailing list with one-line
e-mails saying "What's the lightbulb mean?").

   On our end (I use "our" loosely and perhaps presumptiously :)) we need
to remember that it's not 100% obvious to everyone that the lightbulb
represents knowledge gained, the little thing-a-ma-bob next to that is the
government, etc, etc.  Users *will* follow the pattern described in the
Advogato article, even incredibly smart ones (or at least my fiancee does,
so I'll kick anyone's ass that takes a shot at her intelligence :)).

> p.s. justin, did you think about a qt client? that would eliminate
> alot of cross platform woes and still allow the client to retain its
> open source status under the gpl.

   This got hashed over this past August.  I don't recall the outcome, but
feel free to dig through the discussion and draw your own conclusions.

> IMHO C++ is the only way to go for gui... and... well, everything
> else. e.g. rewrite the network IO stuff to use ACE, city classes, unit
> classes, player classes, nation classes, map classes, the list goes on
> :)

  Beyond that the discussion here could get ugly. :)


Department of Computer Science, Duke University, Durham, NC 27708-0129
Email:  justin@xxxxxxxxxxx

[Prev in Thread] Current Thread [Next in Thread]