228586 - Tree View in "Add Bookmark" dialog is too small.

Status: RESOLVED INVALID

(Firefox :: Bookmarks & History, enhancement)

Description

[Kevin Ar18]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031215 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031215 Firebird/0.7+

The current tree view in the "Add Bookmark" dialog is limited to 6 lines.  This
is a pretty small amount of space, for something as complex as a tree view.  To
truly use the tree view effectively, we need to show more lines.

How many lines?  I do not know.  Internet Explorer shows 10.  However, what
factor we should use to determine how many lines to show as default, I am not sure.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[José Jeria]

The dialog is resizable...

Comment 2

[Kevin Ar18]

Ah... I see... and it even remembers the size after closing it -- good.

Still would you think it a good idea to at least increase it's size by a few
more lines as the default?

Comment 3

[Casey Weston]

You dont want the window too large.  You want it to be elegant and non-intrusive
on your web browsing experience.  Plus, the average and beginning user does not
have that many folders to begin with.  If you dont like it you can resize it and
it will save your size, and you wont have a problem again.  I don't see this as
a problem.

Comment 4

[José Jeria]

The only problem that I see is that average users dont get that you can resize 
this dialog, I mean, how could you? Usually when something is draggable you 
see it on the bottom right. 

Comment 5

[Kevin Ar18]

Hmm, nice clean look vs too much information....  I can understand a little bit
of where you are coming from.  However, I don't think that it would hurt the
non-intrusiveness of the dialog to expand it.  Since the tree view is not
expanded when you first use Firebird, that is one plus for it being
non-intrusive.  Second, people who want the tree view will probably want the
wealth of information it can provide.  In that respect, here was my reasoning:
The purpose of the tree view was for the wealth of information it provides.  It
allows the user to quickly see the organization of their bookmarks and find the
right folder quickly.  The drop down method, on the other hand, is somewhat
limiting when you are trying to put your bookmark in the right spot. 
Considering that the tree view is used for such organizational purposes, I see
limiting the number of lines as counterproductive.  (You need more space so you
can see everything -- that's one reason the drop down was so limiting.)

On another note, José Jeria also brought out a good point in that a number of
people will not even think about resizing it.  Perhaps someone could file
another bug/enhancement report: "Add resize control widget to Add Bookmark dialog."

Comment 6

[Mike Connor [:mconnor]]

Adding a resizer widget wouldn't look right for a dialog, and besides that every
single dialog in Firebird (excepting alerts/confirmation dialogs) is already
resizable.

However, the usability with 8-10 lines is greater within a treeview, so I'll
confirm this for pch's review

Comment 7

[(not currently active) Ted Mielczarek]

*** Bug 251007 has been marked as a duplicate of this bug. ***

Comment 8

[Mike Connor [:mconnor]]

*** Bug 251007 has been marked as a duplicate of this bug. ***

Comment 9

[Fareed Rizkalla]

well i resized and there was a problem

some space started appearing between the tree view list

Comment 10

[Jesse Ruderman]

Fareed: that's bug 233759.

Comment 11

[Asa Dotzler [:asa]]

I think this is just the right height. It's roughly equivalent to IE's add tree
and if you need more, open the bookmarks sidebar or bookmarks manager and add
there. recommend wontfix.

Comment 12

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change

Comment 13

[Marco Bonardo [:mak]]

actually the treeview is about 8 lines, and the dialog changed completely so i'm marking invalid (though i second Asa's idea to wontfix), if this is still an issue for anyone a new bug specific to places implementation should be filed.