First famo.us employee here, want to give people some food for thought to consider as you gripe about things like zoom and and the scrollbar (rightfully so). Some of the more controversial points, especially those regarding accessibility and progressive enhancement, made below are my own.
I think I'm the only person at the company that browses the web with JavaScript disabled, so I know how broken the original world wide web from when I first went online in 1994 is. I also remember using text-only browsers like lynx, and demonstrate it to co-workers on occasion. Lastly, I've been doing the web app development schtick for several years now and seen the good and the bad.
With all that in mind, the push towards progressive enhancement starting in 2003 when AJAX was just starting to become popular has proven to be a false prophet. IMHO, no idea has done more to make the web less accessible while also holding it back in terms of interactivity. You simply cannot use the same abstraction for both documents and applications and expect decent results for either.
What we should have done instead is allowed the two to diverge long ago and especially after 2007 when mobile computing took off and that change in screen size afforded us the opportunity to return to screens not all that dissimilar from those I remember using in '94. The first iPhone had a effective resolution of 320×480. You can effectively show as much on an iPhone as a 1994 computer monitor and have it be readable on both. In fact that's basis of the "Mobile First" design paradigm that frameworks like Zurb Foundation have pushed for. Designing content for a single-wide column that scrolls up and down, that you can jump backward and forward on via anchor hypertext references was a really smart abstraction for lots of content. The site http://www.motherfuckingwebsite.com/ illustrates this poignantly.
The technology direction we should have taken should have made sure that search engines, the blind (or otherwise disabled or dexterally challenged) actually remained the first class citizens on the web instead of taking the back seat to print designers and interaction designers. It's easy to take the content designed for those constitutents and make it available via APIs that can then be consumed by people making rich web apps.
We even had something like that, it's called RSS and it is glorious. RSS may have actually survived if it had not been for progressive enhancement which was crap but just good enough that people could get away with killing RSS off. Every technologist should make themselves familiar with the concept of path dependency (this Slate articles on the persistence of rockets as our primary way of putting objects in space is illustrative: http://www.slate.com/articles/technology/future_tense/2011/0... ). Had progressive enhancement not become the road taken, no one would have ever argued to kill off RSS in favor of a hack jobbed DOM implemented where maybe 1 in 100 developers actually understood how to actually implement accessibility. RSS and other means of programmatic content consumption would have become the prime way of being indexable by search engines. Everyone would have maintained content that way because it would have been in their self interest to do so. Not only that, progressive enhancement is just usable enough to not get sued under the ADA. Without progressive enhancement, businesses (read: at least every fortune 500 company and then some) would have poured gobs money to into making sure they have the digital equivalent of wheelchair ramps. Progressive enhancement gave everyone the opportunity to do the least amount of effort and still maintain a defensible position if challenged legally.
The screen reading experience has been shit for like for ever and it's only gotten worse as designs have become more complex. Skipping over the level of abstraction that made content usable programmatically not only impoverished those that need it, but those who don't as well because we're deprived of richer, more flexible APIs.
Having worked with webapps for a while, I think one of the most amazing improvements in the last 5 years has been the move towards displaying content on many more screens than just the desktop. This has forced us to go back to API solutions (usually REST, but sometimes RPC over websockets) that often ape what we originally tried to accomplish with RSS. This is the only sane way to provide content that needs to be displayed in different ways, from a Mobile First single long scroll page rendered by the server to a Famous/Ember/Angular/Backbone/React app that takes that server-rendered page and replaces it entirely with a rich interactive experience in the browser.
We (at famo.us) don't yet have a solution for this future that treats everyone as a first class citizen, but we eventually plan to address this if the community doesn't tackle it first. We've been inspired by a few attempts at figuring out how to achieve this. Spike Brehm and crew over at AirBnB have been exploring this with Rendr, that works with Backbone.js, https://github.com/rendrjs/rendr , and August Lilleaas has worked on a solution for React, http://augustl.com/blog/2014/jdk8_react_rendering_on_server/ . We feel like there is potential for a generalized solution that doesn't need to be necessarily tied to how one framework works.
If you look deep at Famo.us, we don't throw out the DOM wholesale, instead we use the DOM where it matters. In Famo.us, there is a concept of a Surface (which is similar to Layers in CoreAnimation). The Surface is basically a container for HTML Document Fragments, usually fragments that are very strongly structured semantically. The entire scene graph above each Surface node basically helps you programmatically abstract away all the bullshit that many today handle awkwardly with levels and levels of DIV hell controlled by JavaScript. This is not only the abstraction that makes building things in Famo.us easy and fast, but also provides a boundary where content gets lumped into semantic chunks that oftentimes should be consumable for use in a long-scroll, semantically rich, Mobile First design where navigation is hyperlinked anchor based instead of spatial navigation.
When browsers were first designed, they made a decision to have a 1 to 1 relationship between the window object and the document object. While reasonable at the time (remember: small screens, low bandwidth, high latency), this proved unscalable to larger screens, greater bandwidth and lower latency. Take Twitter for example. Twitter.com is basically an application for displaying a tiny document called a Tweet. There hundreds of tweet documents shown at a time. The code for tweets is semantically rich. The code for the twitter app? That's DIV hell. This is what Famo.us helps with. Like Flash and Silverlight before it, it helps apps be apps, but unlike its predecessors, it allows documents to be documents. Keeping these two separate keeps abstractions from leaking into each other in the code you write.
So while some things may be broken, and the way its broken may inspire ire, it's important to understand that it's not where the puck is that matters, but where it is going. The scrollview we've made is still inferior to the native scroller in a few ways, such as missing keyboard bindings, but are temporary shortcomings that we and the community are going to address in time. Eventually the feature and quality gap will narrow and the Famo.us scrollview(s) will reach parity with native scrollers.
Furthermore, some of the abstractions in the Famo.us scroller are remarkable for their programmatic flexibility. When most people think of a scroller, they only think of three scenarios: vertical scrolling, horizontal scrolling and a pannable tiled area (like Google Maps or Open Street Maps). This is actually a pretty limited view of what's possible to explore if you abstract a scroller to its essence. A scroller at is essential is a mathematical set with a curser and that all scrolling does (whether by mouse or keyboard) is move the cursor position in that set. When you think about it that way, many more things you've seen are scrollers. For example, the Apple Time machine view is a scroller in the Z-direction. CoverFlow is another scroller that is horizontal, but where the affine matrix transform applied to a surface is based on the distance of a surface from the cursor and inverts on each side of the cursor. One team of beta testers used the scroll view to display a DNA double helix. It was basically two position linked vertical-scrollers, where the positioner function didn't just set the position on the Y-axis, but also manipulated the affine matrix to create the helix shape.
While probably not the best approach, even Google's new interactive Rubik's cube doodle could probably be implemented as a series of Famo.us scrollers. Each scroller would contain 12 surfaces (doubly linked in a ring), with pagination occurring at every three surfaces. The pagination function instead of translating the surfaces along only one axis instead rotates all the surfaces 90 degrees around an axis. All surfaces would belong to two scrollers "perpendicular" to one another at any given time, being lifted from one to the other and back depending on which one was in motion.
And since all this is based on the same scroller, which will eventually reach parity with native scrollers, it means that they get all the same features. Home goes to the top of a vertical scroller, the left of a western horizontal scroller, the beginning of the double helix or the begging of time in z-axis time machine like scroller. End does the opposite.
These examples just begin to scratch the surface of what's possible when you expose primitives that map to mathematical concepts like a set and current index to developers.
Last, but not least, we're going to look at all the feedback on the scrollview and try to address all the issues you all have encountered.
Holy wall of text, batman! But seriously, why isn't any of this present on the website? If your big goal is to improve the web's usability and accessibilty, why doesn't that get more real estate than the "complex UIs for any screen" part of a small tagline?
I find myself agreeing with most of what you wrote, and yet, it doesn't matter. You keep sabotaging yourselves.
Does no-one do QA? Do you not have a Steve Jobs-esque character who has taste and an eye for detail and who can look at this stuff the way your users will? Because such a person would've looked at this and Noped the fuck out of there, cancelled whatever PR you had planned, and put everyone around a table saying "we're not there and can we fix it?".
Your first hyped launch thing was a sign-up form with blurry fonts leading no where. Now you've implemented a giant janky scrollbar with easing equations calibrated for "instant turn off". The parallels to Flash really are quite similar.
You should not imitate native behaviour unless you have someone going over it with a fine toothed comb, and you shouldn't be making grand claims about the future when you cock up the present.
If you believe your own claims, then why does your page work terribly on my brand new laptop, never mind the 4 year old one it just replaced?
1) Launch an imperfect product that works well for some use cases; or
2) Perfect everything and be ridiculed as vaporware
I wish we were Apple and had $159 billion in cash reserves. We're not though and have to operate within different constraints that don't afford us the same luxuries. You can't really compare Apples to Famo.uses
No offence by I cannot read anything on your website because the native scroll doesn't work, nor does my keyboard ( I had to scroll using my mouse-wheel and it was not smooth). That is neither 1) nor 2), it's 101.
How can I trust your "Ready to start building a beautiful UI?", when the basic tenant of a UI in regards to a webpage is missing.
If you did this to any popular website it would be a mass exodus in no time flat.
If you spent two years hyping vaporware and then do a major Apple-esque launch with all the fanfair while claiming to the next evolution of technology...
... you should at least attempt to make the scrollbar on your own website work correctly.
Seriously. You don't have to be Steve Jobs to realize that your scrollbar needs fixing. It's not just unpolished, it fundamentally doesn't work.
It took us some time, but it shipped, so by definition, it cannot be vaporware.
Yes, the scrollbar needs fixing. We're working on it. Remember that the framework is also open source, so we're open to receiving pull requests that help get these issues resolved sooner.
Wikipedia was once compared to Encyclopedia Britannica in terms of number of errors it contained. It had more errors, but shortly thereafter those errors were fixed. Many of the shortcomings of our scroller will be fixed very soon. Some fixes may take a bit longer, but anyone bitten by a particular bugs has the ability to fix the problem.
Linux also went through similar pains with obviously broken parts early on before it reached maturity.
I don't know about you, but I much prefer a world where open source projects exist, even if a little broken in the beginning. Whenever someone actively hates on an open-source project they are essentially littering in and poisoning the commons instead of helping cultivate and nurture that public space.
I think this is really the point I'm driving at that people need to consider. Building something of this magnitude and ambition takes time. It's open source and anyone, including everyone wielding criticism in this thread has the power to download the source code, try it out, find out where it shines and help polish it where it does not yet shine.
Give it a fair shot; discover its merits; help make it better for everyone.
>I absolutely loathe this attitude that has taken over entrepreneurship. This is not OK. I don't give a shit what the Lean Theory zealots say.
They've worked insane hours for over a year to create a tool. It's an imperfect tool, but one capable of doing amazing things. And they've given it away for free. How are you not OK with this?
If you work insane hours for over a year, your company is broken. That is a problem of time allocation and unrealistic expectations, and has no bearing on the quality or usefulness of the work being done.
As for "capable of doing amazing things", this is stuff that Flash was able to do better 10 years ago. If people hadn't forgotten where we came from, and browser makers hadn't ridden the CSS train to performance hell, Famous wouldn't even be necessary.
So far, all I've seen is a) huge, hyped up promises and b) janky demos that feel like some interaction design student's wild experiments. You don't need to be Apple to do this right, you just have to be able to be honest about the output of your own work.
I expect negative comments on occasion from everyone, but you've been registered on HN for 16 days and every single comment you've made since you've joined has been vitrolic haterade that adds nothing constructive to the threads you participate or the community. Do you ever have anything positive to say about anything? If you're so embittered, why participate here at all?
I agree but add that it's not lean.
Being lean means having reduced functionality but the bits that you do launch should work well. In this case, the launched bits don't work well.
Don't sweat it, I recall Meteor went through the same thing way back when - cool core technology, no security or other practical considerations - and look at them now, $11.2M Series A from A16Z. You can never have too many JS frameworks doing cool new stuff pushing the limits on what's possible on the web, launch warts notwithstanding.
Thank you for your comment. It refreshing (not because it involves my company (although that helps), but because it sets the right tone for the community). Encouragement with constructive criticism combined results in greater good.
TBH I'm not sweating it at all. I understand the criticism. Some of it is fair commentary from thoughtful people, some is typical cynicism that blinds the otherwise intelligent. At the end of the day, the only difference between a bug report and a rant is the tone of voice used to communicate.
I'm mainly trying to provide counterpoint so that others who have yet to make up their own mind have the opportunity to do so. Many discussions can often get trapped moving in the direction in which they start. Get of on the right foot and things evolve excessively positive without constructive criticism. Get off on the wrong foot and things spiral out of control into doom and gloom. Regardless of which way it goes, doing a reality check lets the conversation focus on criticisms that actually have merit instead of the devolving into the mutual admiration society or a grand hate parade.
Our website is not the product. I promise you that if you take the time to explore actual product we're working on, you'll see that it's pretty polished, but lacks some features.
The problem is that it seems to be the only thing bigger than a one-click demo built with the product that is available, so it is -- whether you intend it to be or not -- the most powerful statement you have about what the utility of your product.
(It doesn't help that the broking scrolling makes it very hard to get to some of the rest of the content.)
If you think it represents the product poorly, I think you desperately need (1) to not rely on your product for your whole public-facing website (dogfooding is good, but part of that is having good judgement about fitness for purpose), and (2) build something that has a clear role that is more than a trivial demo that demonstrates the real utility of the product (something that's part of your public website, and a key and useful part and not just a demo, may be good, but it needs to be something that the product is ready to do acceptably.)
Or, if the problems really are fairly minor, then fix the problems that makes using it for your whole website and turn that into a plus.
> I promise you that if you take the time to explore actual product we're working on, you'll see that it's pretty polished, but lacks some features
Asking people to do more work to discover the value of your product is generally not a compelling way to get people on board with it. If the external visitors first impression isn't positive, its not their job to work harder to get to a positive impression.
Your website is seen to reflect the quality & state of your product - by extension it _is_ your product.
I realize all the negative feedback must be demoralizing, but humans are silly beasts who have knee-jerk reactions to most things, and don't bother delving any further. Unfortunately, it's often best to cater to that.
The fact that you seriously say "our website is not the product" shows how utterly misguided you are in your marketing. I am not trying to be mean, this is simple and logical advice.
You make a platform for making websites. Your website is a huge turn-off that reminds everyone of every shitty over designed web brochure / 'experience' they've ever seen. And you think this is just a problem because people are picky.
For such an ambitious project, bugs at this stage are totally reasonable. The problem is that they're front and center following months of hype and promotion.
And there's nothing wrong with building momentum either, Famo.us has really done a solid job generating the buzz. But if you are going to take that route, then yes, the details at launch-time are dang important.
I'm very intrigued by the premise and think the progress is tremendous. But I can't really blame folks for their initial reactions and that's kind of a shame.
What use cases is this good for? It seems to be fundamentally broken on both desktop and mobile for even basic functionality. There's something that solves only some very narrow provide problem better than existing solutions; that offers clear, if niche, value. But I don't see how this rises to that level.
I'm not sure 'make scrolling (a feature the browser does natively) work on desktop' = "perfect everything"... I can perfect scrolling by creating a blank html page.
I think I'm the only person at the company that browses the web with JavaScript disabled, so I know how broken the original world wide web from when I first went online in 1994 is. I also remember using text-only browsers like lynx, and demonstrate it to co-workers on occasion. Lastly, I've been doing the web app development schtick for several years now and seen the good and the bad.
With all that in mind, the push towards progressive enhancement starting in 2003 when AJAX was just starting to become popular has proven to be a false prophet. IMHO, no idea has done more to make the web less accessible while also holding it back in terms of interactivity. You simply cannot use the same abstraction for both documents and applications and expect decent results for either.
What we should have done instead is allowed the two to diverge long ago and especially after 2007 when mobile computing took off and that change in screen size afforded us the opportunity to return to screens not all that dissimilar from those I remember using in '94. The first iPhone had a effective resolution of 320×480. You can effectively show as much on an iPhone as a 1994 computer monitor and have it be readable on both. In fact that's basis of the "Mobile First" design paradigm that frameworks like Zurb Foundation have pushed for. Designing content for a single-wide column that scrolls up and down, that you can jump backward and forward on via anchor hypertext references was a really smart abstraction for lots of content. The site http://www.motherfuckingwebsite.com/ illustrates this poignantly.
The technology direction we should have taken should have made sure that search engines, the blind (or otherwise disabled or dexterally challenged) actually remained the first class citizens on the web instead of taking the back seat to print designers and interaction designers. It's easy to take the content designed for those constitutents and make it available via APIs that can then be consumed by people making rich web apps.
We even had something like that, it's called RSS and it is glorious. RSS may have actually survived if it had not been for progressive enhancement which was crap but just good enough that people could get away with killing RSS off. Every technologist should make themselves familiar with the concept of path dependency (this Slate articles on the persistence of rockets as our primary way of putting objects in space is illustrative: http://www.slate.com/articles/technology/future_tense/2011/0... ). Had progressive enhancement not become the road taken, no one would have ever argued to kill off RSS in favor of a hack jobbed DOM implemented where maybe 1 in 100 developers actually understood how to actually implement accessibility. RSS and other means of programmatic content consumption would have become the prime way of being indexable by search engines. Everyone would have maintained content that way because it would have been in their self interest to do so. Not only that, progressive enhancement is just usable enough to not get sued under the ADA. Without progressive enhancement, businesses (read: at least every fortune 500 company and then some) would have poured gobs money to into making sure they have the digital equivalent of wheelchair ramps. Progressive enhancement gave everyone the opportunity to do the least amount of effort and still maintain a defensible position if challenged legally.
The screen reading experience has been shit for like for ever and it's only gotten worse as designs have become more complex. Skipping over the level of abstraction that made content usable programmatically not only impoverished those that need it, but those who don't as well because we're deprived of richer, more flexible APIs.
Having worked with webapps for a while, I think one of the most amazing improvements in the last 5 years has been the move towards displaying content on many more screens than just the desktop. This has forced us to go back to API solutions (usually REST, but sometimes RPC over websockets) that often ape what we originally tried to accomplish with RSS. This is the only sane way to provide content that needs to be displayed in different ways, from a Mobile First single long scroll page rendered by the server to a Famous/Ember/Angular/Backbone/React app that takes that server-rendered page and replaces it entirely with a rich interactive experience in the browser.
We (at famo.us) don't yet have a solution for this future that treats everyone as a first class citizen, but we eventually plan to address this if the community doesn't tackle it first. We've been inspired by a few attempts at figuring out how to achieve this. Spike Brehm and crew over at AirBnB have been exploring this with Rendr, that works with Backbone.js, https://github.com/rendrjs/rendr , and August Lilleaas has worked on a solution for React, http://augustl.com/blog/2014/jdk8_react_rendering_on_server/ . We feel like there is potential for a generalized solution that doesn't need to be necessarily tied to how one framework works.
If you look deep at Famo.us, we don't throw out the DOM wholesale, instead we use the DOM where it matters. In Famo.us, there is a concept of a Surface (which is similar to Layers in CoreAnimation). The Surface is basically a container for HTML Document Fragments, usually fragments that are very strongly structured semantically. The entire scene graph above each Surface node basically helps you programmatically abstract away all the bullshit that many today handle awkwardly with levels and levels of DIV hell controlled by JavaScript. This is not only the abstraction that makes building things in Famo.us easy and fast, but also provides a boundary where content gets lumped into semantic chunks that oftentimes should be consumable for use in a long-scroll, semantically rich, Mobile First design where navigation is hyperlinked anchor based instead of spatial navigation.
When browsers were first designed, they made a decision to have a 1 to 1 relationship between the window object and the document object. While reasonable at the time (remember: small screens, low bandwidth, high latency), this proved unscalable to larger screens, greater bandwidth and lower latency. Take Twitter for example. Twitter.com is basically an application for displaying a tiny document called a Tweet. There hundreds of tweet documents shown at a time. The code for tweets is semantically rich. The code for the twitter app? That's DIV hell. This is what Famo.us helps with. Like Flash and Silverlight before it, it helps apps be apps, but unlike its predecessors, it allows documents to be documents. Keeping these two separate keeps abstractions from leaking into each other in the code you write.
So while some things may be broken, and the way its broken may inspire ire, it's important to understand that it's not where the puck is that matters, but where it is going. The scrollview we've made is still inferior to the native scroller in a few ways, such as missing keyboard bindings, but are temporary shortcomings that we and the community are going to address in time. Eventually the feature and quality gap will narrow and the Famo.us scrollview(s) will reach parity with native scrollers.
Furthermore, some of the abstractions in the Famo.us scroller are remarkable for their programmatic flexibility. When most people think of a scroller, they only think of three scenarios: vertical scrolling, horizontal scrolling and a pannable tiled area (like Google Maps or Open Street Maps). This is actually a pretty limited view of what's possible to explore if you abstract a scroller to its essence. A scroller at is essential is a mathematical set with a curser and that all scrolling does (whether by mouse or keyboard) is move the cursor position in that set. When you think about it that way, many more things you've seen are scrollers. For example, the Apple Time machine view is a scroller in the Z-direction. CoverFlow is another scroller that is horizontal, but where the affine matrix transform applied to a surface is based on the distance of a surface from the cursor and inverts on each side of the cursor. One team of beta testers used the scroll view to display a DNA double helix. It was basically two position linked vertical-scrollers, where the positioner function didn't just set the position on the Y-axis, but also manipulated the affine matrix to create the helix shape.
While probably not the best approach, even Google's new interactive Rubik's cube doodle could probably be implemented as a series of Famo.us scrollers. Each scroller would contain 12 surfaces (doubly linked in a ring), with pagination occurring at every three surfaces. The pagination function instead of translating the surfaces along only one axis instead rotates all the surfaces 90 degrees around an axis. All surfaces would belong to two scrollers "perpendicular" to one another at any given time, being lifted from one to the other and back depending on which one was in motion.
And since all this is based on the same scroller, which will eventually reach parity with native scrollers, it means that they get all the same features. Home goes to the top of a vertical scroller, the left of a western horizontal scroller, the beginning of the double helix or the begging of time in z-axis time machine like scroller. End does the opposite.
These examples just begin to scratch the surface of what's possible when you expose primitives that map to mathematical concepts like a set and current index to developers.
Last, but not least, we're going to look at all the feedback on the scrollview and try to address all the issues you all have encountered.