[Bugsquad] [KDE Usability] tasks for Google Code-in

Sat Oct 15 15:39:37 UTC 2011

On Sat, Oct 15, 2011 at 16:31, todd rme <toddrme2178 at gmail.com> wrote:
> 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.

Most of these unfortunately look way too big for Code-in. Some sure
could be done.
But please - let's not all cross-post to all lists. Just think about
this for now. I'll start the actual collection later.

Cheers
Lydia

-- 
Lydia Pintscher
KDE Community Working Group / KDE e.V. board member
http://kde.org - http://about.me/lydia.pintscher