[Imap-protocol] Childless noselect mailboxes
bhayden at umn.edu
Wed Dec 30 12:24:57 PST 2009
On Dec 30, 2009, at 1:19 PM, Mark Crispin wrote:
> On Thu, 31 Dec 2009, Joel Reicher wrote:
>> I think it's likely that users view messages as the "privileged"
>> that is at the end of the name hierarchy only because they are using
>> interfaces that place it there.
> I agree. Usability studies are rarely conducted in a completely
> unbiased and controlled setting; and thus quite often lead to
> predetermined answers. Thus, we have atrocities (like the Microsoft
> ribbon or the Apple single-button mouse) which we were assured that
> usability studies had proven were the perfect interface.
> The problem is that the very questions and framework of the study
> bias the answer. It's like the political opinion polls commissioned
> by a political party.
Your generalizations about usability studies are well and good--and
have some truth to them, but are still generalizations. Let's get
specific: I am talking about spontaneous utterances from people alone
in a room doing normal tasks in an email client. Not answers to
And fifteen years of help desk reports.
The average user views a message as privileged because it is the
apparently atomic unit that they care about. Yes, I know it isn't
atomic. Yes, I know it might contain a text/plain MIME part with the
body, a text/html part with another version of the body, and three
octet-stream parts that are GIFs... *but the user doesn't care*. I
agree that being a container is not why it's special, precisely
because the vast majority of users would never describe a message as a
container. It's "the message" as a unit that they care about because
that is how the human brain works. You send someone "a message"
whether it's speaking a sentence to them or sending them a letter in
> Yup. Messages are not the end node of the name hierarchy; the
> mailbox is. If a message was the end node of the name hierarchy,
> there would be no need to select the mailbox prior to accessing the
> mailbox. Select is a very different operation from descending the
> name hierarchy, and creates a very complex state.
> It's easy to dismiss all this, because only a few IMAP clients are
> sophisticated enough to take advantage of this state. The vast
> majority are glorified POP clients that babble IMAP protocol. This
> came about because of the long-obsolete notion that Internet access
> is a difficult and expensive commodity that requires that the client
> must keep a mirror of what's on the server. The success of webmail
> (which transforms the browser into the ultimate thin client) proves
> that this notion is complete nonsense today. Yet people persist in
> claiming it.
I'm not sure what this has to do with anything. People like us can
discuss "the end node of the name hierarchy" all day, but users aren't
interested until it has a meaningful translation into something useful.
More to the point: when *all* X have problem Y, a reasonable person
needs to ask what might be causing Y--because it's unlikely that the
designer of *every* X is precisely the same kind of stupid.
I'd draw your attention to a server behavior that you approved of
earlier in the thread:
>>  "tag CREATE foo/"
> Same as "CREATE foo".
>>  "tag DELETE foo" where foo is selectable and has a child?
> Leave foo as \Noselect, don't delete children.
>>  "tag DELETE foo/bar" where foo is \NoSelect and bar is the only
> Delete both foo/bar and foo.
This is unfriendly; a user never expects a parent to disappear simply
because they deleted a child. Not only is it unexpected, but it's
inconsistent; they can create an empty container, but it's removed
unilaterally if it happens to become empty after it's had something in
How do you propose to communicate to a user the following:
"See this thing here? It's like a directory in your filesystem. Except
it can only contain other directories that in turn contain text files
and images--it can't contain any text or images itself. Oh, and if you
have one of those directories underneath it that does contain text and
images, and you delete that directory, this one will disappear too and
you'll have to go to the trouble of recreating it next time you want
to put something inside it.
So what will happen is that you will create a server where actions
have side effects that were not asked for and are not desired, so then
clients will (each in their own hackish way) work around it, and then
people like us will complain about the stupid clients.
You admitted earlier that the whole concept is a mistake that you
regret; so I'm not sure what the use is of saying clients are "crappy"
because they haven't come up with a good way to represent this thing
that you acknowledge is a goofy kludge.
That was my point.
More information about the Imap-protocol