Apply HN: Bubblin Superbooks
bubbl.in
bubbl.in
We're the Bubblin'oes and we're trying to "reinvent" books.
I know this sounds a bit hackneyed but our motivation with Bubblin is to make books a first class citizen of web. Make them gorgeous, accessible and full of life.
It starts by considering that book is a collection of webpages. And then we can choose to do books with anything inside 'em: WebGL, Shaders, CSS3, JavaScript, HTML5 - you name it!
Recently one of our books 'ABCs for babies'[1] was well received in this community.
It's nothing but a bunch of cute alphabets and animals done in pure CSS3. It's also open source:
[0] https://github.com/marvindanig/ABCD-Animal-Book
What would be the incentive for an author to work with you vs. a more traditional publisher?
How big is this market compared to mostly-text ebooks and print (picture) books?
Great point!
So right now there's a great divide between the world of authors and let's say front-end developers. But there is some intersection too and that is where we focus currently. We work closely with new writers (I personally sit with them or collaborate with them over Github) and try to yield their thoughts into telling creatives -- it's a bit different for everyone, depending on the nature of book/individual etc.
In the medium term we intend to provide this as a process with which developers and designers can work alongside ordinary writers to help them create bestsellers. As if the book were an app!
Part of our strategy is also to provide open source tools (See bookiza[1]) and predesigned templates so that writers can start off quickly and not have to worry about HTML/CSS, or the underlying "tech". They can focus on writing their story instead and leave the "tech people" handle their tech. Obviously, different people have different skills and preferences so we'll see if this evolves into a 'book writing framework' sorts or just a, say, predesigned editing/word processing tool or a set of hard rules that people may or may not always follow.
> What would be the incentive for an author to work with you vs. a more traditional publisher?
There are quite a few big ones:
1. Number one: The ability to create a winner.
Imagine a horror story with a webgl interactive showing blood spilled on a glass table? Eww. Heh, I just made it up but why not! :=) You can add visual explanations[3] to the context, like showing a physics experiment to explain how a pendulum works or showing how projectile motion can become an in-orbit flight around a planet with acceleration etc. -- in your book. It will add life to the context of your story.
This simply isn't possible on traditional platforms that are based on artefacts that sit outside of web. In other words, with Bubblin you'll be able to do books that are otherwise impossible to do elsewhere.
2. Second big advantage: 100% Support!
Our books work everywhere -- all devices, all OSes, all viewports[3]. They are responsive and scale well. In theory, your book can reach everyone on the web and not just those who are behind similar but closed ecosystems today.
3. Third, it takes about half the time to get the book out. Guaranteed! I encourage you to try Bookiza and see for yourself.
Why so? Because HTML and CSS!
Compared to writing with an enterprise-y tool like MS Word and then having a bunch of people (editors/friends) back-and-forth it and then converting it to N different ebook formats this one rakes in much less complexity and saves time.
We tap into all the advantages of our existing developer toolchain - using git for versioning, ability to collaborate with co-authors on Github, using markdown or haml or just plain text, utilizing rapid manuscript deployments for editions etc. etc. etc. So quite a few advantages in there!
4. Fourth, the readers don't have to wait for a book to download or worry about disk space. Again this is convenience & simplicity of web. There is no botheration of managing files or their compatibility, format or other issues. Portability is simply in-built. I mean, it just works!
> How big is this market compared to mostly-text ebooks and print (picture) books?
You can always do a text-only book or an images-only magazine on Bubblin. Whatever makes your readers happy!
ebooks market size and opportunity is pretty big even if we subsection it into just interesting set of interactive books. I'll be happy to run by some numbers if you want.
Feel free to reach me at marvin@bubbl.in :-)
You need to solve for supply side via a creation mechanism - the demand side will come. If you havent already, do spend some time on reddit.com/r/selfpublish
Yup, that is pretty much spot on!
Let me invite you over @bookiza? - our open source book reification framework. It's on similar footing, as you've suggested, but still very different from traditional online publishing.
Which browser/OS are you on? I've alerted Tomasz & Judith about the zrebak losing its head ... :P
Can I create a super book and sell it on Amazon or my own website?
Our open source tool - Bookiza[2] - does exactly this.
It will bootstrap a project (manuscript) for you in your local. Then:
$ bookiza server
Now you can "develop" your book like it were an app. Once ready, hit
$ bookiza publish #and boom it will go live.
Yep, it is fun! :-)
Short answer: "We don't".
But I'm personally looking forward to sell my work online. Which is also likely going to be the business model for other writers/developers in our community.
I have to admit that some of these books make great use of the layout, with 2-page wide drawings and text fit around the illustration. However, that same effect can be accomplished with vertical scrolling (as Medium has done) and those 2-page wide drawings get split in half on mobile where only one page is visible at a time.
> ... but here on the web you can have ... pages with sections divided however you want.
Yep, exactly. :-)
Yes, I'm familiar with the type of work they publish, but I'm talking about those beautiful full-width images they use (https://help.medium.com/hc/en-us/articles/215679797-Images), in comparison with the 2-page wide images used in some of the example books. And full-width images have even worked well for longform stories like https://medium.com/matter/who-killed-the-jeff-davis-8-d1b813... ... Just look at those illustrations and consistent color-palette, absolutely beautiful.
> > ... but here on the web you can have ... pages with sections divided however you want.
> Yep, exactly. :-)
The phrase "infinitely long" is important. Without it, it sounds like I'm talking about fixed-size pages, rather than a single page encompassing an entire chapter or even an entire book.
it's not as if a user doesn't need to do any manipulation of any kind in order to scroll. with that being the case, i don't see how clicking a button to "turn a page" is worse.
and as pagination gives the ability to "chunk" the content, to avoid problems such as pictures split across the viewport, i see pagination as a much smarter mechanism in many cases...
but a hybrid mode that enables both preferences is the best.
-bowerbird
This is super super critical! Piece-mealing helps people remember the content better. It has a direct impact on the ability to recall and then apply those concepts later in life.
It is pertinent to mention here that web is no longer desktop only. It is there on mobile and tablets and people consume web on each differently at different times of the day. It will be very wrong to assume that our application interfaces do not have to evolve accordingly. And by that I mean a lot of hearsay from 2003 isn't valid anymore.
For example, it can be a real pain to read an essay on mobile that has reflowed into what one would call a thick "billing paper roll". You keep scrolling and scrolling and not even be at the middle of the article by the time you're done. In fact many people quit reading blogposts midway just after 2-3 downswipes and then they reopen it on their desktops.
For a book, it is simply out of question.
Chunking (in the context of cognitive science) does help with recall, but I rarely see pages being used to group relevant information... The tendency seems to be "fit as much as you can on a page, and only break to the next page early if you reach the end of the chapter". This doesn't apply to picture-books (where the use of illustrations is dictates layout more than the text), but it does apply to the _majority_ of published books.
I see "chapter (or header) -> paragraph -> sentence -> word" as the way written works are organized, with pages providing an index for lookup and marking progress, but not for denoting meaning. For example, I'll remember the story Contracrostipunctus and that it was at the end of chapter 3 in GEB, but I don't have a clue what page it was on and if the page numbers changed between editions (or were removed entirely), I probably wouldn't notice.
> It is there on mobile and tablets and people consume web on each differently
That's part of why pages are such a pain. On my phone (which is significantly smaller than a book) I need to scroll from the top to the bottom of the page, and then turn the page and scroll back to the top. On some readers that present fixed-width pages with a tiny font this is even worse because the pages don't reflow to the width of my device and I need to scroll left-to-right for every single line. Bubblin doesn't have this problem - it just crops off the left side of the page and refuses to let me zoom, but I write this with the assumption that it'll be fixed and will exhibit the aforementioned problems simply by virtue of having a fixed-size layout.
> You keep scrolling and scrolling and not even be at the middle of the article by the time you're done. In fact many people quit reading blogposts midway just after 2-3 downswipes and then they reopen it on their desktops.
Citation? I've never done this before or seen it done. I actually like reading books on my phone because I can lay in bed in any position and read till I fall asleep.
a chapter-header should not appear in the
middle, or at the bottom, of the viewport.
initial text after a chapter-header should
appear in the same viewport as that header.
the first line of a paragraph shouldn't be split
across viewports from the rest of the paragraph.
the last line of a paragraph should not be split
across viewports from the rest of the paragraph.
an image should not be split across a viewport.
a caption for an image should appear in
the same viewport as the image itself.
the table-header for a table should not be
split across viewports from the table itself.
a table which will fit entirely within the current
viewport should not be split across viewports.
the caption for a table should not be split
across viewports from the rest of the table.
a blockquote should not be split unnecessarily
across viewports if it'll fit on a single viewport.
a list should not be split unnecessarily across
several viewports if it would fit on a single one.
a description term should appear on a viewport with
its description definitions, to the extent possible.
the last paragraph of a chapter shouldn't appear on
a separate viewport from the rest of the chapter.
any two contiguous chunks of text which refer to
each other should be shown on the same viewport.
the cover-page for a document shouldn't be split
across multiple viewports, if at all possible.
a dedication page shouldn't be split across viewports.I know this is the kind of thing it's easy to lead with on the internet without thinking, but for present purposes it does not count as nice. Please be nice in these threads: https://news.ycombinator.com/item?id=11440627.
It doesn't! That's the whole point right there.