[KDE Usability] tasks for Google Code-in

[todd rme]

On Sat, Oct 15, 2011 at 3:19 PM, Lydia Pintscher <lydia at kde.org> wrote:
> Heya folks :)
>
> Google Code-in (http://www.google-melange.com/gci/document/show/gci_program/google/gci2011/about)
> has been announced again for this year. Org applications will start on
> Monday and we'll try to get in again given last year's success. The
> kids were wonderful.
> Google changed the rules a bit this time. If we're accepted we need to
> add a large number of tasks at the beginning and can only add a second
> round in the middle of the program again. This means we need to start
> thinking of good tasks for the kids now. All this small stuff you wish
> you had time for - make it a task. If you're unsure if it's suitable
> find me in #kde-soc and I'll help you. Tasks can come from the
> following areas:
> * Code: Tasks related to writing or refactoring code
> * Documentation: Tasks related to creating/editing documents
> * Outreach: Tasks related to community management and outreach/marketing
> * Quality Assurance: Tasks related to testing and ensuring code is of
> high quality
> * Research: Tasks related to studying a problem and recommending solutions
> * Training: Tasks related to helping others learn more
> * Translation: Tasks related to localization
> * User Interface: Tasks related to user experience research or user
> interface design and interaction
>
> Please think of tasks. I'll go around with a wiki page or similar
> later to collect them.

Some ideas (they may or may not be appropriate for this):

1. Rewrite individual or small numbers of plasma widgets in QML

2. Write comprehensive unit tests for a particular module

3. Make sure a particular module conforms to its coding style

4. I noticed openSUSE is working on something called openQA for
automated testing of software.  It might be worth seeing if that could
be useful

5. Some sort of easy-to-use tracking and display of page hits and/or
search terms for userbase so we know what people are trying to find
out or learn

6. Integrate the amarok feedback system into one or more other applications

7. Improve detection and handling of duplicates in Dr. Konqi, such as
detecting duplicate backtraces

8. Some sort of fuzzy duplicate search, ideally with some sort of
learning algorithm, in bugs.kde.org (or bugzilla in general) that can
rank reports in terms of how likely they are to be duplicates to help
triagers focus their searches.  Bug reports could also be run through
this before submission to help users find out if their bugs are
duplicates.  This could be too difficult for such a project, though.

9. Something in bugs.kde.org to let users report a bug as likely fixed
or a likely duplicate.  These sorts of reports should probably be
prioritized over normal comments since they can help reduce the
overall noise in bugs.kde.org, so having a dedicated way to do that
would be helpful.  Maybe a general way for users to report bugs that
should probably be closed but that they do have permission to close
themselves.  Once again this might be better done in upstream
bugzilla.

10. Scientific and technical QML components like plots, axes, meters,
dials, LEDs, thermometers, etc.  Each person would either do one such
component or a small number of them.  The goal would be to reproduce
the stuff offered by the QWT project in QML.

11. Remove all Qt3support or KDE3support instances from one
application or part of one application (depending on the size of the
application and number of such instances)

12. Integrate a simple, low-bitrate screencast tool into both KDE and
userbase so it is easy to make and upload visual walkthroughs of
various tasks.  It should ideally be dedicated to this tasks, with
annotations and automatically pausing after each stage so the user can
do it themselves.

13. Make an interactive problem solver for Userbase that directs
people to particular articles based on their responses to a series of
questions.

14. Integrate userbase with the existing KDE help system.  This would
probably involve two projects, one to have userbase search in the help
system (but would just show links that open the page in a web
browser), and a second to display userbase web pages directly in the
help browser.

15. Fix the search in KDE help.  Maybe use strigi to index the help
and man files.  A second project could be something in nepomuk to
automatically cross-reference help pages based on the mention of
specific applications or tasks in other help pages.

16. Packagekit help integration, to automatically try to download
documentation for an application when the documentation cannot be
found on the system.  This is already available for debuginfo and
codec packages so there is a basis someone could use to get this
started.

17. Improvements in how .xsession-errors is handled by KDE.  Currently
applications often dump a large amount of informationt there even when
debug data is turned off in kdebugdialog..

18. Automatically enable and disable debug files.  Currently you need
to manually enable or disable the debug information kdebugdialog, and
if it is off my impression is drkonqi cannot use it.  Perhaps have it
off by default, and have drkonqi turn it on when it needs it then turn
it off again afterwards.  Turning on the debug information manually
would still be possible for developers.

19. Integrate GHNS into one system settings module or application that
does not currently support it.  Examples include: personal image,
bespin and qtcurve styles, and perhaps others.

20. General usability overhaul of the File Associations configuration.
 It needs quite a bit of work.

21. Go through and make sure all (or some subset of) lists that can be
re-ordered support drag-and-drop reordering.  Many lists still require
you to use buttons to re-order objects, which is good to have for
accessibility reasons but is not as easy with mice.  Do the opposite
as well, make sure lists can be re-ordered with buttons if
accessibility requires it.

22. Many applications have menu entries and.optional toolbar entries
without icons.  Probably going through some subset of applications
and, where possible, assigning existing icons to those would be nice.
Another possibility would be a card-sorting poll for which icons
should be used in those cases.  This would only use existing icons, or
at least icons that are in the spec even if oxygen doesn't implement
them.

23. When building KDE applications I see a lot of warnings about icons
that are not the size that the folder says they should be.  Perhaps
going through and checking and fixing oxygen icon sizes would be good.

-Todd