PDA

View Full Version : Will the n810 software use finger scrolling?


heron61
11-04-2007, 02:30 AM
I'm very tempted by the n810, but I don't want to have to pull out the keyboard in order to do everything and I hate using a stylus. Does anyone know if the web browsing or media playing software will support finger scrolling or kinetic scrolling.

aflegg
11-04-2007, 05:50 AM
The web browser has, since IT OS 2005, supported dragging on a web page's content area to scroll. I imagine this isn't going to change in IT OS 2008, either.

No kinetic scrolling, though :-(

Rocketman
11-04-2007, 06:26 AM
I believe there is a 3rd party music player for the n800 which supports kinetic scrolling already. I am not sure if it is n810 ready, though. Can someone help me with the name?

aflegg
11-04-2007, 06:59 AM
Kagu and UKMP both support kinetic scrolling.

pycage
11-04-2007, 07:10 AM
I don't think that kinetic scrolling is good for reading a website. I have tried it on my desktop with a firefox plugin, but it didn't convince me. Kinetic scrolling is good for browsing large collections of items to find the one you're looking for. But apparently not for reading text, IMHO.

benny1967
11-04-2007, 08:26 AM
Kinetic scrolling is good for browsing large collections of items to find the one you're looking for.

Scrolling through really large collections of items is a pain, no matter which type of scrolling you use. Kinetic scrolling doesnt really help here, while it makes things a little more difficult for small lists. Maybe it takes more time getting used to it, but so far I'm not very convinced its any good except for a few cases where lists are just large enough for kinetic scrolling to be helpful, but small enough so that scrolling isnt out of the question in the first place.

Alvin
11-04-2007, 09:19 AM
using the MicroB browser on N800 I find that some web pages don't work with finger/stylus scrolling, whereas they always do with the Opera browser.

I hope this is better in OS2008...

Moonshine
11-04-2007, 12:43 PM
using the MicroB browser on N800 I find that some web pages don't work with finger/stylus scrolling, whereas they always do with the Opera browser.

I hope this is better in OS2008...

I think you'll find this is due to Javascript on some sites that intercepts mouse down (stylus down) events. Disabling Javascript would allow you to scroll.

MicroB will have to be smarter about this in the future, but it's not something that Opera would really run into as it's support for advanced Javascript events was very limited.

MicroB will have to look at a mouse/stylus down event and the action afterward (ie. movement) and then make a decision if it should scroll or pass the event to the site javascript that want's to intercept it. May not be an easy decision in some cases.

hircus
11-05-2007, 09:41 PM
Kagu and UKMP both support kinetic scrolling.

Mauku does as well, I think, and the code to do so is exposed as a library, IIRC. It would be nice if the different codebases get merged -- there's no need for three solutions to the same problem!

Capt'n Corrupt
11-05-2007, 10:29 PM
I think the simplest solution is creating a fat scrollbar on the right. It would cut down on screen real-estate, but would be easy enough to target with a fat finger.

A twist on this idea, is a small box target in the top-right/bottom-right. Pressing the target with a finger then dragging initiates and completes the scroll. It could be translucent and would only obscure a minuscule portion of the interactive site.

Another good solution is a button-touch combination to initiate scrolling using any dragging over the whole screen (or a portion). Perhaps one of the face keys, or the multi-purpose button can be leveraged for this.

From here, fancy effects like inertial scrolling can be implemented.

The problem with scrolling using non-interactive space on the page is simply compatibility. While it is very convenient, many javascript and flash sites that capture the mouse event will not work properly with this type of interaction.


}:^)~
YARR!

Capt'n Corrupt

Traecer
11-06-2007, 12:26 AM
I think the simplest solution is creating a fat scrollbar on the right. It would cut down on screen real-estate, but would be easy enough to target with a fat finger.


YES. Especially for apps that don't allow finger scrolling, there needs to be a scroll bar that can be fingered (if not thumbed) up and down. Though I think ultimately it would be better if all content areas simply supported finger scrolling.

Though I love finger scrolling, I believe in most cases kinetic scrolling SUX. In all the implementations I've seen so far (including the much-praised iPhone), the list scrolls unpredictably and too fast to easily read what is scrolling by.

hhedberg
11-09-2007, 03:53 AM
Mauku¹ is using it's own Miaouw Library² to provide kinetic/inertial scrolling. The difference between Mauku/Miaouw and Kagu/UKMP is that the first is implemented in pure C/GTK+ while the latters uses Python.

The Miaouw Library is available under LGPL license. It would be nice to see also other developers using and improving it.

¹ http://mauku.henrikhedberg.com/
² http://miaouw.henrikhedberg.com/

zerojay
11-09-2007, 09:55 AM
I think the simplest solution is creating a fat scrollbar on the right. It would cut down on screen real-estate, but would be easy enough to target with a fat finger.

While talking with ThoughtFix during his Tech Support chat thing, I asked him to show off the Media Player a bit and it was very very clear that the scroll bar in Media Player is absolutely huge.

Which sucks because I had no problems scrolling with the little scroll bar... but oh well.

icerabbit
11-09-2007, 11:13 AM
I like both capt'n 's ideas to improve scrolling.

Tapping near the corners would be something I like to test. Like how you can scroll maps on the web & software. Certainly in full screen that could work - no menu bar in the top right corner. Would have to be just below it in regular view.

Otherwise I always use the stylus. Doesn't seem I can rely on finger scrolling or the dpad - every time. And with the stylus it is never a problem. That said, if one could do it reliably without the stylus. That'd be great.

Capt'n Corrupt
11-09-2007, 04:59 PM
Thanks guys!

I love the keypad for the N810 and the stylus, but don't think that they should necessarily be required for casual use. This is can be controlled through some clever adjustments to the interfaces of programs, most importantly, the web browser. The ability to use the finger to surf or look up information without fumbling around for a stylus is very important, and can make/break the decision to buy a tablet for some consumers.


}:^)~
YARR!

Capt'n Corrupt

Darius2006
11-10-2007, 06:09 PM
using the MicroB browser on N800 I find that some web pages don't work with finger/stylus scrolling, whereas they always do with the Opera browser.

I hope this is better in OS2008...
Frankly speaking I don't see any finger scrolling in Opera.
I don't scroll but select web links in html document.
Scroll bars are too thin for finger operating.

Darius

isaacs
12-14-2007, 07:03 PM
Anyone found a good solution to scrolling? Some pages you can click and drag, others don't like it and it selects text instead. What are you guys doing for browsing on web pages?
Thanks,
Isaac.S

dblank
12-14-2007, 07:16 PM
On my N800 I usually page up and down with the hardware buttons, and occasionally tap the scrollbar if i don't feel like making clicking noises :)

Finger scrolling seems to work ok, but it's not as sensitive as I'd like, maybe that's because of the stock screen protector I'm using though.

It also uses more CPU than just a simple page up / down, since it's doing more screen updates.

slim
12-14-2007, 10:00 PM
I think the simplest solution is creating a fat scrollbar on the right. It would cut down on screen real-estate, but would be easy enough to target with a fat finger.

That's definitely the simplest, but I think it's the worst. I'd hate to pay for and carry around a 4.1" screen only to get the use of a 3.8" screen. With multi-frame views (such as Modest) it's even worse.

A twist on this idea, is a small box target in the top-right/bottom-right. Pressing the target with a finger then dragging initiates and completes the scroll. It could be translucent and would only obscure a minuscule portion of the interactive site.

That could work well.

Another good solution is a button-touch combination to initiate scrolling using any dragging over the whole screen (or a portion). Perhaps one of the face keys, or the multi-purpose button can be leveraged for this.

I think this is a little less intuitive. But what about dedicated scroll buttons, or some other physical scrolling mechanism? I think a reasonable rule of thumb is that if an interaction is common enough, it should be removed from the screen so the screen can be used for more dynamic content.

From here, fancy effects like inertial scrolling can be implemented.

How's this for fancy: Kinetic scrolling that creates a semi-transparent scroll bar where the finger stroked. This would allow someone to switch to manual scrolling from kinetic scrolling if they wanted to scroll faster or slower.

The problem with scrolling using non-interactive space on the page is simply compatibility. While it is very convenient, many javascript and flash sites that capture the mouse event will not work properly with this type of interaction.

Do many sites capture the "stroke" event? It should be pretty easy to differentiate between a stroke and a tap. You don't have to capture the borderline cases, just the obvious ones, and the user will learn what to do. What is really needed is some sort of re-usable code base that can reliably differentiate between these events.

aflegg
12-15-2007, 11:16 AM
Fat-scrolling is a really bad idea. The right answer for a finger/stylus-usable device with limited space is content-area drag to scroll.

I've raised a bug in Bugzilla about the 4 different ways I've counted in OS2008 that you've got, out-of-the-box, to scroll various different applications:

https://bugs.maemo.org/show_bug.cgi?id=2564

bonaojnfr525
12-15-2007, 05:28 PM
hey capt i agree i think the fat scrollbar should be an option though a capability that you can disable and/or enable

isaacs
12-17-2007, 02:32 PM
how about a semi-transparent fat scrollbar? How hard would it be to implement this?

Thanks,
Isaac.S

Benson
12-17-2007, 03:47 PM
The trouble with a semi-transparent fat scrollbar is that you're covering content under it. So you either need someway of popping it out of the way (to access that content) or you have content that doesn't get any user interaction. In the latter case, a good argument can be made for drag scrolling, hopefully inertial. And while it's been suggested that kinetic scrolling is bad for some types of content, a well-designed system will do what you want -- it'll differentiate between a drag and a "flick", and keep that behavior including threshold constant across as many apps as possible.
I've nothing against the idea of a semi-trans-fat-scrollbar (pun intended), but it seems of limited application. And anywhere it's not helpful, I'd rather not have transparency. Eye-candy bloat does cause sluggish performance, even if each change is small, and we seem to be talking of changes here which we'd like to see system-wide.
I'd like all scrollbars just about 1.5~2x the OS2007 width. Not really fat, but just enough to make finger grabbing reliable. Right now, I've no problem with scrollbars at the edges (slide finger along bezel), but ones out in the middle of the screen can be awkward. And, for all non-interactive content, I'd like kinetic (both drag and inertial) scrolling.

For the file-manager, and indeed for anything else where you must be able to select items from a list, one possibility that would make me happy is two split the list in two vertically. Taps/drags on the left half would select one/multiple items. Drags on the right half would scroll the list. The background color could be changed slightly to visually differentiate the halves; perhaps better, in lists where the items are separated by dividing lines of some sort, is to have those dividers disappear (fade out over ~20 px) as you go from the left half (separate, selectable items) to the right half (continuous, draggable list). Kagu is partial inspiration here; this isn't the same idea, but is applicable to, e.g. an album/track selector list.

emory
02-06-2008, 03:00 PM
Sorry for the necro-post, but why not make the scrollbar in microb invisible? why not just have a large "drag area" on the right like on most modern touchpads, letting you scroll by dragging your finger down the right-most edge?