Linked by Kroc Camen on Thu 5th Nov 2009 21:05 UTC
Talk, Rumors, X Versus Y There's no right way to do it, only ideas that are better than others in certain situations. But if you had the opportunity to head up the design of a new OS, one to Put Things Right, one that could be radical enough to varnish out those UI/X bumps that have clung on for years, but practical enough to be used every day, what would you design? How would you handle application management? What about file types and compatibility? Where would you cherry pick the best bits from other OSes and where would you throw away tradition? I've tackled this challenge for myself and present (an unfinished idea): KrocOS (warning: HTML5 site, will display without CSS in IE/older browsers). OSnews Asks: What would make your perfect OS?
Thread beginning with comment 393127
To read all comments associated with this story, please click here.
sorpigal
Member since:
2005-11-02

This post will be long and somewhat critical/negative. This is by necessity in both cases and it should be noted that no malice is intended.

I have given some thought to a lot of the same issues as mentioned in the article with radically different conclusions (mostly). I wont go much in to what I think but instead try and focus on what makes the article's solution good, bad, or in need of some more thought (a lot of this).


Everyone has his own idea about what makes a 'perfect' OS--or should we just say a better OS? One reason we don't have one like the article describes is that everyone has a *DIFFERENT* idea of what's better.

To me, most of the things he talks about would be VERY BAD! Giant leaps sideways and some backwards. I do *not* want my computer to 'adapt to context'. Context is irrelevant. I will decide what I am doing and TELL my computer that. It should not assume!

Example: Suppose I do go to a directory of audio files. Do I necessarily want itunes-type functionality? Maybe I want a mass tag editor. Maybe I want to zip them up. Maybe I want to do a lot of things. The computer probably *cannot guess what I want* and should not try!

What he's really asking for here is de-monolithicizing (if I may coin a terrible word) which is what BeOS does that's so good. The application should treat things that can be files as files, because that makes application interop much easier (and more logical!). Contrast to Outlook PST or even Mozilla style mail handling and BeMail is obviously superior. But, making Explorer become a mail app when viewing a mail directory... no. No! I don't want to mark my directories as "for mail" or "for pictures." This is tedious, like nepomuk tagging is tedious, and tedious things just get ignored. I don't want the system to 'guess' the way e.g. Windows Explorer now guesses what view mode to use by default based on some of the files in the directory. I don't want browsing to my mail folder to auto-load a GUI I don't necessarily want, wasting my time and computing resources.

The article's passing praise for spatial file management is suspicious and an indication of one major way in which I will always disagree with the author.

2.1 Managing Applications

Oh, horror. I agree that "no branding" is good and generic names are better... when you only have one application of any type and when the difference between types is clear-cut. In utopia there's no conflict, but we do not live in utopia.

Text Editor - vi or emacs or notepad? Wait, what about Wordpad? Or is that Word Processor? But what about Word? No, what about ooo-writer?

Okay, so let's say we only have one good one installed at a time. Which one? What happens when I invent a better way of doing e.g. a music app, because I am a genius like that. Suppose I write it in C and the current one is written in Java. I can't just patch the existing one to be like mine (maybe I do not know Java). How do I use mine instead? How do I have them both installed while testing/troubleshooting? What happens if a user wants to use mine today, but their old one tomorrow?

Example: I download the adobe ebook reader and it appears as "E-Books." But, Adobe doesn't support the format used by my favorite e-zine provider! So, I download their E-Book reader and...? Now what?

2.2 App Folders

Preference data is user-generated data. Ignore this fact at your peril.

Games internally store save files? But what about multi-user systems? Are we back to the old "only 4 save slots, sorry" syndrome? What about copying games to a friends' system? What about the fact that game save files are often HUGE?

3. A Better File System Hierarchy

Restricting users to only user data is more or less done today. In Windows you just never leaver %userprofile%, in *nix you never leave $HOME. KDE and GNOME are pretty good about showing you just your home. Now, granted, you could do better at hiding the rest of the real system... but it doesn't require much work on existing systems.

All that said I think it's a bad idea. If you make things discoverable people who want to learn will learn. Just make them hidden-in-plain-sight such that users who don't want to learn will know not to get themselves in trouble. If you are too good at hiding complexity the next generation of developers never emerges...

If you really want to make things simple for the user why don't you get rid of the f--king desktop? Why would you want *devices* on your *desk*? The desktop metaphor is old and very, very broken. Trying to make software work more like the metaphor is as useless as trying to keep extending the metaphor further. This is a real area where a little well placed innovation would be worthwhile. Hint: I have never used a file folder in real life, I don't keep things in desk drawers, I don't have a desk that does anything other than hold a keyboard and monitor... and I probably represent the leading edge here.

The reality appears to be that BeFS is the closest thing we can currently get to a Database Filesystem. Remember Microsoft failing to get WinFS working? That's because this is really, really hard. So, assume you can't get a better technical answer than BeFS and build your better FS layout on its capabilities.

4. A Better File System and File Types

BeOS, as I recall, already stored the mime type of each file as an attribute in the FS. This is what you want, just have a mime-like attribute that stores a less specific mime type (e.g. text, not text/plain) and you're mostly there. Decoding and decomposing other data from files as they are saved would be helpful, I suppose. Would the import process actually te-tag MP3s? It's an interesting idea. You could not guarantee an ability to understand every kind of file that exists, nor are there ways to actually remove some kinds of metadata from some kinds of files. Example: PNGs could save a lot of header information in the FS, but it would not really be a PNG at that point.

The idea of auto-decomposing and recompiling metadata as the file moves in and out of the system is interesting. So far it's the only thing I've heard that would be useful, however impractical. On we go.

5. RISC OS’ Menus

The problem with context menus are well known, I will mention a few:
- not very discoverable
- quickly grow huge (think Windows Explorer's after you've installed a few apps. If you think this would not happen... well, think what you like)
- slows down interaction
- usually hard to access without a mouse
- did I mention really slow?

That said, maybe RISC OS had some answer for this that would survive leaving a niche OS without a lot of chaos. I never used it, so let me know.

6. Viewing / Editing Files

Again, some issues exist.
- I have GIMP and PhotoShop installed. What verbs will be used to differentiate them?
- What if you have a photo-retouching app and a painter app. Both could open images. Which one is Edit depends on who you are, so which is Edit? (And what is the other called?) You could say "Retouch" and "Paint" but sooner or later this question must be answered for the generic case.

7. Window Management

The way to avoid minimize/maximize, etc, is to use a modal interface and multiple desktops/modeviews. I know people will cry "heresy!" but this is the answer I have. No matter what you do you will need to accommodate:
- interaction between multiple app windows on the same screen
- one app consuming the entire screen
- switching between multiple full screen apps
- interaction between multiple app windows on different screens/modeviews.

Case: I want to see a tail -f style log window and a monitoring app for various I/O and my text editor for my code and my IRC client all at once.

Case: Then I want to play Quake 4 and pwn some friends.

Case: I am playing Travian (travian.us) and want to queue up 4 different attacks, requiring 4 different web browser windows with specific sets of tabs. This is a personal one, for me multiple desktops is good enough here.

Reply Score: 7

sorpigal Member since:
2005-11-02

Continuing, because I hit the char limit.

App Examples:

I will say only this... have you tried the IRC client 'sic'? In terms of using files for things, it is quite fine... usability suffers somewhat. No, this is not on topic, but it is cool (-;

Exciting Finish:

It's nice that you're thinking, but I would never want to use this OS. Some of the ideas are interesting, most of them are just horrifying. A lot represents a naive understanding of the problems being solved.

I am really a nuts-and-bolts guy. I am more interested in how would this be implemented than a birds eye view/mockup of the interaction and concepts.

The important thing to do is understand why we're here and take into account all of the people who are not like you when designing something new. One size doesn't fit all, but doesn't everyone (more or less) use Windows?

It's easy to design an OS I would love, it's hard to design an OS everyone could live with.

Reply Parent Score: 3

Kroc Member since:
2005-11-10

I am more interested in how would this be implemented than a birds eye view/mockup of the interaction and concepts.


I am interested in the birds eye view, because I’m a designer and would lack the skills to get into the very specifics. I never set out to produce something complete and bullet-proof—these are just a collection of ideas I wanted to get off of my chest ;) Should someone want to implement this, it would go through several hundred design revisions until all the kinks were worked out.

Reply Parent Score: 1

Kroc Member since:
2005-11-10

The computer probably *cannot guess what I want* and should not try!


No, I would _never_ have the computer guess, that’s annoying. Windows XP does it, and it’s annoying. You would set folder types as and when required.

Text Editor - vi or emacs or notepad? Wait, what about Wordpad? Or is that Word Processor? But what about Word? No, what about ooo-writer?


Again, just purely ideas and I never designed it to be a solution to 3rd parties disagreeing with each other. If I could make an OS that regular people could accomplish everything they ever needed, easily, then it would still be a success—even if you couldn’t install Word on it.

Vi/emacs in particular would be system utilities—under the hood stuff like the command line, an area I haven’t described yet.

If you really want to make things simple for the user why don't you get rid of the f--king desktop? Why would you want *devices* on your *desk*? The desktop metaphor is old and very, very broken.


I never for a moment thought about my design as a 'desktop metaphor'. I just personally like my devices on the desktop picture, like we have on OS X, Amiga OS and even as I was doing so in the 1980s with GeOS. It’s one less screen to go through to get to something, unlike Windows—I hate the clunkiness of “My Computer”.

Games internally store save files? But what about multi-user systems?


An oversight, I will think about a better way of doing that. (Remember, the computer is personal).

You could not guarantee an ability to understand every kind of file that exists


File filters would be centralised like Amiga OS, so they could at least be easily plugged in and all apps would gain the ability to understand new file types.

- I have GIMP and PhotoShop installed. What verbs will be used to differentiate them?
- What if you have a photo-retouching app and a painter app. Both could open images. Which one is Edit depends on who you are, so which is Edit? (And what is the other called?) You could say "Retouch" and "Paint" but sooner or later this question must be answered for the generic case.


1. this is contrived because these things would have to be ported, and that would be unlikely, the built in editor would be as good as GIMP to begin with, and those needing something even better could swap out the built-in editor with a new binary (keeping the same verb), or use a new verb of their choosing ('Photoshop' ;) ). Maybe “Edit (Pro)”, or have the simple editor as “Modify” and the complex editor as “Edit“.

The way to avoid minimize/maximize, etc, is to use a modal interface and multiple desktops/modeviews.


Haven’t done much about this, but one idea I had was perhaps a workspace manager could minimise / maximise entire sets of windows into an icon on the desktop. Instead of virtual desktops, you would have groups of windows that could all be hidden or shown together when you wanted, and this information stored as a file that you could name and move around. Thus you can setup a screen full of windows for a particular task (like debugging) and save this session to a file that you can open at any time.

---

Thanks for comments. Do note though, that KrocOS is just a pipe-dream and no serious attempt to solve anything, as it would never come to exist anyway. It’s just how I would design a computer ecosystem if I was like Steve Jobs, being tasked with unswervingly driving an OS how I see fit.

Reply Parent Score: 1

sorpigal Member since:
2005-11-02

"Text Editor - vi or emacs or notepad? Wait, what about Wordpad? Or is that Word Processor? But what about Word? No, what about ooo-writer?


Again, just purely ideas and I never designed it to be a solution to 3rd parties disagreeing with each other. If I could make an OS that regular people could accomplish everything they ever needed, easily, then it would still be a success—even if you couldn’t install Word on it.
"

There are ways to solve this problem. It could be as simple as a simple priority list: Text Editor would not be a single app, but any app that implements Text Editor. It might be possible to create an easy UI that allows the user to know that there are multiple options and toggle between them without requiring specific names. Or, perhaps a creator code type system could be used to select a preferred one if many are available.

I never for a moment thought about my design as a 'desktop metaphor'. I just personally like my devices on the desktop picture, like we have on OS X, Amiga OS and even as I was doing so in the 1980s with GeOS. It’s one less screen to go through to get to something, unlike Windows—I hate the clunkiness of “My Computer”.


Several of the things you describe, most notably any talk about folders, suggests a desktop metaphor. Sorry if this is not what you intended.

I don't have a problem with icons on my workspace indicating devices, although I don't prefer it, but don't call it a desktop (-:

"You could not guarantee an ability to understand every kind of file that exists


File filters would be centralised like Amiga OS, so they could at least be easily plugged in and all apps would gain the ability to understand new file types.
"

Doesn't BeOS also do this? I do like it, it's the correct answer as far as I'm concerned, but in the real world you have to have an answer for what to do with unknown file types (or file types where splitting information out of the file is not feasible).

Ideally all files would be in some kind of nice format (I rather liked IFF and its friends) but in the real world legacy formats must be accommodated.

1. this is contrived because these things would have to be ported, and that would be unlikely, the built in editor would be as good as GIMP to begin with, and those needing something even better could swap out the built-in editor with a new binary (keeping the same verb), or use a new verb of their choosing ('Photoshop' ;) ). Maybe “Edit (Pro)”, or have the simple editor as “Modify” and the complex editor as “Edit“.


The situation is contrived for this specific case, but in general an answer is needed. I am not against removing specific names but there are some problems with doing so. Another example: Grandma doesn't need something as complex as the GIMP or an editor of similar power, she just needs to remove red eye. Is it still a good idea to make the default editor so powerful? This is a less contrived reason why you might need two programs that can do the same thing (retouch photos).

"The way to avoid minimize/maximize, etc, is to use a modal interface and multiple desktops/modeviews.


Haven’t done much about this, but one idea I had was perhaps a workspace manager could minimise / maximise entire sets of windows into an icon on the desktop. Instead of virtual desktops, you would have groups of windows that could all be hidden or shown together when you wanted, and this information stored as a file that you could name and move around. Thus you can setup a screen full of windows for a particular task (like debugging) and save this session to a file that you can open at any time.
"

I like it. It would be especially useful if I could store iconified work-sets like this on my dock, which I like to keep as an ever-present 64px sidebar on the right hand of my screen. The only thing at that point would be to make some good keybindings for rapidly toggling between them.

It would solve my need for 32 virtual desktops fairly well, without the clutter of always having 32 desktops.

You could even throw in session/state management features. When iconified the entire work-set could be unloaded and saved to disk, then copied to another computer and restored. Maybe.

Reply Parent Score: 2

cycoj Member since:
2007-11-04

I really have to congratulate you on this post. I find it very informative and well thought out. Although I don't agree in all points with you I think we both have a very similar way of interacting with computers. Just a couple of things which I like to add which my ideal OS would have.

CLI:

Every program would be easily controllable from the commandline. I find myself doing 70-80% of my work using terminals. I don't understand why people want to use filemanagers, in 99% of the cases the work is done much faster using bash. This is also why I disagree with the whole KrocOS approach of contexts. If I go to a folder I know how I want to manipulate the files. And that could be very different from one time to the other. For example if I write an article in latex, sometimes I want to compile the file to ps sometimes to pdf, sometimes I just want to edit it or just grep a for a word. I don't want to set folder properties which decide how I interact with the file.

WindowManagement:

I agree with your premise of getting rid of maximized/minimized windows. I think virtualdesktops are far superior (and I can't believe how long it took OSX to get them). Also I want grouping of windows, e.g. all gimp windows are part of a group so I can set properties on the whole group, i.e. to have all the windows always open on the same desktop.

Reply Parent Score: 1

sorpigal Member since:
2005-11-02

I tend to agree with regards to the command line, which is what I use for my file management (and a lot of other things). Originally I did this because all GUI file managers for Linux sucked. Since then I have found three that do not suck, but it's far too late to go back now.

I sometimes think I escape to the simple elegance of the command line because all GUI interactions suck. Other times I am not so sure.

The idea that the computer adapt to what you're doing is a tempting fallacy, IMO. Until the computer can literally read your mind, via a neural implant, it can only guess or not guess. Guessing is always wrong (this is not true, but it is true enough of the time that it may as well be true all the time).

Kroc had some interesting things to say about window management elsewhere in this thread, which may interest you.

I find that many non-maxed windows per virtual desktop is a rare, but not unheard of. Since I began using 32 desktops and one window per desktop (more or less, somehow I seem to find an xterm on each desktop too) I find that in all but a few cases application use is modal. But you cannot require this, because sometimes it isn't and when it isn't you absolutely must have non-modal.

I have very, very rarely wanted drag and drop. It sounds like a good interactive idea (and extends the useless desktop metaphor) but outside of painting programs I don't think I ever use it. Without drag and drop there's limited need for same-time viewing for interaction. Not to say you don't want to view different sources of information side by side, which you do, but the fact that apps do not actually share data due to user manipulation means a lot when it comes to what your window management design can be like.

Some experimentation with window management optimizing for the case where windows don't need to interact and only one app is in use at a time would probably bring forth some useful innovations.

Reply Parent Score: 2