performance issue (imap spool on san)

[Daniel Eckl]

Hi Scott!

Thanks for your thoughts! I really appreciate reading your perspective!

I might not have stated clearly enough, whos opinion I speak about. It
was the opinion of about 20 very different users I evaluated Mulberry
with and my opinion, too.

This of course is not representative in any imaginable way and might and
will not apply to you and many other people. Above all I think it does
not apply top most of the mailing list members here which all more or
less do administrate a major professional grade IMAP server named
cyrus-imapd. But it could easily be the opinion of most users without
technical background being used to clients like Outlook Express or
Thunderbird.

Yes I fully believe that I might find some or many of my missing
features if I read the manual thoroughly. So perhaps the only problem
which is a real one for me might be the lack of intuitive usability. All
others might be just an aftereffect of that. It would really be nice if
the (near or far) future would provide an improvement here.

Virtual folders I used and use in thunderbird, kmail, IMP Webmail (Horde
framework) and opera mail. Without that, mulberry is not unreasonable
for everyone, that's just for people using IMAP the way I do. I don't
have any clue how many people this might be.
Because I used vfolders until now, I have less real folders and changing
to mulberry would mean to create a lot of folders, moving and copying
mails around, and many of the new folders will contain copies of mails
already in other folders.
Or as an alternative, starting the same searches manually over and over
again. Both is not practicable either for me or for my mailbox quota. :)

Inline viewing of attachments surely is a subject worth of discussion,
but you will never get a definite answer. You have to make that
configurable and depending on your major type of users you have to
choose what's the default.
With mulberry which is mostly choosen by geeks I think, I would choose
disabled inline viewing by default.

Drag and Drop from konqueror to mulberry somehow didn't work for me, but
after your writign I don't want to blame mulberry here without further
investigating that. So I just accept that it should work and there might
be something broken in my KDE DnD functionality. :)

Regarding the visual candy thing, you are correct, there will be people
loving mulberrys interface style, but I cannot believe that this is more
than a homeopathic attenuation. Just look at all the actual major
interfaces out there (qt, gtk, windows xp/vista) to get a clue what
seems to be wanted by the majority of normal PC users.
I'm really sure that Mulberry would benefit from being ported to a
nowadays widget style and follow one of the major usability guidelines
people are used to.

Regarding the single-threaded nature of mulberry I didn't run into
problems with that so far, but thinking of small dial-in lines like GSM
I could easily imagine that it's disturbing to wait for one mail to be
sent and not being able to start writing the next one until it's done...

So thanks again and have a lot of fun!

Best,
Daniel

Scott Adkins wrote:
> --On Monday, September 11, 2006 2:14 PM +0200 Daniel Eckl
> <deckl at nero.com> wrote:
> 
> Everyone is entitled to their opinion and yours is certainly welcome.
> However, beauty is in the eye of the beholder... I have heard comments
> the cover pretty much the whole spectrum with regards to its usability
> and looks, and really, I don't see any particular opinion winning over
> the other.  For the most part, opinions are based on how well that
> particular user loved a favorite e-mail client they previously used.
> 
>> And it misses a lot of features I use every day. Virtual folders, inline
>> attachments (jpegs for example), forwarding emails attached, view
>> attached emails, Drag and Drop support and so on and so forth.
> 
> I must admit, I would love to see Virtual Folder support... however, is
> this implemented in the majority of IMAP clients out there?  I am not sure
> that it is... so, to single out Mulberry for that is unreasonable.  Is it
> a wish-list item?  Certainly.
> 
> Inline attachments are a long heated topic of debate here... of course
> there are features left to implement... however, Cyrus is one man and he
> has to prioritize what order of features should get implemented in.  When
> Mulberry was not a free product, the features that were requested most
> and/or payed for were the features to get implemented first.  Now that
> Cyrus is a one-man show (currently), it may be awhile before we see any
> new features get added...
> 
> Forwarding as attachments is a function that already exists.  Viewing
> attached e-mails exists, but maybe not the way you would like... If it
> can be viewed inline, Mulberry allows it... otherwise, you right-click
> and click "view" and it opens an external viewer...
> 
> Drag and drop support is also implemented... though, without context in
> your complaint, I am not sure what you are expecting... I certainly can
> drag and drop an attachment from my desktop to the attachment section of
> my draft and it works as expected.  Admittedly, I haven't dragged and
> dropped things anywhere else...
> 
> Your arguments that things aren't as intuitive and easy to find is a good
> argument.  Some people don't have problems (like me), but other do.  This
> may be why some of the features you mention above aren't known to you.
> There was a project from CMU (by students?) that had taken on the job of
> analyzing the Mulberry interface to make recommendations on how to improve
> it.  They did surveys and usability testing, and had entered an agreement
> (contract?) with Cyrusosft (Isamet) to implement most if not all of the
> recommended changes.  This was a great step forward and a great idea.
> However, the project seem to go slowly and then disbanded when Isamet
> fell apart.
> 
>> And a thunderbird with cached headers is multiple times faster in
>> resorting and scrolling, not only over 3 MBit DSL Line, but even over
>> LAN. It's fine that mulberry doesn't need to cache headers, but why
>> isn't it able to do so? Loading on demand and then caching it would be
>> the best of both worlds.
> 
> The same could be said for IMSP preferences.  It isn't as noticeable over
> high speed connections, but over dialup... *whoosh*.  The first thing I see
> is Mulberry download all of my preferences (and I have a lot).  Then I see
> it turn around and write all the preferences back (at least from what I
> could see).  Only then can I start to use Mulberry.  Shutting down is also
> just as hard... all of my preferences get written back.  I am not sure if
> there is a good answer... especially since I don't REALLY know what is
> going on...
> 
> Another popular problem people complained about is the multi-threaded
> nature of Mulberry.  Some Mulberry actions freezes the whole application
> and prevents you from doing anything until those actions are done.
> 
> The point it, there is lots of improvements that could still be made and
> were in the works.  Cyrus acknowledged the problems it had and was very
> clear where he stood and where he was going.  It is a tough job being the
> author of one of the most popular IMAP clients on the marget, as a lot
> more demand and expectation gets added to that...
> 
>> So just implementing every IMAP feature available might be the best
>> thing for the server and the protocol, but not for the user. You need a
>> intuitive interface and nowadays it really has to look nice, too if a
>> non-geek should use it. And to be honest, mulberry simply looks
>> horrible...
> 
> I would not agree with the "horrible" philosophy.  I personally like the
> look and feel of Mulberry.  I think the CMU approach was a good one and
> it would be nice for something like that to be resurrected.  There is
> something to be said for surveys and usability testing... it answers
> some of the issues you have brought up.
> 
>> But it's nice, that everyone who doesn't care about looking and
>> usability now has a suitable free IMAP client availiable.
> 
> Uh... okay :)  Of course, we really don't know how big the "everyone
> who doesn't care about looking at usability" really is now, do we?  As
> I said before, there are a lot of people on BOTH sides of the equation.
> 
> Your points are well taken and they are valid... just offering another
> user's perspective!
> 
> Scott