TXLF: HeliOS helps schoolkids and challenges developers
Ken Starks of the HeliOS Project delivered the keynote talk at the second annual Texas Linux Fest (TXLF) in Austin on Saturday. HeliOS is a not-for-profit initiative that refurbishes computers and gives them to economically-disadvantaged schoolkids in the Austin area — computers running Linux. Starks had words for the audience on the value of putting technology into young hands, as well as a challenge to open source developers to re-think some of their assumptions about users — based on what HeliOS has learned giving away and supporting more than one thousand Linux systems.
How HeliOS works
![[Ken Starks]](https://static.lwn.net/images/2011/txlf-starks1-sm.jpg)
Starks led off by giving the audience an overview of HeliOS, both its mission and how it operates in practice. It is under the federal non-profit umbrella of Software In the Public Interest (SPI), which supports Debian, Freedesktop.org, and many other projects. The program started in 2005, and since then has given away more than 1200 computers (some desktops, some laptops) to Austin-area children and their families.The families are important in discussing HeliOS's work, Starks said, because the 1200 number only counts the child "receiving" the computer. When siblings, parents, and other family members are included, he estimates that more than 4000 people are using HeliOS's machines.
The hardware itself is donated by area businesses and individuals. But the project does not accept just any old end-of-life machines. The goal is to provide the recipient with a working, useful system, so the project only accepts donations of recent technology. At present, that means desktops with Pentium 4 or Athlon XP processors and newer (at 2GHz and above), 1GB of RAM or more, with 40GB of storage. The full list of accepted hardware reveals some additional restrictions that the project must make (it no longer accepts CRT monitors for liability and transportation reasons) as well as predictable pain points, such as 3D-capable graphics cards. Starks has said in the past that roughly one third of all computers donated to HeliOS must have their graphics card replaced in order to be useful on a modern desktop.
Referrals come from a variety of sources, including teachers, social workers, police officers, and even hospitals. Starks and HeliOS volunteers make a visit to the home to get to know the family and scope out the child's situation before making a donation commitment. A family that can afford a high-priced monthly cable bill, he suggested, might get a call back in a few days recommending that they lower their cable package and purchase a reduced-price computer from HeliOS instead. But a computer is always in tow for the first visit, ready for immediate delivery.
Volunteers assemble and repair each PC, then install HeliOS's own custom Linux distribution — currently an Ubuntu remix tailored to include educational software, creative and music applications, and a few games. The team delivers and sets up the computer in the family's home, providing basic training for everyone in the household. They continue to stay involved with the families to provide support as needed. Support for the hardware and the Linux distribution, that is.
Periodically, HeliOS receives a call from a recipient's family member asking for help with a copy of Windows that they installed after erasing Linux from the machine. The child never removes Linux, Starks said, only a parent, and the support call almost always means trouble with viruses, malware, or driver incompatibility. At that point, HeliOS politely refuses to support the Windows OS, but will gladly reinstall Linux. This type of event is a rarity; Starks mentions on his blog that it happened just eight times in 2010, out of 296 Linux computers. It never matters to the kids what OS is on the computer, he said, the kids are simply "jacked
" to be finally entering the world of computer ownership.
But Linux is not merely a cost-saving compromise HeliOS uses to make ends meet (although Microsoft did offer the project licenses for Windows XP at a reduced rate of US $50 apiece). The project includes virtual machine software in its distribution, and has a license donated by CodeWeavers to install Crossover Pro for those occasions when a specific Windows application is required, Starks said. The real reason Linux is the operating system of choice is that it allows the children to do more and learn more than they can with a closed, limited, and security-problem-riddled alternative. Our future scientists and engineers are the students learning about technology as children today, he said, and HeliOS wants them to know how Linux and free software can change that future.
What HeliOS can teach the developer community
![[Ken Starks]](https://static.lwn.net/images/2011/txlf-starks2-sm.jpg)
Over six years of providing Linux computers to area schoolkids (the oldest of whom include five just entering graduate school), Starks said, the project has amassed lots of data on how children and new users use computers, which allows him to give feedback to the developer community that it won't hear otherwise. The open source community creates a lot of islands, he said — KDE island and GNOME island, for example. But the most troubling one is User island and Developer island, between which people only talk through slow and ineffective message-in-a-bottle means. Because open source lacks the inherent profit motivation that pushes proprietary software developers to keep working past the "works for me" point, too many projects reach the "good enough" stage and stop.
Starks explored several examples of the user/developer disconnect, starting with the humorous indecipherable-project-name problem. He listed around a half-dozen applications that HeliOS provides in its installs, but with names he said reinforce the impression that Linux is not only created by geeks, but for geeks: Guayadeque, Kazehakase, Gwibber, Choqok, Pidgin, Compiz, and ZynAddSubFX. The pool of available project names may be getting low, he admitted, but he challenged developers to remember that when they introduce a new user to the system, they are implicitly asking the user to learn a whole new language. When there is no "cognitive pathway
" between the name of the application and what it does, learning the new environment is needlessly hard.
He then presented several usability problems that stem from poor defaults, lack of discoverability, and confusing built-in help. In OpenOffice.org Writer, for example, most users simply choose File -> Save, unaware that the default file format is incompatible with Microsoft Word, which starts a day-long firestorm for the user when they email the file to a friend and it is mysteriously unusable to the recipient. The lxBDPlayer media player — in addition to making the awkward-name list — confronts the user with a palette of Unix-heavy terminology such as "mount points" and "paths" even within its GUI.
Time ran short, so Starks skipped over a few slides, but he does blog about many of the same issues, further citing the experience of HeliOS computer families. The message for developers was essentially to rethink the assumptions that they make about the user. For example, it is common to hear the 3D graphics-card requirement of both Ubuntu's Unity and GNOME 3's Shell defended by developers because "most people" have new enough hardware. Starks touched on that issue briefly as well as in a February blog post, and might amend that defense to say "most middle-class people" have new enough hardware. Most users do not have any problem with the application name GIMP, but Starks asks the developers to consider what it is like when he has to introduce the application to a child wearing leg braces. Most developers think their interface is usable, but Starks asks them to try to remember what it was like when they used Linux — or any computer — for the very first time.
Starks concluded his talk by assuring the audience that the example projects he talked about were chosen just to stir up the pot, and not cause any real offense. He poked fun at the Ubuntu Customization Kit's acronym UCK, for example, but said HeliOS indebted to it for allowing the project to create all of its custom software builds. Indeed, Starks can dial up his "curmudgeonly" persona at will to make a humorous point (as he did many times), but also switch right back into diplomatic mode when he needs to. He ended the talk by thanking the open source community for all of its hard work. "Sure, we give away computers, but without what you do, we give away empty shells
", he said.
Starks believes in the mission of the HeliOS project because the next generation will discover and innovate more than the past two generations combined — and they will be able to do it because they will learn about technology using the software created by the community. It is a humbling and exciting future to contemplate, he said, one that if the developer community stops to consider, makes for a far better incentive to innovate than the profit motivation that drives the proprietary competition.
Impact
I am part of the organizing team for TXLF, so I can tell you that among the reasons the team invited Starks to deliver the keynote this year were the opportunity to present a "Linux story" from outside the typical IT closet environment and the major distributions, and Starks's ability to present a challenge to the community. He certainly delivered on both counts. What remains an open question is whether that challenge gets taken seriously, or gets lost in the well-oiled machinery of the release cycle.
After all, most of us have heard the "project name" dilemma before, and yet it remains a persistent problem. Is the fact that HeliOS has hands-on, real-world examples of new users being put off by application names going to prompt any project to re-evaluate its name? Who knows. It is easy to dismiss Starks's stories as anecdotal (and he readily admits that his data is not controlled or scientific), but the project does install around 300 Linux computers per year, in the field.
In the meantime, it is good to know that the project will keep up that work. Starks took time out of his allotment to present volunteer Ron West with the "HeliOS volunteer of the year" award, and mention some of the ongoing work the initiative is currently engaged in. It recently moved into a new building, and has started The Austin Prometheus Project to try and raise funds to provide Internet service to HeliOS kids, 70 percent of whom have no Internet connection. Of course, that statistic flies in the face of yet another assumption the development community makes all the time about always-on connectivity. I suppose the challenges never end.
Index entries for this article | |
---|---|
GuestArticles | Willis, Nathan |
Conference | Texas Linux Fest/2011 |
Posted Apr 7, 2011 9:58 UTC (Thu)
by mjthayer (guest, #39183)
[Link]
Sad but true - very few developers are willing to devote their precious free time to something that doesn't interest them. So if free software is to become more user oriented, it will probably have to involve finding ways of making that task more interesting for the developers. On the face of it it doesn't sound like a hopeless task, as I am sure that most people get a tickle of pleasure from seeing their brainchild in use. Perhaps people wanting to promote free software uptake should work on teaching users to interact with developers in constructive ways. Users complaining and demanding things is very off-putting, but users who are clearly appreciative and also willing to think about a problem and what they can do themselves to help solve it can be very encouraging. Nothing is for free, and if you aren't paying money for the software you should expect to invest in some other way.
Perhaps in the case of five year old children it is their mentors who should be targeted - or then again, perhaps not just them!
Posted Apr 7, 2011 11:54 UTC (Thu)
by pjm (guest, #2080)
[Link] (1 responses)
If you dislike the name Choqok, then you can see the futility in trying to provide a cognitive pathway. (Choqok provides as good a cognitive pathway for a Twitter client as any, to people who know it as a word meaning sparrow.)
It's hard to be sure that a given proposed project name doesn't exist as slang with negative connotations somewhere or other: for example, the relatively large English dictionary on my shelf doesn't mention the US slang sense of the word gimp that the speaker was referring to (which I gather means something like limp), and most of the meanings it does give are somewhat decorative (and positive) in nature, so appropriate to a graphics program. Trying to choose a name that provides a good cognitive pathway in one language seems more likely to fall afoul of this problem than choosing a name like Kazehakase.
Perhaps the lesson to take from the HeliOS experience, then, is not so much about project naming as having interfaces give more prominence to descriptions and icons and less prominence to project names.
Posted Apr 7, 2011 16:15 UTC (Thu)
by martinfick (subscriber, #4455)
[Link]
Not to mention that the average non computer literate person doesn't know what twitter is anyway (I have to say, I am not even sure I know what twitter is). Name confusion is not a free software problem, it comes with any complex domain and it is not likely going away. Are the problems real? Yes. Is there really a way around it? I doubt it.
With complexity, if you are going to communicate, you need large vocabularies, and thus complexity. The vocabulary is there to help those in the know, not to make things complicated for those who don't. It is complicated for them, with or without the vocabulary. Blaming the vocabulary seems like a miss placed complaint, pointing at a symptom, not the cause of the complexity.
Posted Apr 7, 2011 11:55 UTC (Thu)
by Seegras (guest, #20463)
[Link] (3 responses)
"Kazehakase" clearly is a japanese word; I don't see anything wrong with a japanese speaker choosing something like this.
I actually associated "gimp" with the gimp from "Pulp Fiction", concluded from the "GNU Image Manipulation Program" that there was probably another meaning, maybe something along the german meaning of "gimpel" (Pyrrhula, a bird; also somebody not quite intelligent), and left it at that.
And there are many more. Also, of course, there are english words that sound (or are written) exactly the same as english words, but have a total different meaning. "Mist" for instance is exactly written and spelled the same in german -- only, in german it means "Manure"... Or "burro" in spanish ("donkey") versus italian ("butter")...
In the end, you can't actually avoid these problems. Ignore them. Name your project however you like. And probably "Gwibber" is better than "ZynAddSubFX" ;)
Posted Apr 7, 2011 13:18 UTC (Thu)
by tstover (guest, #56283)
[Link]
I think many do as well. What made it so bad was the mascot/logo of the dog. So now everyone wanted to know what this "gimp puppy" thing was.
Posted Apr 8, 2011 8:36 UTC (Fri)
by jezuch (subscriber, #52988)
[Link] (1 responses)
Oh... For whatever reason I thought it was from one of the Indian (the Native American Indian, I mean) languages.
> In the end, you can't actually avoid these problems. Ignore them.
Yup... We in Poland got used to OSRAM (the light bulb brand) even though it means something like German "Mist" but worse ;) The language centers in our brains can be quite flexible with interpreting words differently in different contexts.
Posted Apr 8, 2011 14:14 UTC (Fri)
by aryonoco (guest, #55563)
[Link]
Posted Apr 7, 2011 15:08 UTC (Thu)
by dark (guest, #8483)
[Link]
Posted Apr 7, 2011 18:03 UTC (Thu)
by iabervon (subscriber, #722)
[Link] (1 responses)
The current situation is a bit like someone refusing to hand you your cell phone unless you can identify its product name, and people complaining that cell phone brands are hard to identify as cell phones. The problem is not that project names are hard to understand; it's that users have to understand them in order to use the project.
Posted Apr 7, 2011 18:47 UTC (Thu)
by halla (subscriber, #14185)
[Link]
On my desktop it has entries like "Choqok (KDE microblogging client)" or "Amarok (audio player)" if I use the menubar style. And if you use the "application launcher" style instead of the menu style, applications are shown as an icon and two lines of text: in bold, heavy print the description and in light, smaller, gray print underneath the application name. And typing "Word Processor" in the search bar gives you a choice of word processors.
This sounds pretty ideal to me, actually.
Posted Apr 12, 2011 15:25 UTC (Tue)
by wilck (guest, #29844)
[Link]
"path" is a first-class concept in computing, and easy to explain, too. I see no reason not to use this term. "mount points" are a different issue.
Posted Apr 15, 2011 14:01 UTC (Fri)
by robbe (guest, #16131)
[Link] (1 responses)
We all had to learn what these stand for, the same way we had to learn that the tool to put nails into wood is called a hammer, not a nailinator.
Posted Apr 15, 2011 16:00 UTC (Fri)
by Trelane (subscriber, #56877)
[Link]
"Hammer." The -"er" indicates that it effects the thing that it attaches to, e.g. a "carrier" carries and a "flier" flies.
So clearly, a hammer hams. Perhaps it creates hams, or helps in the creation of ham?
TXLF: HeliOS helps schoolkids and challenges developers
project naming
project naming
Project names
Project names
Project names
Project names
I don't think the 'hellious' project has any cause to be making fun of other project names :)
TXLF: HeliOS helps schoolkids and challenges developers
TXLF: HeliOS helps schoolkids and challenges developers
TXLF: HeliOS helps schoolkids and challenges developers
TXLF: HeliOS helps schoolkids and challenges developers
Project names
Project names