[kde-edu]: Unmaintained apps in kdeedu

[Anne-Marie Mahfouf]

On Tuesday 24 April 2007 20:23:54 Jason Harris wrote:
> Anne-Marie Mahfouf wrote:
> > Jason: If you explain me how to do a "QA audit" maybe we could do a
> > week-end or a day on IRC and get people to help. Maybe even they'll find
> > maintainers.
>
> Sure, here's what I meant in detail:
>
> First, compile a list of the program's expected behaviors.  Every single
> action the user can take while interacting with the program should be
> included.  For example, the behaviors list for KAnagram might look like
> the following:
>
> 1. Menu functions
> +  Quit program
> +  About KAnagram
> +  About KDE
> _  KAnagram Handbook
> _  Configure Kanagram opens the dialog
> _  Next word presents the next puzzle
>
> 2. General gameplay
> _  Correct answer flashes green in edit line, presents a new puzzle
> _  Incorrect answer flashes red in edit line
> _  Clicking "Hint" shows a hint (for a short period?)
> _  Clicking "reveal word" shows the correct answer
> _  Clicking on the category name switches to the next category
> _  leading and trailing whitespace is ignored when checking for a
> correct answer
> _  An answer is submitted by pressing the Enter key, or by clicking on
> the "Up arrow" button next to the line edit.
> B  Mouse cursor changes to the "click hand" over all active elements
> X  Gameplay sounds work
>
> 3. Configuration Window
> B  When opening the configure window for the first time, all options are
> synced to the actual settings being used by the program
> _  Selecting a different language works
> X  Installing chalk font works
> ?  Switching to chalk font works
> ?  Toggling sound works
> _  Create new vocabulary works
> _  Edit existing vocabulary works
> _  Delete existing vocabulary works
> X  Download new vocabularies works
> _  Default options button works
>
>
> Once you have compiled the list, you go through each one and check
> whether it works properly in the program (and under a variety of
> conditions, if applicable).  Then, you indicate whether it passed or
> not.  I use the following characters:
>
> + = correct behavior
> _ = not yet tested
> B = Buggy behavior (perhaps it works under some conditions, but not always)
> X = Broken feature
> C = causes a crash
> ? = Could not test
>
> So, for example, I found that sound did not work, I could not install
> the chalk font, and I could not install a new vocabulary using Get New
> Stuff (each of these may be due to the fact that I only have
> kdelibs+kdeedu on this machine).  Because sound and installing the chalk
> font didn't work, I was unable to test their toggles (hence the "?").
> Finally, the mouse-cursor item gets a "B" because the cursor doesn't
> change when you mouse over the KAanagram title graphic, even though it
> is clickable (it reveals the About dialog), and the initial options sync
> gets a "B" because the program initially auto-hides hints, but the
> Configure window shows "Do Not Auto-Hide Hints" for this option when it
> is first opened.
>
> It may be tempting to skip "obvious" behaviors in compiling the QA list
> (such as "Quit program", or pressing enter to submit a guess), but it is
> important to include *all* of the program's behaviors that you can think
> of.  It's amazing how often some long-overlooked bug is exposed by this
> process.
>
> In general, I try to restrict myself to the set of expected behaviors,
> as described in the handbook or implied by the GUI.  Enumerating the
> behaviors like this will inevitably reveal issues, such as usability
> issues, that could be considered outside the scope of this QA survey.
> However, we may still want to note these.
>
> For example, in KAnagram, it would be nice if the category name in the
> upper right revealed a listbox when clicking, so that any category could
> be selected.  If this is inconsistent with the kid-friendly GUI, then at
> least providing a "previous" arrow in addition to "next" would be nice.
>
> Also, when the solution is shown with "reveal word", it would make sense
> to provide some visual cue for proceeding to the next puzzle.  As it is,
> you either press the regular "Next word" button, or type in the revealed
> solution.  I was thinking of something like a next arrow drawn on the
> chalkboard itself, to the right of the revealed word.
>
> Again, issues like this are *not* the expected KAnagram behaviors, they
> are new ideas.  So they don't really belong in the QA list.
>
> regards,
> Jason

Thanks a lot for the nice explanations. It would be a good idea indeed to 
audit all KDE-Edu programs at some point using that procedure.
In the meantime I'll work a bit on Kanagram fixinfg the obvious maybe I'll 
start on Saturday if nothing else comes up.

Cheers,

Anne-Marie