?

Log in

No account? Create an account
Semiformalishmaybe

Forgetting Your Limitations

In my Firefox, I now have:

  • Ubiquity
  • Greasemonkey
  • Jetpack
All three of them are programming interfaces to extend the web, and it is possible to write useful scripts in any of them to do the same thing. This is confusing, terrifying, and yet perhaps a bit awesome.

I've occasionally flirted with minimalist window managers even though I'm very happy with 3-year stale WindowMaker nowadays. I have not flirted as much with minimalist browsers - Twibright Links is the only one I can remember using much (an extension of links to handle javascript and graphics). Minimalism is an interesting phonomenon in people's 「goodness criteria」 - some people like minimalism because it tends to be fast, some because it tends to be less buggy, and some because they like being able to wrap their head around the entire feature set.

Software-wise, I can say that despite some occasional urges to the contrary, I am not a minimalist. I do like fast software, and I don't like bugs, but I don't like "applications" to be so simple that I can understand them all. vim and emacs are both wonderful pieces of software, partly because they offer facilities enough that people can extend them, and partly because they're powerful enough that people don't need to extend them. Despite being so big, they're pretty fast, and they fulfill a lot of the other notions of my idea of good software. If people complained that they find vim or emacs "too big", pointing at the memory footprint on their laptop with 4 gigs of ram, most people would laugh at them.

I think browsers should be seen as the same - the web is an information source, and providing tools and facilities allowing us to change how we interact with that information (using any of the models of the above firefox extensions, or more) either by writing it ourselves or finding things others have written is awesome, and that awesomeness should be balanced with the legitimate concerns about performance and bugs. Application size is in most situations a red herring and it's weird to see ricers geeking out over it.

(note that some people confuse "bad design" and "big" - not everyone likes the way GNOME and KDE environments are in-your-face sometimes and it's easy to neglect the many other WMs/desktop environments that might be more suitable for an individual geek's taste.

One of the things that I've come to believe more strongly over the years is that it is important to let people embed their personal logic into how they interact with systems. There is no single interface that can make everyone happy, nor a single way of interacting with one's data. Apple has done a fantastic job of pushing the opposite belief as far as it can go - they attempt to find universal interfaces, and in that impossible task they at least find appealing interfaces for unempowered people. Their front-stage applications are good at hiding complexity and being pretty, to the occasional frustration of more sophisticated users when they want to embed their own logic into something. (I should note that Apple still does a decent job, sometimes, at providing deeper capabilities for more sophisticated users - they are the company that gave us HyperCard and Applescript, but the empower-the-sophisticates philosophy is not as pervasive in Apple's software jungle). Traditional Unices are better at this on a basic level, both because their architecture is naturally and cleanly extensible and because people explicitly thought about ways to make this natural (pipelines, etc). They have traditionally failed at this at higher levels (which is why people on MacOS can "tell application to open document and do this and that and save" using generic facilities much more readily than we can). This is primarily because the architecture of Unix (at the commandline) itself makes it hard to be ill-behaved - only if you use curses or otherwise play with the terminal do you become antisocial and hard to extend - this attitude did not extend upwards into the graphics toolkit because the "X culture/architecture" in Unix was poorly planed, thought out, and executed. Nobody has fixed it.

It is important to have a nice interface for common tasks - email, browsing the web, spreadsheets, etc. That's a minimum. In the end, we should hope to empower users by providing well-designed generic-as-possible hooks into every aspect of our applications so they can extend or replace our default logics with things that better meet their needs, either as one-time events or permanently. The Apache Bucket model is a great example of this for a webserver, as are the mozilla extensions above. Relational calculus in SQL and regular expressions are nice examples of minilanguages for data processing when something deeper isn't required. These are the kinds of things that we should want in every application, plus ways to extend the UI to add our own features. We further should hope to create gentle introductions to these features so people can gently and fruitfully wade into these waters without getting a computer science degree first.

Bravo to Netscape .. err.. mozilla? Whatever they're calling themselves, for paying attention to this. Open, extensible systems are more useful than either minimalist or closed ones.

Comments

Regarding your longest paragraph, KDE actually has powerful facilities for making graphical apps scriptable. I don't know how KDE4 does it, but for KDE3 check out the "dcop" command and its relatives. For example, I wrote a script that uses dcop to list all the tabs open in all my konqueror browser windows, and another one I can use to do a remote logout without losing my current session information.
Awesome! If only there were an equivalent for GNOME and other apps and then some wrapper that could talk to whatever standard they were to come up with.

Remember "netscape-command"? :)
Yep, I remember. :-) Also don't forget the much newer emacsclient.

I think the cross-desktop solution (covering Gnome and KDE4) may be D-Bus (including a dbus-send command), though I haven't looked into it much yet.
At the risk of suggesting an already complex standard should've been more complicated,

Imagine where Unix on the desktop might be now if someone had figured all this out back when the ICCCM was being drafted and included it.