This is is just a proof of concept, if there is enough demand I will refine it and improve it but it suits my needs for now, hopefully it will make life easier for you too!
Introducing a "WYSIWYG" for dev.to
If you are new to dev.to and are about to write your first article you may find the editor a little bit confusing.
Liquid Tags, markdown etc. are not particularly friendly if you aren't used to using them.
Even if you are a veteran Markdown user, creating documents in dev.to can be laborious having to type everything by hand.
Well struggle no longer, I present to you dev-WYSIWYG! (I know this isn't technically a WYSIWYG but it was easier to call it that!)
It is a bookmarklet (currently pointed at my server but once the bugs are ironed out it will point to github) that gives you bold, italic, headings and more!
Even better, every command has a corresponding keyboard shortcut with Ctrl + Key Name
Keyboard commands:
Simply press Ctrl + the modifier key shown in the buttons.
For example for a codepen liquid tag (to display an inline codepen) press Ctrl + 5
Commands are:
- Ctrl +2: heading 2
- Ctrl +3: heading 3
- Ctrl +4: heading 4
- Ctrl +B: bold
- Ctrl +I: italic
- Ctrl +L: link
- Ctrl +K: inline code (backticks)
- Ctrl +Q: block quote
- Ctrl +R: horizontal rule
- Ctrl +0: Code Block (triple backticks)
- Ctrl +5: Inline Codepen
- Ctrl +6: Inline jsFiddle
- Ctrl +7: inline dev.to article link card
- Ctrl +8: inline dev.to user profile card
- Ctrl +9: inline dev.to comment card
If you are used to stackoverflow controls a lot of them are similar so it should be easy to pick up!
Behaviour
If you have text selected then it will use that text within whatever tags are being inserted.
If you have no text selected then it will enter some default text for you.
For certain items you will get prompts to fill in the key information. Please note that if you have selected some text the prompts may be ignored (I will tidy that up later).
Give it a try before using it.
The below fiddle allows you to try out the editor first in a fiddle to get used to it and see if it is "good enough" in it's current state for your needs.
Using it on dev.to
Once you have played with the fiddle and you like the editor, simply drag the link in the fiddle that says "dev.to WYSIWYG" to your bookmarks bar.
Then click the link when you are on the dev editor page (https://dev.to/new) and voila you have editor features and keyboard shortcuts!
Conclusion
Maybe people will hate it, but I already love the fact that I can just press Ctrl + B to make selected text bold.
There are still a few things to add such as ordered and unordered lists and <kbd>
wrapping commands as I find those particularly annoying!
Anyway, let me know what you think and if you end up using it!
p.s. I advocate for accessibility all the time, at the moment this is not fully accessible and I am aware of that, once I have finalised the functions etc. I will make the adjustments needed (it is still usable as it is, just awkward).
Top comments (15)
You can also consider creating a user script that can be used with tools like: chrome.google.com/webstore/detail/... .. it would be more convenient for many of us
Great suggestion π»!
If it proves popular then I will definitely do that (once I have refined it and added the missing features) as at the moment the code is a jumbled mess due to experimenting!
I have also never made a chrome extension before so if people do like it I may just make it an extension as that is inline with being "beginner friendly".
Nice work! Kind-of similar to what I'm doing with CodeWrite, just that the editor is separate and Dev.to (as well as other platforms) are supported through auto-filling. Might plug-in directly to the editors in the future.
Love the bookmark idea though - didn't think of that!
Great work on CodeWrite, I have added it to my list of "things to try".
Does it have an API (or will it have?) as it could be a great plug and play solution for people who build custom websites.
Thought about it already. Maybe in the future. Auto-filling on the web is pretty hard - especially with
contenteditable
rich editors. Techniques that I use won't work on every website, but on the vast majority. Might do a blog post on this.So, if I manage to standardize it, then yeah, API might be on the way.
Sorry just re-read this.
I meant an API to retrieve the HTML / markdown generated for processing.
I thought that way people can use your service to write, then publish to everywhere including their own site. Or is that what you meant was difficult π?
Kind-of. Right now it works like that:
CodeWrite detects potential issues (e.g. images too large, code highlighting not supported), presents you with potential solutions (e.g. resize image to FHD, convert to GitHub Gists embeds) and "auto-fills" the post's content within the editor.
Auto-filling and issue-resolving mechanisms aren't the same for every website, and so they aren't good candidates for an API.
I could provide generalized access to the pop-up menu and created content, but this would leave too much work on the API user's side.
As for standard "Markdown exports" - they're in development, alongside GitHub Pages auto-filling.
Hopefully, I'm clear. CodeWrite is a rather unique idea and it's quite hard to explain it properly.
@ben we should add this to dev.to
I think you meant we should add something like this to dev.to - nobody wants my crappy hacked together code running on the site permanently π€£π€£π€£
There are a few items already in the github repo about this, so I am pretty sure it is on their radar already.
github.com/forem/forem/issues/3049
github.com/forem/forem/issues/5023
github.com/forem/forem/issues/10522 (this one has a nice design that fits the site aesthetic)
Learned something cool here, thanks for sharing :)
Is there an open issue for adding something like this to Dev.to? Would be good to add this to that issue if open already. If an issue doesn't exist yet, would be good to create one.
github.com/forem/forem/issues/3049
github.com/forem/forem/issues/5023
github.com/forem/forem/issues/10522 (this one has a nice design that fits the site aesthetic)
are ones that I could find that seem applicable.
Let me know if you end up using this (or if there is a better one somebody else has already built) in the comments!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.