I like Conkeror but I'm switching

I like the Conkeror web browser. I like the idea of it. It's based on the emacs model, making all the control details accessible to the user. Or perhaps I should say, the user/programmer. Conkeror not only lets you bind new keys and write new commands, it wants you to.

And I like the feel of it. It uses the familiar emacs keybindings. Its commands tend to be powerful ones like emacs. It provides apropos. Its treatment of links, frames, and images is very nice.

So why am I switching if I like it so much? Because nobody else does. Oh, I'm not such a crowd-follower that I'd give up a browser I like just to be part of the crowd. Far from it. But all its wonderful, open programmability isn't being used. Almost nobody is programming it. So Conkeror lacks many features that I am used to using in other browsers.

For instance, managing your bookmarks. It doesn't quite do that. You can create bookmarks, and that's about it. You can't edit them or delete them or organize them. You can't even get into a text file and edit them manually, because they're all kept in a database file (Apparently XULrunner's design decision, not Conkeror's)

I could write the bookmark functionality, and if it was the only thing that was missing that's what I'd do. But it's not. There are other common features that never got written. Form-filling jumps to mind, and password-remembering. Conkeror seems to have just never reached critical mass. More's the pity.

So today I downloaded Google Chrome and tried it out. I miss the power and the programmability. I don't like Chrome's windows that want to put 3 bars up at the top, taking up more screen real estate. But Chrome has the features that I keep wanting to use, and Conkeror doesn't.

So adios, Conkeror. You will be missed.

Write or die mode

Write-or-die mode is an emacs mode that "makes" you keep writing or it erases text. I find that it's good for my writing. I have a tendency to get very bogged down in polishing what I write, to the detriment of the writing. Write-or-die mode doesn't let me do that.

I'm actually writing this mini-essay to test out my configuration of write-or-die mode on a different system. So far, so good.

Emacs+org-mode and blogger

A few days ago when I set up this blog, the first thing I thought about was how I could write posts with emacs and org-mode. Yes, Blogger provides an online editor, but I loathe online editors. Why would I want to type into a little box and pick from a markup menu when I can use emacs?

For the moment, I am using a package called weblogger.el It works well but it doesn't let me upload images.

A few observations:

• Org-mode will export HTML but it wasn't immediately obvious how to make it export the body. Those who are familiar with org-mode won't be surprised to hear that there is already a way to do that. It's just not offered as an option in `org-export' (C-c C-e). It's just:

  (org-export-as-html nil nil nil "*Org HTML Export*" t)
  

• Pasting text into Blogger is a non-starter.
  • I don't want to do that manually every time I post
  • The online editor "helps" you, thus ruining the post.
• I tried Blogger's mail-to-post interface. It sort of works, but:
  • Can't upload images. Google's docs say you can¹. But I found that an attached file was simply displayed literally, as line-noise-looking text.
  • In order to post HTML, you have to convince your mail client to send content-type text/html instead of text/plain. My ISP's squirrelmail webmail simply would not do that.

    There is a bright side to that: It pushed me to reconfigure my SMTP setup. Years back I abandoned it because it wouldn't work over dialup. Back then it was all sendmail, now it's all exim-4 and easy to configure. Kids these days!

    Nevertheless, I am not using the mail-to-post interface because weblogger is better.

  • It doesn't support labels.
• Weblogger.el is easy to set up, just customize it.
  • It tries to send labels, but Blogger drops them.
• One problem using Blogger with Weblogger is that what Blogger wants for your username is not your Google username but your email address. Weblogger doesn't know this - it serves not just Blogger but anything that takes xml-rpc - so it just calls that field "username". Confusing unless you know it.
• Even better, I'd have liked to use an Atom API instead of an XML-RPC API. That may still happen, but I'm not in that much of a hurry. My main reason for changing would be to can upload images². But none of the packages seemed to support that. I looked at these:

  emacs-atom-api

  gone.

  atompub.el

  The code seemed messy, and when it set up an XML buffer and wanted nxml, I bailed.

  Google's g-client

  Haven't tried it out. I'm looking at it now. Doesn't appear to handle images, but I know Atom can do so.

Footnotes:

¹ Google's docs say "To include an image in your post, you can attach an image to you your email."

² Mostly dia diagrams converted to images, I expect.

About the hreview microformat

While looking for information on support for atom blog posting, I came across the hreview microformat. It is an XML microformat. That basically means you can treat it as a small, optional part of XML with specialized semantics. It is a general format for reviews (of restaurants, movies, products, anything)

What I like, and my vision

I like the idea of specifying a general purpose review format and the decision to use a microformat for it. I like it because I have a vision about reviewing functionality in software.

• When something you can review is fresh in your mind, you should be able to rate it immediately and publish that review. For instance:
  • In your web browser as you are surfing a site.
  • When a song or album is playing, or finishes playing, or you stop a song (maybe you hated it) or repeat one.
  • In a video game, especially for multiple sources of content, for instance user-generated content.
• Applications shouldn't have to roll their own functionality for this. They should fill in a few obvious fields and hand the work off to a library, or a plug-in, or an external program.
• Casual reviewers shouldn't have to choose between learning some site's review format and limiting their review's distribution. This is something the hReview format helps make possible.
• Since others, like you, can review at the push of a button and their reviews share a common format,
  • Tons of reviews are available to you without really digging for them. You don't have to keep track of what review sites exist for each type of thing.
  • Those reviews are easy to search
  • Those reviews can be collectively summarized.

What I don't like

What I don't like are the specifics of hReview. These fields have problems, in my opinion:

type

Type has to be "one of the following: product, business, event, person, place, website, url".

• The categories are too broad. Suppose I'm looking for reviews of blogging hosts. Seems like everything under "website" qualifies. How can I narrow the search to "blogging hosts" if the categories are this broad?

  One cannot rely on the "item" element to distinguish subtypes. "Item" can be an hCard, which (currently) doesn't allow any subtype entry. Or similarly, an hCalendar event.

• The categories seem to overlap - either they do overlap or it takes special knowledge to know what really belongs in each. Above, should "website" have been "business", or could a blogging host be either? Or maybe "url"? "Url" is somehow different than "website", but without digging for information, the distinction isn't obvious.
• The categories also seem like they must include more than their names suggest. Consider the "product" category. It appears to me that the following reviewable things must be surprisingly classed as products:
  • Free software (in the free-speech sense)
  • User-generated content relating to commercial products, for instance video game levels.
  • Text files that are passed around, eg Linux HOWTOs.

version

There are 3 concepts of "version" that one might want to express. Will every implementor of hReview get it right?

• Version of hreview format. That's what this field is actually supposed to mean.
• Version of the review. Yes, reviewers might want to add information or even change their minds.
• Version of the item. Properly belongs somewhere in the "item" field, but even so, this is an error opportunity.

rating

Allowed values are from 1.0 to 5.0. Wrong! Ratings are ordinal scales. They are rankings. They are not intervals or ratios. Five 1.0's are not equal to one 5.0. The difference between 1.0 and 2.0 is not equal to the difference between 4.0 and 5.0. That is a mistake that I see people make over and over. Worse, it tempts people to do crazy things like averaging ratings.

As a user interface issue, I understand the appeal of typing a number and being done. Problem is, the data it generates is a lie. At best, you could theoretically recover the rankings from the numbers, and only if the user's transfer function hasn't drifted over time.

Other than that, good effort.

How I'd fix the problems

Here's how I would fix the problems:

type

There needs to be some concept of subtyping. It could do one of the following:

• Allow "type" to be a list, which should be a path from a major type (product, etc) down to as detailed a sub^Ntype as one wants to express.
• Allow a "subtype" field, which can contain the list above except for the first element.
• Recommend that the "tags" field accept this

version

I would just rename this field more clearly: "hreview-version".

rating

Two approaches, which IMO should both be used:

• Allow comparative rankings as an alternative to numerical ratings. Comparative rankings would be indicated with respect to another item of the same type. I'd support these possibilities:
  • "better-than Item"
  • "worse-than Item"
  • "same-quality-as Item"
• When numerical rankings are used, explictly indicate the scale. Here are some possibilities:
  • Do so by indicating one or more anchor points. I'd tentatively recommend 1.0 and 3.0. So allow another field:
    • "set-to N.N Item", where N.N is between 1.0 and 5.0 inclusive and Item is an item. That item must agree with the "type" field.

      For instance, "set-to 1.0 item-X" would mean "the 1.0 rating is set equal to the quality of item-X; for purposes of this rating, no item inferior to it is considered a representative of this genre".

      Canonical anchor items should be found for each genre of interest so that meaningful comparisons can be made. But this may prove to be difficult. What is a reviewer to do if he feels that the canonical 3.0 item is actually worse than the canonical 1.0 item?

  • Alternatively, indicate the scale by reference to another review or body of reviews that use the same scale.
    • "same-scale-as URL"
  • Or indicate the scale by reference to a well-defined collection of reviewable items. This was actually my first thought, but it needed work. The collection needs to be well-defined, otherwise Sturgeon's Law (90% of everything is crud) will stop us. For any genre, there is usually a large set of poor examples that go deservedly unknown.

Hello

Welcome to my blog.

I plan to talk about these topics:

• Social choice
  • Decision markets
    • My non-Hansonian design for legislative decision markets (futarchy)
    • FutAIrchy (legislative decision markets combined with AIs) as an answer for The Singularity.
  • Iterated quasi-hay voting (IQHV)
  • Other social choice topics
• Programming
  • Emacs-lisp programming
  • My ideas on how programming might be made clearer, easier, or better.
• Rationality
  • fair argument mechanisms (which overlaps with social choice)
  • Balanced thinking
• Ideas that I like
• Personal likes and dislikes

Of course this is tentative. My blogging plan, like anyone's, is subject to change.