It’s way too slow implemented in javascript. It’s a slow, frame-skipping, laggy mess for me.
The outline floating on the left, or some condensed version of the content, is mandatory but unmentioned. Skipping two-thirds of the way through a document is something that needs to be possible with a single UI action. Scrollbars, conveniently, combine this with the scrolling UI in a single compact element.
Speaking of the floating outline, they broke their own stated rules with it: it floats, but the indicator gradients include the part of the page it floats over.
None of this actually matters. Even if they resolved every possible complaint, getting the zillions of people who use but don’t actually care about computers to change their habits is a total non-starter. (IMO, this is actually really unfortunate, and not a good reason to not experiment with UI, but be realistic about what your penetration will ever look like.)
I agree with Irene that reimagining interfaces is definitely not a bad thing. It would be sheer folly to imagine our GUIs are anywhere near optimal. (For one thing, that was achieved by the Unix commandline in the 70s. ;) I don’t think this quite works (needing a condensed visual summary effectively eliminates all the benefits), but it’s definitely an interesting thought. Unfortunately, it’s severely hindered by being prototyped in Javascript on the web. I’m reminded of the general complaint about web developers that not everybody’s web browser is running on a late-model Macbook Pro.
The outline floating on the left, or some condensed version of the content, is mandatory but unmentioned. Skipping two-thirds of the way through a document is something that needs to be possible with a single UI action. Scrollbars, conveniently, combine this with the scrolling UI in a single compact element.
Uhm, really?
intence does not provide any controls for changing the scrolling position, and this was done intentionally. From now the issues of scrolling indication and scrolling control are separated: intence is responsible for indication and is supposed to work along with a navigation widget, like the menu on the left side. It can be a pager, or an area with small previews, a progress bar, or something totally new and different. Such components can be designed for the needs of a particular application and solve the issue of controlling the scrolling better than the general-purpose scrollbar.
In practice I imagine the result would be that some programs would have one of the 2 widgets, some programs would have the other, and some programs would have both, depending on the whims of the designer. Being general-purpose and standardized is a significant advantage.
The idea beyond intence is that it’s supposed to be a standard designation of a scrollable area, and a navigation widget may be different depending on the particular needs.
Well, I missed that paragraph when I skimmed through looking for it apparently. Oops. =) I don’t think it really impacts my point, though: a long-form navigation widget is mandatory, and a page without it is broken. Enabling broken pages is dubious design at best. Scrollbars nicely include the long-form navigation and thus sidestep the issue.
Funny bug. Clicking at the bottom of the navbar starts scrolling down (almost painfully slowly). If I click again at the top before it gets to the bottom, it keeps going down for a while before reversing directions and slowly scrolling up.
So two points. If I can race your UI animation without trying, it’s not fast enough. If I win the race and you don’t adjust, it’s not responsive enough.
nice that someone noticed it. the animation time is always the same (600 msec to get to the target, I think). The animation is a spline. When you change the target of a running animation, it calculates a new spline which has the same speed and acceleration at it’s starting point as the currently running animation.
So, from the ultra-negative angle:
I agree with Irene that reimagining interfaces is definitely not a bad thing. It would be sheer folly to imagine our GUIs are anywhere near optimal. (For one thing, that was achieved by the Unix commandline in the 70s. ;) I don’t think this quite works (needing a condensed visual summary effectively eliminates all the benefits), but it’s definitely an interesting thought. Unfortunately, it’s severely hindered by being prototyped in Javascript on the web. I’m reminded of the general complaint about web developers that not everybody’s web browser is running on a late-model Macbook Pro.
Uhm, really?
In practice I imagine the result would be that some programs would have one of the 2 widgets, some programs would have the other, and some programs would have both, depending on the whims of the designer. Being general-purpose and standardized is a significant advantage.
The idea beyond intence is that it’s supposed to be a standard designation of a scrollable area, and a navigation widget may be different depending on the particular needs.
Well, I missed that paragraph when I skimmed through looking for it apparently. Oops. =) I don’t think it really impacts my point, though: a long-form navigation widget is mandatory, and a page without it is broken. Enabling broken pages is dubious design at best. Scrollbars nicely include the long-form navigation and thus sidestep the issue.
Funny bug. Clicking at the bottom of the navbar starts scrolling down (almost painfully slowly). If I click again at the top before it gets to the bottom, it keeps going down for a while before reversing directions and slowly scrolling up.
So two points. If I can race your UI animation without trying, it’s not fast enough. If I win the race and you don’t adjust, it’s not responsive enough.
nice that someone noticed it. the animation time is always the same (600 msec to get to the target, I think). The animation is a spline. When you change the target of a running animation, it calculates a new spline which has the same speed and acceleration at it’s starting point as the currently running animation.
What does isomorphic mean here? What is what isomorphic to?
running the same code both in browser and under nodejs unchanged and without any kind of translation
But what’s the isomorphism?
Perhaps the result of a code execution regardless the environment?
this term was not invented by me: http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/
and yep, it has nothing in common with isomorphism from maths.