The natural language interaction they suggest is partially satisfied by Google (or, in general, web search). Most information you want can be found in this way, and we don't have any issues of allowing an undo mechanism or being interactive with the user because searching the web involves no mutation of the state of your computer or anything. And Google search results freely change and improve without the user's knowledge..
The Anti-Mac Interface (1996)
81–90 of 138 posts
Re: The Anti-Mac Interface (1996)
#82One thing that almost always gets overlooked when critizing / trying to innovate on Xerox Parc-like interfaces, is discoverability. Look at departures from this interface (or predecessors of it) and you'll almost always find a system where it's hard for users to discover what they can do and how their actions will affect the state. Most prominently: * iOS style gestures * Office Ribbons (where has my feature XY been…
I’d love to have a shell-like environment where every command’s output was a stream of structured records with support for rich data types (ideally including stuff like images), not just lines of plain text. The hard part here is not just figuring out all the core UI and protocols (though that would also take some work), but actually implementing all the hundreds or thousands of essential basic programs. Unfortunatel…
I understand it's a holywar topic, but what's so bad about XML? I'd say it's a very nice serialization format for arbitrary data with a host of very powerful tools around it. I would love to see more software offering an XML dump option for their internal formats.
Re: The Anti-Mac Interface (1996)
#83Earlier quoted context omitted.
LOLcats. The very first thing I do when I set up a new OSX install is to completely disable spotlight.
Why?
I'm not the author, but I too had problems with it in old days. First versions of Spotlight were very buggy and sometimes the background indexer slowed down the computer very noticeably (eating up 25% and more of processor time). Apparently, it had something to do with the first invocation: if it didn't manage to index all at the first time (which could easily happen if the user restarted the computer), then it entered that processor-hungry mode.
Another thing is bad UI. It starts to search as soon as I type it, which, for me works so: I type one or two characters, then it freezes because it starts searching and finds everything with these characters. Then after a few very long seconds it thaws out and I get a chance to type the rest of it and also set search options. I almost always search for file name, not contents, so I have to set this option on every search.
Somehow I don't have these problems on Windows; here I always have a chance to type the whole phrase. I also use content search much more often, that is, I don't bother setting options, I'm content with the results :) (My PC hardware is faster, but not that much faster; I think the problem is in bad timing.)
Re: The Anti-Mac Interface (1996)
#84Earlier quoted context omitted.
Yes that's mostly enough for simple cases, but have you ever tried to discern a gcc command with 12 compilation flags enabled? It takes you half an hour to find everything you need in the man pages. 30 years after the wide scale spread of pointer devices this is IMO just ridiculous.
I wouldn't try to justify the awfully huge number of commands that many unix util implementations have - which seems like an anti-unix design movement to me - but you can at least cut down the 30 minutes of man page spelunking with man | grep -A 3 "\ ". Adjust -A argument as needed. (for example, if you don't know what -A does on grep, run `man grep | grep -A 3 "\-A"`).
You can also use / in man to do a search in man. (Assuming your pager supports it, don't forget to use the home key to go back to the beginning for a new search option.)
Re: The Anti-Mac Interface (1996)
#85Earlier quoted context omitted.
It's not "stagnating", there's simply not much need to "innovate" it anymore. It works well for both new and advanced users. Changing the standard UI would just be a pointless frustration - see Windows 8.
OSX has never gotten the basic keyboard interactions right that Windows has had from the beginning: The ability to trivially navigate menus from the keyboard. I want Alt-F to open the file menu, and then "S" to save a file. Yes, I know that the Mac has Cmd-S to save, but there can be 50+ menu options spread across various menus, and the 10-15 that I use the most are far easier to remember (for me) as Alt-[menu letter…
The idea is that you'd use the mouse when you don't remember the keyboard shortcut.
Re: The Anti-Mac Interface (1996)
#86Earlier quoted context omitted.
I’d love to have a shell-like environment where every command’s output was a stream of structured records with support for rich data types (ideally including stuff like images), not just lines of plain text. The hard part here is not just figuring out all the core UI and protocols (though that would also take some work), but actually implementing all the hundreds or thousands of essential basic programs. Unfortunatel…
I understand it's a holywar topic, but what's so bad about XML? I'd say it's a very nice serialization format for arbitrary data with a host of very powerful tools around it. I would love to see more software offering an XML dump option for their internal formats.
XML is a very complex spec which is difficult to implement properly, a heavy format with high storage overhead, which is extremely expensive to parse or process, but also too verbose and finicky to be pleasant for human editing. It doesn’t have built-in standard support for most of the common data types you want in a structured document, so they are all stored as strings or sequences of tags, and then parsed out in an ad-hoc way by each tool built on top. Its namespace feature is ineffective and often a potential security vulnerability. Its separation between attributes and elements is handled arbitrarily by various XML-derived formats and tools, usually inconsistently within the same format. It has terrible support for big arrays of numeric or other binary data. Etc. Etc.
XML, like SGML, is plausibly reasonable when you have something like a word processor document or web page, but is wholly inappropriate for almost every other use.
Notice that despite its acute limitations, JSON ended up as the metaformat of choice for most Web APIs.
Re: The Anti-Mac Interface (1996)
#87Earlier quoted context omitted.
I’d love to have a shell-like environment where every command’s output was a stream of structured records with support for rich data types (ideally including stuff like images), not just lines of plain text. The hard part here is not just figuring out all the core UI and protocols (though that would also take some work), but actually implementing all the hundreds or thousands of essential basic programs. Unfortunatel…
I understand it's a holywar topic, but what's so bad about XML? I'd say it's a very nice serialization format for arbitrary data with a host of very powerful tools around it. I would love to see more software offering an XML dump option for their internal formats.
>what's so bad about XML?
That no programming language deals natively with XML's data structure. That's why xpath and xslt needed to be invented. This suggests that XML's data structure is not actually a good mapping for people's problems.
Re: The Anti-Mac Interface (1996)
#88Earlier quoted context omitted.
Why?
I'm not the author, but I too had problems with it in old days. First versions of Spotlight were very buggy and sometimes the background indexer slowed down the computer very noticeably (eating up 25% and more of processor time). Apparently, it had something to do with the first invocation: if it didn't manage to index all at the first time (which could easily happen if the user restarted the computer), then it enter…
Spotlight used to be bad, but the issues were resolved long ago. It's fast and gives good results, and no longer freezes or consumes lots of CPU. In Yosemite you even have a bunch of NLP stuff, like typing "100 feet in meters" to perform calculations.
Re: The Anti-Mac Interface (1996)
#89One thing that almost always gets overlooked when critizing / trying to innovate on Xerox Parc-like interfaces, is discoverability. Look at departures from this interface (or predecessors of it) and you'll almost always find a system where it's hard for users to discover what they can do and how their actions will affect the state. Most prominently: * iOS style gestures * Office Ribbons (where has my feature XY been…
I'd like for all apps to have a command lookup similar to Sublime Text: Type some text to match a command.
The list must be exhaustive -- if it's not there, the command cannot exist. (Unfortunately, Sublime commands are explicitly registered and the list isn't complete; it even lacks core Sublime commands.)
The list should also show keyboard shortcuts and allow a way to modify them in-place. (Sublime doesn't do that either. A real missed opportunity.)
Re: The Anti-Mac Interface (1996)
#90Earlier quoted context omitted.
> The point about "user control" is odd though, since that's basically the exact opposite of the Apple philosophy today, and even the older Macs seemed more opaque and with less user control than the PCs of the time. As an advanced user, I don't want more control. I want defaults that are good enough that I never want to change them. Every hour I spend tinkering with my computer, is an hour I didn't spend achieving u…
Why not both? I want good defaults, and also the ability to change the things that I might want tweaked for whatever reason down the line. A powerful preferences interface is the software equivalent of opening up the hood of a car -- just because I want it to run well doesn't mean I'm not gonna poke around.
About your cars reference, there's a funny segment from an old Top Gear where the presenters beat everyone at the modified cars drag strip race using a stock Bentley.
Everyone else poured thousands of hours and thousands of dollars into their car. James May showed up with a stock Bentley - a big fat comfortable car - and won the day.