404.11 KB, image/png
1.99 KB, patch
|Details | Diff | Splinter Review|
11.15 KB, patch
|Details | Diff | Splinter Review|
2.28 KB, patch
|Details | Diff | Splinter Review|
Tabs on the left take way too much space from the content on tablet, and I couldn't figure out how to hide the tabs. (This is my immediate first-run user experience)
Madhava, Brian - Can we discuss a way to hide or shrink the sidebar? I can think of lots of cases where this will be desired, such as games. (Eventually we will have a full-screen API that some games will use, but I think we'll still want a way to hide the tab thumbnails sometimes.)
(In reply to Matt Brubeck (:mbrubeck) from comment #1) > Madhava, Brian - Can we discuss a way to hide or shrink the sidebar? I can > think of lots of cases where this will be desired, such as games. > (Eventually we will have a full-screen API that some games will use, but I > think we'll still want a way to hide the tab thumbnails sometimes.) Some web apps already have a sidebar (like Google Reader, tt-rss, GMail, Zimbra, etc.) and having our sidebar and the app sidebar might leave not a lot of space for the actual content. In general, I wonder why we want to have the sidebar always visible? IIRC, desktop users have around 2 and 3 tabs opened in average and I believe mobile users very likely have less than that. Is that really useful to have the sidebar always visible for that? I'm not a UX guy at all but my feeling is that for most users having the sidebar always visible will most of the time be a burden more than a help. Couldn't we get the previous behavior of the sidebar but allow the user to lock it if wanted? (like with a long pressure maybe?)
quickest fix I've encountered so far is to flip to portrait view - I must say I do dig the tree-style tab preview, but auto-hide tabs would be nice to have. All release channels seem to boot up lightening fast ( >5s) overall is a great experience so far (day 2 of using the Samsung 10.1)
Matt, can we try enabling a similar interaction to our phone browser, where you slide the tabs in and out from the left?
(In reply to Ian Barlow from comment #4) > Matt, can we try enabling a similar interaction to our phone browser, where > you slide the tabs in and out from the left? In the phone UI, we slide the browser partly off-screen when the sidebar appears. But in the tablet UI, we shrink the browser to make room for the sidebar. So sliding the tabs away would make the browser resize. We can try this, but the interaction might be a little weird... Let's experiment with it.
Here is my experience with the new tab bar: I like it. But as mentioned in this bug, I already wished I could make it disappear an several occasions. And there's another aspect that is starting to bother me: I usually don't have more than 2 or 3 tabs opened, which leaves a whole lot of black on the screen... As a side note, the screenshot updating seems to make the UI feel slightly sluggish.
Created attachment 560581 [details] [diff] [review] WIP This work-in-progress patch works by making the "tabs" button visible in both portrait and landscape; in landscape mode it toggles the sidebar. This patch applies on top of the patch from bug 685839. We'll probably want a different icon for this button when the sidebar is visible, and it should be styled similar to the new portrait "curvy" tab button (bug 685285).
Just a comment as someone who uses the current "phone" version of Firefox Mobile on my tablet, and really likes the fact that it give me a full screen browsing experience. Please consider the value of the full screen browsing experience before losing it in favor of a "fancier" interface.
My first-run user experience was like smaug's. I wanted to make the tab bar go away in the landscape mode, but couldn't figure out how. Honeycomb keeps it's own button bar at the bottom of the screen at all times. It's also possible for apps to add a button to the bottom bar. I suggest hiding the tab bar and the location bar when browsing and having a button in Honeycomb's bottom bar for showing Firefox's tab bar and location bar. In this scenario, it would make sense to make both the tab bar and the location bar horizontal and stack them at the bottom of the screen to put them near the button for showing them.
Created attachment 560988 [details] Mockup of tab interaction Hi all, here is my proposed solution for opening and closing tabs on fennecomb. As you can see in the mockups, the default state is to have the tabs open. Users can dismiss the tab bar by swiping left anywhere within the tab bar, or within 15-20px to the right. This should minimize inadvertently closing the menu while panning around a page, but allow a big enough swipe area to make the menu easy to close. NOTE: There is no button to close tabs. This is a deliberate choice; our hope is that the swipe gesture will be discoverable enough that no button will be necessary. We have thoughts on how to add a button if needed, but in the spirit of keeping a minimal UI, let's keep it out unless our assumptions are proven wrong. When the tabs are closed, the action bar basically matches the styling of that in portrait mode, showing a tab icon and number of open tabs. Users can tap this menu to open tabs, or swiping from the left edge of the content view will open them as well. -- I am still working on some styling tweaks to the action bar when tabs are opened (basically I want to see if that tab shape can be worked into the bar in an attractive way), but let's not have that stop us from creating a prototype based on what I described above.
Between images 3 and 4 in the mock-up, there seems to be some glitch. After swiping the tabs away, the number of tabs shown is fine. But, there is a shift in the Back/Foward buttons, and a new button pops-in there. (Will this be animated?) I feel this could cause some problems with constant changes in the navigation bar. Having a permanent button is better, I feel.
(In reply to Ian Barlow from comment #11) > When the tabs are closed, the action bar basically matches the styling of > that in portrait mode, showing a tab icon and number of open tabs. Is there a reason why the screen real estate of the navigation bar is used for this instead of using the (unused) real estate in Honeycomb's bottom bar (the one that houses the Android home button, etc.)? (See comment 10.)
(In reply to Henri Sivonen (:hsivonen) from comment #13) > (In reply to Ian Barlow from comment #11) > > When the tabs are closed, the action bar basically matches the styling of > > that in portrait mode, showing a tab icon and number of open tabs. > > Is there a reason why the screen real estate of the navigation bar is used > for this instead of using the (unused) real estate in Honeycomb's bottom bar > (the one that houses the Android home button, etc.)? (See comment 10.) Are we sure Android allows applications to add their own buttons to the OS bar at the bottom of the screen? All the Android UI guidelines I have seen use the ActionBar concept, at the top of the screen.
Henri, Mark is right: We don't (and shouldn't) put any of our own UI in the bottom bar (except notifications). This is standard for all Android 3.0 apps.
Created attachment 561315 [details] [diff] [review] WIP 2 This proof-of-concept patch implements the dragging UI from the mockup. There's still some work left to do: * This patch only allows dragging from the edge of the browser area, not from anywhere in the tab bar. * The tab bar moves/animates as you drag, but the toolbar and browser do not. * Need to test performance on device. * Need to show/hide the tab button in the action bar. * The code is very hacky, needs to be cleaned up.
Created attachment 561332 [details] [diff] [review] WIP 3 This shows/hides the toolbar button correctly, and adds animation of the browser and action bar. Resizing the browser is very slow even on desktop fennec, though. I think we'll need to make that part happen after the drag is finished. Still need to clean up the code, and allow dragging anywhere in the tab bar.
(In reply to Ian Barlow from comment #15) > Henri, Mark is right: We don't (and shouldn't) put any of our own UI in the > bottom bar (except notifications). This is standard for all Android 3.0 apps. Almost every app I've obtained from Market puts an extra button in the bottom bar and the button calls up some UI that's otherwise tucked away. Even Google+, which is a recent app from Google, does this. Are all those pre-3.0 apps and the button is for pre-3.0 app compat? (It's not clear that not having that button and having an analogous button in the top right corner of the part of the screen owned by the app is a win.)
Henri, Google + adds a "menu" button to the footer, which is an indicator that the app is actually made for phones, and hasn't been optimized for tablets. This is a workaround created by Android to allow phone apps to work on tablets without having to change the design. You really aren't supposed to use the footer for tablet UIs.
Created attachment 561600 [details] [diff] [review] part 1: Make the tab bar hideable Just another snapshot. Some minor bug fixes and some significant cleanup. Still need to implement dragging over the sidebar.
Created attachment 561613 [details] [diff] [review] 3/3: allow dragging in the tab sidebar This adds the ability to drag within the tab bar. I still need to clean up a few things before requesting review, but I expect to have these patches finished tomorrow. There's a new test build with both patches here: http://people.mozilla.com/~mbrubeck/fennec-slide-tabs-2.apk
Created attachment 561650 [details] [diff] [review] 1/3: cache sidebar width
Created attachment 561654 [details] [diff] [review] 2/3: make the tab bar hideable
Comment on attachment 561613 [details] [diff] [review] 3/3: allow dragging in the tab sidebar I think these patches are ready for review. They'll require some additional changes to work in RTL locales, which I plan to do in bug 685308. There's a new test build at: http://people.mozilla.com/~mbrubeck/fennec-slide-tabs-3.apk The previous versions resized the browser and action bar dynamically while the sidebar moved. This was too slow and made dragging unresponsive. The latest patches resize the action bar and browser just once. This adds some sudden changes at the start or end of a drag, but I find this overall much more pleasant than the jerkiness from trying to resize them continuously.
Comment on attachment 561654 [details] [diff] [review] 2/3: make the tab bar hideable Can we move the grab/ungrab sidebar code out of ViewAreaObserver? That code should probably be in Browser, with the other sidebar related code. Otherwise this looks ok.
Comment on attachment 561613 [details] [diff] [review] 3/3: allow dragging in the tab sidebar r+, but update this for the ViewAreaObserver -> Browser change
Created attachment 561762 [details] [diff] [review] 2/3: make the tab bar hideable Move sidebar-grabby code into Browser.
Created attachment 561763 [details] [diff] [review] 3/3: allow dragging in the tab sidebar s/ViewableAreaObserver/Browser/g. Carrying r=mfinkle.
https://hg.mozilla.org/integration/mozilla-inbound/rev/31f2a1d947be https://hg.mozilla.org/integration/mozilla-inbound/rev/8547992229cc https://hg.mozilla.org/integration/mozilla-inbound/rev/99280262eba3
https://hg.mozilla.org/mozilla-central/rev/99280262eba3 https://hg.mozilla.org/mozilla-central/rev/8547992229cc https://hg.mozilla.org/mozilla-central/rev/31f2a1d947be
Verified fixed on: Mozilla/5.0 (Android;Linux armv7l;rv:9.0a1)Gecko/20110926 Firefox/9.0a1 Fennec/9.0a1 Device: Acer ICONIA A500 OS: Android 3.1