10. January 2010

Error notification bar final look

Made some modifications to the way notification bar looks like: 32px of height was a bit too much, lowered it to 24px, make the bar more reddish and  changed the gradient, because glass look didn’t suit it. This is now the final look:

final_error_bar

09. January 2010

Easier navigation between messages in the same thread

I’m probably not the only one that is subscribed to a lot of mailing lists or has a really long conversations which span trough some 10s of messages. To ease the navigation between messages in the same thread I decided to move part of the thread closer to the message I’m currently reading. Starting with today’s builds there is a Message threads pane displayed at the bottom of message view pane.

msg_threads

This is how it works: After the message is loaded the following messages from the same thread are shown:

  1. parent message
  2. message being read message (will be colored differently)
  3. messages on the same level as message being read
  4. messages one level lower (deeper into the conversation) as message being read

Update 10.01.2010: The implementation in today’s development version actually works, but it’s still a bit rough around the edges.

msg_threads_colorized

07. January 2010

New notification style on send/receive message error

As some users pointed out the big red X on the account is not visible enough when there is an error on send/receive e-mail messages. But this really becomes an issue, when you spend most of your time working in Favorite mail view as now you have to explicitly switch to Classic view.

Well in a few days this will be in the past. As I’ve decided to add notifications at the top when such an error happens.

new_error_notification

There will be at most one bar per account displayed. And the text will change depending on when the error happened (send, receive, send and receive). Right now I don’t think that I should limit the number of displayed bars as most users have a small number of accounts.

If anyone would like to play with the colors e.g make it reddish,  please let me know and I’ll give out the current ones.

Update 08.01.2010: This is now implemented in latest 1.2.x development builds.

11. September 2008

si.Mail auto configuration, more thoughts

So if I continue yesterday’s thought on auto configuration (AC in the rest of the post), then there seems to be a big problem – updating AC file. At first I thought on just checking si.Mail’s homepage when creating new account if newer version of AC file is available, but this poses another problem, getting this information from ISPs and/or mail service providers. This would be tedious work and won’t be ideal. There should be another way.

Finally it came to me. Why not do it like DomainKeys, and spf records are implemented. Use DNS TXT record.  So In layman’s terms, we add new TXT record. Something along example.com. IN TXT “mailAC=http[s]://path_to_AC_file”. You are probably asking why AC couldn’t be put directly into the TXT record the main reason is, it’s too big and thus it would be hard to edit.

So how would this work? si.Mail extracts domain part of e-mail address and fetches TXT records from nameserver for that domain. If it founds correct TXT record it downloads the file and auto configures everything that’s needed to send and receive e-mail messages.

Now imagine that you are a hosting provider using Plesk, CPanel or any other software. (Usually all domains you host have the same type of e-mail access) You just add to your DNS template url to one AC file and all e-mail accounts for all domains you are hosting can be configured from a SINGLE file. Also you have complete control of AC file so if anything changes you can modify AC yourself without bugging anyone. This is also ideal for small companies where users can configure e-mail client by themselves.

09. September 2008

New account creation window mock up

Because I’ve gotten quite a few complaints that account creation wizard is troublesome for some users I decided to change account creation drastically. si.Mail already has some sort of automatic account configuration, but I’ve decided to take it to the next level.

With current automatic account configuration you still have to go through entire wizard although that wouldn’t be necessary. At the moment there are some fields that could be auto configured but they are not.

Account creation mock up

As you can see at the mock up above in reality for auto configuration usually only first 3 fields are necessary and sometimes the 4th one, in cases where user name doesn’t equal any part of e-mail address (user name field would be hidden by default and would be displayed only if necessary). If there won’t be any data for auto configuration, user will automatically get the same window as if it would have clicked on Advanced settings.

So what is your opinion on this?