Adding widgets to panel?

[Aaron J. Seigo]

On Tuesday, September 13, 2011 10:20:28 Thomas Pfeiffer wrote:
>  On Tue, 13 Sep 2011 11:10:20 +0200, Aaron J. Seigo wrote:
> > or switch to the activity with it on it. if i am, indeed, constantly
> > monitoring something (not just checking it every so often visually)
> > then i am
> > probably going to be in the relevant activity.
> > if i just want to check from time to time, having it on another
> > activity isn't
> > a big problem.
> 
>  Let me rephrase my suggestion:
>  I think there should be a way for users to put widgets at some place
>  where they can - at any given time - access them without having to do
>  too much.
> 
>  Let me give an example: On my desktop I usually have a network traffic
>  monitor always in sight. The reason for that is that if a web page
>  seems to take forever to load, I want to know if it does actually still
>  load or if it stopped transferring but the browser just hasn't realized
>  it yet.

that is a highly technical usage, that i'm not sure describes many people in 
our target groups .. but you're in good company there: i'm totally not the 
target group when it comes to such technical usages either. :) 

for me, i'm looking at more "commonly human" traits to satisfy and prioritize, 
such as "a living record of my life" or "organizing my work progress" than 
these technical things.

but i'm sure we could also find more "commonly human" traits to create the 
same kind of user story you just offered 

so ... 

... it occurs to me that the window strip offers a live preview of windows.

... and we have the ability to run widgets in a window, essentially a "full 
screen" mode (from the user's interaction POV, not a technical definition at 
the programmatic level)

... which would allow one to peek at the progress in a nice little thumbnail 
alongside all other windows in the widget strip

... if we ordered and grouped windows in the window strip using some strategy 
like:

[ Home screen ] [ FSP ] [ FSP ] [ App ] [ App ]

where "FSP" == "full screen plasmoid", then we'd get a peek area, great full 
screen interaction when needed/desired and stable locations for them.

they could be launched (as one can already, in fact) from the launcher area 
...

.. and that means we'd be able to avoid adding any new "top level" UI 
concepts, but instead just re-use the launch and peek concepts to accomodate 
this need.

what do you think?

>  I might be part of a minority of users who do that, but I can imagine
>  that many users have _something_ they often want to check (say, an
>  auction
>  on ebay or the current value of a certain stock), regardless of their
>  current activity.
> 
> > alternatively, the widget strip app could be used.
> 
>  The widget strip does work better than a widget on just one activity
>  for
>  that, true (although it definitely has to be explained to the user,
>  I for one did not have a clue what it's used for until it was mentioned
>  in an email). But even that is not always visible (and not even with
>  one action).

true ...

> > we can/should monitor future usage of these devices to see how people
> > end up
> > using them over time, of course, and adjust our positions in
> > accordance if
> > needed.
> 
>  I would replace can/should with "have to". The "... and listen to your
>  customers"
>  part of the "release early, release often" philosophy (although I'd
>  strongly
>  prefer "... and observe your customers using the product" whenever
>  possible)
>  is crucial.

the real trick we face here is making sure we are able to not put too much 
weight on the actual recommendations our users give us (which will be offered 
from the perspective of current usage paradigms; unnavoidable, and something 
we even struggle with ourselves! :) and instead focussing on actual usage.

the social sciences struggle with this a lot: what people say about their 
motivations, concerns, values, etc. and what actually motivates them and what 
actually fulflils their needs.

it isn't for the scientists in those fields, and i expect it to be a constant 
challenge for us as we chart a path to introducing these new usage paradigms 
to the world.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/active/attachments/20110913/c6024b52/attachment.sig>