<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<link href="chrome://translator/skin/floatingPanel.css"
type="text/css" rel="stylesheet">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 24/03/12 20:22, JoeS wrote:
<blockquote class=" cite" id="mid_4F6E2D14_4000007_gmail_com"
cite="mid:4F6E2D14.4000007@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
On 3/23/2012 7:41 PM, Unicorn.Consulting wrote:
<blockquote class=" cite" id="mid_4F6D0A35_1030107_gmail_com"
cite="mid:4F6D0A35.1030107@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<link href="chrome://translator/skin/floatingPanel.css"
type="text/css" rel="stylesheet">
<div class="moz-cite-prefix">On 24/03/2012 4:54 AM, Blake Winton
wrote:<br>
</div>
<blockquote class=" cite" id="mid_4F6CBFFB_5080609_mozilla_com"
cite="mid:4F6CBFFB.5080609@mozilla.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Hey TB-Planners,<br>
<br>
Now that all the big features are landed, and we have some
time to breathe again, I've been thinking a little bit about
what we want to do on Thunderbird's front-end over the next
couple of releases.<br>
</blockquote>
In general I think that the compose in a tab (optional) should
be at the top. In saying that, I don't see this as a compose in
Tab so much as either replace for fix the existing composer. The
pain point for users is not the absence of the tab, it is the
creaking and unwieldy composer code.<br>
</blockquote>
</blockquote>
+1 for replacing composer. Is there nothing out there we can use?<br>
<blockquote class=" cite" id="mid_4F6E2D14_4000007_gmail_com"
cite="mid:4F6E2D14.4000007@gmail.com" type="cite">
<blockquote class=" cite" id="mid_4F6D0A35_1030107_gmail_com"
cite="mid:4F6D0A35.1030107@gmail.com" type="cite"> <br>
<a moz-do-not-send="true"
href="https://bugzilla.mozilla.org/show_bug.cgi?id=250539">Bug
250539</a> is one that appears in support on a regular basis
and clearly is a big issue.<br>
<br>
Users also complain that they can't edit the HTML directly (I
think this is an offshoot of the clunky design tools, not a real
interest in HTML editing. Although it would be nice to be able
to switch to HTML ala Blogger)<br>
</blockquote>
A simple workaround for that:<br>
Edit>>Select all>>Insert HTML will allow you to edit
the raw code.<br>
<blockquote class=" cite" id="mid_4F6D0A35_1030107_gmail_com"
cite="mid:4F6D0A35.1030107@gmail.com" type="cite"> <br>
I would also suggest that introducing Compose in a tab without
fixing the composer code would be worse than doing nothing at
all. Users are disgruntled but sort of accepting that the
composer is clearly not getting any attention. Introducing the
'compose in a tab' without due fixes to the composer would
rightly or wrongly lead users to the view that the composer is
receiving attention, but it is the fancy stuff, not the basic
usability of the composer and it more than likely going to upset
them <br>
<br>
Matt<br>
<br>
<br>
</blockquote>
I must agree completely here.<br>
Compose in a tab is just another rendition of broken editor.<br>
My personal opinion is that there will never be any headway on
this issue unless the Editor components are forked.<br>
Compose in the browser context can never be fully reconciled to
the message context IMO<br>
<br>
<blockquote class=" cite" id="Cite_2" type="cite">
<ul>
<li> Papercuts! (Fix the easy little things that are making
Thunderbird worse to use.)</li>
<ul>
<li>Things like the tab you go to after closing the current
tab (bug 508776).</li>
</ul>
</ul>
</blockquote>
Yes. A "home tab" is a must.<br>
If we are going to push "tabs" vs standalone windows, then that
alternative should be superior.<br>
That certainly is not the case today.<br>
<a moz-do-not-send="true"
href="https://bugzilla.mozilla.org/show_bug.cgi?id=392328">Bug
392328</a><br>
After using the standalone windows mode for so many years, it's
really hard to change.<br>
(I'm trying , but still occasionally close the app, thinking I'm
closing the window.<br>
<br>
<blockquote class=" cite" id="Cite_3" type="cite">
<ul>
<li>Social Search.</li>
<ul>
<li>Extend OpenSearch to social networks.</li>
<li> Also <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://mozillalabs.com/blog/2012/03/experimenting-with-social-features-in-firefox/">http://mozillalabs.com/blog/2012/03/experimenting-with-social-features-in-firefox/</a></li>
</ul>
</ul>
</blockquote>
Don't know if we will ever make headway into this area.<br>
I think folks are too entrenched in the "browser" way of doing
things here.<br>
<br>
Which leads me to my next point:<br>
If we want to attract the "social media" crowd, then we must make
that easy for them.<br>
The basic requirement for that is easy html and multimedia access.<br>
<br>
The Conversations extension made a step in that direction by
adding an option to convert Youtube "links" to automatic iframe
conversion.<br>
This is what I consider a progressive agenda, It gives folks what
they want.<br>
<br>
Sadly, I still see comments relating to the age-old html vs.
plaintext controversy around and about.<br>
Further we should facilitate CSS in email to make email more
web-like.(maybe some nice clean CSS templates)<br>
</blockquote>
Yes, better CSS support would go a long way towards fixing the
Composer as well. I find that I can do quite fancy stuff (when using
stationery in order to edit the html), without too much effort; a
style editor for the styles dropdown with some nice templates might
be a first "cheap" step. Only problem is the CSS compatibility with
other mail programs; e.g. AFAIK outlook still expects css styles to
be inline, so there would have to be an optional "compatibility
mode" when sending out emails.<br>
<br>
regards<br>
Axel<br>
<br>
<br>
<div style="bottom: auto; left: 155px; right: auto; top: 490px;
display: none;" class="translator-theme-default"
id="translator-floating-panel">
<div title="Click to translate"
id="translator-floating-panel-button"></div>
</div>
</body>
</html>