https://wiki.mozilla.org/api.php?action=feedcontributions&user=Mbear&feedformat=atomMozillaWiki - User contributions [en]2024-03-28T23:00:07ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=Talk:Firefox/4.0_Windows_Theme_Mockups&diff=158031Talk:Firefox/4.0 Windows Theme Mockups2009-07-28T16:10:41Z<p>Mbear: /* Tabs-on-top: yes or no */</p>
<hr />
<div>This theme looks beautiful. <br />
I have started using Chrome more frequently just for its very clean and light look. <br />
I am going to switch to full time use of Firefox as soon as 4 is released.<br />
I am hoping to see more screenshots, so that I/we can provide more specific feedback. <br />
Do not pay attention to the critics that call this a duplication of <br />
Chrome look. <br />
This is simple an evolution of a very nice user interface design originally <br />
promoted by Google. <br />
--[[User:Ebegoli|Ebegoli]] 22:12, 27 July 2009 (UTC)<br />
<br />
== Tabs-on-top: yes or no ==<br />
<br />
Personally i like tabs on top. Right, tabs on top might confuse some users ("Breaks Consistency/Familiarity - Moving things confuses existing users."). I've never developed a Firefox extension or theme (so some of my assumptions might be wrong or already implemented):<br />
<br />
1. Implement a mechanism so that every theme supports tabs-on-top and tabs-on-bottom modes (a new requirement for version 4.0 themes to support both modes). Add an option in the preferences pane (default to tabs-on-bottom).<br />
<br />
and/or<br />
<br />
2. Add an API to write reliable tabs-on-top themes. I know, there's an extension that places tabs on top. But the extension never worked reliably (at least for me): Moving the firefox window does not work when the title-bar is hidden, graphically glitches when used in combination with some themes... I don't know why the tabs-on-top-extension does not work correctly for me. Maybe there's no API to hide the window-title-bar and the extension is using a hack?<br />
<br />
---<br />
<br />
Tabs on top look beautiful, and it's the craze right now. After Chrome, even Safari has it. It will certainly look appealing to regular Firefox users. But being the craze is the problem. I suggest the design in Firefox 4.0 must be original. Copying old ideas is not anything different. We also want our Foxy to be the best and stand out from the crowd.<br />
<br />
---<br />
Tabbed browsing in Chromium is easier to pick up for novice users because of how the URL appears as belonging to each tab. For me it is much more common to see people spawning multiple single tabbed windows with both ie7+ and firefox because of this than in Chromium.<br />
This current layout of the user chrome was stablished by Opera waaaaaaay back when there where limited computing resources and ui-controls to choose from, and it should be ditched already.<br />
Also, notice that the bookmarks button from A version is missing in B version.<br />
--[[User:Ponzonik|Ponzonik]] 23:55, 27 July 2009 (UTC)<br />
<br />
<br />
How about '''address-bar-on-top'''? That way you'll give users more screen realestate without breaking consistency / familiarity. Further more, address bar needs less horizontal space and is less fragmented than tabs bar, so it might even look better than current proposal. --[[User:Karl3|Karl3]] 05:36, 28 July 2009 (UTC) <br />
<br />
--> I added this idea to my mockup further down on this page Karl. :D --[[User:Dipso|Dipso]] 10:53, 28 July 2009 (UTC)<br />
<br />
----<br />
>> That certainly sounds like an option. I say, making the effort to have both as an option might be the way to go, that way you don't risk alienating users who are used to the 'old way' while catering to new users and users who prefer the 'chrome' way. On a personal note; i like the chrome approach, i feel it makes the ui seem more "whole" and natural. --[[User:Dipso|Dipso]] 06:22, 28 July 2009 (UTC)<br />
<br />
----<br />
Please don't force Tabs-on-top on us users. I know quite a lot of people that have their tabs on the bottom of the window.<br />
It's such features that brought me to Firefox in the first place and I absolutely hate it, when "essential" features get removed (Windows Vista/7 anyone?) --[[User:Nifelan|Nifelan]] 10:18, 28 July 2009 (UTC)<br />
<br />
----<br />
Why can't this be configurable? Let users choose tabs on top or bottom as per their preference. But if I have to choose between one or the other, I'd certainly prefer bottom, as it is currently in 3.5. --[[User:Vpadiyar|Vpadiyar]] 11:21, 28 July 2009 (UTC)<br />
<br />
Personally, I think tabs-on-top would be bad; I'd hate it and it would mess up the way I'm used to using FF. However, I completely agree with Vpadiyar - why not make it configurable?<br />
<br />
----<br />
Why not make the menu bar and tab bar customizable like the toolbars already are? --[[User:Teohhanhui|Teohhanhui]] 12:32, 28 July 2009 (UTC)<br />
<br />
----<br />
I'm with Vpadiyar, make Tab Bar positioning configurable. I wouldn't want Tabs or the Awesome Bar in the title bar - maybe some buttons. Rather than a Chrome UI model I'd prefer an Office 2007 UI model, i.e. an "Orb" in the title bar to get at the menu bar functions. Again make it configurable probably via extensions/themes - FirefoxUI, ChromeUI, OfficeUI.<br />
----<br />
I like tabs-on-top, but I think it's critical that the tabs are flush with the top of the screen when FF is maximized. Based on the screenshots, the proposed "tabs on top" design appears to miss the boat by not honoring Fitts's Law: http://bit.ly/xNx44<br />
<br />
Arguably, the biggest advantage of "tabs on top" is that the height of each tab (button) is made effectively infinite -- and therefore an easy click target -- but only if the tabs are flush with the top of the screen. Google Chrome gets it right by taking full advantage of this precept. The FF4 screenshots shown here suggest that Mozilla's approach would leave several pixels of dead space between the tabs and the top of the screen.<br />
<br />
Of course, the clickable area of each tab doesn't have to be the same as its visual area. If the proposed design has the tabs terminating several pixels below the upper screen edge only VISUALLY (while being clickable all the way up to the very top of the screen), that's better than nothing. But it's still a poor choice because the user has to figure out the "secret" for themselves. -- Remiel 12:49, 28 July 2009 (UTC)<br />
----<br />
How about a tab acting as '''address bar and progress bar''' for that particular tab?<br />
What I mean is having address bar,progress bar and the title of the page on the tab itself.<br />
----<br />
Tabs on Top = NO.<br />
The thing that I would change in the mockups is to move the tools button lower to be on the same line with the tabs - and move the icon (thumbs - the one with 4 squares) in the left side of the tools button. In this way I would get rid of the title bar and optimize at maximum the space and still maintain Firefox feeling.--[[User:Andygongea|Andygongea]] 12:59, 28 July 2009 (UTC)<br />
<br />
>>> Pixelwiz 9:07 A.M. EST 08/28/2009<br />
I think whatever you end up doing, the tabs has to be a full horizontal line. I know me personally and many friends like to open up tons of tabs. Like when I search google, I control-click on every link on like the first 2 pages of results and let them all open in tabs, then go through the tabs to review, close the ones I don't need and keep open the ones I do. So the more space we have horizontally for tabs the better. And please have the ability to move a tab to create a new window like Chrome. I like the idea of moving the address bar up, since it's not used as often as the tabs are, at least in my opinion. Or even do what the iPhone does, only show it when the mouse is moved up there (have it as an option to hide it at least).<br />
I also like consolidating as many of controls as possible, I like the 2 button idea. Anything to simplify the UI, as long as there is still a way to do everything especially for expert users, so maybe hide an advanced/expert button somewhere. And the best idea is probably just to have a nice default, but to make more things customizable so that the user can set things up the way they prefer that suits their browsing habits.<br />
---<br />
----<br />
<br />
I vote no as the default. If you want to allow developers to create a new theme or extension that does this, great. More power to you. But as the default I think you'll annoy users too much. <br> <br />
<br />
There's actually a nice example of the problems with "tabs on top" in this Ars Technica review of [http://arstechnica.com/apple/news/2009/02/hands-on-safari-4-beta-fast-mixes-polish-rough-ui-edges.ars Safari 4 Beta]:<br> <br />
<blockquote>Apple has also redesigned Safari's UI on Mac OS X and especially on Windows, and the company clearly took a tab page (or three) from Google Chrome's book. "Tabs on Top" means exactly what it says: instead of your tabs pointing down towards the document, they point up, and live in the actual title bar area of the application.<br><br> The close buttons have been axed and drag handles have been added to the right of each tab. These handles tip users to the fact that tabs can indeed be dragged left or right, or even away from the tab bar to create new windows (a feature introduced in Safari 3). Note, though, that Apple now hides the handle-drag and tab-closing controls until mouseover. In addition to Safari's somewhat clunky ctrl/cmd-shift-brackets shortcuts for switching tabs, Firefox's ctrl-tab shortcut now works as well. Developer Sebastiaan de With has noted that, in the rush to move tabs above the window, Apple somehow forgot to include Safari's trademark in-address-bar progress bar. Oops.<br></blockquote><blockquote>This new tab UI also lends itself to some windowing confusion. While tabs are certainly more defined in a single window, stacking two windows (like we have above) can make it look like a tab in a background window has attached itself in a brain-slug-like fashion. Unfortunately, the Safari team appears to have found a new love for click-through behavior, as clicking a tab in a background Safari window will bring both that window and tab to the front. This can cause confusion in our example above, but figuring out a safe place to click amid the tiled windows in our example on the right can be even more difficult.<br> </blockquote> <br />
(I can't get the relevant images to appear here, but please look at them.)<br> <br />
<br />
And from a [http://arstechnica.com/apple/news/2009/06/safari-4-final-no-tabs-and-performance-updates-for-106.ars later article about Safari 4], a rationale for the "no tabs on top" default:<br> <br />
<blockquote>With the final version of Safari 4, Apple has changed both of these, opting for middle-ground compromises. On the tab situation, Apple has merely updated the visual appearance slightly and returned the tabs to their original home beneath the bookmarks bar. '''Many people find this arrangement much easier to digest, as it again draws a better distinction between the coordination needed to move the whole window or reorganize you tabs.''' (emphasis mine)</blockquote><br />
<br />
<br />
----<br />
I vote yes - since tabs separate pages, it seems logical to include all page specific elements within the area contained by the tab.<br />
--[[User:Mazz0|Mazz0]] 15:12, 28 July 2009 (UTC)<br />
<br />
----<br />
I like tabs on top - it makes sense to include the address bar etc. as part of the tab. It gives the tabs more prominence, and conserves screen real-estate - vital for netbook users like me. If Firefox made no changes to the user experience, so as not to rock-the-boat for existing users, we wouldn't have tabbed browsing in the first place. We need to move on with the times. --[[User:Chirimolla|Chirimolla]] 15:51, 28 July 2009 (UTC)<br />
<br />
== Progress on tabs instead? ==<br />
<br />
As i stated in the thread about 3.7 and 4.0, why not have the proposed progress indicator on the tabs instead? this makes a lot more sense if you open a new background tab, especially for a new user. <br />
<br />
----<br />
<br />
That's a great idea. As I mentioned in the previous section, the progress bar should be on tabs. But then the tab is not as long as the progress bar. i like the idea of the thin, colour changing progress bar mentioned in this article, but I suppose we must put the progress bar in the address bar, like in the older Safaris. The colour changing idea mustn't be waived though. <br />
<br />
----<br />
<br />
The original post i made: <br />
<br />
I noticed the addition of a progressbar under the awesomebar in the 4.0 mockup. Wouldn't it be much better to have progress show on the tabs them selves, that way if i open a lot of tabs at once i can instantly see what tabs are loading and how far along they are. I use tabmixplus for this currently and find it to be a really useful feature. <br />
<br />
The progressbar could be a thin one like suggested with the current mockup, or it could be the tab filling with color like the new taskbar in win7 (this way it keeps with the system scheme.) <br />
<br />
Just a thought. <br />
<br />
--[[User:Dipso|Dipso]] 23:43, 27 July 2009 (UTC) <br />
<br />
There's already a progress indicator and a stronger one would make for a really busy screen. --[[User:Ponzonik|Ponzonik]] 23:51, 27 July 2009 (UTC) <br />
<br />
I agree with Dipso. Maybe someone can suggest a better idea for how to do it with minimal clutter, but the idea is worth thinking about. <br />
<br />
--[[User:NoamNelke|NoamNelke]] 00:12, 28 July 2009 (UTC) <br />
<br />
<br> I use an extension called Fission that puts a safari style progress bar in the location / awesome bar itself. It shades the whole bar blue. It's very effective, reduces clutter and is a lot more obvious than the suggested progress indicator. <br />
<br />
--[[User:RoryOK|RoryOK]] 10:12, 28 July 2009 (UTC) <br />
<br />
----<br />
<br />
You can use tabmix plus to get progress bars on the tabs right now. Thats what i do, and i don't find it to busy, nor do i find the bar to small. In fact its realy helpful, especially if im on a slow connection or browsing slow sites. This way i can see in the corner of my eye when tabs are done loading, all the while reading the active tab. --[[User:Dipso|Dipso]] 09:48, 28 July 2009 (UTC) <br />
<br />
----<br />
<br />
Here is a quick and dirty mockup of a window with awsomebar and buttons on title area, and with an example of loading tab "windows 7 style". <br />
<br />
[[Image:Mockup-4-0-Vista-(Awsome Buttons Top TabProgress).png]]<br />
<br />
Obviously you could have the active tab load the same way, both for consistancy and aestetic, i just didn't bother doing it in the mockup :P.<br />
<br />
The idea of having the address bar at top is that when you use the tabs, you don't really look at the title bar to find out what is the current page anyways, you scan the tabs for the titles of the other pages you have open.<br />
<br />
--[[User:Dipso|Dipso]] 10:42, 28 July 2009 (UTC)<br />
<br />
----<br />
What about having the address bar double as a progress bar? It's long and wide enough. --[[User:Teohhanhui|Teohhanhui]] 12:35, 28 July 2009 (UTC)<br />
----<br />
It occurs to me that there isn't such a need for a progress bar these days, with internet speed making load time so short. In fact I think it kinda makes the loading time seem longer, /except/ for tabs other than the one you're looking it - then it makes you feel like it's getting somewhere. Perhaps some professional psychology study should be conducted to decide this, like all that stuff that was done about how quickly progress bars should start/accelerate/decelerate.<br />
<br />
Anyway, I definitely think you should see progress bars on tabs, so you can see how all the ones you've just opened are doing. But on the other hand, I do like that thin line, it looks nice. Wow, this was a very unhelpful comment, wasn't it?!<br />
--[[User:Mazz0|Mazz0]] 15:32, 28 July 2009 (UTC)<br />
<br />
== Menus ==<br />
<br />
I like the new designs, especially the Chrome-like one (Tabs-on-top), it seems more thought-through (perhaps because Google has).<br />
<br />
The part that I liked better about the first (tabs-on-bottom) design is the visual differentiation between controls that relate to the currently visible page (Page menu attached to the top-left corner of it) and controls that relate to the browser (Tools menu right under the close button).<br />
<br />
One possible usability issue is that people often don't know in which of the two menus an item is (often happens to me when using Chrome/IE). For that reason (among others) I think it's vital to keep the two menus next to each other (they are on opposite sides of the window in the first design).<br />
<br />
Aesthetically, I don't like the way the page menu is attached to the page.<br />
<br />
Here's an idea: Look at the second design (tabs-on-top). What if you removed the "tab background" from behind the Tools menu as if the corner of the tab was missing and the menu took up that space. Basically the button would stay where it is now, but it would no longer be on the tab, but on the window behind it.<br />
<br />
Here is a Photoshopped image I made to illustrate the idea:<br />
[[File:ffidea.png]]<br />
<br />
My idea creates some clutter, so I'm sure someone will come up with a cleaner solution, but I uploaded it anyway to give some food for thought.<br />
<br />
--[[User:NoamNelke|NoamNelke]] 00:12, 28 July 2009 (UTC)<br />
<br />
The first problem with master menu buttons like "Page" and "Tools" is that it is not clear what functions belong in which master menu.<br />
<br />
If the app can tolerate things like tabs in the top area, why not keep version A and put traditional menu items up next to the app icon and the title? That would conserve vertical space, use horizontal space that is currently blank, and maintain traditional dropdown menus.<br />
<br />
--[[User:ehume|ehume]] 2053, 2009-07-27 (EDT)<br />
<br />
--[[User:romanujan|romanujan]]<br />
<br />
Please, keep the menus where they are now. I use them from time to time and I am really confused if I cannot find them (Google Chrome, Internet Explorer 7.x, 8.x, etc.). The idea of windowing systems was, that all applications should look similarly and behave similarly - but if all applications will start experimenting with UI paradigms, then soon we will be back in the era of DOS or Commodore 64 when you had to spend considerable amount of time learning each application you wanted to use.<br />
<br />
----<br />
<br />
-> You could also place the tools button along with the tabs, i think that makes for a cleaner UI. --[[User:Dipso|Dipso]] 10:44, 28 July 2009 (UTC)<br />
<br />
== Combo buttons - pros and cons ==<br />
<br />
Positive effect could be easily seen - it saves some space for the button. But negative effects are, IMHO, much bigger:<br />
<br />
1. Sometimes you need both functions, but have access only to one of them. If we combine "Go" and "Refresh", user will loose ability to reload page if he/she occasionally entered something to the address bar.<br />
<br />
2. Switching buttons without user intervention may cause user to click wrong button, if it changed just before the click. If you combine "Stop" with "Refresh", user trying to stop a long-loading page could cause it to reload instead. I faced this problem in Opera quite often, so in my opinion it makes "Stop" button just too dangerous to use.<br />
<br />
----<br />
Hi, I like the idea of combo Buttons, when the negative effects are wiped out:<br />
<br />
1. This situation requires that the user typed something wholy different in the adress bar, not just a modification of the current adress (in the latter case, the go-button would be no difference to the (invisible) refresh-button).<br />
For this case, users of Opera have the option to hit ESC (or even STRG-Z) to revert the url to that of the page currently opened. In Firefox, the Go-Button should switch back to Refresh-Button immediately when ESC is pressed. And there is still the option to press F5 to reload the current page.<br />
<br />
2. I know and hate this problem from Opera and Iphones Safari as well. The myterious is that this happens _so_ _often_, that it can't be coincidence that the button always changes just in this 0.1 second between my brains decision to hit that button and my finger clicking the mouse.<br />
But this can be avoided if the button gets some intelligence:<br />
* If the mouse hovers the button, never change it (or wait two seconds, so it is clear the user likes to hover it but not to click it in this state)<br />
* After the disappearing progress bar indicated that the page is fully loaded, wait a second so that the user gets "warned" that the button will change and if he intended to click, he doesn't need anymore.<br />
<br />
dartrax<br />
<br />
: This problem is actually solved by the [http://userstyles.org/styles/2131 Smart Stop/Reload] extension. It disables the button for a little bit when the page fully loads. That way, you don’t have to worry about accidentally reloading the page when you want to stop it from loading. There’s a [https://bugzilla.mozilla.org/show_bug.cgi?id=343396 bug] about it, so I take it that, when Firefox finally gains a merged button, this improved behaviour will be integrated. —[[User:David Regev|David Regev]] 12:17, 28 July 2009 (UTC)<br />
<br />
== Is UI change really needed? ==<br />
<br />
Is there really a need to combine the refresh/go/stop buttons? Most people have plenty of horizontal space, and having separate single purpose buttons is a lot less confusing.<br />
<br />
Also, why ditch the menu bar? I use that all the time (and not just bookmarks). Saving that little bit of vertical space really isn't worth inconvenience. And when IE 7 first came out, I managed to convince several long time IE users to move to Firefox, in good part because Firefox looks more like a standard Windows app than IE 7 (or IE 8) does. <br />
<br />
Anyways, it seems odd to me to try and make Firefox looks more like Chrome or IE8. If I wanted a browser that looked like IE8 or Chrome, I would use IE8 or Chrome. Firefox is simply a better browser than either of those two, and should be careful about copying them.<br />
<br />
---<br />
<br />
I have to agree with the above. Although I would like to see the menu items up with the app icon, title and window controls, that is minor. More of concern is the absence of the Stop button. You don't miss it until you click on a link by mistake in Chrome and you find you cannot stop the process. If it is a page that loads slowly, you are just plain stuck until it loads.<br />
<br />
Then, of course, there is the complete absence of the bookmarks toolbar. Maybe you don't use it, but I do, all the time.<br />
<br />
Even worse is the absence of the searchbar. Again, maybe you don't use it, but the absence of a searchbar is the single thing that made me not wholly abandon Firefox before I discovered No-Script (for some of us, this extension speeds up Firefox navigation enormously). Because Chrome lacks a separate searchbar, you can't switch quickly, say, between Google, Amazon and Wikipedia, for example. Or even Microsoft Support Search. You are stuck with your default search engine and switching is a laborious process. The searchbar is so important to me that I move it to the menu bar, to give it plenty of room.<br />
<br />
Chrome and IE do not allow for much of a diversity in how people use those browsers. Firefox gives one much more flexibility. I see no reason to do a me-too UI just to follow Chrome. <br />
<br />
--[[User:ehume|ehume]] 2115, 2009-07-27 (EDT)<br />
<br />
<br />
Yes, I think the UI does need to be updated. Change is good. I quite like the mock-ups I have seen. There are a few things I'd like to see (as standard or options):<br />
<br />
The bookmarks tab being something that pops out. Hidden from view with perhaps just an icon that pops out when you roll over. I have bookmarked a number of folders and it would be great to see more screen and less clutter but still retain one click access.<br />
<br />
I've always wondered why the address bar has to be at the top of the browser? I guess it's like a header and seems logical to put it at the top of the window but it could be more practical to have it at the bottom of the page as when you are reading a page, your cursor is more likely to be at the bottom of the screen than the top. Perhaps too big a shift for many but would be good to see some mock ups or have it as an option.<br />
<br />
Prefer the shots without the Windows title bar - looks much smarter.<br />
<br />
Great to have the URL/address bar and search blended into one.<br />
<br />
--[[User:romanujan|romanujan]]<br />
<br />
I do not think the UI revolution is necessary - current UI, with tabs, is an effect of years of evolution. It is convenient, people got used to it. You can put tabs above the menu, but what's the purpose of such modification? I think this is just a mater of taste.<br />
<br />
Moreover, if you start experimenting - well, possibly you will have some good ideas, but for certain some of them will be totally wrong. Most users (especially those, who do not use every single option the browser provides) will only get confused. If you plan some revolution - please, give us an option to use old-style interface in Firefox 3.7 or 4.x.<br />
<br />
== New section ==<br />
<br />
The Menu area which contains File Edit History Bookmarks Tools Help is extremely important to me. Please do not remove this very important part of the menu bar. <br />
<br />
Please do not make any changes at all to the menu system. Firefox has a loyal customer base and your market share is huge. The ease of use and familiarity is why your market share continues to grow.<br />
<br />
Do not copy the IE8 menu system, if you do than there is no compelling reason to use Firefox.<br />
<br />
== For locating tabs on the side of the browser ==<br />
<br />
Personally, I use the Tree Style Tab plug-in in FF, which allows to :<br />
1. open my tabs on the browser side (in my case, the right side)<br />
2. open and be able to see more tabs than with any top location<br />
3. manually set the tabs width, in order to be able to read more easily their titles<br />
4. accessorily, to group my tabs hierarchically.<br />
<br />
I consider that this location takes advantage of today's 16:9 format screens, which allow to gain some useful room vertically while keeping enough room hozizontally. There is no longer any reason to design a browser according to former 4:3 screens. By the way, my Windows' taskbar is also positionned on the side. Also, the look of the browser window seems more tidy (then simplified), since there are less bars at the top of the screen.<br />
<br />
In addition to being more convenient and relevant according to screens evolution, that option would be more creative than just copying Google Chrome.<br />
<br />
HTH<br />
<br />
Philippe<br />
:I aggree with that. Most website have a vertical design, and much blank space around the layout. Using this space should be smart. --[[User:Antwan|Antwan]] 09:41, 28 July 2009 (UTC)<br />
<br />
Got to disagree with the assertion that "There is no longer any reason to design a browser according to former 4:3 screens". In my experience, the majority of users still have 4:3 monitors.<br />
--[[User:Mazz0|Mazz0]] 14:59, 28 July 2009 (UTC)<br />
<br />
== Change and brainstorming is not a matter of copy ! ==<br />
Stop to try to match Chrome design. This is obviously '''not''' a model. To release 3 screenshots only for a "woah"-effect is pathetic. I am disapointed by the team which did that, this does not reflect the quality of Mozilla streamline.<br />
<br />
- What are the differences beetween 3.7 and 4.0 ?<br />
<br />
- Don't you find sketches would be better to focus on usability, instead of a Chrome-copy screenshots? Now this is relayed by many media, and misunderstood.<br />
<br />
- Glass everywhere, especially on tabs, is too much.<br />
<br />
- Keep focused on OS integration : Do not remove menu bar on XP. All XP application handles menubar. It would look weird to remove it.<br />
<br />
- Page/Tool buttons are so IE/Chrome. Again : this is not a model, there are other ways to organize command. Think at it !<br />
--[[User:Antwan|Antwan]] 09:41, 28 July 2009 (UTC)<br />
<br />
== Keep Search Bar ==<br />
<br />
I really like the mockups but I have one serious issue with them: the search bar is missing. The main reason I don't use chrome is the lack of search bar. I have a number of reasons for this.<br />
<br />
First not having a search bar makes it difficult to switch your search engine on the go. I switch between google and wikipedia probably 10 times a day. In chrome I'd have to go to options which is a huge headache.<br />
<br />
Second combining search into the address bar is a risk to privacy. The bar has little to no way of figuring out whether I want a search, go to a url or visit a previously visited page. In order to have on the fly search suggestions, Firefox will need to call the search engine even when I don't want to make a search.<br />
<br />
Third the purpose of the address box becomes muddled. Now I either visit a url or a previously visited page. Either way I'm going directly to the end result of my navigation. When I search though, I'm not going to the end result directly; I'm going to a page with suggestions of where my end result might be. I think its more natural for usability purposes to have separate boxes for separate purposes. --[[User:Wwahammy|Wwahammy]] 14:39, 28 July 2009 (UTC)<br />
<br />
If they're making it Chrome-like (and I'm not saying they should, I haven't made my mind up, but my initial inclination is towards fewer controls. The awesome bar is there to get you where you want to go - you already use it to search your history and bookmarks - that's not going directly to the end result) then you don't need to change your search provider in options - you click in the address bar and type something (eg g for google, w for wikipedia) then tab then enter your search term.--[[User:Mazz0|Mazz0]] 14:50, 28 July 2009 (UTC)<br />
<br />
== Title in Awesomebar ==<br />
<br />
Why not display the page title instead of the URL in the awesomebar except when the user clicks in it?--[[User:Mazz0|Mazz0]] 14:54, 28 July 2009 (UTC)<br />
<br />
== Page transition effects ==<br />
<br />
And can we have a nice effect while a page is loading? Like fade the old page to white, maybe display some sort of progress bar/activity indicator in the centre of the page, like with java or flash apps, then fade into the new page?</div>Mbearhttps://wiki.mozilla.org/index.php?title=User:Mbear&diff=104158User:Mbear2008-08-14T15:07:32Z<p>Mbear: Created personal page.</p>
<hr />
<div>Personal website: [http://www.towerofjade.com/ http://www.towerofjade.com/] --[[User:Mbear|mbear]] 15:07, 14 August 2008 (UTC)</div>Mbearhttps://wiki.mozilla.org/index.php?title=Calendar_Talk:Feature_Implementations:Emailing_Events&diff=104157Calendar Talk:Feature Implementations:Emailing Events2008-08-14T15:05:53Z<p>Mbear: corrected incorrect formatting, added signature.</p>
<hr />
<div>''I didn't know where else to put this information, so here it is. You may already know about it, but it never hurts to make sure.--[[User:Mbear|mbear]] 15:05, 14 August 2008 (UTC)''<br />
<br />
IBM's [http://www.research.ibm.com/remail/ ReMail project] has some nice ideas for combining email and calendaring functions. The [http://domino.research.ibm.com/cambridge/research.nsf/2b4f81291401771785256976004a8d13/d9a38d8e3230f3a585256daa005d86a7?OpenDocument Identifying and Understanding Dates and Times in Email] paper in particular has some information you may find very useful.<br />
<br />
== UI/scheduling dialog box concepts==<br />
''From [http://www.research.ibm.com/remail/calendar.html http://www.research.ibm.com/remail/calendar.html]''<br />
=== Calendar ===<br />
Calendars are important organizational tools. A calendar integration with email provides convenience to users, as email often contains information about times and dates. The Remail prototype allows people to easily move messages onto their calendar as reminders or events. Clicking and dragging any message to the calendar brings up a scheduling dialog box. If the item was dropped onto the day of the event in the calendar's at-a-glance month view, the dialog box is filled in as a "reminder" type entry for that day. If the item was dropped on a particular hour in the calendar's at-a-glace day view, the dialog box is filled in with the start time and date of the event. The message in the in-box is marked with a calendar icon, and clicking on this icon makes that day appear on the calendar. Remail also detects dates and times in the body of an email message and allows people to use this information to prefill the scheduling dialog automatically.</div>Mbearhttps://wiki.mozilla.org/index.php?title=Calendar_Talk:Feature_Implementations:Emailing_Events&diff=104156Calendar Talk:Feature Implementations:Emailing Events2008-08-14T15:04:46Z<p>Mbear: </p>
<hr />
<div>''I didn't know where else to put this information, so here it is. You may already know about it, but it never hurts to make sure.''<br />
<br />
IBM's [http://www.research.ibm.com/remail/ ReMail project] has some nice ideas for combining email and calendaring functions. The [http://domino.research.ibm.com/cambridge/research.nsf/2b4f81291401771785256976004a8d13/d9a38d8e3230f3a585256daa005d86a7?OpenDocument Identifying and Understanding Dates and Times in Email] paper in particular has some information you may find very useful.<br />
<br />
<br />
== UI/scheduling dialog box concepts==<br />
''From [http://www.research.ibm.com/remail/calendar.html http://www.research.ibm.com/remail/calendar.html]''<br />
=== Calendar ===<br />
Calendars are important organizational tools. A calendar integration with email provides convenience to users, as email often contains information about times and dates. The Remail prototype allows people to easily move messages onto their calendar as reminders or events. Clicking and dragging any message to the calendar brings up a scheduling dialog box. If the item was dropped onto the day of the event in the calendar's at-a-glance month view, the dialog box is filled in as a "reminder" type entry for that day. If the item was dropped on a particular hour in the calendar's at-a-glace day view, the dialog box is filled in with the start time and date of the event. The message in the in-box is marked with a calendar icon, and clicking on this icon makes that day appear on the calendar. Remail also detects dates and times in the body of an email message and allows people to use this information to prefill the scheduling dialog automatically.</div>Mbearhttps://wiki.mozilla.org/index.php?title=Calendar_Talk:Feature_Implementations:Emailing_Events&diff=104155Calendar Talk:Feature Implementations:Emailing Events2008-08-14T15:02:32Z<p>Mbear: Added information regarding IBM Research ReMail project.</p>
<hr />
<div>''I didn't know where else to put this information, so here it is. You may already know about it, but it never hurts to make sure.''<br />
<br />
IBM's [http://www.research.ibm.com/remail/ ReMail project] has some nice ideas for combining email and calendaring functions. The [http://domino.research.ibm.com/cambridge/research.nsf/2b4f81291401771785256976004a8d13/d9a38d8e3230f3a585256daa005d86a7?OpenDocument Identifying and Understanding Dates and Times in Email] <br />
paper in particular has some information you may find very useful.<br />
<br />
<br />
== UI/scheduling dialog box concepts==<br />
''From [http://www.research.ibm.com/remail/calendar.html http://www.research.ibm.com/remail/calendar.html]''<br />
=== Calendar ===<br />
Calendars are important organizational tools. A calendar integration with email provides convenience to users, as email often contains information about times and dates. The Remail prototype allows people to easily move messages onto their calendar as reminders or events. Clicking and dragging any message to the calendar brings up a scheduling dialog box. If the item was dropped onto the day of the event in the calendar's at-a-glance month view, the dialog box is filled in as a "reminder" type entry for that day. If the item was dropped on a particular hour in the calendar's at-a-glace day view, the dialog box is filled in with the start time and date of the event. The message in the in-box is marked with a calendar icon, and clicking on this icon makes that day appear on the calendar. Remail also detects dates and times in the body of an email message and allows people to use this information to prefill the scheduling dialog automatically.</div>Mbear