Editmode: Make any website editable inline(editmode.app)
editmode.app
Editmode: Make any website editable inline
https://editmode.app/
38 comments
i have a bookmark for it: javascript:(function () %7Bdocument.designMode%3D'on'%7D)()
I actually have this one :
javascript:(function () { document.designMode == 'on' ? document.designMode = 'off' : document.designMode = 'on';})()
javascript:(function () { document.designMode == 'on' ? document.designMode = 'off' : document.designMode = 'on';})()
Just so you know, the immediately-invoked function expression (IIFE) syntax is unnecessary here. This would do:
javascript:document.designMode=document.designMode=='on'?'off':'on'Oh my god, I had the same thought and forgot how readily this features actually exists.
I suppose I still like the idea of persisting those changes for websites I control but that's going to be way less straightforward.
I suppose I still like the idea of persisting those changes for websites I control but that's going to be way less straightforward.
As a kid, I used to love doing "document.designMode = 'on'"
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!
But then you can't do anything with the changes, right? Like Inspector, it's all lost when you reload the page.
> But then you can't do anything with the changes, right?
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!"
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!"
You can still have JS running on the page, e.g. to periodically walk the DOM tree and save changes to disk.
Huh, clever! I wonder if anyone has built that.
I also think Mavo is a pretty neat tool for this: https://mavo.io/
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.
Every 5 years or so there is one of those CMS with edit inline, I always wish them the best but they usually don't stick around?
Good idea but bad idea?
Good idea but bad idea?
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.
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...?
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.
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.
Beware, page has auto-playing video with audio about half way down the page.
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.
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.
All things considered, I would defend her right to do so today, I think.
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.
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?
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?
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.
Can you clarify what you mean by "simplest content API"? Is it going to be a headless CMS?
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.
TinaCMS is similar and open source, works with Gastby/Next
[deleted]
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
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
This looks cool - wish this worked with Jekyll!
[deleted]
Ggg
dgdgdf
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.