UX Priorities.

Axel axel.grude at googlemail.com
Mon Mar 26 11:40:10 UTC 2012


On 24/03/12 20:22, JoeS wrote:
> On 3/23/2012 7:41 PM, Unicorn.Consulting wrote:
>> On 24/03/2012 4:54 AM, Blake Winton wrote:
>>> Hey TB-Planners,
>>>
>>> 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.
>> 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.
+1 for replacing composer. Is there nothing out there we can use?
>>
>> Bug 250539 <https://bugzilla.mozilla.org/show_bug.cgi?id=250539>   is one that 
>> appears in support on a regular basis and clearly is a big issue.
>>
>> 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)
> A simple workaround for that:
> Edit>>Select all>>Insert HTML will allow you to edit the raw code.
>>
>> 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
>>
>> Matt
>>
>>
> I must agree completely here.
> Compose in a tab is just another rendition of broken editor.
> My personal opinion is that there will never be any headway on this issue unless the 
> Editor components are forked.
> Compose in the browser context can never be fully reconciled to the message context IMO
>
>>   * Papercuts!  (Fix the easy little things that are making Thunderbird worse to use.)
>>       o Things like the tab you go to after closing the current tab (bug 508776).
>>
> Yes. A "home tab" is a must.
> If we are going to push "tabs" vs standalone windows, then that alternative should 
> be superior.
> That certainly is not the case today.
> Bug 392328 <https://bugzilla.mozilla.org/show_bug.cgi?id=392328>
> After using the standalone windows mode for so many years, it's really hard to change.
> (I'm trying , but still occasionally close the app, thinking I'm closing the window.
>
>>   * Social Search.
>>       o Extend OpenSearch to social networks.
>>       o Also
>>         http://mozillalabs.com/blog/2012/03/experimenting-with-social-features-in-firefox/
>>
> Don't know if we will ever make headway into this area.
> I think folks are too entrenched in the "browser" way of doing things here.
>
> Which leads me to my next point:
> If we want to attract the "social media" crowd, then we must make that easy for them.
> The basic requirement for that is easy html and multimedia access.
>
> The Conversations extension made a step in that direction by adding an option to 
> convert Youtube "links" to automatic iframe conversion.
> This is what I consider a progressive agenda, It gives folks what they want.
>
> Sadly, I still see comments relating to the age-old html vs. plaintext controversy 
> around and about.
> Further we should facilitate CSS in email to make email more web-like.(maybe some 
> nice clean CSS templates)
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.

regards
   Axel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120326/e82ac1ee/attachment.html>


More information about the tb-planning mailing list