3 ms·
> One thing I learned is that you should lean towards letting non-technical people choose their own tools like why we largely let developers choose their own to
by solardev 2y ago
> One thing I learned is that you should lean towards letting non-technical people choose their own tools like why we largely let developers choose their own tools.
IMHO: I think a more sustainable variant of this (for your own sanity) might be to ask them which tool(s) they like and then take some time to understand WHY. But then instead of just letting them use those directly, you would either vet them first yourself or else find a similar one to those that can satisfy their needs (as an editor) AND yours (as a dev).
If I let every client/friend/family member who came to me for this sort of advice just pick their own tools, I'd end up with a bunch of Word docs and print-to-PDFs with embedded copied & pasted crap from five other tools and no easy way to clean and publish them or back them up and version control them for diffing and rollbacks, etc.
I guess the dev version of this would be like letting every individual dev set up their own production deploys however they like, even if it's just some rando FTP client, instead of having some sort of orderly CI/CD or at least git-based process.
If it's just you and your buddy and you don't mind taking the time to clean up their docs every time there's a new blog post... that's fine, I guess. But it can quickly get pretty overwhelming if you have more than a single user/tool to support, or you just publish updates frequently. In that case, having a nice WYSIWYG for them that's good enough, but can also generate clean structured output for you (something like Markdown or an API, as opposed to RTF, Word XML, HTML, etc.) can make life MUCH easier for you and your frontend. And anyone that comes after you. Otherwise, some unexpected input certainly can and usually will crash your frontend... it's just a matter of time.
You can also build your own system off something like https://quilljs.com/ https://quilljs.com/, https://prosemirror.net/ https://prosemirror.net/, or https://www.slatejs.org/examples/richtext https://www.slatejs.org/examples/richtext to customize it to their needs while still getting clean enough input.
- verdverm 2y agoI agree, there is an dimension of how much they use the tool vs you, which factors into the considerations. I'm coming at it from the point of view that the business side is going to handle the main website, content management, etc... and that I will be mostly hands off, in a reviewer role. It sounds like OP is near this situation, without more details. They also sound like where I was initially, that I wanted a blogging setup that we both could use. Then I reflected about delegation and came to the opinion I lean towards today