hadaso,

I would have to respectfully disagree on most counts.

I would guess that 'edit as raw html' would be the least used option, and as such would make a lousy default. I would like to see the 'edit as' box become sticky, and simply default to the users last selection (much like the basic screen/advanced screen). This would make the issue moot.

I do like your idea to simplify the Inline HTML and Quote HTML options. The current implementation causes confusion and I don't see the value add. Perhaps fm should add the 'edit as' combo box to the view message screen and let the user specify the editing mode beforehand.

The two copies idea sounds too complicated. I have no problem with the formatting loss when going from html to text to html. To me, this is expected behavior.

minor grammer change in edit

Re: Simple is good
 

Hi Chris,

Which version of FireFox are you using?

I am using the .8 milestone and the editor loads and works fine for me..

Well, raw HTML editting would probably be almost noone's default, but for anyone wanting to reply an HTML message quoted without losing the original message formatting, and using a browser that does not support the HTML editor, it would be the only choice.

Eliminating the two flavors of "inline" and "quote" from the "basic" view screen is essential, I think. It's too much for the basic screen.

The "two copies" method can be used to eliminate the number of options in the quoted/inline selector in the view menu. It would let the user postpone the choice to the compose screen, which is certainly what most nomn-sophisticated users would expect (i.e., to decide to reply, press reply, then toi decide whether to compose plain text or rich text...) For this to work there would need to be a check and if there was no change in the text until the user decides to switch modes between plain text/HTML, no conversion+replacement would take place. This way, if the user goes to froward/reply, get to texy mode in the compose screen, and then decides to switch to HTML editing, the user gets the original message with the original HTML formatting, and not the text version without formatting converted to HTML, as it happens now.

I agree that the "two copies" model is probably more complicated than the "single copy" model for the programmer, but for the user of the basic screen it would be completely transparent, that user would not know about another existing copy, and it would be almost as transparent for the user of the advanced screen who didn't explicitly chose to separate the two copies by using an action buried in a pull-down menu. The user should not be aware that two copies exist: if the user switches mode, the copies are "synchronized", unless there was no change since the last time they were "synchronized". The user is not aware that after the conversion the old copy is kept. It would be replaced by a copy of the active copy if the user ever change modes again, unless the user is aware of the possibility to separate the two copies and edit each one separately.

I agree that there is no problem with loss of formatting if all you did was apply fonts/sizes/colors/emphasis to 7-bit English characters. But as soon as you have some non-English characters or non-text content such as math formulas, the loss of formatting means loss of content which has to be regained manually. Math might have things like <i>x</i>^<i>n</i>+1 which would be automatically converted to xn+1 but which would have to be manually reformatted to something like x^{n+1} to retain the meaning of the formula. Problems with encoding are discussed in a separate thread.

And perhaps the "two copies" method is not more complicated for the programmer. The most difficult parts, the conversions between HTML and plain text, and the integration of the two parts into one email message when "send" is clicked, are already then. The rest is a little bit of bookkeeping. It doesn't seem to me that keeping an extra copy would be noticable in performance. Certainly not compared to the graphic HTML editor. Actually it might be a good idea to keep the original message parts (text, HTML) while composing. This would allow the user to decide any time while composing to quote the original message, and in what form (of course, if the needed controls are there).

Firstly; I must echo myself and say that this editor (HardCore) is way to resource intensive. It really makes the editing experience everything but FastMail...

Secondly; There's a bug with the "<<< Remove" function of the editor. Clicking the "<<< Remove" label sometimes removes the complete form/editable area (at least this is my guess). The textarea is still visually present on the page, but it seems to removed via the js function; All content is deleted and I can't shift focus to it. Clicking on the menubar buttons doesn't return any results, and trying to switch to another format returns an js error (on line 59)...

Hi everyone. Sorry for my unresponsiveness of late. I've been on a bit of a holiday, and it's taken a while to get back to html compose, what with one thing and another.

Anyway, are people finding hardcore too slow in loading, or is it sluggish after that? Once it's loaded I don't have performance issues on my machine.

I've cut down the number of toolbar buttons so that it should be much less confusing now. It should be significantly faster to load.

Also, people that were having problems replying to messages as html - if your message had multiple single quote characters then it would fail, that should be fixed now.

I'll have a chat to J&R about the more involved issues.

Richard.

Thanks, but I'd still appreciate the compose are being a little bigger (not wider, but taller) on Gecko based browsers.

Btw. Eeism just became the very first email service (to my knowledge) to offer (final release) HTML compose on Mozilla browsers. :)

Hehe, I know you guys are working hard, just can't help giving you a little hard time sometimes. Keep up the good work. And I am still a FM worshipper. :)

The color black is still showing up reddish brown when sent from one FM account to another. Also, the color still won't stay for the original when replying. Still loads a little slow (with DSL) but the tool bar loaded twice as fast as before. (haven't looked over all the buttons yet) :)

Sherry

The performance is a bit better, but still a somewhat sluggish. Especially when an email contains more than a few lines of text. But I guess it all depends at what your low-end target specs are, I'm not on a P4 3.2 Ghz...

I've found a way to duplicate this. On the status line of the editor click the "HTML" label, then the remove function becomes "HTML > BODY > FORM action="https://www.fastmail.fm/beta/?Ust=abc;UDm=49" method="post" encType="multipart/form-data" <<< <<< Remove". Which, when clicked seems to remove the complete form...

The current configuration of HardCore editor is slightly better, but it still takes too long to load. Editing is ok.

All in all, my vote goes to HTMLArea. It has proper BiDi support, it "feels" better and it's totally open.

Prog.

I've just been comparing the two editors (Hardcore on the beta server and HTML Area at this page and at www.hugemail.com) and heres my take:

Hardcore:

With the current reduced feature set, there is nothing available here that can't be found in HTML Area (you can't even insert an image at the moment!). One of the key reasons Jeremy said Hardcore was being trialed was that it supported pasting from word, but using the normal paste button it seems to act identically to HTML Area (i.e. OK but not perfect by a long way). The buttons provide no feedback - no hover states or pressed states - and the menus (for text size, font etc.) don't work correctly in Mozilla based browsers - The font, text size and whatever the first one is often show blank (i.e. the first item in the list - what does that mean?) and if you click on one of the menus the curser keeps flickering around and not staying on the one you want to select.

HTML Area:

First off, it looks and feels great. Buttons react the way you feel they should and there are no menu troubles. It also has support for a spell checker, full table editing/formatting and bidi support. The only thing missing (apart from the ability to use local images) is a way to input special characters, which admittedly Hardcore does have.

Now I relalise there are behind the scenes reasons why Hardcore is to be recommended (Jeremy mentioned it does not rely on any particular server-side language) but from the user perspective HTML Area at the moment seems the better choice. I am however happy for FastMail to prove me wrong by turning Hardcore into the editor of the century or even finding something else again.

Cheers,

Neil

HtmlArea doesn't require any particular server side language. Basically the only requirement is that the server must be capable of using the post method of http. (At least if you want to do anything useful with the output it creates ;))...

You don't have to take my word for it. The "Key Features" section on the official site says;

I didn't get to check the new editor enough to have an opinion (other than having no bidi buttons). But I think the most important thing here is what kind of freedom it leaves for FastMail programmers to tailor it to the system: to add functinality to link to attachments (uploaded or fetched from the storage area), to insert images from the storage area (without having to manually open it in a separate window and copy/paste shotcuts), to insert notes from the notepad, etc. If it is not hard to add functionality, then bidi functionality would be something that can be added to FastMail. But anyway the imnportant part is to be able to take one of these editors that are built for online editting of web pages and make it work with email.

The big advantage of the hardcore editor is that pasting from word works much better. However, I haven't really done many experiments with this. *Sigh* It seems like I'm going to have to run my old windows box more often to test this sort of thing. :) Ah well. I'll spend a bit of time with htmlarea and see if there's any way to make it work better with pasting. Also, this will make any performance issues more obvious.

Currently the code just has a switch to select the appropriate html editor. It would be possible to expose this either on the Compose screen, or in Preferences, but I don't know yet if that's a good thing, usability-wise. It might be better if we just settle on one, and focus on that.

The reason I removed the "insert image" button is that I don't yet have the infrastructure in place to upload an image to a message. If people think it's useful in its previous form then we can easily stick it back in.

Richard.

Thanks Richard - I can see you're just experimenting. Putting both editors on the beta server would allow a side by side comparison and then everyone could say which they preferred. I would have thought it would be best to only choose one to make it to the production server though - two would cause confusion and be unneccesary.

In regards to the image input - you're right it's a bit useless at the moment so there is not much point in adding it back in yet.

Regarding the paste from word - when I tried it the two editors were identical. However I believe that one of the buttons you removed was a paste from word button. Could you add that back in so I can try it out and see if that works better please?

Thanks

Neil