TB UI enhancements: Vertical view & inline message
Paul....@gmail.com
I've made some works about the vertical view of Thunderbird (see bug
213945 from comment 26). Take a look at the last screenshots:
http://www.mozbox.org/pub/tb/
In addition, I'm interested in developing a way (a TreeBodyFrame hack
too) to include the message content *in* the threadPane (see
http://www.mozbox.org/pub/tb/inlineMsg.png , an early draft, but it
seems to be faisable).
Since such developments will require a lot of work and many
discussions (such patches are layout component related, it could
impact all Mozilla products), I really need to know if the way chosen
is the right way and if this is something that could interest you for
TB3.
BTW, is there something like mozilla lab for Thunderbird ?
Thanks
Paul Rouget
David Ascher
> Hi folks.
>
> I've made some works about the vertical view of Thunderbird (see bug
> 213945 from comment 26). Take a look at the last screenshots:
> http://www.mozbox.org/pub/tb/
>
> In addition, I'm interested in developing a way (a TreeBodyFrame hack
> too) to include the message content *in* the threadPane (see
> http://www.mozbox.org/pub/tb/inlineMsg.png , an early draft, but it
> seems to be faisable).
>
>
> Since such developments will require a lot of work and many
> discussions (such patches are layout component related, it could
> impact all Mozilla products), I really need to know if the way chosen
> is the right way and if this is something that could interest you for
> TB3.
>
My feeling is that it's certainly possible, but it'd be good to have
that come out of a bigger discussion of _why_ different layouts might
make sense for what interactions, what users, in what contexts, etc.
Bryan, your take?
> BTW, is there something like mozilla lab for Thunderbird ?
>
Not really, but I'm sure if you had a specific idea for something that
made sense within Mozilla Labs, that we could work something out. What
resources do you need?
--david
Eddy Nigg (StartCom Ltd.)
> Hi folks.
>
> I've made some works about the vertical view of Thunderbird (see bug
> 213945 from comment 26). Take a look at the last screenshots:
> http://www.mozbox.org/pub/tb/
>
> In addition, I'm interested in developing a way (a TreeBodyFrame hack
> too) to include the message content *in* the threadPane (see
> http://www.mozbox.org/pub/tb/inlineMsg.png , an early draft, but it
> seems to be faisable).
>
but....mmm...not bad ;-)
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390
JoeS
Interesting views.
You might be interested in what Alta88 has come up with here:
http://morelayoutsforthunderbird.mozdev.org/
For someone that uses full page compositions in newsgroups (Me) , the f11 fullscreen toggle is a Godsend.
--
JoeS
Ron K.
> paul....@gmail.com:
>> Hi folks.
>>
>> I've made some works about the vertical view of Thunderbird (see bug
>> 213945 from comment 26). Take a look at the last screenshots:
>> http://www.mozbox.org/pub/tb/
>>
>> In addition, I'm interested in developing a way (a TreeBodyFrame hack
>> too) to include the message content *in* the threadPane (see
>> http://www.mozbox.org/pub/tb/inlineMsg.png , an early draft, but it
>> seems to be faisable).
>>
> Now THIS looks kind of interesting. Perhaps one needs to get used to
> it, but....mmm...not bad ;-)
>
>
I agree it's an interesting alternative layout for mail when I realized
it is using the Tb3 Tabbed Interface. Where I see a down side is how
the layout would work for vision impared recipients. The need for
smaller print to cram a subject line in below the Sender will reduce
readability.
Has this been evaluated for news reading? News can generate some very
long threads. Also, display of HTML content would need a zoom feature
to enable images to render full detail. The Add-on that provides the
Acrobat drag gripper should work nicely when a user zooms in on an image.
--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
Eddy Nigg (StartCom Ltd.)
>
> I agree it's an interesting alternative layout for mail when I realized
> it is using the Tb3 Tabbed Interface. Where I see a down side is how
> the layout would work for vision impared recipients. The need for
> smaller print to cram a subject line in below the Sender will reduce
> readability.
Actually when I saw it I immediately thought about mobiles and smaller
devices. It's an interesting approach.
Ron K.
> Ron K.:
>>
>> I agree it's an interesting alternative layout for mail when I
>> realized it is using the Tb3 Tabbed Interface. Where I see a down
>> side is how the layout would work for vision impared recipients. The
>> need for smaller print to cram a subject line in below the Sender
>> will reduce readability.
>
> Actually when I saw it I immediately thought about mobiles and smaller
> devices. It's an interesting approach.
>
>
Several years ago when MS was developing the Windows CE OS for Notebook
computers they ran into a Font problem. All the stock fonts that MS was
bundeling with Windows and Office products were either too large or
poorly shaped to scall down to the smaller screens. The solution was
having Mathew Carter, the elite font designer at Monotype, create a new
font face which rendered clearly at 7 pixel size on the Notbook screens.
The Nina family is a descendant of the sequence from Verdana to Tahoma
then Trebuchet MS that Mathew Carter designed for the MS Web Font
collection. Unfortunately Nina is no longer a free d/l from MS, and is
now sold by Ascender Corp. which is the exclusive agent for the entire
library of fonts developed by MS.
Not too far back in time, Bitstream designed the Vera families of sans
and serif fonts for the Gnome Linux project. Those fonts, while
copyrighted, were released under the GPL license which permits font
designers to legally extend and revise the fonts. In my view, Mozilla
Foundation should consider a similar arrangement that would permit
shipping a sanserif font family with Fx and Tb as a system font to meet
the needs of small screen mobile devices.
I have extensively revised the Fx and Tb themes UI with Nina in sizes
from 8px to 13px. The tighter letter spacing yealds a lot more room for
long subject or extensive threads before text begins to truncate.
Greg K Nicholson
> Not too far back in time, Bitstream designed the Vera families of
> sans
> and serif fonts for the Gnome Linux project. Those fonts, while
> copyrighted, were released under the GPL license which permits font
> designers to legally extend and revise the fonts. In my view, Mozilla
> Foundation should consider a similar arrangement that would permit
> shipping a sanserif font family with Fx and Tb as a system font to meet
> the needs of small screen mobile devices.
Mozilla shipping the DejaVu fonts (the open-source descendants of
Bitstream Vera) in their Windows and OS X builds (they should already
come with most Linux distros) would be pretty cool.
Bryan W Clark
> paul....@gmail.com wrote:
>> Hi folks.
>>
>> I've made some works about the vertical view of Thunderbird (see bug
>> 213945 from comment 26). Take a look at the last screenshots:
>> http://www.mozbox.org/pub/tb/
>>
>> In addition, I'm interested in developing a way (a TreeBodyFrame hack
>> too) to include the message content *in* the threadPane (see
>> http://www.mozbox.org/pub/tb/inlineMsg.png , an early draft, but it
>> seems to be faisable).
>>
>>
> Cool!
Excellent stuff, I had been reading over that bug after it was sent to
me last week.
>
>> Since such developments will require a lot of work and many
>> discussions (such patches are layout component related, it could
>> impact all Mozilla products), I really need to know if the way chosen
>> is the right way and if this is something that could interest you for
>> TB3.
>>
>
> My feeling is that it's certainly possible, but it'd be good to have
> that come out of a bigger discussion of _why_ different layouts might
> make sense for what interactions, what users, in what contexts, etc.
>
> Bryan, your take?
Yes, certainly possible and I really like what you've done so far.
I'd like to see this tried out; if it was an extension I would have
downloaded it by now and tested it. But I agree that there are a lot of
open questions in my mind about the overall design of the layout and
where it fits.
Reading the bug from the beginning led me to believe that this layout
change is necessary *only* for the vertical view layout because of the
decreased horizontal space available. While on a wide or normal view
there is plenty of horizontal space available to the tree view and
therefore it doesn't need to compact things into vertical space.
However it is interesting to see the change applied to other layout types.
What's the vision here?
I feel like it's a great time to start the larger discussion of what
makes sense (in terms of layouts) for different people and their email
use. I'm doing a bit of screenshot gathering of some different systems
right now, I'll get back with those.
~ Bryan
alta88
hi,
do you have working code to implement this? nice job if so, the custom
tree view in threadpane is perhaps some of the most complex code in Tb.
1. are you using <richlistitem> for the header info? with the
advancements in that widget in Fx (new urlbar autocomplete) this is
probably the way to go.
2. imo, this should be optional for all views not just vertical.
3. from my understanding, this is a heavily requested feature, and
belongs in core, probably don't need a lot of usage case analysis for
this one..
4. changing into/out of different views and changing from 1 line to 2 or
more in threadpane should be dynamic, no restart.
5. moving the messagepane inline with the threadpane messages is
interesting. moving major DOM nodes can be tricky, but of the 3 in Tb,
messagepane is easiest and lowest impact.
6. don't forget the impact of Lightning - i've found it the only
extension that is problematic with DOM node moves (threadpane and
folderpane), but it doesn't seem you would need to touch those higher
than their <deck> parent.
Paul Rouget
> I agree it's an interesting alternative layout for mail when I realized
> it is using the Tb3 Tabbed Interface.
Yes, using the Tb3 tabbed interface with such layout change make TB UI
really compact.
> Has this been evaluated for news reading?
Seems to work.
On Mar 10, 3:35 am, "Eddy Nigg (StartCom Ltd.)"
<eddy_n...@startcom.org> wrote:
> Actually when I saw it I immediately thought about mobiles and smaller
> devices. It's an interesting approach.
Is there any effort or plan about Tb on mobiles devices ?
On Mar 10, 5:43 am, Bryan W Clark <clar...@gnome.org> wrote:
> I'd like to see this tried out; if it was an extension I would have
> downloaded it by now and tested it.
I can provide a TB build including these patches (bugzilla patch is
not up-to-date).
> Reading the bug from the beginning led me to believe that this layout
> change is necessary *only* for the vertical view layout because of the
> decreased horizontal space available. While on a wide or normal view
> there is plenty of horizontal space available to the tree view and
> therefore it doesn't need to compact things into vertical space.
> However it is interesting to see the change applied to other layout types.
>
> What's the vision here?
These patches provide 2 new features:
* give a way to add more content below the classic row
* display the message in the thread pane.
Currently, I use this new space to display subject and preview, which
makes sense for the vertical view.
But it could host any other information (just the preview for
instance).
Such layout changes don't invalidate current layout, there just
provide new way to custom the TB UI.
I think this layout change don't have to be vertical view only
related. A checkbox in the view menu let you switch between classic
rows and mutliline rows.
About the inline message, I especially think about a "tiny & easy" UI.
Combined with the tabs, it could be funny:
http://www.mozbox.org/pub/tb/inlineMsg2.png
On Mar 10, 4:38 pm, alta88 <alt...@gmail.com> wrote:
> do you have working code to implement this? nice job if so, the custom
> tree view in threadpane is perhaps some of the most complex code in Tb.
Yes, screenshots are not mockup. Multiline rows seem to work well (no
big bugs). Inline message is really tricky, lot of bugs. But it's an
early draft ! The TB integration is poor.
> 1. are you using <richlistitem> for the header info? with the
> advancements in that widget in Fx (new urlbar autocomplete) this is
> probably the way to go.
No. It's a TreeBodyFrame (layout object wich displays object
implementing nsITreeView) hack. It's very important to use a tree to
display message list, for performance issues.
> 2. imo, this should be optional for all views not just vertical.
It is optional. Just selected "multiline" in the view menu.
> 3. from my understanding, this is a heavily requested feature, and
> belongs in core, probably don't need a lot of usage case analysis for
> this one..
> 4. changing into/out of different views and changing from 1 line to 2 or
> more in threadpane should be dynamic, no restart.
It is almost dynamic. No need to restart, but currently, you have to
switch between two folder to have "multiline" option taken into
account.
Actually, the integration in TB is not perfect (specialy about
"subject" column display and primary column selection).
> 5. moving the messagepane inline with the threadpane messages is
> interesting. moving major DOM nodes can be tricky, but of the 3 in Tb,
> messagepane is easiest and lowest impact.
> 6. don't forget the impact of Lightning - i've found it the only
> extension that is problematic with DOM node moves (threadpane and
> folderpane), but it doesn't seem you would need to touch those higher
> than their <deck> parent.
The modifications are not really intrusive. I've extended a lot
nsMsgDBView (and groupView), but I'm pretty sure Lightning will not be
impacted.
ovidiu
> Hi folks.
>
> I've made some works about the vertical view of Thunderbird (see bug
> 213945 from comment 26). Take a look at the last screenshots:
> http://www.mozbox.org/pub/tb/
>
of elements though:
-have it optional
-have also something like "quote collapse" (say activated by default for
this thread preview, even if not for the main view)
-have the attachments, if the case, like a drop down somewhere in the
header (small something ..) for an even quicker access to that part ..
and
-have some of it in TB3 ;)
> In addition, I'm interested in developing a way (a TreeBodyFrame hack
> too) to include the message content *in* the threadPane (see
> http://www.mozbox.org/pub/tb/inlineMsg.png , an early draft, but it
> seems to be faisable).
>
only one thing: is this [message preview and message inside thread] a
potential security issue? Hope not.
I just remember that some discussions in support group mentioned how the
message pane means actually opening a msg and how some prefer not to use
it but to open msg in a new window so that they can actually avoid
opening by accident certain ones. In this case msg will be kinda opened
by default ..
ovidiu
open the msg in a new window/tab
on the other hand, this readability makes me think of some more control
over the size of the elements in text and the size of the "message pane
inline with thread". Some resize handle for the vertical space assigned
to that would do.
Just thinking out loud ..
alta88
---On 2008.Mar.10 10:46 AM, Paul Rouget wrote:
>> 1. are you using <richlistitem> for the header info? with the
>> advancements in that widget in Fx (new urlbar autocomplete) this is
>> probably the way to go.
>
> No. It's a TreeBodyFrame (layout object wich displays object
> implementing nsITreeView) hack. It's very important to use a tree to
> display message list, for performance issues.
>
>
one downside, although worth it for performance, of custom tree views is
that styling <treechildren> currently is more difficult (mostly because
it's not available in DOMi). and people will, rightly, want to style
the multiline display.
i'm not familiar with TreeBodyFrame, but the thought was that
<richlistitem> would be the final 'leaf', and thus not negate any of the
performance advantage - but of course defer to your practical experience
with the code.
also, is it truly multiline or 2 lines? perhaps new creative displays
can be derived from multiline, so not limiting it to 2 lines
architecturally would be nice.
Ron K.
The treeChildren are actually easy to style in userChrome.css and I use
DOMi as an aid to ferret out the Selectors needed to apply font
changes. Also I use a disassembled copy of the default theme to see the
structure. The proposed JS modifying userChrome.js extension has been
wrapped into the Mail Tweak extension that is found as a sup-project of
the Journal extension at mozdev.org. With that extension installed a
user can gain access to additional selectors in the folder pane tree view.
Ron K.
> paul....@gmail.com wrote:
>> Hi folks.
>>
>>
>>
> only one thing: is this [message preview and message inside thread] a
> potential security issue? Hope not.
>
> I just remember that some discussions in support group mentioned how
> the message pane means actually opening a msg and how some prefer not
> to use it but to open msg in a new window so that they can actually
> avoid opening by accident certain ones. In this case msg will be kinda
> opened by default ..
>> Since such developments will require a lot of work and many
>> discussions (such patches are layout component related, it could
>> impact all Mozilla products), I really need to know if the way chosen
>> is the right way and if this is something that could interest you for
>> TB3.
>>
>>
Tb has a different security model than Outlook Express because the
attachments are shown in a separate view container and can not
auto-open. As for JS activation, the Tb default controls of JS are
tighter than Fx so some JS functions that run in Fx can not in Tb. The
support of Marquee is one example. When one adds the Unselect Message
extension (After hacking the MaxVersion) the auto opening of messages in
the view pane is stopped. The biggest advantage of the New Window view
is dropping of any 3 pane view preference when message content is HTML
designed for full screen viewing, or the use of the extension by Alta88
that adds a full screen view without the Tb chrome.
I think the only security issues are those that effect Tb as an
application. Stability conflicts are a separate issue and use by a
large body of testers is what keeps the "Known Conflicts" page at
MozillaZine updated.
Robert Kaiser
> Hi folks.
>
> I've made some works about the vertical view of Thunderbird (see bug
> 213945 from comment 26). Take a look at the last screenshots:
> http://www.mozbox.org/pub/tb/
>
> In addition, I'm interested in developing a way (a TreeBodyFrame hack
> too) to include the message content *in* the threadPane (see
> http://www.mozbox.org/pub/tb/inlineMsg.png , an early draft, but it
> seems to be faisable).
This both looks very promising to me for a mobile device, I for one
wouldn't want it in my usual desktop app though, where I can use screen
estate differently.
Robert Kaiser
alta88
sure, but none of that is 'easy' ;) even for a user beginning to look
into css and DOMi. the syntax for <treechildren> is different:
/* If this collapsed or expanded thread is selected, revert to highlight
text color */
#threadTree > treechildren::-moz-tree-cell-text(container, closed,
hasUnread, read, focus, selected),
treechildren::-moz-tree-cell-text(container, hasUnread, read, focus,
selected) {
color: HighlightText !important;
none of that is discoverable even with DOM, need to code dive, as you
said. yes, MailTweak's CSS Selector is very nice, but installing 2
extensions is a bit much. again, it's worth it for performance, but if
<richlistitem> works then the simpler route should be taken.
Paul Rouget
rich content must be embedded in a tree, and why I chose to enhance
the TreeBodyFrame rather using richlistbox. I've talked a bit wih Neil
Deakin who said he will work on a rich version of the tree immediately
after the FF3 release. I think we should consider this. If such
element is available before the TB3 release, my work could be
deprecated.
Dan Mosedale
>> Actually when I saw it I immediately thought about mobiles and smaller
>> devices. It's an interesting approach.
>
> Is there any effort or plan about Tb on mobiles devices ?
I'm not aware of any current plans in the direction, but that might well
be interesting in the longer term.
Dan