Helping new users choose application software
- Login o registrati per inviare commenti
Greetings. The first thing I want to say is that I really appreciate all the work that goes into Trisquel. I value being able to download and use a fully free code OS, which is user-friendly enough to be installed for GNUbies (GNU newbies ;), to replace Windows versions as old as XP (or maybe even older). I appreciate that the applications software that comes bundled with a default Trisquel install is generally stable, user-friendly, and covers most users' everyday needs.
Since I can't contribute to free code software by programming it (at least not yet), I try to contribute by giving thoughtful feedback from a user perspective, in the hopes that this will help developers and maintainers improve it. The issue I want to address today is the methods available for installing new software from the Trisquel repositories. I'm going to start by describing my suggested solution, then explain the problem I believe my solution will solve.
In short, I propose that the difficulty level involved in installing an application should give some clue as to how user-friendly the application is.
AFAIK there are only three ways to install applications from the Trisquel repos:
* Add/Remove Programs: Any new GNU/Linux user who installs Trisquel will use AR/P a lot, at least at first, because A/RP is prominent in the start menu, and will be one of the first things new users see when they click the Trisquel icon on the start bar. Any applications offered here should be graphical, stable, and GNUbie-friendly.
* Synaptic Package Manager: Synaptic is a little more confusing, as it doesn't distinguish between user applications and other kinds of software, or between user-facing applications, and the various back-end packages they are made up of. However, it does have a GUI interface, so slightly more experienced users might venture into using Synaptic if they can't find what they're looking for in A/RP. Any applications offered here should be graphical and stable.
* Apt-get install: this requires a user to be comfortable opening a terminal and using the command line, remembering to use 'sudo', and knowing the exact package name of the application they want to install. I've been using GNU/Linux as a desktop OS for over a decade, and I still sometimes struggle with this. Any application in the repo can be installed this way, including command-line only apps, and experimental alpha and beta software, which is fine. Anyone who installs software this way is most likely prepared to cope with any problems that may come up.
I know I'm proposing a major change from the way package installation is currently done, which might require major changes to somehow mark available applications according to three classifications (suitable for GNUbies, suitable for intermediate users, suitable for experts). Why do this?
To illustrate what I'm proposing, I recently installed these four applications using A/RP: Hydrogen, Transcriber, FreeBirth, and FreeWheeler.
* Hydrogen: the version in the repos is beta software (0.9.6beta3), 9.6 was released over a year ago. The graphical UI (user interface) is mature, and intuitive enough that I could figure out how to start using it just by playing around. Even running the beta seems pretty stable, and from a look at the project homepage, the development community appears to be active. This is an example of a good application to make available in A/RP.
* Transcriber: the version in the repos (1.5.1) was released more than two years ago, and the package has been obseleted by TranscriberAG. The UI is graphical, but not optimized for GNUbies, for example, testing the stability was hard because I couldn't find my file partition using the open file dialogue (not even under /media or /mnt), and had to copy a speech file to the desktop because I could test with it. When I did manage to load the speech file, it loaded and played fine, so stability seems to be fine. This is an example of a good application to make available in Synaptic, but too rough-around-the-edges to be in AR/P.
* FreeWheeling is also experimental software (0.6-2) and the UI barely qualifies as graphical. No instructions are available, and the program won't even load the UI if JACK hasn't been started first. Another look at SourceForge suggests this may be a dead project too. This is an example of an application to make available only by apt-get install, or *maybe* Synaptic, but it certainly should *not* be available from AR/P.
* FreeBirth: the version in the repos, 0.3.2, was released in 2008. There are no bundled instructions, and no link to any. The UI is so bad I can't even figure out how to make it start. If it's the green button above the yellow button with the pause icon on it, that one just makes the app crash. A web search for "FreeBirth" brings up a SourceForge project, which says its alpha software, and appears to have been abandoned for years. This is an example of an application to make available only by apt-get install (to be honest, I'm not sure why it's in the repos at all).
New users will tend to assume, because A/RP is so prominently displayed, and so user-friendly itself, that it will only offer applications that a) are stable releases, b) work without lots of tinkering, and c) have enough instructions bundled with them to at least start using them. Also, new users installing packages using a graphical interface, even a slightly geeky one like Synaptic, will tend to assume that any application they install is going to have some kind of GUI, and that command-line only application would be installed using... the command line. An experienced GNU/Linux user will of course know that things are often a bit more complicated than that, but a GNUbie may not. Besides, when you stop and think about it, these are actually fairly reasonable assumptions. Can we make them true?
BTW I understand that not everyone reading this forum has English as their first language, so if anything I say is confusing, please feel free to ask for clarification.
Just realised "Add/Remove Programs" (AR/P) should be "Add/Remove Applications" (AR/A). Doh!
I'm probably coming at this from the wrong angle, but here goes: I don't even
support the presence of graphical package management in Trisquel. I don't use
it, don't recommend it, and (when helping others with/ installing GNU for
others) teach them the command-line way of doing things. I never understood the
need for graphical package management- although I concede that this makes
things 'easier' for the first-time user and more similar to the point-and-click
interfaces they are used to, frankly I don't think a user who isn't prepared to
get a terminal open should even be installing new packages and diving into the
often-times confusing world of GNU package management.
There are two main aims which must be kept in mind when considering introducing
people to the free software camp- of course, free software must be as
attractive and functional as possible in order to attract new users. This is
why I support a wide range of well-made user-friendly applications bundled
together with the wonderfully set up Trisquel DE in the default install, to
make things more hassle-free for those just dipping in to GNU for the first
time.
However, the cost of making everything require zero thought is twofold: it
leads to bad administration habits and potentially endangers the user's system,
and it also perpetuates the culture of ignorance that the corporate software
world breeds- the approach that presents users a *surface* upon which to do
their business without asking serious questions about what their computer is
doing, how, or why- or knowing about anything below the surface. This is
antithetical to the aims of free software and opposition to the culture of
ignorance- the creation of a free digital society in which all are participants.
What is the solution? Clearly the world of free software must be as attractive
as possible. However, we must also take care not to breed bad habits,
ignorance, and we must set people on the path to reasonable computer literacy-
a stage at which they have a decent understanding of what's going on behind the
scenes, aren't afraid to ask questions, and aren't afraid to get the command
line open and do some learning themselves.
The best way of doing this is two maintain two main installation options. The
first is a 'new user'-friendly ISO containing the Trisquel DE and stuffed with
as many good applications as possible. The other should be a minimalist
netinstall setup (like the current one) in which all installation options are
to be set by more experienced users who know what they want. Neither should
offer graphical package management.
Perhaps the 'user-friendly' CD could contain a link in the DE labelled
'Add/Remove Programs'. However, this should link to a help file explaining the
concepts behind GNU package management, and APT in particular, explaining (at
the start) just a few basics:
- APT configuration (such as the source list)
- adding, removing, and purging programs
- updating the package list and upgrading the system.
What do you think? It sounds a bit elitist, but I sincerely think this is the
way to start people on the path to terminal literacy.
This is also somewhat biased based on my own experience- my first distribution
of GNU+Linux was Debian, which I started with about a year ago. However, I
never touched Synaptic and taught myself how to do things the dpkg/apt-get way.
Simply being in contact with the terminal kickstarted me on the learning
process, and I am learning new things about GNU every day. The basics of
terminal package management aren't really that difficult to grasp- anyone can
learn.
I disagree. People who do not want to learn how to use a terminal and yet want to install and use programs absent from the default install (i.e., more than 90% of the population, including, for instance, my parents, my brother or my wife) would never use Trisquel (contrary to, for instance, my parents, my brother or my wife). They would believe there is no way to install additional software but following the unsafe Windows way of downloading applications from their sites... what often means, in the GNU/Linux world, downloading source codes that they cannot compile. Opening the Synaptic package manager, searching in the description of the packages and installing them is a breeze. Learning alone how to use 'apt-cache' and 'apt-get' or 'aptitude' (+ the mere existence of those commands + sudo + the basic use of a terminal) is not something most people want to do. And I do not see anything wrong with that. Sure they will never have the skills of a professional system administrator. So what?
Notice that most computer users spend far more time writing in a word processor than administrating their system. By your logic Trisquel should not include LibreOffice but rather only ship Emacs (or should it be 'vim'?) and LaTeX. It is indeed a far better and faster way to produce perfectly formatted texts. But you first need to learn the use of that powerful text editor, the LaTeX language, how to go from the .tex files to the PDF, etc.
I understand where Moxalt is coming from, and in my experience, even total GNUbies do eventually learn to do at least a few things using the command line. A lot of the how-to articles on the web have step-by-step instructions which include how to open a terminal, and commands that can be cut and pasted. However, even if we followed his advice, the problem remains that there's often no obvious way to tell whether a package is fully graphical, semi-graphical (like FreeWheeler or FreeBirth) or command line only, or whether its mature and stable, or experimental.
Also, if we did away with both AD/A and Synaptic as local applications, they would simply be replaced websites like the FSF free software directory, or Freecode/ Freshmeat. Although that might be better in some ways, it doesn't solve the problem described above, it just shifts it from local to remote.
I am a translator!
If one can NOT learn by heart in 1 minute and 12 seconds (to make it easy) sudo apt update / upgrade /install /remove and optionally aptitude search in another 12 seconds I really wonder how is she/he able to even just turn the lappy on..
x_X
I'm not even being funny. I sincerely agree with this.
It may be easy to learn but a lot of people are just more comfortable using a GUI and there’s nothing wrong with that
I am a translator!
That is "being overly comfortable" and might as well be seen as "been lazy" but lazy in a stupid way IMHO.. I don't think being overly comfortable and lazy can be defined as "nothing wrong with that". But then again that is just my opinion.
cheers
p.s - mind that this comes from a guy that uses GUI for pretty much everything. GUI are great and nice but for some things they are counterproductive and just not as good as terminal and for me updating the system and installing and removing apps is a clear example of it.
GUIs pretty much always suck. Period. They're pretty much only good for web-browsing, word processing (even then, LaTeX), and image editing.
Even though terminal programs are generally faster and easier to understand, they're often harder to learn than the GUI for regular users.
Part of this is, I believe, is a self-fulfilling prophecy. People believe that using a terminal is slow and difficult, so when they try it for the first time and mess up a little, they revel in confirmation bias.
People generally avoid GNU/Linux *because* they believe that they'll have to use the terminal. Trying to teach them to use a terminal when they start using GNU/Linux could very well leave a nasty taste in their mouth, and will confirm in their minds that Windows is easier to use.
I recommend referring new users to GUIs, and referring technically inclined users to the terminal.
I am a translator!
Naah.. GUIs are fine.
Graphical interfaces are simply documentation with buttons. When designed well, they are *much* easier to learn independently, just by exploring the various menus and experimenting, which opens the possibility of a GNUbie trying out GNU/Linux without being personally recruited and trained by an existing user. This helps our movement grow much faster, and is tremendously good for the cause of software freedom.
There are many advantages to the repository system we use in GNU/Linux, such as automatic dependency management, clean uninstallation, and being able to download most software from trusted sources, instead of random websites. But it is a very different approach from what GNUbies are used to, which means there is already a steep learning curve.
Everything we can do to make this curve gentler is good for software freedom. I can't stress this enough. Thus, having a simple, graphical installer like A/R A for graphical end-user applications (and only these) is a no-brainer. Once a GNUbie gets settled into GNU/Linux, they can move to Synaptic, which means they start to learn about package names, dependencies etc. It would be great if Synaptic displayed the commands its back-end is running, to coach the user about how to do the same thing in a terminal once they feel confident enough.
>> That is "being overly comfortable" and might as well be seen as "been lazy" but lazy in a stupid way IMHO.. I don't think being overly comfortable and lazy can be defined as "nothing wrong with that" <<
I really thought the GNU/Linux community had moved on from this kind of elitist attitude, which is a hangover from the days before GNOME and KDE when GNU/Linux was only usable by sysadmins. When was the last time you successfully convinced an average user to transition from Windows or OSX to GNU/Linux? How did it go when you explained that things they are used to doing by:
* downloading and clicking an .EXE and clicking 'OK' multiple times (Windows)
OR
* downloading and clicking a .DMG and dragging the application package to Applications (OSX)
...would instead require them to memorize and perfectly type a range of text commands, which if typed incorrectly, or in the wrong order, could totally bork their system !?!
EDIT: In fact, when was the last time you convinced someone to adopt GNU/Linux at all?
>> mind that this comes from a guy that uses GUI for pretty much everything. <<
I rest my case ;)
I am a member!
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Documentation with buttons; I like it; maybe I'll use that in my next
recording.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJWBXIUAAoJEPDWzxLwi2tA6NgIAK+mzY5BUxuMewltWJ3lqlm7
/8MkN/dEcIxGcz9hEJVZgoNzO4KdMrCC0IA2cqxnuM0vjfIILsf+tmv+fDzB7hNC
rsjVarc8M2WfJhJ1G8cEyqwx6DRqtPxKqZXNfPiFna6b6smrejPAveiaN1gLQK18
IaC5dceHs2yDNDlDaflUzv16Dan1S4SVK93y+998i6lozkIHZ9RHwVGDaF0kW4n+
j4+NixIniMx4Bj1+V1Bux5w5wRfGReFh52tl8en8FVK9WZHI1DjcSAj1dodff0Wn
LQulzvJ7/AgiENMj9lgyArAuPcgyrinCDVITQSLzEFOKgC3qtIYQYxIsL95m2Fk=
=MLYr
-----END PGP SIGNATURE-----
I guess the root problem here is the packages themselves. I don't think there really is a problem though. Some packages are intuitive to use, e.g. graphical in nature and insert a menu item when installed. The others one just has to figure out how to use.
Most packages come with manual pages of varying usefulness, usually a man page for each command. Also other documentation is often included, like configuration examples. Especially packages which are meant to be used via the command line normally come with a fair amount of docs.
One useful command to list package contents (of installed packages) isdpkg -L packageFor example the read-out for the package feh (an image viewer) is
/.
/usr
/usr/share
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/feh.1.gz
/usr/share/man/man1/feh-cam.1.gz
/usr/share/man/man1/gen-cam-menu.1.gz
/usr/share/doc
/usr/share/doc/feh
/usr/share/doc/feh/AUTHORS
/usr/share/doc/feh/README
/usr/share/doc/feh/examples
/usr/share/doc/feh/examples/buttons
/usr/share/doc/feh/examples/keys
/usr/share/doc/feh/examples/themes
/usr/share/doc/feh/README.Debian
/usr/share/doc/feh/copyright
/usr/share/doc/feh/TODO.gz
/usr/share/doc/feh/changelog.Debian.gz
/usr/share/feh
/usr/share/feh/fonts
/usr/share/feh/fonts/black.style
/usr/share/feh/fonts/menu.style
/usr/share/feh/fonts/yudit.ttf
/usr/share/feh/images
/usr/share/feh/images/logo.svg
/usr/share/feh/images/menubg_aluminium.png
/usr/share/feh/images/menubg_aqua.png
/usr/share/feh/images/menubg_black.png
/usr/share/feh/images/menubg_brushed.png
/usr/share/feh/images/menubg_default.png
/usr/share/feh/images/menubg_sky.png
/usr/share/applications
/usr/share/applications/feh.desktop
/usr/bin
/usr/bin/feh
/usr/bin/feh-cam
/usr/bin/gen-cam-menu
/usr/lib
/usr/lib/mime
/usr/lib/mime/packages
/usr/lib/mime/packages/feh
/usr/share/man/man1/gen_cam_menu.1.gz
/usr/share/doc/feh/ChangeLog.gz
Therein among other things we can see manual pages (/man/), some extra docu (/doc/) and the binaries or executables it comes with (/bin/).
One reads the manual pages using man, e.g.man feh-cam
The other (plain text) docu can be read using any text editor or e.g.less /usr/share/doc/feh/examples/keys
>> Some packages are intuitive to use, e.g. graphical in nature and insert a menu item when installed. The others one just has to figure out how to use. <<
It's worse than that, as demonstrated in my examples. Some packages don't work *at all*. Also, figuring out how to use a package is much easier for people who already have a solid knowledge of GNU/Linux, for example, I was only able to figure out I have to start JACK first to make FreeWheeler launch because I had seen JACK demonstrated before, by a musician friend who was doing quite a bit of experimenting with free code audio applications. Having applications like this presented in a user-friendly AR/A interface is bad PR for free code software. It provides anecdotal evidence for the FUD argument that proprietary software is more professional and reliable. This is not exactly our fault, but it's something I think we would do best, where possible,to avoid.
AR/P: https://en.wikipedia.org/wiki/Anti-Revolutionary_Party
edit: Why the -1? I was trying to joke (OK I guess it wasn't overly funny....sorry!)
I fully support the original posting and consider the first answers of moxalt and SuperTramp83 as elitist, and elitist in a stupid way if those people want to extend the range of Free Software.
I got almost nothing explained about how GNU/Linux systems work, but i figured out to use Synaptic and i like it. It is better than the graphical way, especially than the (L)Ubuntu Software Center. So i agree: Only basic stuff should be in the graphical Add/Remove App program, and maybe some things are not necessary to have in Synaptic, because the people who might use it (like developers) will have access to them another way,too.
I am a translator!
Ra -> Elitist? Really? lol. Wanting to do your computing on GNU/linux without spending a little bit of your time and effort to learn apt (Debian based distros) and the essential core utilities is like wanting to play guitar but not spending some time to learn no scale or tabs.
I find it and define it being "stupidly lazy". M'kaay?
I don't feel the analogy is apt. For many people, computers are simply a means to an end, perhaps even a necessary evil in their lives--certainly not an instrument they aspire to gain proficiency in using for personal pleasure or to creatively express themselves (e.g., a guitar). Some of the smartest people I know are barely computer literate. And I think the argument between GUI and CLI is especially moot when using Ubuntu and its derivatives (e.g., Trisquel) in the 21st century. These distributions are geared to be relatively accessible to folks whose technical aptitude and available time for learning their way around a more "traditional" Linux system is strapped. Using Trisquel today is not like using Slackware in 1996, for example. Yet strangely, a lot of the rhetoric about CLI use seems not to have changed much despite the knowledge barrier for "entry" in today's Linux world is *much* lower than it was.
As a related aside, I feel the success of Tails (https://tails.boum.org/) is not simply because the project developers are very competent, but also because they have an innate understanding of who they are making Tails for. They don't make their users undergo imagined rites of passage just to retain their anonymity. Instead, the idea was that the special features of Tails should be employed transparently so users can take advantage of their benefits with very little special knowledge.
You might find it interesting to know that Richard Stallman has no idea how to install any GNU/Linux system, because he always has someone else do it for him:
https://www.youtube.com/watch?v=umQL37AC_YM
This isn't exactly the same thing as using the system in a particular way, but RMS also has expressed that he's not very good at using graphical interfaces. I remember the video someone pointed to showing that RMS was using Trisquel 6; he acted entirely confused by Trisquel's interface, and had problems with his slideshow presentation I probably could have solved in a couple seconds were it me. So, he's been the complete opposite of the typical user in that sense.
Now, you can claim that the command line is just superior in every way to graphical interfaces, but the fact remains that RMS hasn't fully learned to use his system, and hasn't learned to install his system at all. So if you're going to claim that all those other users who haven't learned to use the CLI need to learn it, or else they're "stupidly lazy", surely the same also applies to RMS and what he doesn't know how to do?
Coming back to the original posting: Actually a merge of the "Software Center" (Add/Remove Apps) and Synaptic would be good. The way it is now a new user might stick to the Software Center and not even notice the single packages in Synaptic that add new features to many programs. Those single packages can be really important, like language packs and email plugins. Synaptic alone, in turn, is not so easy to understand for newbies.
So, i guess the best would be one program instead of two (isn't reducing redundancy a goal in itself?) with two different levels: One where to find basic programs in their basic edition, and the second one with additional stuff for those programs and less popular programs.
Then even a third level would make sense, with a note like: This section contains a lot of packages that are in development and is recommended to very experienced users.
OK, so you endorse my proposed three category rating system, but propose reducing the number of GUI interfaces to maintain. I believe that AR/A and Synaptic should have quite different purposes. In my original proposal, AR/A would only offer end-user applications, although I agree this would include any user-friendly expansions available for those applications. Synaptic would also offer packages average end users don't use, for things like development environments, test servers etc.
I presume that the same non-graphical back-end programs are being invoked by both AR/A and Synaptic when they call the same functions (eg install or uninstall), and that these same programs are probably being invoked by apt-get commands too. Also, the Synaptic and AR/A GUIs are mostly calling on libraries used in other graphical apps. So there's not as much duplication of effort as it might appear.
> AR/A would only offer end-user applications
Is this not already the case?
You are brave for posting this. I have felt this way for a long time, but as you can see there are too many people here who already know how to use GNU and want everyone else to learn it in the same way they did or at least to the extent that they did. And so, you've been getting a lot of flak for suggesting that we prioritize making CLI knowledge not mandatory for casual Trisquel usage.
To those people, I can summarize my main point of contention in something I've found to be rather concise:
GUIs are self-obvious.
CL interfaces are not.
Obviously, this assumes well-designed GUIs, which are harder to do than CLIs. "Documentation with buttons" is a great description of GUIs, but it comes from the perspective that "documentation" should be separate to begin with - when I prefer applications with enough discoverability that they don't even need documentation.
While GUIs are more accessible from the start, they won't match the workflow efficiency of the CLI - and the solution to that is simple. If you're at the point where you're interested in increasing your efficiency of your tool, learn and switch to the CLI.
Until then, self-obviousness is key. It's obvious how to use a mouse. From there, you position the cursor over some action you might want to take. A tooltip pops up and tells you what the action entails. You decide if it's the behavior you're looking for, and click.
You are immediately presented with all of the program's capabilities. In a terminal, you're presented with a blinking cursor. What are your options? You have to *already know* what you want to do, and how to do it - and of course, you must type it exactly correctly. Sure, you could use TAB completion. But pressing tab is not obvious. Yes, I know you could purview the man page. But that means you know how to do that, which is just more prerequisite knowledge... All these tiny things one must know can be argued to be trivial. But they add up! And for someone new, it's not muscle memory.
Perhaps I can relate this prerequisite knowledge to you in terms of "dependencies". In terms of knowledge, the GUI has only one dependency in many cases - the ability to use the mouse. A CLI has many dependencies, it is a "bloated package" that many users may not want to install into the system that is their brain - even if only due to the file size and download time.
I believe the self-obvious criterion helps in the package management area discussed here, as well. What if I want to go package shopping? The command line doesn't seem to have very good solution for that. Everything's quick if I already know the package name - but if someone wants to know what's out there, what are they supposed to do?
The closest thing to my knowledge is to search for a text keyword in the repository. But with a graphical package manager, we can just _see_ all of the packages on the screen. At this point, clicking on the desired item is incontrovertibly faster than typing the install command + package name into the terminal.
I'm thinking of making a graphical application for browsing the available software that neatly shows a package's Full name and version, where the version is in relation to the latest release, the maintainer and author, the rating relative to others in its category, examples in action, the dependency count, the user experience level required and of course whether the tool is CLI-only (and whatever else I can think of). It's silly how little information the Ubuntu Software Center gives you, but we should definitely take a tip from them where they allow you to hide the “technical packages” that aren't a dedicated “application” on their own. I was thinking of making this in HTML. What do you think, strypey?
As always XKCD sums this up nicely:
https://xkcd.com/627/
With a user-friendly GUI, a web browser, and this "cheat sheet", GNUbies can learn to use, tweak, and fix their system independently. If they install GNU/Linux and get presented with nothing but a blinking prompt, they need an experienced GNUser to talk them through every new thing they need to do. Thus, good GUI massively increases the reach of free code software, and empowers people to adopt it after reading about online, rather than being personally recruited and trained by an existing software freedom jedi.
I taught myself Trisquel in two days. A month ago, I could not even use google properly. I looked around here for a week, then installed Trisquel the next week, this past week I enjoyed helping people in the forums, and helping them figure out solutions to problems. Without cheat sheets or Programming background. That sums up my Three week membership here lol.
SO, it is not impossible to teach yourself Trisquel GNU/Linux. OR command lines. I am still in the life of a Newbie. Perhaps, strypey, what we need is a "Newbie" Corner, for users on here willing to join the forum to ask silly questions. (:
ALSO, I am yet to write the Newbie Wiki, you are more than welcome to join in.
- Login o registrati per inviare commenti