Closed Bug 597971 Opened 12 years ago Closed 12 years ago
For consistency show "progress line indicator" also or just on the front tab
It is quite strange that after switching a tab I need to look at some other place to see whether the tab is still loading.
Yes, visually jarring. Perhaps if there is more than 1 tab, the progress line is shown on the top of all tabs, as well as in the location bar of the selected tab?
Another side effect of the progress line being too thin, in my opinion. If it was covering the height of the URL bar, there would be no way to miss it.
See bug 578028 comment 6 - 11 for prior discussion on this topic.
Hardware: x86 → All
Version: unspecified → Trunk
As far as i'm concerned i would prefer having only one kind of indicator : the progress bar on top of tabs (as long as tabs are displayed) Of course if the tab bar is not shown (only one tab and "Always show the tab bar" unticked) the indicator should move to the url bar Having the progress bar on tabs for background tabs and on url bar for foreground tab leads to useless complexity from my user point of view The "anything page-related is in Location Bar" argument seems a little bit too intellectual and doesn't reflect my user feeling FWIW Robert O'Callahan seems to agree with that (see http://margaret.mit.edu/2010/09/a-month-at-mozilla/#comment-66 ) Anyway the progress bar should be at least on foreground tab and eventually also in Location Bar (if needed)
I find myself looking at the top of the tab for a progress line (PL), but can't find any. I shouldn't need to look up and down depending on what tab is loading. The PL under the URL bar looks misplaced, and it is too thing to actually see where the progress is. Especially on Windows 7 where the default theme is blue and where the PL line is almost the same color. I guess the color could be fixed, but it doesn't fix the fact that I look at the wrong place every time a tab is loading.
(In reply to comment #5) > The PL under the URL bar looks misplaced, and it is too thing to actually see > where the progress is. Especially on Windows 7 where the default theme is blue > and where the PL line is almost the same color. I guess the color could be > fixed, but it doesn't fix the fact that I look at the wrong place every time a > tab is loading. On XP, it's grey. Almost invisible under the Silver color scheme.
Just to add my voice to the choir, I strongly agree with this bug. The PL under the location bar is visually difficult to pick up and imposes a lot of eye-strain when switching between tabs. Further, it breaks the visual paradigm of always looking at the tab itself to determine its status. Now, I have to remember that when the tab I'm looking at is active, I need to look *back* at the location bar to find the information I was seeking in the first place. Add to that the fact that the PL is very thin and the net result is a great deal of frustration on my part. I can understand the arguments for moving it to the location bar for the active tab, which is why I would propose that we have a configuration setting for this. It seems that this feature has divided people into three rather vocal camps: one which wants the PL for the active tab to be in the location bar and not in the tab (the current implementation), one which wants the PL exclusively in the tabs regardless of activeness, and one which wants the PL in both places. This seems to divide nicely into a three-state config option.
Blocking for decision; Shorlander, we need to figure out what to do here. I agree that it's a little odd that the bar moves places, but perhaps making it thicker (bug 597968) will end up being the solution.
Assignee: nobody → shorlander
blocking2.0: ? → betaN+
(In reply to comment #8) > Blocking for decision; Shorlander, we need to figure out what to do here. I > agree that it's a little odd that the bar moves places, but perhaps making it > thicker (bug 597968) will end up being the solution. I would like to get bug 597592 fixed before reaching a final decision since I feel it largely alleviates a lot of the issues with visibility. I have been experimenting with a few different approaches in addition to trying to address visual problems with the "line" treatment. I don't know that increasing the size of the line is going to really fix the disjointed feeling of having the indicator shift on tab switch. It also creates more problems with UI overlap and the larger you make it the stranger it tends to look. One of the reasons for making it a line initially was to keep it subtle. Background tabs in particular don't have to be screaming for attention with regards to progress but you should be able to glance at them and see if it is complete and if not how close to being complete it is. I think if the line isn't working the best approach would be to use the whole height of the tab and/or url bar. The solution might also be to just use the tab and not the url bar for progress because it is pretty jarring to have it shift on tab switch. The url bar is also quite busy as it is. I have some design ideas I am working on. I will make a newsgroup post.
(In reply to comment #7) Your arguments against putting the current PL in the location bar instead of the tab were basically in line what I already said before it was done. (comment 3 -> bug 578028 comment 6 - 11) (In reply to comment #9) > I don't know that increasing the size of the line is going to really fix > the disjointed feeling of having the indicator shift on tab switch. > The solution might also be to just use the tab and not the url bar > for progress because it is pretty jarring to have it > shift on tab switch. The url bar is also quite busy as it is. That was my primary argument against putting the PL in the location bar. It breaks the metaphor of tab folders layered together, with the user selecting the topmost. Switch through tabs and the PL moves; tabs aren't consistent. The only way to make things consistent is to, well, make things consistent and always have the PL in the same place for all tabs, including the current one. The location bar PL is frankly too big for what it needs to do anyway, so just having it on the top of the current tab is best. > I think if the line isn't working the best approach would be > to use the whole height of the tab and/or url bar. I've used progress bars which go behind text and they're really disorienting if you ever have to look at the text. Please, whatever solution is decided upon, do not have a full height of tab/bar sized progress indicator that has to be behind any text. The color has to adapt to the background as progress goes and it's distracting even if the text color remains constant. The simple thin progress line was a wonderful idea, and it works great on tabs tops. > One of the reasons for making it a line initially was to keep it subtle. If it's going to be a per-tab progress bar, as a thin line it is best. Simple==best.
The more I use current Minefield the more I don't like the current setup. I was swayed by the idea of having it be "more noticeable" for the current tab, but in practice it just isn't. When I switch to a loading tab, I loose the PL and have to look at a different spot with a big wide thing that sorta blends into things in comparison to the tab PLs. To expand on one big problem I'm noticing: the location bar is bigger than a tab. For me sitting at my laptop, I can glance at a tab PL and see the whole thing, whereas for the location bar I have to widen my focus to see this big overly long progress bar. The fact that I have my window maximized makes the current tab PL have a higher cognitive load to check.
Summary: For consistency show "progress line indicator" also in the front tab → For consistency show "progress line indicator" also or just on the front tab
It looks like bug 602964 is going to replace all PLs with a new better favicon multi-state indicator. From the initial mockups and discussion, it looks like this will fix most concerns with the new loading indicators and even has suggestions for a replacement for the status bar text. Simpler==better. :)
Indeed, bug 602964 makes this invalid.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.