Problems solved by segusoLand


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.


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

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.