Plasma User Types

[Celeste Lyn Paul]

On Friday 11 April 2008 19:58:11 Michael Rudolph wrote:
> On Friday 11 April 2008 15:50:35 Aaron J. Seigo wrote:
> > On Friday 11 April 2008, Celeste Lyn Paul wrote:
> > > I've finished the interviews for the Plasma user groups.  A full
> > > report and
> >
> > awesome. we're going to do a session based on your blog entry and the
> > user profiles today to get everyone onside and aware. hopefully this
> > will also help guide us over the next few days here in milano (and
> > beyond)
>
> Hello everyone,
>
> I'm really intrigued to learn about your report and analysis, Celeste.
> And I'm also looking forward to hear what you will come up with in
> Milan. Because, honestly, I have problems understanding plasma user
> types so far. But perhaps i just disagree with you here.

Keep in mind these are not THE plasma user types. They are the types of users 
within the realm of knowledge held by representative Plasma developers who 
have the potential of using Plasma.  They are data to begin discussion of who 
Plasma should focus on.  They need to be discussed in the context of existing 
or future project goals.  Not all the types listed are primary users, just 
potential users.  Certainly, some of them are more representative of KDE 
users and likely to take advantage of Plasma than others.  This information 
is just a way to start conversation on the topic, because otherwise, no one 
would know where to start.  (Hence the "preliminary" -- meaning there was no 
analysis done on the raw data)

I hope this clears up some of your concerns.  Otherwise we have a lot more to 
talk about.

~ Celeste

> With my limited comprehension I sincerely hope that all these user types
> will not be relevant to the further progress of plasma. Distinguishing
> in this way seems to me like prematurely caving in. And although you
> ruled that answer out in a previous blog post, Celeste, I think,
> that "everyone" is the description of the typical plasma user type.
>
> A user's curiosity is a factor that I hope will not matter at all. As I
> see it, whenever we interact with our environment, patterns emerge as
> we reduce complexity and try to make sense of the huge amounts of data
> coming in. This process is commonly referred to as learning and it is
> inevitable. We can not not extract patterns out of what happens around
> us. Now, being curious means to be actively participating and shaping
> this learning process. Not being curious meas to be a very, very sorry
> being. Because you're not actively involved, you're just "being learned
> with".
> In software design we construe an almost complete reality for the user,
> since everthing is virtual, we can not rely on common patterns like
> gravity or magnetism from the real world. If we want windows to snap
> together, and act magnetically, we have to create (or imitate)
> magnetism ourselves. In this vein we almost completely control the
> stream of data the user is dealing with; interaction patterns do not
> emerge from real world properties, we have to carefully design these
> patterns to create a pleasant and non-disturbing user experience. This
> is a very pedagogical task, and as good pedagogues we have to work hard
> to spark curiosity in every user.
>
> Likewise a user's experience level should not matter in a properly
> designed system, because proper design means that the system gracefully
> scales to the users needs and expectations. A couple of days back Aza
> Raskin was giving a talk at google tech talks again and complimented
> the 30boxes interface in contrast to google calendar's, because their
> interface for adding new appointments is just a single lineedit. And
> the controller behind the lineedit is smart enough to extract relevant
> information. After the talk a google employee asked about
> discoverability, which surely is quite limited given just a single
> lineedit and no radio buttons, checkboxes and other labeled lineedits.
> I don't remember Aza's answer, but mine is better anyway :-)  F*
> discoverability! If the controller behind the lineedit is smart enough
> to extract places, times, people and so on, the user can just type
> whatever comes to his mind and his calendar will just do the right
> thing with the input. And it doesn't really matter that the user might
> miss out on two or three features; because what is much more important,
> he can enter data his own way, without thinking about features at all.
> Why not let the user discover new features as sites like Lifehacker or
> 43folders write about advanced features of your calendar? This way the
> features are much more likely to be presented in terms of a user's
> workflow and ultimately in terms of the user. If developers advertise
> the features themselves they will most likely be described in terms of
> computer mumbo jumbo and a user who learns about them that way, will
> probably start to translate his appointments, that previously he just
> entered, into computer terms based on all the great features he now
> knows about. Creating user interfaces that don't get in the users way
> will actually work for everyone, regardless of their experience.
>
> Also discriminating between Linux and Windows users does not do plasma
> justice. It has so great potential that every user should be able to be
> instantly productive with plasma, even when they learned to do things
> the wrong way through years of Windows usage.
>
> Since large parts of the framework are already in place we should
> considerably raise the bar for our design goals to not thwart what has
> already been achieved.
>
> Now if only that lazy bum who promised to draft a vision statement got
> his act together. - No wait! That was me. I'll put the little that I
> got up on techbase tomorrow, so others might be able to already see,
> what I'm talking about.
>
> So as Aaron just said an hour ago: I'll go to bed, so tomorrow I can get
> up, first thing in the morning :-)
>
> michael
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel



-- 
Celeste Lyn Paul
celeste at kde.org
KDE Usability Project
usability.kde.org