Episode: 553
Title: HPR0553: interview with celesteLynPaul
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0553/hpr0553.mp3
Transcribed: 2025-10-07 22:56:19

---

Hi everyone, this is Clat 2 and I'm at Southeast Linxfest 2010 sitting here with Celeste
Lorenz Hall from pretty much the KDE project I'd say.
So I'm sorry.
I am doing well.
Thank you.
Cool.
Yeah.
Thank you for talking to me.
So how are you liking the fest?
This is your first Southeast Linxfest?
Yes, although, haven't there only been a few?
Two.
Yeah, so I'm one for two.
Yeah, cool.
So, Celeste, you gave a talk today about KDE everywhere.
Yes.
And what is the idea behind KDE everywhere?
Basically, KDE everywhere is trying to describe how KDE is more than just a desktop operating
system and it's more than just a technology.
So KDE is actually rebranded itself recently from more than just the desktop environment,
the technology, but what we're trying to get away from to the community.
And it's the community that is really KDE and it's the community that produces the
technology and it's the community that helps people be free and provide them ways to
be more free through providing a great desktop environment.
But the other part of it is, KDE isn't just for the computer desktop.
It's not just for that computer that's sitting in your home office or sitting at school.
It's not even just the desktop environment that's sitting on your laptop.
We've gotten smaller and we've gotten more abstract and fuzzier.
We've moved on to netbooks and it's not just squeezing KDE down to fit onto a netbook.
We've actually designed an interface specifically for the netbook.
We've moved on to phones and so cute has been the popular technology, especially since
Nokia acquired TrollTech for smartphones and so that allows KDE to easily be ported
and provide a lot of the KDE functionality to smartphones.
And again, it's not just about the technology or even the hardware.
KDE provides a lot of services that allows users to interact with anything and everything
often in the cloud that people like to talk about.
So you can interface with Facebook, you can interface with micro blogging, you can
interface with pretty much any service that makes its API or information available.
And so that's really what I mean by KDE is everywhere because it's not just here on
the desktop, this solid piece of technology.
It's really more of a free idea and providing freedom for everyone anywhere.
That is the case.
Shouldn't we start seeing KDE on more than just Linux and BSD?
Yes, well, I know there's a Windows port and I know there's sort of a Mac port but I'm
talking like really.
There's a lot of great work being done porting KDE to Windows Assistant and Windows 7.
People have gotten the plasma desktop to work flawlessly with Windows 7.
Oh really?
Although maybe not the rest of it.
So the applications aren't running as well but I've seen just some amazing work where you
see plasma widgets in Windows 7 widgets side by side working in harmony.
Wow, this is a Linux technology, this is a non-Windows technology, it looks like it belongs
here.
So that's really exciting.
Same with Mac OS, Mac OS, it makes things a little bit easier but KDE, when you talk about
open source technology and you talk about open source community, a lot of it centers around
Linux because it's really the head of the movement but BSD is not Linux but BSD also, KDE also
runs on BSD.
KDE also runs on solar, so it's not just Linux, it's everywhere.
It's everywhere.
Not to repeat myself or something like that.
I can play a little sound every time.
I can play a little sound every time.
Yeah, well, part of the reason that is KDE is a cross-platform technology and that's really
the basis for KDE and so it makes it really easy to port.
You don't have to emulate anything, it's just natively running, so it opens a lot of
doors for KDE where other technologies can't quite get there yet because it's just such
easy work for us to do it.
Okay, so let me, I had a question but now I'm going to back up a little bit because what
exactly, I know you primarily as the usability person in KDE, that's how I know, what exactly
do you do in KDE?
So I am currently serving on the KDE board of directors and the KDE is similar to the
American Nome Foundation where it's the nonprofit that helps manage the assets of legal representation
and other administrative stuff for the KDE community.
So I do a lot of boring administrative works but also really, you know, it's important
work that needs to get done and sometimes people just need to herd cats and get decisions
done and find ways to provide support to the community because one thing I do want to
notice, the KDE does not make technical decisions nor drive technical directions.
We're there to provide resources to the community so that the community can herd in a specific
direction.
Actually it really is herd in cats in a non-community management sort of way, so that's one of the things
that I do.
I also work with the KDE usability project and it's a mixture of actually doing design and
education and I think the education part is probably more important than actually doing
design.
In my talk, I gave a little bit of a background of just, you know, the concept of usability
and open source and some key points in KDE's history where usability really was a turning
point in the direction that KDE was going.
And I think it's important for developers to understand, you know, what good design is,
what good usability is because then it empowers them to create better technology to think differently
about how they want to solve problems.
But then it also makes them empathetic to users and overall it just increases the value
and increases, the benefits that KDE can provide to the greater user community.
So how important is free software, do you think, in general?
I think it's extremely important, but maybe not in the philosophical way that a lot of the
more hardcore SS people are about it.
I think it's great for innovation because it provides an extremely competitive environment
for new ideas to sort of sprout and grow.
I'm also a big believer in free culture and open culture, so I think it's just something
that is right.
But, you know, the world isn't perfect and people need to make money and that sort of thing.
So I'm also very practical whenever it comes to working with a business who might be using
some open source technology, but then they have proprietary stuff, well, you know, do
I provide them support or design services or not?
And, you know, I might work for them or provide them, like, pro bono services in hope that
if their business takes off, that they'll, you know, have an appreciation for the open
source technology that they're using and they'll give back to the community.
And some companies really do do that.
Sure.
How much do you think of usability or maybe even intuitiveness, if they might be the same thing?
How much of that do you think is simply the user's history of, you know, what they expect?
This is how I've always done it, so that's how I expect it to be done.
And if it's done in the same way, then it's automatically more user friendly, more intuitive.
So that is actually a really complex design question that not just open source suffers
from.
I'm also a professional designer and I'm also working on my PhD and HCI, so I come across
this problem more than frequently.
You're always struggling with that trade-off because you have to be aware and you have
to be empathetic to people's experiences because that will shape how they use and learn
your software or any type of interface.
It doesn't just have to be software and how they use and learn their software.
You have to be able to predict that you can support them in the necessary ways.
However, if you look at some past examples, especially in open source, taking from what
is maybe popular and mimicking or being overly influenced by those designs, regardless
if it was the best design or not, can also have a bad effect on the users.
And so that's whenever you start getting into trade-offs, well, do we want to support
what the user already knows, even though we know they tend to make these types of mistakes
and have these types of problems, or do we create something completely different that
we feel better supports the user, but give them something that's a little bit more difficult
to learn and maybe they won't be so happy getting over that learning curve.
So it's a very, it's not an easy trade-off to make.
Right.
Okay.
Well, similarly then, how much do you think consistency and or redundancy is about influences
usability, such as you've got those tabs down beside a conqueror, or well, if you're
in the file management field, but you've got those tabs down the side.
You open up Amrock Voila, there are those little tabs down the left hand side for your
collection, your playlist.
You open up DigiCam, there's those tabs.
After a while, the user presumably becomes accustomed to the fact that if it's a KDE application,
there's a really good chance that there's going to be tabs down the side and it becomes
more more usable, right?
Yes, no, that is absolutely correct.
Consistency is an extremely low-level, very important concept for usability.
Consistency allows people to transfer knowledge that they learn in one application to other
applications.
So it frees up mental resources for them to either work on whatever task it is, or you
know, have a more enjoyable experience without the stress of overcoming problems with the
interface.
So having Consistencies between all of our applications like that, so the places area that you find
in a file dialogue and dolphin, and anything where you need to get to somewhere, is an
example of that.
So that's more of a consistent object that we provide everywhere, but it's always called
places in the places that are listed in the places box are always the same, always in
the same order, and that allows users to learn that, you know, that feature is always available
and that they'll always be able to get to these certain locations, and so they can go
into an application with the expectation of, oh, well, I don't need to copy over files
from my remote file storage and put it over into my home directory because I know that
location, my web server, or, you know, my NFS chair, is available in places and places
available in this application, I can just go there.
I don't need to do this extra work to overcome this inadequacy.
Well, that is funny that you would use that as an example because that took me, I think
I've been using KDE for like a full year probably, before I realized that in KDE, unlike
in my former OS, which was Mac, unlike that in KDE, I could actually go to the save as,
save it like to an FTP server, or to, like, I could save it anywhere in the world, and
it literally, it took me because it was like, in Dolson, I would start seeing, oh, wait,
I could just type that URL with the protocol, I can do that over here too, you know, and
it became sort of like applying one thing to another.
It's a learning process, but then once you have that knowledge, you can transfer it and
it makes learning the other applications easier.
It makes the integration of all the different applications more, I mean, I don't want to
say integrated, but it makes them flow together more, so you don't have to think about it anymore,
you just do things, and you do the things that you're meaning to do and that you want
to do, and you don't have to struggle with the interface and make the computer work
the way that you want it.
Okay, with KDE being such a beautiful and magical and perfect environment, and I mean
depth in the bottom of my heart, how much of a problem is it, in your opinion, is the
fact that we've also got these great, great, great GTK apps and X apps, and all these are
the things that we can run because we're using like a very flexible platform, like Linux.
We can run them within our KDE environment, but obviously, like, you know, you're going
to go to save ads, and suddenly you're looking at the GNOME, I guess, that file-saver,
whatever.
How does that affect the user, I guess?
So I guess there's two points I'd like to address.
One's sort of a design perspective, and the other one's from more of a standard perspective.
So the standard perspective is probably the easier one, and the shorter answer, so I'll
start with that.
So for example, with common elements, such as the file dialog, such as the printing dialog,
those are elements that the desktop environment should control.
So for example, if you're running a GTK application in KDE, and you want to open a file, then
the native file-open dialog should appear, not whatever is attached to the application.
One, it makes the user experience more consistent, and two, it reduces the amount of crap that
you have to shift with the application.
It shouldn't have to come with its own file dialog.
Just to clarify, that's not how it works right now, is that right?
Well, it depends.
Some application, so I'll give you an example where it does work.
Recently, there was some work between Ubuntu and upstream KDE in order to standardize the
deepest protocol for notifications.
So now, if you run NOME applications, certain, I think most NOME applications in KDE, and
you get some type of message where it needs to alert you of something, it will use the
KDE notification system, even though it's a NOME application.
It's great.
I have not seen this.
And if you're in Ubuntu, and you're running a KDE application, if a KDE application needs
to send you a notification, it sends it through the Ubuntu notification system, which is
great.
And the real strength in this is whenever you look at the two environments, KDE and Ubuntu
do notifications in a completely different way, completely, like just conceptually very
different notifications.
And if anybody wants to learn more about that, all you have to do is look up the dialogue
that's been going on for the past two years about notifications in Ubuntu.
But it works.
It makes the experience just flawless.
So even though Ubuntu puts notifications in a certain corner and has its style, a certain
way, presidency information is a certain way, and this allows actions, that doesn't take
away from the KDE application.
You don't have to switch between, oh, wait, I'm running a KDE application in Ubuntu.
I have to think about this differently.
People shouldn't have to think about something that basic.
So the second point that has to do more with design is, again, it's back to the trade
off.
And a good designer will always tell you it depends.
That's our answer to everything.
Because it really, it really depends.
So the benefit of consistency is, you know, all of the things that I talked about before.
However, whenever you step outside the common elements in maybe you're designing all email
applications the same, or you're designing all music management systems the same, all
of a sudden you're losing a lot of creativity.
And you're reducing, you're really making the environment dumber for the user unnecessarily.
Users like exciting things, users like learning, they like discovery, within a limit, you
know, if they think that the amount of work that they have to put into something in order
to learn something and get the computer to do it for them, if that limit is okay, then
they're perfectly happy for it.
So it's in consistency in that respect while there are best practices in things like
interface design and human factors usability, you can't be constrained too much by that
because then you're going to lose a lot of creativity and whenever you lose creativity
then you're going to lose innovation.
In terms of those standardized elements, it seems like the K apps, you know, like the
KDE software compilation, the things that make up KDE all are pretty good about following
those things.
But then sometimes you'll go to like KDE apps.org or something and you'll find something
that was, I guess it's not, you know, branded as a KDE application, I guess, and sometimes
they'll use like a different file chooser, like I guess it's a default, cute file chooser
maybe.
Yeah.
That might be a little bit the ignorance of the developer creating the KDE application.
Maybe they started with the cute technology and wanted to pull in a few things from KDE
because all cute applications will run in KDE, which is the foundation for KDE.
And then a lot of people might start with a cute application, decide to port it to KDE
and start using some of our, some of the libraries that provide additional functionality on top
of cute.
They might not be aware that KDE has its own file chooser, maybe they were just lazy
and didn't decide to try it, which, you know, if the application is going to be successful
in KDE then it needs to look like it belongs to KDE.
And so you need to have that trade off of, you know, the core elements, the things that
don't matter really ought to be the same.
They need to work together harmoniously.
But then, you know, however you decide to do, you know, whatever it is that you're doing,
use the developer, use the freedom to be as creative as you want.
And, you know, the users will tell you how successful you work that because they'll
either use your application or not.
Right.
So.
I imagine that you've probably got a certain set of people who are pre-well integrated
with the whole KDE scene and, you know, what they're doing and all that other stuff.
The loan programmer wanders along and maybe they're dabbling in cute and maybe they're
trying to dabble in KDE.
Where do they go to learn about like the quote unquote proper or maybe just the KDE way
of doing things?
So techbased.kDE.org has all of the developer documentation and it has some really great
introductory documentation for developers everywhere from, you know, how do you check
out a KDE SVN so that you're getting the right stuff to compiling it so it works with
everything else.
So specific projects have specific user interface guidelines, they'll provide code samples
so that the new developer writes in the correct style, that's sort of things.
There's also, you know, open source, one of its strengths is peer review and so the best
thing somebody could do is put their idea out there and get feedback.
You know, if it's a good idea, even if there's problems with it, they will get feedback.
So if you're really serious about it, that's, I mean, that's one way of doing it.
You can go to our C channels, you can go to mailing list and get help.
However, keep in mind, KDE has similar open source culture as any other open source
project and you have to do work if you want people to help you.
You can't just say, oh, well, you know, I have this idea, help me write it or write it
for me.
You know, you have to have some code to show and then people will usually help you because
even from a practical standpoint, like for me as a designer, it's really difficult to
help a developer or even another designer with a design idea until they get something
down.
And for me, it'd be paper or, you know, images or anything else like that because you
have something tangible to look at, you have something to provide constructive criticism
on and you also know that they're committed to following through so that the cost of
me giving that person advice is counterbalance.
Right.
Okay.
Cool.
What's your background with, like, Linux?
How did you find Linux?
And now, you know, what have you been doing with it, I guess?
Anytime anyone asks me this question, I have to tell the story about my friend Michael
Oller's from my undergraduate days because he was really the one who is instrumental in
getting me involved in Linux and he loves this story.
And I've told this story many, many times in other interviews.
I was first year in undergraduate and I randomly meet this guy who happened to be a friend
of my friend's roommate who was really into Linux and he just had to show everybody the
Linux operating system and he had to get anybody who was willing to install it, to install
it on their computer.
And somehow, I was sucker enough to install it and, you know, I fell in love with it.
It was great.
I loved having control over my operating system.
I loved having an option besides just having whatever was given to me whenever I bought
my hardware.
And keep in mind, I didn't go to college, I mean, I was fairly computer literate.
I had a computer when I was growing up and in high school and that sort of thing, but
I was no way, you know, a developer or a geek at that point.
I was still, you know, sort of getting a handle on this computer stuff and it just really
got me excited about computers.
It really helped that I did have, you know, Michael to help me with Linux because 11 years
ago, let's see here in 1999.
Here was a really great, non-technical user community out there.
And if you had a problem, which back then, there were lots of problems.
I mean, I think it was like kernel 2.2.10 or something that I was using.
So if there were lots of hardware problems and that sort of thing, you would be dead
in the water.
You would be installing Windows next day because there's no way for you to figure it out
on your own.
I didn't have the skills yet.
So he was really, you know, he provided support and he was really helpful in doing that
and all of a sudden, look where I am.
I'm contributing to KDE.
I'm talking at this conference, you know, I'm traveling all the time and it's all the
thing.
No, Michael, this is your fault.
So it's in, you know, and there were a lot of factors in how I got involved specifically
in KDE and how I got really interested in open source and that sort of thing.
But I really, if there was a single event where, you know, yes or no, this would have been
my path in life.
I have to attribute it to Michael always.
Okay, well, cool.
So that's, that's, thank you so much for talking to me.
Thank you for having me.
This was a good talk.
Cool.
Okay.
I'll probably catch you some other time.
Thank you for listening to Hack with Public Radio.
Thanks for your responses by Carol.net.
So head on over to C-A-R-O dot-A-N-C for all of her things.