So what do I do? Resort to web-based email access which our corporate server provides. This seems to work because Firefox seems to consume less memory, and is "more responsive" compared to Thunderbird. Also, the issue could be with thunderbird having to initialize a large email store (I have anywhere between 3000 to 4000 emails in inbox at any time). The headers are synchronized first, and are available instantly. But the loading the body takes a lot of time.
So here is the idea: Enhance thinderbird extension so that it helps open email using browser - assuming that your webmail can take the URL with appropriate ID, and allows you to login without losing that ID...
Small niceties always help.
As the app devel cycle takes lesser and lesser time, the UI improvements will keep going on continuously. A simple "merge" operation should be sufficient to ensure that the developer-made changes are automatically integrated into next version of UI. This means templates should be designer-friendly and amenable to versioning, diff's and merges. This means that all the "code" part to be within attributes and special tags. Kid template language of Python does this right.
And again, assuming we spend time with UI, we require templates to be managed by content management system - and that means Wiki. And more important, we would like the capability to be uniformly available to end users as well. And this means we need to have "Safe" templates - those which can be edited from web itself. For example, Liquid, a ruby-based templating system, seems to do it.
Widget integration is going to be another interesting area. Dojo, prototype etc. already give us good widget environments. Widgets will probably make it easy to standardize on Layouts - such as 3-column, or 3-pane (like in outlook). How exactly should widgets get integrated with templating languages? In some sense, widgets seem to compete with standard templating approaches: A widget specificaiton is going to be very simple. Remember Dojo's ridiculously simple slideshow widget example specification? And the problem is, the widget is going to take inputs as parameters. Some of them will, well, be widgets. And this means that your template will basically be XML tree, and that's bad. (After all, templates should look like real HTML!) In any case, as long as browser can show this properly without requiring other servers, I think people will come to accept this approach. We would have to see how this will roll out. And not to forget, we are also talking of ajax-enabled widgets which need to integrate well with JSON-RPC or some such scheme.