Tasks for Google Code-In

[todd rme]

On Thu, Oct 27, 2011 at 10:45 AM, Thomas Pfeiffer <colomar at autistici.org> wrote:
> Hi all,
> Lydia Pintscher asked me if we could come up with UI design or UX research
> tasks
> for Plasma Active for Google Code-In ( see
> http://blog.lydiapintscher.de/2011/10/17/i-need-your-ideas-for-google-code
> -in/
> for details). These tasks are supposed to be rather small and doable by
> high-school
> students.
> Here are some that came to my mind:
> - Identify KDE applications that would be especially useful on a mobile
> device and
> identify what would need to be done to make them touch-friendly
> - Identify what would need to be done to make non-Active apps currently
> shipped
> with PA (e.g. Okular, Bangarang) more touch-friendly
> - Extract interaction patterns from the shell as well as current Active
> apps to add to
> our - yet to be created - Interaction Pattern Library
> - Further expand our FAQ
> - Create additional usage scenarios for Plasma Active
>
> What do you think of those? Which ones should go in, which should not?
> Additional suggestions?
>
> Is anyone willing to mentor any of those tasks?
>
> Regards,
> Thomas

There needs to be different levels, right?  Like easy, medium, hard.

Perhaps some others:

Hard: Develop a set of UI rules and constraints for non-touch devices
(like set-top boxes).  Every person would need to do it for one device
class.  This would not involve setting up the UI, but surveying the
hardware commonly used for interacting with such devices (for instance
TV remotes, game controllers, and Wii remotes for set-top boxes) and
figuring out what sort of interactions are and are not feasible for
users to carry out with such input devices (for instance the sliding
panels are definitely a no).  This would also include the impact of
screen size, for instance.  For example, dragging windows would be a
no-go with a remote, but the large screen size would allow for
multiple windows to be open, so a tiling window manager might be
superior to a conventional interface like on the desktop or the
full-screen one on tablets.

Medium: A review of existing smart phone and tablet keyboard systems
with their capabilities, benefits, disadvantages, and such.  This
would need to involve fairly technical assessments rather than a more
cursory overview.

Medium to hard: a cleanup of the active OBS instance to make it easier
to maintain and easier for others to make use of through OBS.  For
instance converting the source dumps to patches against upstream, or
moving the Qt Mobolity packages to something other than
Applications:Geo (like KDE:Qt).

-Todd