RFC browser: URL bar, bounce effect, performance

Thomas Pfeiffer colomar at autistici.org
Thu Oct 27 15:16:02 UTC 2011


> RFC1:
> ** Proposed Change **
> leave the URL bar in the active browser on top and visible all the time
> while scrolling down
> 
> ** Reason For Change **
> users want to change quickly the url (as we dont have tabs currently) to
> move to other websites and its irritating if the whole URL bar moves up
> and dissappears

Having it always visible steals precious vertical screen estate, though. 

What do you guys think of Firefox Mobile (aka Fennec)'s solution
to that problem (i.e. displaying browser chrome when swiping to the left
or right of the visible page)? Personally, I like that idea a lot because
since web pages are usually longer than wide (and when pages are well
designed and we send a useful useragent that indicates we're on a small
screen, they will arrange their content accordingly anyway), you usually
have to scroll much less until you're at the left or right edge than at
the
top or lower one. So you can still make the chrome only appear on demand
but with much less effort than having to scroll all the way to the top.
I'm using Fennec on my n900 and I like that feature pretty much.

We don't necessarily have to do exactly that (although copying from
an open source product that works well is absolutely okay imo), but
I don't want to have to scroll even more because the browser chrome
covers too much of the screen. It also doesn't feel very mobile-ish to me.

> RFC2:
> ** Proposed Change **
> Improve the loading speed for websites to 3 sec max for displaying it.
> 
> ** Reason For Change **
> Currently it takes over 10 seconds to load a common webpage in the
> active webbrowser. Thats way too long.

+1

> RFC3:
> ** Proposed Change **
> If scrolling a website to its end, it should be indicated by a small
> bounce of the content - not shaking the whole interface browser
> background to white background and bouncing back.
> 
> ** Reason For Change **
> The current bounce effect while scrolling a website to its end is
> irritating and looks like a bug, because the "white background" is
> visible. Can we do a more reduces animation to show, that the scroll is
> at its end?

I'm not sure how this can be done, but the current behavior really isn't
ideal.

> RFC4:
> ** Proposed Change **
> The zoom gesture should scale exactly into the position where the two
> fingers are put on the screen.
>
> ** Reason For Change **
> Currently the interface of the browser zooms at a point on the left of
the
> tablet, not really in the middle of the two fingers of the user. So the
wrong
> content gets zoomed out, but some position to the next.

Absolutely! I guess this is more of a technical issue than on purpose, but
if it can be fixed in any way, it definitely should be because only then
the
pinch gesture is really helpful.

> RFC5:
> ** Proposed Change **
> Add tabs to Browser.
> 
> ** Reason For Change **
> Its just more handy and a tablet is real surf-device... so I guess every
user is
> somehow a internet surfer poweruser. To be limited to one tab in the
year
> 2011 doesnt feel innovative.

Agreed. But they should not be always visible either (see RFC 1).

> RFC6:
> ** Proposed Change **
> Put the reload button in front of the URL or move SLC icons.
> 
> 
> ** Reason For Change **
> The reload buttons is way to close to shareLikeConnect Icons. I always
hit
> both at the same time.

How about putting it insie the url bar as other browser nowadays do?



More information about the Active mailing list