
Apply HN: Bubblin Superbooks - marvindanig
https://bubbl.in/books
======
marvindanig
Hello HN!

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](https://github.com/marvindanig/ABCD-Animal-Book)

[1]
[https://news.ycombinator.com/item?id=11237233](https://news.ycombinator.com/item?id=11237233)

[2] [https://bubbl.in/cover/alfabet-polski-by-tomasz-
walen](https://bubbl.in/cover/alfabet-polski-by-tomasz-walen)

------
mydpy
My concern is that the relationship between time to create content and
financial reward will dissuade people from adopting your platform.

------
buss
How will you work with authors to make these books? I would wager that most
authors don't know HMTL5/CSS3.

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?

~~~
marvindanig
> How will you work with authors to make these books? I would wager that most
> authors don't know HMTL5/CSS3.

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 :-)

[1] [http://bookiza.io](http://bookiza.io)

[2] [https://vimeo.com/64895205](https://vimeo.com/64895205)

[3] [https://bubbl.in/support](https://bubbl.in/support)

------
sandGorgon
the problem with ebook or magazine publishing isnt hosting the created books..
but its the creation process itself. Which is why I have a lot of hope for
things like [https://atlas.oreilly.com/](https://atlas.oreilly.com/) .

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

~~~
marvindanig
> ... solve for supply side via a creation mechanism

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.

[http://bookiza.io](http://bookiza.io)

------
mydpy
ARGGHHHHH! Poor zrebak!

[http://imgur.com/dc4Ek81](http://imgur.com/dc4Ek81)

~~~
marvindanig
Thanks!

Which browser/OS are you on? I've alerted Tomasz & Judith about the zrebak
losing its head ... :P

~~~
mydpy
Chrome/Mac OSX (latest)

------
wehadfun
Can superbooks be hosted from, sold through, other platforms?

Can I create a super book and sell it on Amazon or my own website?

~~~
marvindanig
Yes, you can host it anywhere -- even on Github[1] pages!

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! :-)

[1] [https://craigleat.github.io/#1](https://craigleat.github.io/#1) [2]
[http://bookiza.io](http://bookiza.io)

------
PM_NAKED_PIKS
What are you looking that YC offers? Or, do you just want the YC stamp?

------
sharemywin
How do you make money?

~~~
marvindanig
Good question! I'm Marvin here, one of the co-founders.

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.

~~~
sandGorgon
You could be a marketplace for new content if you get authoring right.

------
slang800
I'm so tired of sites trying to bring animated/turnable pages to the web.
Pages make sense when you're constrained to to the size of a physical book,
but here on the web you can have infinitely long pages with sections divided
however you want. There should be no need to click a button to advance or
split your text by what fits onto a page, and it certainly shouldn't need to
break the Find tool.

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.

~~~
accordionclown
> There should be no need to click a button to advance

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

~~~
marvindanig
> pagination gives the ability to "chunk" the content.

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.

~~~
slang800
> Piece-mealing helps people remember the content better.

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.

~~~
accordionclown
actually, i have in mind "chunking" like this:

    
    
        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.

