Problems solved by segusoLand

Discoverability

segusoLand excels on discoverability. Think of anything: you immediately discover if and how segusoLand can do that.

This is accomplished with the Index of Concepts, which allows you to easily search for any combination of keywords. In traditional programs, the option dialogs are not searchable (you have to search them with your eyes). segusoLand has no dialogs: only a flat list of commands, that can be narrowed by selecting keywords from the index.

Learnability

segusoLand must not be learnt. You already know how to use it. You tell segusoLand what you want to do with your own words. You will never ask yourself "Where is the option to do this?".

Slow migration time to Linux

Before segusoLand, if you wanted to switch to linux, you had to relearn to do everything from scratch. (e.g. how can I watch a movie with an srt file, how can I listen to an APE sound file, how do I create an mp3, how do I read a pdf, how do I read a DOC file, how do I scan a drawing, how do I...)

Each of these tasks had to be learned separately. That is, everything was done in a different way. Therefore you had to learn many new things ("in order to read a pdf I must use this or this..."). Learning takes much time and effort. This causes reluctance to switch OS, and therefore inertia.

With segusoLand, after you have learned the basic paradigm of executing an action, you do everything the same way. So you instantly know how to do everything. This is what I mean when I say "segusoLand must not be learnt".

The currently available interfaces are not homogeneous

The currently available interfaces (Windows, KDE, Gnome...) often force you to use very different techniques (or "paradigms") to accomplish similar tasks.

Example: under KDE (and Windows), in order to play a song, you can click it (or double click it). But this paradigm of interaction is not "expressive" enough: it can't be used to issue a command that is a bit more complicated (e.g. play two songs consecutively, or play the song with a specific program, or play the song tomorrow at 12 am). For that, you have to use another, completely different, paradigm. In other words, we say that the paradigm is not "extendable" or "scalable".

The reason why multiple paradigms are available is, of course, the need to speed up the execution of common actions. This way, the most common actions become very easy to be accomplished, and the unusual ones are still available (at least in principle; in practice, KDE does not allow you to play two songs tomorrow, etc.).

So, what's the problem? The problem is

The multiple paradigms must all be learned, and this increases the system's learning time. And causes reluctance to switch to the new system (e.g. KDE).
Even when you have learned, switching paradigm when you want a bit more control is very annoying. Say I have a konqueror window open, showing my songs. I want to enqueue the song instead of playing it now. You can't do that from konqueror (anything you click is played immediately), so you have to open the player's menu, traverse the file system, find the songs and issue the command from there. In other words, I am forced to switch from the document-oriented paradigm to the program-oriented one.
The paradigms to accomplish uncommon actions are usually not apparent. The systems tend to hide them. So the person who is learning the system can fail to realize if and how something can be done. But the newcomer does not want to do things quickly: he wants to easily find out how to do things (both usual and unusual), and does not want to remember different paradigms to do something, depending on details which are irrelevant during the learning phase. He would prefer only one paradigm, which is sufficiently expressive to allow him to do anything, yet is reasonably easy to execute. But not necessarily quick to be executed.

For these reasons, segusoLand has a different approach: do NOT create two ways to do the same thing, but use only ONE paradigm, which is expressive enough to be able to specify everything, and render THAT paradigm easy to use. For example, segusoLand forces you to specify the program and the time, but this is made easy with tricks (the program clickable area is large, and the time can be selected only once and then left selected).

Other example of paradigm clutter in current systems: even though a file and a computer are both logical objects, you cannot act on them the same way. You cannot shut down your computer the same way you delete a file.

Once upon a time, some programmer must have decided that a file, a program and a device are different things, therefore they must be treated differently. But it is not true: in a sense, they are all OBJECTS, they all support some VERB.

Example: If you want to delete a file, you can drag it to the trashcan, but if it is not visible you have to use another technique.

There are hundreds of inconsistencies of this kind.

Under GNU/linux there are too many programs to keep track of

How many times do you use the shell because you don't know a GUI program to do what you need? Think of krename, kparted...

How many times do you use a program because you don't know an alternative?

segusoLand puts an end to this. The idea is to support all useful programs eventually.

The user cannot have a list of equivalent programs for doing a given task

The start menu solves this a bit, but only when it's well organized, and task-oriented. And it has many other problems (it doesn't do narrowing for example).

The user cannot have the list of tasks a given program is capable of

Of course you can run the program, but many times it is not apparent what the program is supposed to do.