Thank you for saying that. Seems this important point is often missed.
Regarding cars though, from what I understand it was the quality of Honda and other Japanese brands that finally proded the American manufacturers into making more reliable cars. The most profitable manufacturers are currently all Asian according to The Economist. I wish the best product always won. I also wish that all cars didn't look the same, and that all cordless phones didn't look like crap and have obnoxious rings, and that I could find a pair of jeans that fit... I guess one-size-fits-all is more cost effective:(
Wow, someone hasn't read his Rasking properly. I think you mean:
--Confirmation Dialog--
Jef Raskin, are you sure you want to log out?
[Type the (5th) word of the question to log out] [Remain logged in]
Dialog gradually fades away if no response given, and remains logged in
Or even better, like the other response, there is no confirmation dialog, merely an undo (log back in, and everything is as you left it).
Not to beat a dead horse, but confirmation dialogs often become less than worthless as users habitualize the most common response and then automatically give confirmation without thinking. The users then blame themselves for the mistake leading to further frustration.
Moral of the story: People make mistakes. Allow for easy "undo". If "undo" is impossible, make it impossible to habitualize the confirmation.
more fuel from growing corn than it takes to grow the corn
Well, of course not. But it takes sunlight to grow corn, among other things. Sunlight is "free". "Other things" are not free. And I have seen statements that the energy output can be greater than the input ("other things").
That should get you started. I can't find the link I want... it had a nice chart comparing corn, soybeans, rapeseed, and algae. I think corn barely puts out more than you put in (a point of contention I gather), but others are solidly energy positive (discounting, of course, the sun's energy input). Algae is nice because it can be grown in salt water...
Question: for laboratories, are there hoods with a laminar airflow from top to bottom that acts as a "door" that you can put your hand through? Could this be done for store refirerators, to keep the cold air in the fridge while having no door? I suppose if it could be, and if it would save money, it would have been done already...
Don't buy them! I bought some, only to discover that they have a flaw in their construction. Probably somebody trying to unload their obsolete stock...
... Example: Don't use 2 radio buttons when one checkbox would suffice,...
I respectfully disagree about that one. How many times have you seen a checkbutton that says something like "Do it this way" and found yourself thinking "as opposed to what?". Two radio buttons make the "what" obvious in a nicer way than a tooltip or a longer description to the checkbox. Click the one you want while thinking about what it does. (Much like how dialog boxes with "yes" "no" are evil. Put the action in the button: "discard changes". You think "discard changes" while clicking rather than having to mentally substitute the action in for "yes").
I'd also like to take this moment to state that toggle buttons suck. Please use checkbuttons instead. Example: the button is depressed and says "stop". Hm, so will clicking on it stop it? Or is "stop" an indication of the current state? There is no way to tell.
LyX is probably the fastest application I use semi-regularly that's also fairly complex (I guess I'm comparing it to GIMP, AbiWord, OpenOffice, Firefox and every other browser, Evolution, Kmail). Maybe it just doesn't do as much automatically, but it sure feels snappy in a way that no other GUI program ever has (except for "print preview" which invokes latex...). Can anyone enlighten me as to why? Is it antialiased fonts used in gtk2?
A more general comment related to the article: it is much much better to feel fast than to actually be fast, in my opinion. What techniques exist to ensure a responsive GUI application? I know many GUIs are multithreaded, with, say, one thread running the GUI's mainloop. Or you can simply use a mainloop+callback model. With threads and Gtk (and any X toolkit?), anything outside of the GUI thread must aquire a global lock before it touches the GUI, and the GUI is frozen for the duration. With callbacks, the GUI is again frozen for the duration of the callback. How does one ensure (within reason; I don't expect a realtime system) that the GUI isn't being held up too long? And what is "too long"? I've heard 250ms as the longest time a program should ever take to respond to input...
Hm... I hate my volume control situation... First, the soundcard has a master level and different levels for e.g., PCM, analog CD, input gain (which I suppose are all necessary). Second, some applications have volume knobs which modify one of the soundcard's volume knobs (xmms), while others have an entirely seperate volume knob that presumably controls in-application volume attenuation. And finally, I plug my soundcard into powered speakers that have yet another volume knob.
My troubles are: too many volume knobs. Probably the applications that have their own internal volume are correct; otherwise one could not turn, say, IM notifications sounds way down (but not off), and have music at a reasonable level. I suppose the soundcard's knobs for its analog headers (CD) are necessary because there's no other way to adjust that volume... but digital audio extraction is nice. The two master volumes really bugs me though (soundcard's and powered speakers', and if all audio is going through PCM, the PCM knob is essentially a third master). I suppose it would help if computers had an easy to click master knob (or preferrably, a physical knob) for those occasions (phone call*, door knock, unexpected annoying sound) when you need to turn the volume down immediately. Or perhaps the computer should ditch the master knob completely and assume that whatever your plugging into (powered speakers, receiver, etc.) has a master volume knob... I don't know how exactly I'd like it to work, but I think a big part of my troubles is the awkwardness of adjusting volumes with a mouse and sliders in a GUI... it isn't quick like a big knob or real faders on a mixer
What does anyone else think about this?
* P.S. Does there exist phone that draws power from the phone company (i.e. no cordless I've ever seen) that has a gentle ring whose volume may be adjusted? I don't want to hack my phone just to stop it from shreading my nerves...
Paper isn't an optical medium? Punchcards perhaps... I assume you are talking about better tech than my laser printer + scanner which I've estimated could hold about 1MB (which I believe is what the Paper Disk software can do) on a 8.5"x11" page. So what kind of data density can you achieve on paper, and what sort of printer and scanner are you using?
But, it's an optical format... so why not design materials that can achieve much greater data densities? Like DVDs? Surely it's possible to design something like a DVD that would last as long as paper? Or maybe not...
So, is this or is this not what I've always been seeking in a GUI:
total resolution independance? E.g. right now I can have my monitor at
800x600
and everything is *huge*, and I can have it at 1600x1200 and everything
is *tiny*. Sure I can have Gnome/Gtk+ use larger icons and fonts. But
not larger everything. Currently in Gtk+, one specifies the spacing
between widgets in pixels. Will this change to vector units and allow
the ability to smoothy scale everything up so I can use the full
1600x1200 but still have things readable? (And no, using a resolution in
between those two extremes is not a solution. They are too few;
none is quite right. Or it's an LCD where all but one is garbage.) And
what will these vector units be?
Actually, I'm usually running at 1024x768. There's always those few
programs that just don't fit on the screen... The ability to scale them
down would be fantastic. Ideally I'd have an enormous
monitor, but I don't.
If this is the direction this small step is headed in, then I applaud
the Gtk+ team and look forward to the future with excitement.
I second that request. Can we also please please please *please* throw in a real keyboard? Something like the happy hacking keyboard (I've got the Lite. Pretty costly, but the feel is fantastic... anyone want to buy me the Pro?). I don't care if it's 4 inches thick. I had an old (P133) IBM thinkpad that was pretty darn thick (not because of a good kbd, it sucked) and I rather liked it.
Damn I would buy one of these in a second (well, perhaps 486 speed is a little low...).
FYI, I have a Fujitsu P series with an 800Mhz Transmeta Crusoe and a short-height (can't recall the resolution at the moment) display. Supposedly with the extra battery you can get 8 hours of battery life. It lacks parallel and serial ports. Though, as others have mentioned, some fuel cell battery will likely be used to feed our power hungry devices rather than anyone sell a lean machine.
Redesigning the system isn't that hard. What's hard is convincing everybody to start using the new design.
Well, I'm convinced... show me the design. Are there any projects with any sort of following to design the ideal message exchange system? I'd be very interested in reading about them.
I guess this message sums up a lot of problems with IM2000.
With a push system (SMTP), sending is simple (just connect to a server and dump the message); receiving is complex (run/rent a server with permanent internet connection). In a pull system, sending is complex (run/rent a server with permanent internet connection); receiving however, still requires a server to receive notes. Once these notes are collected, receiving is simple, with no guarantee of robustness (connect to remote message stores and download message).
Surely there are many projects to reinvent email? Most discussions here are about modifying SMTP for reasons of its sheer momentum, but I'd also like to see what the ideal system would look like. Links anyone? I suppose I could start by reading the article... but who does that?
While I'm at it, are there any projects or interesting discussions about distributed trust webs (a la gnupg/pgp)? Some way to quickly determine the trustworthiness/legitimacy of an ID you've never met given that you trust or don't trust a few IDs you have met before.
Just today I ran across Internet Mail 2000, a concept apparently initially conceived by Dan Bernstein. I haven't read all or even most of the information on that page, finding it somewhat difficult to wrap my head around. The big difference from it and SMTP is that it is a pull rather than push protocol. For Alice to send a message to Bob, Alice puts the message on an IM2000 server (replaces the originating SMTP server) which sends Bob a note "hey, I've got a message for you". Bob's email client then downloads the message from the server.
The big advantage here is that the note is small, and Bob need not download the message at all if he believes it is spam, reducing the spam bandwidth usage. Also, the sender must make an effort to have a permanent server so the receiver may even get the message. Not really a burden for legit mails that already need a permanent server somewhere for receiving mails (right?). Forgeries are also prevented, because the note necessarily contains correct information about how to find the message.
Aside from the usual reply to anti-spam solutions (this one requires mass participation and won't happen, yadda yadda), and the lame name (shouldn't they change that to IM3000 now?), have others looked at this? What are your opinions on it?
Other replies have covered the technical side. But it may be the case that because they have a positive emotional response from using the iPod, for whatever reason (iPod's looks, enhanced self image, etc.) it actually does sound better to them even though the sound waves are identical.
Hm... you have a point certainly, but to dismiss "art" in an interface as rubbish is a bit drastic. Have you read Don Norman's Emotional Design? In it, he cites a two studies that compared ATMs. Two types of ATMs were used, identical in function with one looking "good" and one "not so good". Users of the nicer looking ATM had fewer problems using it than those of the other. Yes, actual observed problems, not answers to a survery "did you like it?". I do not know how they decided one ATM was "better looking" than the other, which is the first question I'd like to have answered.
At any rate, the study seems fascinating but not terribly surprising. Norman proceeds to sketch a theory of why the nicer looking ATM was easier to use, using cognitive psychology and the usual HCI tools to do so. I have only read the first couple chapters of the book, but highly recommend it.
Your final comment is appropriate. An interface that ignores art will likely look awkward or be otherwised noticed by the user, thus negatively affecting usability.
Which reminds me of a question... We spend all this time and energy looking for alien signals, but are we actively broadcasting anything interesting for aliens who may be looking for us?
Yes, I agree that filesystem abstraction is good. Have you looked at the Reiser4 filesystem? The papers on that site have similar ideas to yours. Why can't the filesystem be the interface to many things? Then we gain in the ability to use common tools (ls, less, rm,...) on something new.
Also, I am aware of two projects to create filesystems in Linux userspace. This is also a great idea and I don't truly understand those who do not see the usefulness. One is FUSE, the other is LUFS. Both require a kernel module (obviously), but from that point on users (other than root) can mount and use arbitrary filesystems. I have used sshfs included with LUFS to mount a remote fs only available via ssh. This makes me so happy. I love running commands over ssh, but I love running local tools on remote files even more.
Well, it isn't so hard to write good software per se (not that it's easy...). Your example with KDE shows that it is possible to have a good consistent interface *within the domain that you control* (i.e. KDE is controlled and written by one group of people who will all agree to write software in such a way to take advantage of the common spell checking).
The real trick, and perhaps an impossible one, is to design a system that has consistency of interface by design. Unix pipes on the command line approach this, but of course not in any useful way to those unable or unwilling to learn quite a bit of command line magic. It just isn't possible to write a program that takes a stream of bytes on stdin and outputs a stream of bytes on stdout that breaks the command line interface (well, it is but...).
Yeah, I'd say we're pretty much in agreement. It frustrates me greatly that when I need to perform a simple calculation beyond what I can do in my head, I leave the computer on which I am typing, fantastically powerful as it is, and reach for the pocket calculator in my desk drawer.
And while I'm at it, I know enough about programming to be dangerous. I can write small applications. But I cannot write anything "professional" complete with undo, redo, spell checking, built in calculator, whatever. If the system was designed so that it could free me, as a programmer, from having to worry about all that, then my small contributions would be vastly more useful.
Of course, like you say, the world then moves on and needs things that were not designed in like indexing. And they may be impossible to add after the fact to such a designed system. Or at least, they can be added but not by enterprising third parties without having that "tacked on afterthought" feel. Certainly a difficult problem.
Take spell checking as an example, but this applies to many many tasks a computer can easily perform. My word processor includes a spell checker. If I don't know the spelling of a word, I can right click on a close approximation and likely find the proper spelling. My text editor does not include a spell checker, but it includes commands to run a buffer through external programs (e.g. ispell). If I don't know the spelling of a word, I can send part of the buffer to the spell checker. My shell does not have a spell checker. If I don't know the spelling of a word, I can run "dict approximation" and hope for the best, or "cat/usr/share/dict/words | grep". My web browser does not have a spell checker. If I don't know the spelling of a word, I simply misspell it and take the ridicule from the slashdot horde; alternatively, I open a shell or use the word processor to do it and copy the correctly spelled word back to the browser.
In my opinion, I should not need to care whether each and every application requiring text entry can or cannot spellcheck, and if so whether or not it will use a certain spell checker with features I've come to enjoy (a personal dictionary for example). I should only need to care if "the computer knows how to spell check". It does, does it? Ok, show me how. Ok, now I know how to spell check every bit of text I could ever want to. And it's always the same.
Slashdot Mirror
Oh come on, I receive about 50 spam emails per day (which makes me lucky). It wouldn't take long for it to become "usual".
Yes, there are too many TLDs already. If you want to fix DNS, why not fix DNS.
Things I like about the telephone directory:
Allows names with spaces
Allows names with punctuation (O'Malley)
Allows entries with identical names
Corporations still have trademark law
I think the only thing ".com" is good for is making it obvious that you're talking about a website.
In hair gel land, I belive the heirarchy is something like this:
Super, Mega, Ultra, Mega Mega, Ultimate Extreme
Don't all coporations need a charter from some government (state gov't ?)
wikipedia
The Rise of Corporations
So... it seems corporate charters of the past were limited in time and contained a "public good" clause but have neither feature today.
Thank you for saying that. Seems this important point is often missed.
Regarding cars though, from what I understand it was the quality of Honda and other Japanese brands that finally proded the American manufacturers into making more reliable cars. The most profitable manufacturers are currently all Asian according to The Economist. I wish the best product always won. I also wish that all cars didn't look the same, and that all cordless phones didn't look like crap and have obnoxious rings, and that I could find a pair of jeans that fit... I guess one-size-fits-all is more cost effective :(
Wow, someone hasn't read his Rasking properly. I think you mean:
--Confirmation Dialog--
Jef Raskin, are you sure you want to log out?
[Type the (5th) word of the question to log out] [Remain logged in]
Dialog gradually fades away if no response given, and remains logged in
Or even better, like the other response, there is no confirmation dialog, merely an undo (log back in, and everything is as you left it).
Not to beat a dead horse, but confirmation dialogs often become less than worthless as users habitualize the most common response and then automatically give confirmation without thinking. The users then blame themselves for the mistake leading to further frustration.
Moral of the story: People make mistakes. Allow for easy "undo". If "undo" is impossible, make it impossible to habitualize the confirmation.
more fuel from growing corn than it takes to grow the corn
Well, of course not. But it takes sunlight to grow corn, among other things. Sunlight is "free". "Other things" are not free. And I have seen statements that the energy output can be greater than the input ("other things").
http://en.wikipedia.org/wiki/BiodieselThat should get you started. I can't find the link I want... it had a nice chart comparing corn, soybeans, rapeseed, and algae. I think corn barely puts out more than you put in (a point of contention I gather), but others are solidly energy positive (discounting, of course, the sun's energy input). Algae is nice because it can be grown in salt water...
Question: for laboratories, are there hoods with a laminar airflow from top to bottom that acts as a "door" that you can put your hand through? Could this be done for store refirerators, to keep the cold air in the fridge while having no door? I suppose if it could be, and if it would save money, it would have been done already...
Don't buy them! I bought some, only to discover that they have a flaw in their construction. Probably somebody trying to unload their obsolete stock...
I respectfully disagree about that one. How many times have you seen a checkbutton that says something like "Do it this way" and found yourself thinking "as opposed to what?". Two radio buttons make the "what" obvious in a nicer way than a tooltip or a longer description to the checkbox. Click the one you want while thinking about what it does. (Much like how dialog boxes with "yes" "no" are evil. Put the action in the button: "discard changes". You think "discard changes" while clicking rather than having to mentally substitute the action in for "yes").
I'd also like to take this moment to state that toggle buttons suck. Please use checkbuttons instead. Example: the button is depressed and says "stop". Hm, so will clicking on it stop it? Or is "stop" an indication of the current state? There is no way to tell.
LyX is probably the fastest application I use semi-regularly that's also fairly complex (I guess I'm comparing it to GIMP, AbiWord, OpenOffice, Firefox and every other browser, Evolution, Kmail). Maybe it just doesn't do as much automatically, but it sure feels snappy in a way that no other GUI program ever has (except for "print preview" which invokes latex...). Can anyone enlighten me as to why? Is it antialiased fonts used in gtk2?
A more general comment related to the article: it is much much better to feel fast than to actually be fast, in my opinion. What techniques exist to ensure a responsive GUI application? I know many GUIs are multithreaded, with, say, one thread running the GUI's mainloop. Or you can simply use a mainloop+callback model. With threads and Gtk (and any X toolkit?), anything outside of the GUI thread must aquire a global lock before it touches the GUI, and the GUI is frozen for the duration. With callbacks, the GUI is again frozen for the duration of the callback. How does one ensure (within reason; I don't expect a realtime system) that the GUI isn't being held up too long? And what is "too long"? I've heard 250ms as the longest time a program should ever take to respond to input...
Hm... I hate my volume control situation... First, the soundcard has a master level and different levels for e.g., PCM, analog CD, input gain (which I suppose are all necessary). Second, some applications have volume knobs which modify one of the soundcard's volume knobs (xmms), while others have an entirely seperate volume knob that presumably controls in-application volume attenuation. And finally, I plug my soundcard into powered speakers that have yet another volume knob.
My troubles are: too many volume knobs. Probably the applications that have their own internal volume are correct; otherwise one could not turn, say, IM notifications sounds way down (but not off), and have music at a reasonable level. I suppose the soundcard's knobs for its analog headers (CD) are necessary because there's no other way to adjust that volume... but digital audio extraction is nice. The two master volumes really bugs me though (soundcard's and powered speakers', and if all audio is going through PCM, the PCM knob is essentially a third master). I suppose it would help if computers had an easy to click master knob (or preferrably, a physical knob) for those occasions (phone call*, door knock, unexpected annoying sound) when you need to turn the volume down immediately. Or perhaps the computer should ditch the master knob completely and assume that whatever your plugging into (powered speakers, receiver, etc.) has a master volume knob... I don't know how exactly I'd like it to work, but I think a big part of my troubles is the awkwardness of adjusting volumes with a mouse and sliders in a GUI... it isn't quick like a big knob or real faders on a mixer
What does anyone else think about this?
* P.S. Does there exist phone that draws power from the phone company (i.e. no cordless I've ever seen) that has a gentle ring whose volume may be adjusted? I don't want to hack my phone just to stop it from shreading my nerves...
Paper isn't an optical medium? Punchcards perhaps... I assume you are talking about better tech than my laser printer + scanner which I've estimated could hold about 1MB (which I believe is what the Paper Disk software can do) on a 8.5"x11" page. So what kind of data density can you achieve on paper, and what sort of printer and scanner are you using?
But, it's an optical format... so why not design materials that can achieve much greater data densities? Like DVDs? Surely it's possible to design something like a DVD that would last as long as paper? Or maybe not...
So, is this or is this not what I've always been seeking in a GUI: total resolution independance? E.g. right now I can have my monitor at 800x600 and everything is *huge*, and I can have it at 1600x1200 and everything is *tiny*. Sure I can have Gnome/Gtk+ use larger icons and fonts. But not larger everything. Currently in Gtk+, one specifies the spacing between widgets in pixels. Will this change to vector units and allow the ability to smoothy scale everything up so I can use the full 1600x1200 but still have things readable? (And no, using a resolution in between those two extremes is not a solution. They are too few; none is quite right. Or it's an LCD where all but one is garbage.) And what will these vector units be?
Actually, I'm usually running at 1024x768. There's always those few programs that just don't fit on the screen... The ability to scale them down would be fantastic. Ideally I'd have an enormous monitor, but I don't.
If this is the direction this small step is headed in, then I applaud the Gtk+ team and look forward to the future with excitement.
I second that request. Can we also please please please *please* throw in a real keyboard? Something like the happy hacking keyboard (I've got the Lite. Pretty costly, but the feel is fantastic... anyone want to buy me the Pro?). I don't care if it's 4 inches thick. I had an old (P133) IBM thinkpad that was pretty darn thick (not because of a good kbd, it sucked) and I rather liked it.
Damn I would buy one of these in a second (well, perhaps 486 speed is a little low...).
FYI, I have a Fujitsu P series with an 800Mhz Transmeta Crusoe and a short-height (can't recall the resolution at the moment) display. Supposedly with the extra battery you can get 8 hours of battery life. It lacks parallel and serial ports. Though, as others have mentioned, some fuel cell battery will likely be used to feed our power hungry devices rather than anyone sell a lean machine.
Blitz is pretty fun with 4 players, though certainly not realistic.
Redesigning the system isn't that hard. What's hard is convincing everybody to start using the new design.
Well, I'm convinced... show me the design. Are there any projects with any sort of following to design the ideal message exchange system? I'd be very interested in reading about them.
With a push system (SMTP), sending is simple (just connect to a server and dump the message); receiving is complex (run/rent a server with permanent internet connection). In a pull system, sending is complex (run/rent a server with permanent internet connection); receiving however, still requires a server to receive notes. Once these notes are collected, receiving is simple, with no guarantee of robustness (connect to remote message stores and download message).
Surely there are many projects to reinvent email? Most discussions here are about modifying SMTP for reasons of its sheer momentum, but I'd also like to see what the ideal system would look like. Links anyone? I suppose I could start by reading the article... but who does that?
While I'm at it, are there any projects or interesting discussions about distributed trust webs (a la gnupg/pgp)? Some way to quickly determine the trustworthiness/legitimacy of an ID you've never met given that you trust or don't trust a few IDs you have met before.
Just today I ran across Internet Mail 2000, a concept apparently initially conceived by Dan Bernstein. I haven't read all or even most of the information on that page, finding it somewhat difficult to wrap my head around. The big difference from it and SMTP is that it is a pull rather than push protocol. For Alice to send a message to Bob, Alice puts the message on an IM2000 server (replaces the originating SMTP server) which sends Bob a note "hey, I've got a message for you". Bob's email client then downloads the message from the server.
The big advantage here is that the note is small, and Bob need not download the message at all if he believes it is spam, reducing the spam bandwidth usage. Also, the sender must make an effort to have a permanent server so the receiver may even get the message. Not really a burden for legit mails that already need a permanent server somewhere for receiving mails (right?). Forgeries are also prevented, because the note necessarily contains correct information about how to find the message.
Aside from the usual reply to anti-spam solutions (this one requires mass participation and won't happen, yadda yadda), and the lame name (shouldn't they change that to IM3000 now?), have others looked at this? What are your opinions on it?
Other replies have covered the technical side. But it may be the case that because they have a positive emotional response from using the iPod, for whatever reason (iPod's looks, enhanced self image, etc.) it actually does sound better to them even though the sound waves are identical.
Hm... you have a point certainly, but to dismiss "art" in an interface as rubbish is a bit drastic. Have you read Don Norman's Emotional Design? In it, he cites a two studies that compared ATMs. Two types of ATMs were used, identical in function with one looking "good" and one "not so good". Users of the nicer looking ATM had fewer problems using it than those of the other. Yes, actual observed problems, not answers to a survery "did you like it?". I do not know how they decided one ATM was "better looking" than the other, which is the first question I'd like to have answered.
At any rate, the study seems fascinating but not terribly surprising. Norman proceeds to sketch a theory of why the nicer looking ATM was easier to use, using cognitive psychology and the usual HCI tools to do so. I have only read the first couple chapters of the book, but highly recommend it.
Your final comment is appropriate. An interface that ignores art will likely look awkward or be otherwised noticed by the user, thus negatively affecting usability.
Which reminds me of a question... We spend all this time and energy looking for alien signals, but are we actively broadcasting anything interesting for aliens who may be looking for us?
Yes, I agree that filesystem abstraction is good. Have you looked at the Reiser4 filesystem? The papers on that site have similar ideas to yours. Why can't the filesystem be the interface to many things? Then we gain in the ability to use common tools (ls, less, rm, ...) on something new.
Also, I am aware of two projects to create filesystems in Linux userspace. This is also a great idea and I don't truly understand those who do not see the usefulness. One is FUSE, the other is LUFS. Both require a kernel module (obviously), but from that point on users (other than root) can mount and use arbitrary filesystems. I have used sshfs included with LUFS to mount a remote fs only available via ssh. This makes me so happy. I love running commands over ssh, but I love running local tools on remote files even more.
Well, it isn't so hard to write good software per se (not that it's easy...). Your example with KDE shows that it is possible to have a good consistent interface *within the domain that you control* (i.e. KDE is controlled and written by one group of people who will all agree to write software in such a way to take advantage of the common spell checking).
The real trick, and perhaps an impossible one, is to design a system that has consistency of interface by design. Unix pipes on the command line approach this, but of course not in any useful way to those unable or unwilling to learn quite a bit of command line magic. It just isn't possible to write a program that takes a stream of bytes on stdin and outputs a stream of bytes on stdout that breaks the command line interface (well, it is but...).
Yeah, I'd say we're pretty much in agreement. It frustrates me greatly that when I need to perform a simple calculation beyond what I can do in my head, I leave the computer on which I am typing, fantastically powerful as it is, and reach for the pocket calculator in my desk drawer.
And while I'm at it, I know enough about programming to be dangerous. I can write small applications. But I cannot write anything "professional" complete with undo, redo, spell checking, built in calculator, whatever. If the system was designed so that it could free me, as a programmer, from having to worry about all that, then my small contributions would be vastly more useful.
Of course, like you say, the world then moves on and needs things that were not designed in like indexing. And they may be impossible to add after the fact to such a designed system. Or at least, they can be added but not by enterprising third parties without having that "tacked on afterthought" feel. Certainly a difficult problem.
Take spell checking as an example, but this applies to many many tasks a computer can easily perform. My word processor includes a spell checker. If I don't know the spelling of a word, I can right click on a close approximation and likely find the proper spelling. My text editor does not include a spell checker, but it includes commands to run a buffer through external programs (e.g. ispell). If I don't know the spelling of a word, I can send part of the buffer to the spell checker. My shell does not have a spell checker. If I don't know the spelling of a word, I can run "dict approximation" and hope for the best, or "cat /usr/share/dict/words | grep". My web browser does not have a spell checker. If I don't know the spelling of a word, I simply misspell it and take the ridicule from the slashdot horde; alternatively, I open a shell or use the word processor to do it and copy the correctly spelled word back to the browser.
In my opinion, I should not need to care whether each and every application requiring text entry can or cannot spellcheck, and if so whether or not it will use a certain spell checker with features I've come to enjoy (a personal dictionary for example). I should only need to care if "the computer knows how to spell check". It does, does it? Ok, show me how. Ok, now I know how to spell check every bit of text I could ever want to. And it's always the same.