[Imap-protocol] Childless noselect mailboxes

[Brian Hayden]

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"  

>> container

>> 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  
interview questions.

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  
the post.


> 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:


>> [1] "tag CREATE foo/"

> Same as "CREATE foo".

>> [2] "tag DELETE foo" where foo is selectable and has a child?

> Leave foo as \Noselect, don't delete children.

>> [3] "tag DELETE foo/bar" where foo is \NoSelect and bar is the only

>> child?

> 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  
it?

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.

Have fun!"

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.

-Brian