I know what I want. It’s pretty ambitious:Today, I wrote to him about why his call for software is misguided. It's advice I would do well to take myself!
I want a database-centric personal publishing platform.
The front end is sort of like a word processor. But it is really a database.
...Then I can extract this data in many forms. My first extract would be to send it to a blog for posting. Perhaps I highlight the group of text and images i want to send. The blog has a style sheet which styles the output. I check the result and look and I get to manually override styles before I publish.
The same information is also sent out in a an email with a different set of styles and parameters. Or it may have some extra bits of info taken from the database.
I may then take a whole bunch of postings and want to reformat it for a more permanent web page, with a different look, structure, function.
And I will definitely want to extract the same data into a page-makeup layout program and make a long-form “book” out of the same stuff with different formatting, style, etc and make a PDF or print it.
Here's what I wrote:
Kevin, I think the trend has been away from all-encompassing software systems towards an ever-changing constellation of tools--for better or worse.
E.g., consider if someone had built a solution approximating your description at the time that you wrote this. Would the email component be as good as MailChimp? Would the blog component be as good as Medium?
And then there is version control. Think how often you might make a change in one context--say, more frequent paragraph breaks on your blog--that you don't want to percolate to the rest, say, the book version. Then, you rearrange the wording of a sentence that now starts a paragraph. Should that change percolate? Should it prompt you to percolate the paragraph break after all, in case they are contextually linked?
One problem with using our imaginations to fantasize about functionality is that we tend to see the intuitive ease-of-use and not the pain that would come from avoiding hard decisions in the design. When we look at the limitations around us, they seem hopelessly small minded and unimaginative; and often they are! But a lot of the time those limitations come in part because they allow us to avoid the misery of recursive unintended consequences of overly ambitious software.
In other words, the fact that you couldn't do all this stuff in 2008, and still can't today, may well be a feature of successful software, not a bug!