Quote:Original post by Cipher3D
Ok, so if you say X should be totally destroyed, how should the windowing manager be like? I don't really understand why X is so bad. Well, maybe it is slow because it sticks to the client/server model although 99% of users don't take advantage of the client server feature, but what else is bad about X? |
The problem with X is that it has no concept of objects. Everything must be described - and thus sent over the wire - as a description in terms of lines, pixels and colors. Why can't the window manager inform the windowing system of how to draw various widgets, and then describe the interface at this higher level?
X must die.
Quote:Original post by Mayrel
How do you suggest we go about that? |
Start by evaluating tasks. What do users typically want to do with their computers? For each of these tasks, break them down into their component tasks until we finally get at the point where atomic operations occur. We must then ask ourselves, what is the most natural, efficient and intuitive for a person to communicate the intent to perform that operation to a computer, and document the entire process.
There, that wasn't so hard, was it?
Quote:| 1. Users shouldn't have to save files. The problem with this is that +we can't pick a sensible name for a document. The second potential problem is that if storage is transparent, undo information will need to be stored on the disk. This means the user will need to periodically discard undo information or run out of disk space. |
First off, most users never fill their hard disks. The cost of memory is falling continuously.
Now, let's assume that we have intrinsic versioning as a property of the filesystem. The default discard interval will be set such that the average user maintains a reasonable balance between the ability to roll back and memory consumption.
Voila! Memory problem solved.
The third issue, naming files. Why do we refer to files by name anyway? Of all the natural and mechanical properties they have, that's probably the most useless and unnatural. When you refer to the pictures in your photo album, don't you mentally categorize them by subject(s), location and date? When you refer to a report with a colleague at work, isn't it what the report is about - say, Q2 2004 Walt Disney Radio Presentation - that you base your discussion around? So why do our user interfaces foist upon us the busywork of coming up with creative file names, managing them and remembering them?
And why do we explictly have to save? In the old days, saving served as a valuable pause mechanism for programs due to the limitations of hardware. Today there already are programs that continuously save in the background with no discernible negative impact on user productivity. In fact, I'd go further and say that auto-saving
increases productivity, because you won't lose much work/data in the event of an unexpected interruption of operation.
That a user should work on a machine and then have all of that effort disappear into nothingness because of a non-user fault is a fundamental insult.
Moving on, why do we have directories? Actually, to answer this in non-rhetorical fashion, we have directories because of the limitations of older computers, which couldn't count beyond a very attainable limit like 256 or 1,024 without jumping through hoops, so the directory was introduced as a means of "resetting the counter."
Is that limitation still practical? My computer can count to at least 4 billion without breaking a sweat. There's no reason why I should be forced/required to store my files somewhere in a hierarchy - a hierarchy with a dangerous tendency to grow wide and one in which it is ludicrously easy to lose files.
In other words, the point is valid, but is only the starting point for a full discussion on file location, storage and retrieval usability. You'd see that if you weren't so tied to the attitude that we're just bitching for no reason.
Quote:| 2. Users shouldn't have to exit programs. A curious assertion. Fundamentally, all you need to do is change the "Exit" or "Quit" menu item to read "Close". Further more, I'm not at all convinced this is a problem. |
Actually, his point was that some programs make a distinction between close and exit. You can close all windows and, for all intents and purposes, have shut down the application, but the program actually continues to run.
There are instances where this behavior is desirable - instant messaging applications, for instance, or other "background" apps. Any other case, this is a Sin. Fortunately, this is far less common today. In fact, it is almost entirely a closed issue.
Quote:| 3. Users shouldn't be able to select files from a dialog. This is just stupid. Because the file manager can be open all the time, he argues, file selection dialogs are crufty. Which misses the fact that, on many modern UIs, file selection dialogs are the file manager. |
Uh, his point was that user shouldn't
have to select files from a dialog, particularly given that the file explorer (or Finder, or whatever) provides the same functionality but with a different interface. It's confusing.
You don't think so? Read JWZ's
comments about his mom and OS X.
(Don't know who JWZ is? Then you might as well roll over and die right now as far as this discussion is concerned. I expect you to know all the principal actors in the movement.
Hint: "Open Source is not magic pixie dust.")
Quote:| 4. Users shouldn't have a Start Menu. This is shockingly dumb. He argues that users should browse to the folder in which a program is installed and run it from there. Most users will find it easier to choose a program from a simple list that appears when you open the Start Menu. |
I'm actually with you on this one, to a large extent. Folder browsing is silly, given that I debunked having folders at all.
Where I differ is that I think that all major functionality should be immediately apparent to the user. The Start Menu hides top-line functionality between a three-tier menu (Start -> Program Menu -> Application). Bad. OS X' Dock is a much better idea, though it could probably use some tweaks.
Quote:| Any sufficiently complex extension to the operating environment is indistinguishable from an application. |
What is this, a paraphrase of Clarke's First Law? You missed my point anyway.
The current notion of an "application" serves primarily as branding. It's unnecessary. A much better approach is to expose functionality, along the lines of "Create a Text Document" (as opposed to an implicit "Launch Microsoft Word") or "Paint a Picture" (versus the shockingly blank wall of "GIMP").
But it's not just a presentation or menu entry issue. The deeper issue is why these applications should exist as segmented, isolated entities that duplicate functionality. I think it was you that boasted that your Gentoo Linux distribution contains 8200+ "applications". Wow. And how many
types of applications does it contain? In other words, how many of those applications are, for all intents and purposes, redundant? How many of these application categories are esoteric, meaning that the majority of users will never, ever use them?
The goal of a usable environment is to minimize the number of unnecessary decision points. Yes, configurability (and, by consequence, choice) is a virtue, but hide that behind an advanced user interface. When an average computer user wants to install Linux, do you think it's any wonder they look for the GUI button that says "Default"?
Quote:| What's the alternative? The data a specialised application uses, by its very nature, will be specialised for that application. |
Just. Not. True.
I've written on the concept of codec-based data storage before, and I do not feel like reiterating my entire spiel. Suffice to say that the actual storage mechanism of the data can be independent of the nature of the data itself, opening up interesting possibilities through synergies of functionality. Yes, that's a fairly obtuse block of text, but I posted a link to a complete discussion earlier.
Quote:| It isn't entirely unreasonable to suppose that a text editor can't open a video clip. |
No, but is it unreasonable to suppose that a user might want to embed a video clip in a text document (and by "text" here I include all word processors, not just the sort created by Emacs, vi and Notepad)?
Oh, wait, but that's already possible! OLE, COM, ActiveX, Bonobo. Oluseyi, you're just reiterating the existing.
What I'm suggesting is that this approach to data become so much more intrinsic that "embedding" is no longer a function of the application, but of the entire platform/user environment.
Quote:| The problem with componentisation of the GUI and document-manipulation systems is that there is no component system that a large majority of the OSS development community is willing to get behind. Componentisation is tantamount to object-orientation, and many OSS developers are (inexplicably) opposed to object-orientation. |
That's beceause the platform allows for competing componentization. If the components are part of the operating system, the only way to write applications for the OS is in terms of those components (or to author new components), and using those components is ludicrously easy, then the issue becomes moot.
OSS experiences these factional divisions because the problem is being address at the wrong level, tied too closely to non-issues like decoration, widget set, etc.
We can do so much better.
