xScope, a multitouch pinch zoom browser

[tbain98]

Awesome update - it's tough keeping up with this thread given all new features you are adding! I have a couple of comments/suggestions:

1) I really like the address bar swipe up and down (and also right to get to the extra buttons). However, one thing is that, as you scroll down a web page, the address bar automatically swipes up and disappears. Someone let me know if I'm just doing it incorrectly.... would it be more convenient to only have the address bar disappear if you put your finger in the address bar area directly and swipe up (just like you have to put your finger in the area to swipe right) rather than auto-disappearing when you scroll down? BAsically have it replicate the address bar behavior when you scroll down via the volume buttons. I feel that I am spending a fair amount of time swiping down to restore the address bar.

I want to expand upon what NeuroNY began describing, since his comments seemed to pass unnoticed. The concept of dragging the address bar into and out of the screen is a great one, and X, congrats for thinking of it. However, I think that the actual implementation isn't as user-friendly as it could be, due largely to the fact that that the current implementation co-opts the existing use of the up-or-down swipe motion (i.e. scrolling of the content pane).

Currently, if the address bar is not visible and the user makes a downwards drag motion in the tab bar (if visible) or anywhere "near" the top of the content area (on my Droid, "near" appears to be within approximately 2x the height of the address bar), the content area will scroll and the address bar will simultaneously be displayed.

If the address bar is visible and the user makes an upwards drag motion anywhere "near" the top of the content area, the content area will scroll and the address bar will simultaneously be hidden. Dragging upwards in the tab bar (if visible) and the address bar has no effect. (Of special note: dragging upwards on the notification bar doesn't cause the notification bar to go away. I agree with what NeuroNY said: everything else aside, when I do an upwards drag on the address bar, it should be interpreted as a hide request.)

With this behavior, it's way too easy to accidentally display/hide the address bar, especially when the Droid is in landscape mode; in this mode, and with the Android Notification Bar, the tab bar, and the address bar all visible, only ~60% of the total screen area can be used for scrolling without displaying the address bar. In addition (but much less important), to me it's really annoying that the content scrolls when I'm trying to display the address bar. I want the content to scroll when I tell it to scroll, and the address bar to appear when I tell it to appear, and neither one to happen when I tell the other to occur.

To me, all of these problems ultimately stem from the fact that you're using the drag action on the content area to control something outside of the content. So I'd propose the following instead:
* When the tab bar is visible, downward drags on the tab bar (or the partially-displayed address bar) will display the address bar; all drags on the content area will apply only to the content area.
* When the tab bar is not visible, downward drags "near" the top of the content area (or on the partially-displayed address bar) will display the address bar (and I'd vote for not scrolling the content, unless there's some special case where this is required). If the address bar is partially displayed, the calculation of "near" would include the partially-displayed address bar, so a smaller and smaller portion of the content area would accept input towards the address bar as the address bar became more-completely displayed. "Near" should be narrowed to be only the height of the tab bar, to limit the likelihood of unintended displays of the address bar.
* Upward drags on the tab bar (if visible) or on the address bar will hide the address bar (and will not scroll the content). All upward drags on the content area will only scroll the content (regardless of whether the tab bar is visible).

With this alternate approach, we'll only show/hide the address bar in response to drags on the tab bar and/or the address bar, unless neither one is visible (and in that case, we'll limit the amount of content area that controls the address bar).

One final thought: is there actually value to smooth-scrolling the address bar? It looks pretty, but does anyone actually use it when it's halfway down? (I don't, but maybe someone else does...) Should the up/down drag just fully show/hide it rather than doing it partway? If it was an all-or-nothing situation, that would simplify some of the logic I proposed above (you wouldn't have to worry about downward drags on a partially-displayed location bar, and you wouldn't have to recompute how much of the content area was still "near" the top when the location bar was partially displayed). Just something to consider.

With all that said, I think this is a great browser, and I'm really impressed with the obvious amount of work that X has put into it and with his responsiveness to the comments and suggestions people make on this forum. It's very much appreciated...

 

[xScope]

Wow. This is long..........should I read through it? LOL. THANKS.
It's like a dissertation.
Please update to the latest version. It will not let the addressbar in partway but a little jerky.

There are basically three things up there:
1. the system status bar
2. the tabs
3. the address bar.

Apparently, the current approach is not very consistent yet. One thing I guess most of us will agree on handling appearing and disappearing of each one of them: swiping is the most intuitive way (although making status bar showing or disappearing with a swipe has not been implemented yet). Now the question becomes how? I certainly will incorporate all the ideas you have brought up and others (NeuroNY).
My plan is that eventually, I will have an update just for making all kinds of customizations so that users can choose the way they like how things should work.
Current stage is still like Can-do or Proof of concepts. So everything is kinda rough and fixed. But they can be changed by users eventually.

I want to expand upon what NeuroNY began describing, since his comments seemed to pass unnoticed. The concept of dragging the address bar into and out of the screen is a great one, and X, congrats for thinking of it. However, I think that the actual implementation isn't as user-friendly as it could be, due largely to the fact that that the current implementation co-opts the existing use of the up-or-down swipe motion (i.e. scrolling of the content pane).

Currently, if the address bar is not visible and the user makes a downwards drag motion in the tab bar (if visible) or anywhere "near" the top of the content area (on my Droid, "near" appears to be within approximately 2x the height of the address bar), the content area will scroll and the address bar will simultaneously be displayed.

If the address bar is visible and the user makes an upwards drag motion anywhere "near" the top of the content area, the content area will scroll and the address bar will simultaneously be hidden. Dragging upwards in the tab bar (if visible) and the address bar has no effect. (Of special note: dragging upwards on the notification bar doesn't cause the notification bar to go away. I agree with what NeuroNY said: everything else aside, when I do an upwards drag on the address bar, it should be interpreted as a hide request.)

With this behavior, it's way too easy to accidentally display/hide the address bar, especially when the Droid is in landscape mode; in this mode, and with the Android Notification Bar, the tab bar, and the address bar all visible, only ~60% of the total screen area can be used for scrolling without displaying the address bar. In addition (but much less important), to me it's really annoying that the content scrolls when I'm trying to display the address bar. I want the content to scroll when I tell it to scroll, and the address bar to appear when I tell it to appear, and neither one to happen when I tell the other to occur.

To me, all of these problems ultimately stem from the fact that you're using the drag action on the content area to control something outside of the content. So I'd propose the following instead:
* When the tab bar is visible, downward drags on the tab bar (or the partially-displayed address bar) will display the address bar; all drags on the content area will apply only to the content area.
* When the tab bar is not visible, downward drags "near" the top of the content area (or on the partially-displayed address bar) will display the address bar (and I'd vote for not scrolling the content, unless there's some special case where this is required). If the address bar is partially displayed, the calculation of "near" would include the partially-displayed address bar, so a smaller and smaller portion of the content area would accept input towards the address bar as the address bar became more-completely displayed. "Near" should be narrowed to be only the height of the tab bar, to limit the likelihood of unintended displays of the address bar.
* Upward drags on the tab bar (if visible) or on the address bar will hide the address bar (and will not scroll the content). All upward drags on the content area will only scroll the content (regardless of whether the tab bar is visible).

With this alternate approach, we'll only show/hide the address bar in response to drags on the tab bar and/or the address bar, unless neither one is visible (and in that case, we'll limit the amount of content area that controls the address bar).

One final thought: is there actually value to smooth-scrolling the address bar? It looks pretty, but does anyone actually use it when it's halfway down? (I don't, but maybe someone else does...) Should the up/down drag just fully show/hide it rather than doing it partway? If it was an all-or-nothing situation, that would simplify some of the logic I proposed above (you wouldn't have to worry about downward drags on a partially-displayed location bar, and you wouldn't have to recompute how much of the content area was still "near" the top when the location bar was partially displayed). Just something to consider.

With all that said, I think this is a great browser, and I'm really impressed with the obvious amount of work that X has put into it and with his responsiveness to the comments and suggestions people make on this forum. It's very much appreciated...

 

[tbain98]

Wow. This is long..........should I read through it? LOL. THANKS.
It's like a dissertation.

My friends and co-workers would not be surprised.

The executive summary is: I don't think that you should use content-area drags to control the address bar unless you have no other option (because nothing but the content is on the screen at that time), and when you do have to use content-area drags, you should use a smaller portion of the content area and you should use them ONLY for showing the address bar (you shouldn't be both scrolling the content and showing/hiding the address bar at the same time). This also means that I think you should eliminate the code that shows the location bar when you drag past the top of the screen. Others may disagree, but to me that's the cleanest, simplest way to implement it.

Please update to the latest version. It will not let the addressbar in partway but a little jerky.

I just tried it out, and I think this is an improvement (I haven't yet found a use for only seeing the bottom 2/3 of the address bar), though I agree that it's a bit jerky.

There are basically three things up there:
1. the system status bar
2. the tabs
3. the address bar.

Apparently, the current approach is not very consistent yet. One thing I guess most of us will agree on handling appearing and disappearing of each one of them: swiping is the most intuitive way (although making status bar showing or disappearing with a swipe has not been implemented yet). Now the question becomes how? I certainly will incorporate all the ideas you have brought up and others (NeuroNY).
My plan is that eventually, I will have an update just for making all kinds of customizations so that users can choose the way they like how things should work.
Current stage is still like Can-do or Proof of concepts. So everything is kinda rough and fixed. But they can be changed by users eventually.

One other question: is there any way we can increase the number of tabs beyond 6? If I'm searching for information, I'll often open a bunch of tabs (and let them load in the background) to see if any of them have the info I'm looking for. I've hit the 6-tab limit several times and have been frustrated with it each time. Is this something that's in the full app? (I've been meaning to buy the full version anyway, so if it's in there, then no worries.) If not, would it be feasible to up that limit, or is there some limitation that prevents that?

 

[xScope]

Details oriented
The content area is also currently used to switch tabs if there are more than 1. I will make it an option eventually. Also how much swipe should be interpreted as switching tabs is also not well tuned. In general, I agree: the scrolling of the web content has its own purpose and using that to achieve other behaviors causes confusion.
Regarding the tab numbers:
I haven't tried to add more yet. It is pretty scalable in software but I don't know it will affect the resources. So on the safe side, it is 6 (on par with stock, 8???). But I will try to add, say 20, to experiment. If nothing goes wrong, then I will make it 20.

My friends and co-workers would not be surprised.

The executive summary is: I don't think that you should use content-area drags to control the address bar unless you have no other option (because nothing but the content is on the screen at that time), and when you do have to use content-area drags, you should use a smaller portion of the content area and you should use them ONLY for showing the address bar (you shouldn't be both scrolling the content and showing/hiding the address bar at the same time). This also means that I think you should eliminate the code that shows the location bar when you drag past the top of the screen. Others may disagree, but to me that's the cleanest, simplest way to implement it.



I just tried it out, and I think this is an improvement (I haven't yet found a use for only seeing the bottom 2/3 of the address bar), though I agree that it's a bit jerky.



One other question: is there any way we can increase the number of tabs beyond 6? If I'm searching for information, I'll often open a bunch of tabs (and let them load in the background) to see if any of them have the info I'm looking for. I've hit the 6-tab limit several times and have been frustrated with it each time. Is this something that's in the full app? (I've been meaning to buy the full version anyway, so if it's in there, then no worries.) If not, would it be feasible to up that limit, or is there some limitation that prevents that?

 

[Eurosteve]

Still having a problem with hitting a black screen followed by the app closing.

 

[magnus]

I get that sometimes.....but a second start always goes through

 

[stlcity]

Still having a problem with hitting a black screen followed by the app closing.

I get that sometimes.....but a second start always goes through

When finished with browsing use the menu button and exit out of xScope as opposed to using the home button. It does not close out on me the next time when I do that....

 

[magnus]

When finished with browsing use the menu button and exit out of xScope as opposed to using the home button. It does not close out on me the next time when I do that....

I'll try that...Thanks

Xscope.....With all the ROMs out there, I was wondering if there's a certain file or something I can use to save my bookmarks?

Are the bookmarks stored in a file or something that I can just copy over after I'm done nandroiding?

Thanks

 

[xScope]

Guys, Breakthrough!
I have post this message in another forum.
Basically the problem is caused by low memory scenario when xScope was not in font so the system kills xScope to release memory for others. This is by design.
I have tested several ideas to restore it in case xScope was murdered. And I am able to make a proof of concept case working. Need to finalize a solution. Hopefully by tonight.
Thank you!

 

[xScope]

Thanks. This is a clean way to exit.

When finished with browsing use the menu button and exit out of xScope as opposed to using the home button. It does not close out on me the next time when I do that....

 

[xScope]

Not now. What format you need? Or do you like xScope to use global bookmarks instead of maintaining its own? I am considering that.

I'll try that...Thanks

Xscope.....With all the ROMs out there, I was wondering if there's a certain file or something I can use to save my bookmarks?

Are the bookmarks stored in a file or something that I can just copy over after I'm done nandroiding?

Thanks

 

[cadon69]

Not now. What format you need? Or do you like xScope to use global bookmarks instead of maintaining its own? I am considering that.

That's an idea that might be nice. I would def at least like to try that out if at all possible.

 

[deman89]

I am really envious of this right now, on 1.5! Hopefully I'll be able to download this to a custom rom based 2.x after the Eris gets root. The concept seems great.

 

[xScope]

Sigh. Too much work load just for 2.0 now. Hands tied.

I am really envious of this right now, on 1.5! Hopefully I'll be able to download this to a custom rom based 2.x after the Eris gets root. The concept seems great.

 

[xScope]

Hello guys,
Uploaded an update to handle crash problem. Thanks.

 

[rob15594]

Is there a way to share a page? Like the stock browser.

I was wondering about this too. I use share a page (on the stock browser) and send the link to 3banana so I can look at something later on my pc.

 

[xScope]

Guys,
Today's update:
1. Enabled share/copy urls (long press url box)
2. Better file browsing (sorting, delete, rename and view)
3. Tab switcher (icon in address bar). Good for fat fingers
4. Low memory handling
5. Fixed several bugs causing crash

 

[rob15594]

Great update thanks.

 

[negreenfield]

I'm typing this on the xscope browser now and have to say I'm quite impressed. I just started using it so I need to learn all the features but I like this the most of all the browsers so far.

 

[tvBilly]

Today's update:
1. Enabled share/copy urls (long press url box)
...snip...

This is VERY useful for those of us that use SuperGenPass. It saves a number of copy and paste steps.

Thank You very much!

Billy

 

[RocknSteve]

The only thing that's giving me problems some of the time is when I'm typing in a password to sign into a site. I think this has been mentioned before but you sometimes you can't see what you're typing (for example, on the stock browser, it shows the letter as you type and once you've gone onto the next letter, it turns the previous one into the dot). But what's been happening is that instead of seeing the current letter and the dots before it, I either see nothing or I can barely see a peek of something (it generally just looks like this ' ). Last night when trying to sign into Photobucket, I noticed a white box appear over the text field where you type your password. So I'm starting to wonder if that box is covering up what I'm typing.

I don't think that made a lick of sense. But I guess what I'm saying is just that when typing into a password field, it just doesn't work too well. Maybe someone can explain it better than I can.

But keep up the good work!

 

[xScope]

RocknSteve,
To tell you the truth, I have no clue. I do know it is a problem. Somehow it worked on some website (facebook for example) but not all. Someone posted the same thing at google's dev forum and got no answer yet.

The only thing that's giving me problems some of the time is when I'm typing in a password to sign into a site. I think this has been mentioned before but you sometimes you can't see what you're typing (for example, on the stock browser, it shows the letter as you type and once you've gone onto the next letter, it turns the previous one into the dot). But what's been happening is that instead of seeing the current letter and the dots before it, I either see nothing or I can barely see a peek of something (it generally just looks like this ' ). Last night when trying to sign into Photobucket, I noticed a white box appear over the text field where you type your password. So I'm starting to wonder if that box is covering up what I'm typing.

I don't think that made a lick of sense. But I guess what I'm saying is just that when typing into a password field, it just doesn't work too well. Maybe someone can explain it better than I can.

But keep up the good work!

 

[xScope]

If you wish, you could read through the 'Tutotial' at the bottom of the Favorites page. Thanks

I'm typing this on the xscope browser now and have to say I'm quite impressed. I just started using it so I need to learn all the features but I like this the most of all the browsers so far.

 

[hiway12]

nice work on the 'share url' that's the one I've been waiting for

 

[RocknSteve]

RocknSteve,
To tell you the truth, I have no clue. I do know it is a problem. Somehow it worked on some website (facebook for example) but not all. Someone posted the same thing at google's dev forum and got no answer yet.

I just tried again and facebook worked just fine. I think it might just be how certain websites set up their password text input field. If you wouldn't mind, could you try going to mobile Photobucket and just try typing in a password? I don't believe this is the only site that I've had this issue but it's the only one I can remember. I just tried to enter a password on the stock browser on Photobucket's site and it worked fine. So it might just be how the website is set up with their password text input field.

But like I've said, you've done an amazing job! And I really, REALLY like how you take the time to get on here and listen to the ideas of the users and how fast you work on it. I might just delete the app, install it, and delete it again just so I can pay for it again! lol