Wishes for TB 3+
Frank Winkler
IMO, the two major weak point of TB are the address book and the NNTP
client. I'm wondering if there will be relevant changes in TB 3 and if not,
whether it's already too late to think about them.
Concerning the address book, I instantly recall:
- addresses are teated case-sensitive, so "joe....@foo.com" and
"Joe....@Foo.COM" are different things
- there should be something like an "exclude list" (and/or "alias list")
to prevent items looking different but meaning the same occurring over
and over again
- items are stored in "collected addresses" even if they were pulled from
LDAP ==> multiple copies and orphans when LDAP changes
For the news client:
- no way to re-sort subscribed groups
- the ancient PMINews had a cool tab system to organize groups
- I'd like to see a tool for watching a thread
- is it really necessary to distinguish news accounts in the same way
as mail accounts? (OMInews just shows groups, no matter what server they
were subscribed from)
- unsubscribing doesn't delete index files
That's just a quick overview ...
Regards
fw
Wayne Mery
Bugzilla is one place to look for answers.
two simple queries in these two areas reveals approximately
- the fixes already in TB3 http://tinyurl.com/5nm77s
- bugs actively being worked http://tinyurl.com/627bs6
(as defined by changed since 2008-03-01)
Another place to look is Rumbling Edge, for example
http://weblogs.mozillazine.org/rumblingedge/archives/2008/01/much_anticipated_trunk_news.html
Joshua Cranmer
> Hi there !
>
> IMO, the two major weak point of TB are the address book and the NNTP
> client. I'm wondering if there will be relevant changes in TB 3 and if
> not, whether it's already too late to think about them.
>
> Concerning the address book, I instantly recall:
> from
> LDAP ==> multiple copies and orphans when LDAP changes
TB 3, I don't know.
> For the news client:
> - I'd like to see a tool for watching a thread
Those are the only problems with news you had? ;-)
Leni
> - items are stored in "collected addresses" even if they were
pulled from
> LDAP ==> multiple copies and orphans when LDAP changes
You can vote for it to be fixed:
https://bugzilla.mozilla.org/show_bug.cgi?id=58769
Like you, I would love to see this fixed. It must be creating a giant
maintenance headache because it is silently duplicating data in millions
of addressbooks. It duplicates the contacts in any non-PAB addressbook
(not just LDAP).
Leni.
Robert Kaiser
> - no way to re-sort subscribed groups
Already solved on trunk nightlies (and Shredder Alpha 1)
Robert Kaiser
Nelson Bolyard
Really? What is that solution?
Robert Kaiser
Drag-and-drop-reordering of newsgroups.
Robert Kaiser
Ron K.
One of the nice improvements that also permits D&D of accounts too.
Essentially eliminating the need for the Folderpane Tools extension.
--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported Major Error used BSOD to msg the enemy!
Robert Kaiser
> One of the nice improvements that also permits D&D of accounts too.
> Essentially eliminating the need for the Folderpane Tools extension.
Erm, we don't have that yet, AFAIK (at least not SeaMonkey, but think
Thunderbird as well).
We currently can drag-and-drop-reorder newsgroups or folders within an
account, but not accounts themselves.
Robert Kaiser
Ron K.
My bad. I retested and only the groups were sortable.
Nelson Bolyard
Cool. Who knew?
I do wish that nightlies came with a file of brief descriptions of cool
new features, and of changes that are likely to break something.
Sometimes regressions are more livable if one's expectations have been
managed.
Eric Valette
> Hi there !
>
> IMO, the two major weak point of TB are the address book and the NNTP
> client. I'm wondering if there will be relevant changes in TB 3 and if
> not, whether it's already too late to think about them.
If it is already Christmas time, I would like the thunderbird imap
implementation and the imap extension for MS exchange to better cooperate:
- sometimes my imap messages that are still on the server are truncated
especially when they contain picture or attachment (not so frequent.
Size increase frequency). If I use exchange webmail interface (or
outlook when on windows (almost never)), the message are not corrupted
- forwarding message with attachment means recipient will get corrupted
attachment (nearly always when size is > 1mb).
I'm rather sure this is not a TB problem but rather misbehavior of the
exchnage imap implementation but it is nevertheless very annoying.
If someones has patches to apply on exchange server, that is nice too
but we are a very large organization (>200K) and linux is only for
bizarre R&D people so the chance to have the fix in place are low ;-)
-- eric
Arvind Venkataramani
> Frank Winkler wrote:
>> Hi there !
>>
>> IMO, the two major weak point of TB are the address book and the NNTP
>> client. I'm wondering if there will be relevant changes in TB 3 and if
>> not, whether it's already too late to think about them.
>
hi all,
<ot>
i'm new to the community, and this is my first post, so i thought i'd
introduce myself. i'm a design researcher at a firm called sonic rim
(http://sonicrim.com), but i originally trained as an interface
designer/user researcher. i'm hoping to help out with the TB3 User
Experience development and testing. more about me at
http://sensemaya.org. i beg forgiveness in advance if i speak without
sufficient knowledge about how the tb3 development community works, and
i'm happy to be corrected and taught.
</ot>
eric & frank, these are great suggestions, and thanks for bringing them
to our notice. now, i believe the community's default place for feature
suggestions has been bugzilla. i also presume that not all of the
feature requests get implemented, and there's considerable duplication.
i also understand that sometimes a feature request is an interface
design request, and sometimes it's a backend functionality request, and
the mapping between features and development modules is not always 1:1.
is there some 'official' place where user needs that are included in the
next development release are recorded/tracked? i suppose these would be
a subset of the feature requests/ideas on bugzilla, and would have
corresponding items in bugzilla (but not necessarily). what i'd like to
see is some place where there are user interface specifications,
storyboards, scenarios, that are distinct from the bugzilla item. these
would perhaps be selected based on community voting (priority or flags?)
and then spec'd out by the user experience team.
i'm proposing/inquiring about this because i believe describing feature
requests in these standard (visual) formats makes (in my experience)
them clearer to all parties. it also acts as a way for a user experience
designer to combine related requests/features into cohesive experiences,
and avoid duplication of efforts.
there might already standard formats for and/or documentation of user
needs, in which case i'm happy to be pointed to them.
--
arvind
Joshua Cranmer
> is there some 'official' place where user needs that are included in the
> next development release are recorded/tracked? i suppose these would be
> a subset of the feature requests/ideas on bugzilla, and would have
> corresponding items in bugzilla (but not necessarily). what i'd like to
> see is some place where there are user interface specifications,
> storyboards, scenarios, that are distinct from the bugzilla item. these
> would perhaps be selected based on community voting (priority or flags?)
> and then spec'd out by the user experience team.
We primarily use Bugzilla for feature requests and are currently in the
process of aggressive QA'ing to make up for the lack of focus on
Thunderbird over the past several years. Outside of Bugzilla, UX is
generally tracked over IRC, personal blogs, or private email
communications with the UX team.
Bryan Clark
what you are asking for. Here's how I view everything that's going on.
The newsgroup mozilla.wishlist gathers user suggestions, however they
rarely see the light of day. JoeS was doing something I thought really
great when he brought up individual suggestions to this list for some
debate. A next step from that could be moving that discussion into a
place where concrete ideas and plans can be written.
There is also mozilla.feedback.thunderbird where user feedback responses
are gathered. A similar approach of taking common feedback responses
and bringing them to the dev list for discussion might be an interesting
weekly exercise.
You've hit the nail on the head with bugzilla. The frustrating part of
feature requests is when they are focused on the engineering goals and
not the effect those engineering changes have on the people using
thunderbird. Most feature requests need some kind of companion
documentation to help run though some kind of design process.
The only place I'm aware of where some kind of design process happens is
on the dev wiki [1]. If you look at the Planning page [2] you'll see
the different goals we've set out which are based on user feedback and
direction we feel needs to be achieved. It is lacking some decent
organization so suggestions and elbow grease are welcome. Many of the
sub-projects described in the goals have some progress started, but are
lacking pages that would adequately convey progress to a reader.
It would be nice to have some kind of guideline for how to use all these
information sources together, in phases or whatever system is optimal.
Not hard rules, but more design process steps that could be followed,
especially pertaining to the larger goals ahead.
Cheers,
~ Bryan
[1] http://wiki.mozilla.org/
[2] http://wiki.mozilla.org/Thunderbird:Thunderbird3