View Single Post
Old 21 Dec 2016, 12:46 AM   #16
BritTim
The "e" in e-mail
 
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,090
Thank you Bron for taking the time to engage with us. I think I speak for the vast majority of us here when I say that, even when we unfairly take out our frustrations on you, we nevertheless really appreciate your willingness to show we are not ignored.

I have always found you totally honest in what you say (evidenced by your admission that EMD was deliberately neglected, and the understandable reasons why). I firmly believe honesty is the best policy. You will sometimes be attacked when delivering a message people do not like, but it builds trust in the long run that is worth some discomfort.

If I may, I would like to make a few comments on this:
Quote:
It gets harder and harder when you have more staff working on the same code and more users using each feature to justify doing one cool little hack for a few users
There are some features that were provided in the past that were clearly a mistake. The custom Javascript hack was a case in point. While sorry to see it go, I cannot recall anybody seriously questioning the necessity.

Other items are more worthy of discussion. Here are a couple of examples of things available in the old classic interface, but difficult to do in the current interface. They are not used every day, but are important on occasion for one or more of my customers:
  • Copy (not move) messages to another folder. Support for labels would make this unnecessary, but it really is important (to make messages easy to find later) to be able to see messages from multiple places in the hierarchy. Saved searches can sometimes be a band aid, but are not equivalent.
  • Downloading messages resulting from a search as a zip file..
  • Sending multiple messages as attachments in an email. This feature is incredibly useful when sending a select archive of messages for legal review. Other use cases exist.
I make no claim that my experience should mandate keeping these features around when the classic interface is canned (as I think is inevitable). I do believe the decision to remove them should be made only when the impact on the customer base is understood.

Similarly, I believe the decision to implement recent security changes without consulting the base meant that a mostly excellent enhancement has a major flaw that is very troublesome for some users. The availability of limited access to the web interface (public terminals where U2F is unavailable/blocking some users from editing their own configuration) is not necessary for everyone, but is an important security feature for some. Its lack leads to a situation where security must be sacrificed in some cases so as not to get in the way of getting work done. This is particularly tragic as, in most respects, the new security system is a big improvement over the old one. Discussion with the base prior to implementation would, I feel, have avoided this blind spot.

There are some new features that would be great to see (my favorite is the editheader sieve extension) but I am a realist. I recognize they would not be strategic for Fastmail, and resigned (without rancor) to be disappointed. Most users do not know what they are missing, so this does not hurt Fastmail.

I hope you see the above as constructive, and not an attempt to denigrate the work done by you and your colleagues. Notwithstanding the tendency of some to make posts that are unhelpful, I do fundamentally believe in the concept of "the wisdom of crowds".

Last edited by BritTim : 21 Dec 2016 at 12:55 AM.
BritTim is offline   Reply With Quote