Scribd CTO: “We Are Scrapping Flash And Betting The Company On HTML5″
techcrunch.com
techcrunch.com
Which is, of course, a killer move if they can actually pull it off as they will be the first and only company to do it (again, comparing with Google's Javascript PDF viewer misses the point, as that 'just' renders images). I am just dumbstruck to see a company do such a 180 degree turn and they deserve all the credit in the world for having the guts.
Isn't the point of this move to support the iPad, the iPhone, and other non-Flash environments?
A flash PDF reader is worse than useless. I can't use flash on my iPhone, and the Scribd reader used to break back when I used an Ubuntu machine. And it certainly never ran great on my Mac. When you consider that I already had perfectly fine, and free!, PDF readers on all three devices, Scribd was actively harmful.
But an HTML 5 PDF reader could actually be useful! It may be more lightweight than downloading a whole PDF. It will certainly be no worse than what I can currently use to render and read a PDF.
This is good. Scribd may change their image as a widely hated startup.
It's easy. Someone sends you a Scribd link. Scribd is written in Flash so maybe you can't read the damn thing. Before Scribd, people would just send you PDF links. Everybody can read PDFs.
Scribd harms the web by reducing the number of people who can view its content. That's what I call "providing negative value".
I hope a solution is found for this that doesn't require specific allowance of CSS embedding in the license. If it does, some fonts will never be legal to embed.
And the most ridiculous thing is that fonts aren't even copyrightable. (You can copyright the actual file with the fonts, but not the shape of them.)
Things to consider:
- What development tools will devs use?
- How long will it take devs to get up to speed on them?
- How does debugging work?
- How do you handle losing breakpoints?
- What does the new build process look like?
- How are you going to handle graceful degradation?
- How does font-end error reporting work?
- How long will it take to make the migration?
- What business metrics are you tracking to acknowledge you made the right user choice? The right technology choice?
- How soon will we see the needle move on those business metrics?
- How will this affect growth in the short term?
- Do your hardcore Flash employees want to be working in HTML5? What will you do if they don't?
Major technology shifts are a lot more complicated than just "code it and see what happens" when you have an established product and team.
The Google pdf viewer seems good enough to me. It'll be interesting to see what you can improve on that.
I do see the value for formats like .pptx where I may not have a reader, but PDF is already a "lowest common denominator" like HTML.
Sure, I like reading my PDFs with evince, but sometimes HTML is just preferrable.
I've always thought that the best solution would be for browsers to just include PDF rendering support alongside HTML. PDF is a popular enough format on the web that it should really be handled by the browser as a core feature, not by some add-on or external application. I really liked Apple's Safari for this reason (although I dumped it for Firefox because of AdBlockPlus).
Done right it would seem like perhaps some of the higher-level rendering layers of the browser could be reused, regardless of whether the underlying content was PDF or HTML. (In fact isn't this how Safari works, with Quartz?)
No offense to Scribd, but I'd like to see the need for their service go away by in-browser support for progressively-downloaded PDFs.
Removing yet another plugin from your browser shrinks the attack surface, and as a side benefit, reduces use of one of the worst IMO bits of web tech.
PDF -> Internal Representation -> Flash viewer
In principle they should only need to change to
PDF -> Internal Representation -> HTML5 viewer
That alone should make a huge different in terms of time needed.
Never having done something similar myself, I would expect the hardest part to be correctly parsing the original PDFs and dealing with the varyiaty of PDF generators out there.
To me, this feels like desperation. It seems a little late to stop depending solely on Flash. Also, why not say that you're moving after you partially move? The companies I admire the most brag about distant features the least.
I wouldn't use any of the more complex/less-supported features of HTML5 on any live site today, that's for sure.
I always thought that Flash was quite performant compared to browser-based Javascript. Can you point to any benchmarks?
I work with a hardcore Mac zealot and it's a running joke in the office that he will complain about Flash performance every single day.
Now, people who had never heard of this company are aware of them and am 100% sure their hit rate when way up high today.
We're just that amazing. ;]
In reality what you are saying is that if X happens, you waste alot of time, if !X happens then there is still no guaranteed outcome.
I don't agree that the odds are fixed, nor that it's all-or-nothing-to-the-end. For any startup, you take mortal risk as infrequently as you can; you hedge those bets as much as you can; and, since you can invest effort to change the game in reaction to the market, you work to improve your odds over time.
So in the end, I believe you present a false dichotomy. It's rarely $100MM or death, and there's never a guaranteed outcome.
1) Flash is prevalent today. No matter how much people are bashing it on HN, its widely used especially on the sites which are incredibly popular. 2) HTML5 adoption will be slow. Look at how long it to ie6 to die and you'll have an idea of how long it will take html5 to become prevalent. 3) You're taking a technology that allows you to be accessible today and trading it for a technology which will allow you to be accessible at some unknown time in the future, basically removing any barrier to entry for your competitors.
The hyperbole makes this seem worse then it is, I'm sure. You don't really have motivation to ditch your current flash implementation. You'll just put it into a "support as needed" mode.
Come on, it's great that they're ditching Flash, but if it really works on IE6 calling it "HTML5" is nothing but link/pageview-bait. The parts of HTML5 that are supported by IE6 are called HTML4 and Javascript.
http://webcache.googleusercontent.com/search?q=cache:ggG39gK...
One thing that does occur to me is that copy and paste auto attribution link stuff that's getting popular on news sites, something like that could hold more value / less overhead / easier to spread than the awkward embedded widget approach.
Edit: it turns out they already present the text at least some of the time, but markup and text portability still adds some value (see my comment above).
"Friedman estimates that 97 percent of browsers will be able to read Scribd’s HTML5 documents"
That pretty much counts IE6 into the picture, so I'm really wondering exactly what "HTML5" features IE6 supports!
HTML5 isn't something that just came around. It's been in the works by browser makers for quite a while, which is refreshing. Rather than it being a spec made up in a purely academic environment (XHTML 2), it's something that's made up of technologies that have already been used by one or more browser makers (and often, developers on real sites.)
Also, using the HTML5 doctype in IE6 causes IE6 to go into standards mode, which is just pure luck.
You can do a lot of good for users if you start using some of the HTML5 features right now, even if it's not apparent. If you use the type="email" for your forms when you ask for an email, the ipod and ipad will bring up the Email keyboard layout. That alone is kinda cool.
eg:
http://docs.google.com/gview?url=http://infolab.stanford.edu...
Users won't see any difference, or care.
I do think scribd up to now has been pretty bad for the web, locking plain text documents and images up in their walled garden. Maybe they can change that, but what value can they actually add? What problem are they solving?
I understand the added benefits of being able to comment, discuss, share, etc.. your documents with Scribd, but honestly why the need for HTML5 or anything at all? PDF's are viewable just fine in a simple PDF viewer.
ps- i win newsyc bingo: YC company, techcrunch article, HTML5.
Needs: * Facebook integration (or even better for HN cred - removing facebook connect) * "Now works on iPhone/iPad"
DHTML or javascript would have been good enough then, wouldn't it?
for one it might help push a few people into using more html5 capable browsers.
From the article:
"Friedman estimates that 97 percent of browsers will be able to read Scribd’s HTML5 documents because those parts of the standard are older and more widely adopted."
I don't read that as 'graceful degradation', but as a subset based on older tech.
However, the documents will basically look the same across all of our supported browsers.
When I met Microsoft's Chief Software Architect at PDC last year, he kindly thanked me for "betting on Azure" and I thought to myself "I'm just experimenting with a new technology that may make my life easier, I try my best not to ever bet on anything". Not wanting to be a smart-ass jerk, I just talked about lolcats and 4chan instead.
Reading about what Scribd is doing, it seems that the metaphor is pretty appropriate.
Plus the upside is their stuff will then work on mobile devices too.
Plus, it will maintain the fidelity of the document -- meaning that even PDFs with complicated layouts will be rendered properly in HTML. No trivial task.
It's a great technical challenge, but will users notice the difference?
Once this is live, Scribd will gain at least myself as a user, and I suspect many more.
(Nesting is too deep to reply to axod, so: the fact that Google is doing this should be reason enough. Scribd exists as a place to publish material. That material should be reachable by as many users as they can manage.)
Works fine for me :/
Especially if your users are disabled.
I don't know how Scribd is going to carry this off, what with people sometimes uploading outright scans of books. I mean, Scribd is not Scribd without the stuff put there by people -- like with Youtube.
You can get alot of drawing flexibility if you use Canvas, but performance of any Canvas-bridge for IE makes it not worth using.
Now if only I didn't have to log in to read it.
Because I never have been able to before.