New Webmail Interface (Revived)

[MikhailT]

Originally posted by Geir
MikhailT,

Yes, we plan to use AJAX in the Runbox interface, but only where it can improve usability significantly -- for instance message drag-and-drop and preview functionality.

Note that AJAX (Asynchronous JavaScript And XML) is a combination of various technologies and not an established "platform" that can be easily integrated. Although client-side processing has some great advantages it also poses some problems (related to behavioral predictability/consistency and compatibility) and should be implemented with care.

- Geir

Yea I know it isn't an established but its hard to figure out what catagory that AJAX belongs to because I do know that AJAX is just combination of different technologies such as Asych JavaScript and XML. I can say framework but there are various AJAX frameworks as well, like Prototype, Milk, etc etc.

But can't wait to see what you guys can do with it.

[goofy]

Hans, any estimated timeframe on launching this improvement??? Thread started 1 year, ago??? Please let us know.

[carverrn]

This thread was started by a Runbox customer ... Trip. Trip took some of his own time to propose alternate user interface designs for Runbox. While Runbox has acknowledged that the like what was being suggested they have never committed to doing it. At least not then and not now.

Their current priorities have been the new IMAP server, DSPAM and overall system performance.

They have also been without a programmer for a while but Liz says they have been interviewing.

So I wouldn't plan on anything of these changes for a little while.

Regards,
Rich

[hanslysglimt]

Hi,
Thanks for answering that one Rich, you are right on.
Trip has made some really great material for the next upgrade of the webmail system. I want to see this happen.

As you know we are working on the Webmail application doing incremental improvements continiously (my appologies when we are not fast enough in our efforts). Our project-manager/developer Geir Thomas and the team from Linpro are doing a very good job on that. On top of this we have contracted a couple of great guys offshore for some stand alone tasks. What we are currently lacking is our own inhouse senior Perl developer to lift the Webmail to the next level (our sister company Linpro right next door have 30 of them, so we get whatever we need to have done there, still we want our own full time guy). This developer will be incorporating the new exciting stuff - not incrementally but as a "new" version.

As you know Runbox is now profitable, we have the funds and we are interviewing as we speak. It is a matter of getting some pieces in place. Finding the right guy/or girl first and foremost.

Regards,
Hans

[BKB]

Hi Hans,
Good luck with the interviewing . Take your time, there is no need to rush it. Very important to pick the right person. I really look forward to having a full time Perl developer back on the team, and take advantage of the design behind RMM4, i.e. to make further improvement both easier and faster, and take advantage of your vibrant beta testing community.

[carverrn]

Although I'm sure the RMM4 changes are going to break my Runbox Toolbar 2

Rich

[hanslysglimt]

Thanks!

Yes, RMM 5.0 has to take into consideration the toolbar and a lot of other issues. We have a lot in the works on how to do this, and it's going to be a major undertaking.

[hanslysglimt]

Let me share some additional thoughts on RMM 5.0:

There are several ways to go about getting to RMM 5.0.
We have an extensive feature list going for RMM 5.0.

Three main routes:
- Incremental improvements from the current RMM 4.x.
We will be doing this either way.

- Write a "new" webmail application.
Based on previous knowledge.

- GPL (open source) our Runbox Webmail and make it a common effort going forward.
- Fuse into and/or "adopt" one of the existing open source webmail projects:
Open Webmail
Squirrelmail
...or one of the others, there are quite a few:
http://sourceforge.net/search/index....ft&form_cat=18
Your comments on what you could like with these are appreciated.

Runbox could contribute with knowledge development and financially, something these projects are in need of. Many of these webmail projects are also built for certain featureas and not really built to scale, Runbox could help with that.
Most importantly Runbox could therefore contribute with large scale backend integration knowledge - the hardest part of running and email service.

[hobbes]

OK, I'm not a Runbox user, although I used to be. I am both a Fastmail and Tuffmail user. Tuffmail is my primary account.

Tuffmail use both Squirrel Mail and Horde. (Let me just say that the Horde installation on Tuffmail is by far and away the most feature-rich webmail client on the web. Nothing comes close. You may not like the style or manner of implementation, but on mere features it blows everything else away.)

It occurred to me that both Fastmail and Runbox are attempting to reinvent the webmail wheel, and not doing a great job. Webmail development is clearly a resource drain, and its complexity introduces numerous bugs and problems during the "incremental" development. Fastmail has suffered from this particularly in recent weeks. Not a week goes by when a tweak of the interface breaks something for the users.

Tuffmail are one of the most reliable and stable email providers around. Why? Because they leave webmail development to the webmail developers, and pour their resources and expertise into creating and maintaning the email service itself.

Both Fastmail and Runbox have shown that webmail development is agonizingly slow. So, I am all for importing a third-party webmail, which I think will help to deliver a well-designed, well-run Runbox email architecture.

Why reinvent the webmail wheel - unless you really, truthfully can do a better job, without it taking 2-3 years.

Just my own thoughts.

[BKB]

Originally posted by hanslysglimt
Let me share some additional thoughts on RMM 4.0:

There are several ways to go about getting to RMM 4.0.
We have an extensive feature list going for RMM 4.0.

Hans,
You mean 5.0, surely! The current one is 4.0.

[firstone]

Originally posted by hobbes
It occurred to me that both Fastmail and Runbox are attempting to reinvent the webmail wheel, and not doing a great job. Webmail development is clearly a resource drain, and its complexity introduces numerous bugs and problems during the "incremental" development. Fastmail has suffered from this particularly in recent weeks. Not a week goes by when a tweak of the interface breaks something for the users.

I asked this same question several months ago in another thread. The basic answer was, if I understood it correctly, that working on the development helps keep employee morale up. As a programmer, I can understand that - I'd always rather be working on some new interesting inventive project rather than maintaining (or even administeing in this case) someone else's code.

As a user, however, I'd much rather see horde put in place. Especially if it can be done in addition and not as a replacement of the existing web front-end.

Maybe now that runbox doesn't have a programmer, it would be a good time to try to set up horde?

[Geir]

The version number isn't very important in itself, but we're currently on 4.5. When we upgrade RMM to the point where it's no longer backwards compatible with the 4.x version, we'll call it version 5.

While we'll continue to incrementally develop the current version, we do have greater ambitions and visions of a new email service paradigm integrating services and functions in new ways.

Much can be said for the available open source platforms, but none of them are terribly exciting or ground-breaking -- and few (if any) are compatible with the Runbox architecture, which is a quite unusual and very efficient database accelerated email system.

Besides, if no one tried to reinvent the wheel we would all be driving T Fords with wooden spokes.

Hence, Runbox should look beyond existing and established email services towards a system that can meet the needs of emerging usage patterns and communication challenges.

Supported by the Norwegian Research Council we're currently researching the problems email users face, particularly in the work place, and how email can be integrated with task, file, and contact management on a more fundamental level.

We have several concrete ideas for an interface where email related data can be accessed from different perspectives across conventional data structures and hierarchies.

We're very interested in input from you, our most advanced users, on how the ideal email service of the future should look.

- Geir

[BKB]

Originally posted by hanslysglimt
Three main routes:
- Incremental improvements to the current RMM 3.x.
We will be doing this either way.

- Write a "new" webmail application.
Based on previous knowledge.

- GPL (open source) our Runbox Webmail and make it a common effort going forward.

- Fuse into and/or "adopt" one of the existing open source webmail projects

I agree with Hobbes.

The first route has been tried already, as it's the current, default, Runbox approach to webmail. I know a lot of users are quite disappointed with the current speed at which new features have been introduced. Personally, I have been here almost three years and I am not particularly disappointed. But you hear it a lot on the forum. When you add the time it takes to beta test new features, I think it's the least effecient method.

The second route has also been tried, periodally. The current webmail, RMM4 was hailed as a re-write of the webapp, based on previous knowledge, to allow for faster improvement. I participated active in the beta testing effort, but when 4.0 was implemented, I don't remember seeing an increase in the speed at which features were added. I do see a slim benefit in re-inventing the wheel, it's similar to the reasoning behind Apple maintaining Safari instead of jumping on the Firefox bandwaggon, i.e. that it's important to have control over key elements in your business model, but Runbox's track-record demonstrates that this isn't a very effcient development approach either.

The open source route is the most interesting, certainly the most radical, consistent with Runbox's principles, and the right one for Runbox. Since Runbox is a small company - a tiny one if you measure it in terms of employees - with limited resources, there is a strong argument to recruit the open source community, and the current user base. We've seen the benefit of this with various user contiribution, notibly Rich. But I believe there is a goldmine here, and it doesn't take very much to reap the rewards. As Hobbes points out, this lets Runbox focus on the email architecture, which again is another moot point for many people here.

Once the deicision is made to go the open-source approach, the next decision, i.e. open sourcing RMM4 or joining an existing effort, is more of a question for the webmail developer community. What do they think of Runbox's webapp? How does it compare to other efforts? Would they be interested in joining the effort? Also, it would clearly take time to build momentum around a new open-source RMM4 project, and so it's tempting to join an existing project. But can any of them be tweaked to look Runbox-like? Are there any natural choices?

[BKB]

Originally posted by Geir
Besides, if no one tried to reinvent the wheel we would all be driving T Fords with wooden spokes.

Agreed. But those that did re-invent the wheel certainly didn't do it with one or two engineers (programmers, in our case). Whereas it would be great to do this, it would require a lot of manpower, surely. Is this also part of the vision?

[Geir]

After we modularized, refactored, and streamlined the web application code and developed RMM 4, which was a huge undertaking in Runbox scale, we have launched File storage, a new product/payment system with recurring billing, and Email Hosting, among other minor things. Perhaps unimpressive, but their value to Runbox should not be underestimated. Runbox is now profitable for the first time (yes) and ready for a new development effort.

Reinventing the Webmail is comparable to the tasks mentioned above, not to mention developing the first version of the service. This time we would not attempt to rewrite the application, but rather build on the solid foundation and quality Perl code we already have.

I don't think it would require too much manpower -- perhaps one senior developer along with myself and perhaps one or two other (outsourced) developers. It could probably be done incrementally, i.e. we would launch improvements as they are ready.

Runbox really has never employed more than one true Perl developer at the same time, and we're still competitive.

We would naturally welcome outside help, and appeal to the open source community when possible.

- Geir