Android ApplicationsAll the information you could ever want about Android Applications. Find apps, learn about new apps, get helps with apps.. all here!
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...
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.
Quote:
Originally Posted by tbain98
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...
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.
Quote:
Originally Posted by xScope
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.
Quote:
Originally Posted by xScope
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?
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.
Quote:
Originally Posted by tbain98
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?
Still having a problem with hitting a black screen followed by the app closing.
Quote:
Originally Posted by magnus
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....
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?
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!
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 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.
Sigh. Too much work load just for 2.0 now. Hands tied.
Quote:
Originally Posted by 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.
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.
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.
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.
Quote:
Originally Posted by 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.
If you wish, you could read through the 'Tutotial' at the bottom of the Favorites page. Thanks
Quote:
Originally Posted by 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.
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
Lol.
Google got this one right: when you installl the app again, it won't charge you again. So please write a check to ........ LOL
Quote:
Originally Posted by RocknSteve
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
Lol.
Google got this one right: when you installl the app again, it won't charge you again. So please write a check to ........ LOL
Lol. I thought it was that if you delete it once, you can get it again without paying. But if you get it again (after deleting it once and re-downloading it once and get rid of it... again lol) you have to pay (again). Anywho. Lol.
Were you able to see the problem that I was describing?
I've been using the beta version for 1.5 for a few days now, and I'm very impressed. Even in its unfinished state, I use it over Dolphin 90% of the time. Please, please, please update the 1.5 beta, if it's not too much work! I would love to get to use some of the features you have been working on since that version was released.
Also, I agree with tbain on the address bar. Maybe the address bar should disappear after 10 seconds, but reappear if you hit menu (along with the menu). Or it could reappear after a single or double tap.
Lastly, I think a Firefox-style Find As You Type function would be awesome for those of use who have hard keyboards.
Hey,
The version you have installed was stopped. Depending on my workload, after stablizing current version, I will release newer version for android 1.6 though (G1 is running 1.6 now, right?) Thanks
Quote:
Originally Posted by acjohnson55
If you're replying to me, unfortunately my phone only has Android 1.5, so I can't see xScope on the Market, let alone install it
If you were planning to go through the effort of back-porting to 1.6, would it be much more difficult to do 1.5 instead? I'm using the Samsung Moment, which is slated to be upgraded directly to 2.1, but that may be months away. Also, I think Hero users are stuck with 1.5 for the time being, as well.
Judging by the number of people on the thread who can't find xScope in the Market, there are many of us who would jump on a 1.5 version! Also, there is an exodus of people leaving Dolphin, after the controversial 2.0 upgrade (me included), I think it would be great for you to fully take advantage of this opportunity to pick up new users.
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!
That tickles something in the back of my memories. I have a vague recollection of once or twice seeing a web page rendered such that there was a white box the same size as the password input, floating one line above the input itself (which was also visible). It only happened when I did something that caused the browser to redo its layout, like switching from portrait to landscape or opening/closing the keyboard on my Droid. I never fully figured out what user actions triggered the behavior, but it seems to track with the idea that there might be a second input at work with password inputs.
That tickles something in the back of my memories. I have a vague recollection of once or twice seeing a web page rendered such that there was a white box the same size as the password input, floating one line above the input itself (which was also visible). It only happened when I did something that caused the browser to redo its layout, like switching from portrait to landscape or opening/closing the keyboard on my Droid. I never fully figured out what user actions triggered the behavior, but it seems to track with the idea that there might be a second input at work with password inputs.
If you were planning to go through the effort of back-porting to 1.6, would it be much more difficult to do 1.5 instead? I'm using the Samsung Moment, which is slated to be upgraded directly to 2.1, but that may be months away. Also, I think Hero users are stuck with 1.5 for the time being, as well.
Judging by the number of people on the thread who can't find xScope in the Market, there are many of us who would jump on a 1.5 version! Also, there is an exodus of people leaving Dolphin, after the controversial 2.0 upgrade (me included), I think it would be great for you to fully take advantage of this opportunity to pick up new users.
I saw that in the new update you said "no S.a.H". What does that mean?
You posted that link about the password problem, so there isn't a solution as of now? Another question real quick is are you planning on working on the bookmarks some more? Being able to rearrange them would be killer.
Some users experienced that javascript popup error from Google's page.
I will think about the bookmarks thing. Ideally, no limit. So they should be organized at least by labels. Then we will have to enable users a easy way to organize them and selectively showing them.... a whole can of worms
Quote:
Originally Posted by RocknSteve
I saw that in the new update you said "no S.a.H". What does that mean?
You posted that link about the password problem, so there isn't a solution as of now? Another question real quick is are you planning on working on the bookmarks some more? Being able to rearrange them would be killer.
What's it going to take to get a little press for xScope. I want to yell at someone everytime I see Dolphin touted by a journalist or a commenter as "the" multitouch alternative for Android.
What's it going to take to get a little press for xScope. I want to yell at someone everytime I see Dolphin touted by a journalist or a commenter as "the" multitouch alternative for Android.
Sure. Good news, after some research, I actually have some pretty good idea now to make it visible to both 1.6 and 2.0+ android systems. I don't have to release a different version. So once it is ready, it will be exactly the same as what's on 2.0+ except multi-touch part. But frankly, with one finger pin-zoom, I rarely use the multitouch thing.
Here is a little video I made (click title. iPhone users might feel a little insulting but hey it is just for fun! We all know that after 3 years when we look back we will know how stone age we have lived now)
What's it going to take to get a little press for xScope. I want to yell at someone everytime I see Dolphin touted by a journalist or a commenter as "the" multitouch alternative for Android.
I give props for this everytime I see a multitouch thread either here or howardsforums.! Do the same. We need someone who is 'connected'
I really like the xScope Browser, better than the other ones available. What I cant understand is the difficulty of Syncing with the Droid. Even with xScope there is some limitation right now with bookmarks. What I have done is exported an HTML Doc with all my Google Bookmarks and copied onto the SD Card. Then I can open it with the xScope file browser and click on a link.
Great browser! I found a problem with Yahoo web mail though. When typing the message, the keyboard pop-up hides the send button. To send I have to rotate the Droid to make the keyboard disappear.
Address bar dispays/hides too easily
