From my very first post on Steemit/HiveBlog, my goal was always to bring over more creative story tellers. However, let's face it... HiveBlog is not optimized for long form story telling!

I've been giving this proposal some thought over the last day since I saw it, and while I am overall in favor of the idea of new interfaces which bring different ways of lensing the content on the blockchain for the purposes of different consumption patterns, there are a couple of issues that I think may need to have some refinement.

The content is usually followed by a detailed blog to add depth to the post. This can actually take you out of the story, preventing you to keep on reading.

Let's start with this one. One of the few advantages of using what is effectively a blog platform and blog interface for longform content creation (or more accurately in this case, episodic content creation, for reasons I will get into shortly) is the fact that there can be commentary on the text right there with the text, not just created by the original author but in response to the author's thoughts.

While I agree with you that having the episode/chapter/serial content literally interspersed with the commentary is not always a positive when you want to focus on consuming the material itself, removing that entirely from the scope of consumption is to take a step back away from the tools that are available.

One of the better ways that I've seen to actually enable that sort of parallel work/commentary is done on Medium, which for all of its other failures manages to provide a visual and experential interface to both authors and consumers which maintains the coherence of the main text while allowing commentary on that mean text – and it does so by moving that commentary off to the marginalia, which harkens back to an earlier time.

Since Inkito is going to have to build its own presentation from what is effectively going to have to be text content leveraging the already extant Hive blockchain interfaces, there's no reason not to simply use some sort of plaintext header on a post or comment to point to an offset in the original post that a comment, like a footnote, is intended to be read at. Likewise, commentary on the chapter/section as a whole can be moved off the presentation as if it were a footnote section at the bottom, by default kept closed without deliberate user intervention.

Since you're going to have to do the threading of commentary anyway, at some point, you might as well build the capability to hang those comments on specific locations in the text/document upfront and provide functionality beyond what Hive.blog does without too much overhead.

Looking at a profile page can seem chaotic as many series could interlace and get mixed up with blogs and reblogs.

This is absolutely true and would be a great advantage for people who are looking to be engaged with an ongoing narrative or project.

But this isn't longform content.

We need to be clear about what we're talking about here, because longform is a very different thing than serialized/episodic, and all of the tools that you're talking about are focused on improving the latter and don't really do anything for the former.

Longform is specifically about a singular creation which takes significant time for the consumer to engage with.

Movies are longform video media. 56 episode TV series which provide 28 hours of content but are intended to be consumed 30 minutes at a time are not longform content and probably shouldn't be treated like it. They are episodic. They are serialized. They profit heavily from a consumer being able to navigate from one episode to the next and back easily. Classic pulp serials, both filmic and paperback, fall heavily into the serialized mode of presentation. Some classic sci-fi/fantasy of the 60s/70s/80s of the sort you would find published a chapter at a time in Analog is the kind of content that profits most from the architecture you're describing. None of that is longform.

This is really important to nail down because a platform designed to facilitate longform content needs very different tools. Longform doesn't tend to be written and presented a chunk at a time; it is a coherent whole. Edits happen along its entire length and often involve reorganizing entire chunks. It makes no sense to publish one a little bit at a time unless it's already been completed and just being sent out into the world a chapter at a time. But that doesn't seem to be the sort of content you're talking about. (It can leverage the publication process of serial content but not the evolving engagement with an audience in the same way.)

It's the difference between showing people a movie 15 minutes at a time and publishing a comic book which is only completed a couple of issues ahead at any given moment so that audience feedback or just creator whim can change the direction of the creation in relatively short order. With episodic serials, it is expected that earlier content in the line is static (or relatively so) because story evolution will happen as a result of further revelations moving forward in the text. With longform content, if it is still evolving, then those changes can happen anywhere through the text.

As I implied before, longform content which is deliberately presented in a serialized format straddles the divide. If I write a novel and post it a chapter at a time to the Hive blockchain, it is episodic and it is serialized, but I need to have it done before I start because otherwise I'm going to have to edit things that have already been presented and there really is no "serialized" way to experience it. It has to be static when I start. Compare this to deliberately episodic content which is explicitly not complete at any particular time and may never be complete (example: soap operas or professional wrestling) in a narrative sense.

I am creating Inkito, an interface that uses the Hive api specifically for long form content.

So – when it comes to all of these features, I'm generally on board. Unique tags which allow the front into build its own navigation presentation? Absolutely great. Improved reading experience (hopefully involving better fonts for text presentation with a larger size, better line height, and as you say infinite scrolling) is going to be a huge boon. Being able to be displayed with unique cover is pretty nice, though I would ask whether that is going to be maintained through traditional posts to the blockchain or through your own side database? A simplified interface? Maybe good, maybe bad. If you could lift the block-focused editing experience from Medium which makes inserting image content and formatting it for a better controlled experience easier, that would be 90% of the way there.

But we need to take a moment and think about what currently exists on the blockchain in terms of interface that competes.

At this moment, the most competitive way to create episodic content and make sure that people experience it in a linear way as you publish it is probably creating a Community and using that to make posts which are intended to be read as serialized content. If you're serious about it, you can create a second Community with a slightly variant name to make the author-commentary posts which normally get integrated into the content post as people currently use the system. That separates out the content from the commentary and allows you to link from one to the other. Overall, it's a pretty decent way to manage that sort of thing, even though it doesn't have standardized tagging.

Your design would have the advantage of automatically building an infinite scrollable content box for a given project (though that's only particularly useful if you either want to start from the top and read all the way through to the bottom and never want to start over from somewhere in the middle or pickup from the last one you read, though there are interface tricks you can use for that sort of thing – like bookmarks or thumbs), and the ability for people interested in serialized content to have one stop shopping for a place to look for it, which goes a long way. Discovery on Steem/Hive is terrible and anything that allows you to lens content to find what you're looking for is a huge win.

Like I said, in general I'm in favor of it but in specific I think there needs to be some more development on the idea of retaining the advantages you have in having content on a dynamic blockchain which is strongly focused on providing commentary and feedback.

There is also the complication that Hive, like its predecessor, only allows content to be rewarded by upvotes for seven days and serialized content very often extends much further back than that. Some sort of relationship with one of the tipping bots being integrated into the framework would at least allow that Evergreen content to continue to provide earnings for its creator. Something that creates a comment with rewards delegated to the original creator and then votes for itself might be ideal for that purpose.

Just some thoughts for you to chew over as you work on things.