clicked Api, got "Error loading swagger, check your console! ",
console:
Cookie “_strings_session” will be soon rejected because it has the “sameSite” attribute set to “none” or an invalid value, without the “secure” attribute. To know more about the “sameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Cookies api
This page uses the non standard property “zoom”. Consider using calc() in the relevant property values, or using “transform” along with “transform-origin: 0 0”. api
TypeError: Handlebars.templates is undefined application-d45c746a70f556a197d941960cdabf73f08287b8182fe84439e83435d7c0fa7b.js:31:29766
Element to highlight #swagger_sidebar not found universalModuleDefinition:1
Element to highlight #Users_post_login .content not found universalModuleDefinition:1
Element to highlight #Users_post_login .samples not found universalModuleDefinition:1
Element to highlight #sample-Users_post_login_body not found universalModuleDefinition:1
Element to highlight #Users_post_login .sandbox not found universalModuleDefinition:1
Element to highlight #Users_post_login .samples not found universalModuleDefinition:1
Element to highlight #swagger_sidebar .scope-selector not found universalModuleDefinition:1
Technically speaking, this is a super awesome product.
But is it really needed? I could see this opening up issues with security if multiple people have access — and if only one person has access, then why not simply forward the finalized changes to someone who can commit and push instead of sending it to someone on the marketing team?
We use a similar (but clumsier) tool for our Gatsby site. It excels for quick content changes. However, for us specifically, we found that we didn't really edit the content as much as we anticipated, and that most of our quick changes boiled down to styling changes instead. So maybe an ideal product for us will allow editing of styling as well as text? It'd probably look a lot like webflow.
Heh, this reminds me of my discovery, circa 2001, of a content manager who'd created a workflow for editing a key landing page:
1. visit page in prod
2. use browser's "save complete page as..." feature
3. edit the resulting HTML
4. SFTP her edited version to the server (a 3rd-party landing page SaaS platform)
She published changes this way for weeks (months?), mutually oblivious to her colleagues' standard workflows, before I tracked this down as the source of the mysterious "problems" with the nascent homegrown CMS used by the content team.
I guess it wasn't obvious from
my description that her rogue DIY workflow coexisted with a small team's properly-supported workflow involving a CMS, revision control, asset pipeline and test environments.
No, I get it, more of a comment on the unnecessary complexity of a lot of sites that have a minimal amount of dynamic content or user interaction, and yet implement very complex workflows for the content editors.
From the description (“make any website editable inline”), I expected this to be a browser extension or similar that would allow you to change the content on any website. I find instead that it’s a CMS sort of thing, and is just a way of editing content on sites that you control and set it up on.
But in case anyone wants the other:
document.designMode = 'on'
It’s pretty cool. Basically it makes the whole page a contenteditable. Many years ago browsers had more involved UI wrapped around design mode (which was also exposed in the menu), with a formatting toolbars and such.
There were a lot of people showing how they "hack" a long time ago using a similar command `document.body.contentEditable = true`, changing their PayPal balance to $9999, thus getting free money!
This tool definitely seems very close in spirit to mavo, but paid. I didn't last long enough after the autoplaying video to learn if there's anything it can do that mavo doesn't do (maybe hosting services?) that's worth paying for.
I built one of the first of these in the original dotcom boom. The reason ours didn't stick around was because it just wasn't that difficult of a problem. People were willing to pay a little for a CMS, but not a lot. They thought editing live on the page was pretty nifty, but didn't actually add enough value for them to pay extra for it. As the web matured, and more people were capable of putting together web pages, the floor dropped out of the pricing for such tools.
So it isn't that there is a problem with the concept - most people like the actual app. It just doesn't solve a problem that people are willing to pay much for, which makes these types of CMS tools interesting, but not great businesses.
I built one of the first of these in the original dotcom boom.
It's weird to hear that the idea has been floating around for so long. I'm working in yet another version of it. Would you mind pinging me by email? It's in my profile.
I wouldn't like to repeat errors. You say people are not willing to pay for it, maybe there's some other way to add value...?
I added my email to my profile - feel free to reach out.
But in short, my work is and always has been around content management. However, the value of my products is no longer the ability to put a document online - there are plenty of solutions for that. My recent products offer value by making the document authoring part of a larger workflow solution, tailored to improving the lives of people who consume the documents, and helping build products that allow content to flow between people, sites, and systems.
That may be overly vague, but the point is the value comes from workflow, not individual documents.
Founder here. I launched the site about 6 weeks ago on ProductHunt to gather feedback and am currently building out a larger offering and preparing to open the doors to the public in a few weeks - inline editing will continue to be part of the value proposition, but we're also going to focus on building the simplest content API possible, which was a surprisingly large request among the early signups. Would love to answer any questions people have. Will post to show HN again when we launch the updated site and product in a few weeks.
Technically yes, but we'd like to also be used for storing content used by web apps - the CMS is designed for web sites. An analogy that might work well here is the difference between Redis vs. Postgres. Redis = optimised for key/value data at high volume, Postgres - optimised for relational data. That's how we see ourselves vs traditional CMSes.
38 comments
[ 4.6 ms ] story [ 95.3 ms ] threadconsole:
Cookie “_strings_session” will be soon rejected because it has the “sameSite” attribute set to “none” or an invalid value, without the “secure” attribute. To know more about the “sameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Cookies api This page uses the non standard property “zoom”. Consider using calc() in the relevant property values, or using “transform” along with “transform-origin: 0 0”. api TypeError: Handlebars.templates is undefined application-d45c746a70f556a197d941960cdabf73f08287b8182fe84439e83435d7c0fa7b.js:31:29766 Element to highlight #swagger_sidebar not found universalModuleDefinition:1 Element to highlight #Users_post_login .content not found universalModuleDefinition:1 Element to highlight #Users_post_login .samples not found universalModuleDefinition:1 Element to highlight #sample-Users_post_login_body not found universalModuleDefinition:1 Element to highlight #Users_post_login .sandbox not found universalModuleDefinition:1 Element to highlight #Users_post_login .samples not found universalModuleDefinition:1 Element to highlight #swagger_sidebar .scope-selector not found universalModuleDefinition:1
But is it really needed? I could see this opening up issues with security if multiple people have access — and if only one person has access, then why not simply forward the finalized changes to someone who can commit and push instead of sending it to someone on the marketing team?
1. visit page in prod
2. use browser's "save complete page as..." feature
3. edit the resulting HTML
4. SFTP her edited version to the server (a 3rd-party landing page SaaS platform)
She published changes this way for weeks (months?), mutually oblivious to her colleagues' standard workflows, before I tracked this down as the source of the mysterious "problems" with the nascent homegrown CMS used by the content team.
But in case anyone wants the other:
It’s pretty cool. Basically it makes the whole page a contenteditable. Many years ago browsers had more involved UI wrapped around design mode (which was also exposed in the menu), with a formatting toolbars and such.javascript:(function () { document.designMode == 'on' ? document.designMode = 'off' : document.designMode = 'on';})()
javascript:(function () {document.designMode=document.designMode=='on'?'off':'on';})()
You can screenshot it, and use it as "proof".
I've seen people get scammed in this fashion - "he showed me screenshot of his bank balance!"
I suppose I still like the idea of persisting those changes for websites I control but that's going to be way less straightforward.
Good idea but bad idea?
So it isn't that there is a problem with the concept - most people like the actual app. It just doesn't solve a problem that people are willing to pay much for, which makes these types of CMS tools interesting, but not great businesses.
It's weird to hear that the idea has been floating around for so long. I'm working in yet another version of it. Would you mind pinging me by email? It's in my profile.
I wouldn't like to repeat errors. You say people are not willing to pay for it, maybe there's some other way to add value...?
But in short, my work is and always has been around content management. However, the value of my products is no longer the ability to put a document online - there are plenty of solutions for that. My recent products offer value by making the document authoring part of a larger workflow solution, tailored to improving the lives of people who consume the documents, and helping build products that allow content to flow between people, sites, and systems.
That may be overly vague, but the point is the value comes from workflow, not individual documents.