Comment by dmje | Hacker News Reader

Comment by dmje | Hacker News Reader

HN seems often incapable of thinking about how audiences and use cases differ.

I'm personally a huge fan of using MD for my stuff. I'm a recent convert, but am finding it works brilliantly for my use case which is idea capture, presentations, etc. Obsidian is my tool of choice. I've written a parser in php which converts this markdown into html ready for web publishing. All good.

But.

I also work with 50+ clients who want to manage their own websites. And they want to manage their websites easily, effectively and visually. They want things to look beautiful. They have audiences that they need to engage with content that is not just words but images, video, timelines, maps, iiif manifests, audio, sliders and much more.

This is a different audience. To ask my clients to "just boot up a jekyll instance and commit your content to GitHub" is the most wildly hilarious thing to expect of an editorially focused non-technical set of individuals.

Yes, plain text works beautifully for simple blogs, documentation, notes and more. But there is huge value in thinking about audience, about design, about engagement which goes beyond just a simple "text is right, wordpress is wrong" argument.

Then what seems to happen in geek circles is that all that "wonderful simplicity" is drowned by an absolutely insane set of tools to actually publish. Yes, you've got plain text files but if your stack then has some cli/npm/jamstack/js/gulp/brew horror attached to it, with a truly questionable maintainability problem attached to each and every one of those tools, how simple now?

Really the point is: different strokes for different folks. You can't make a stunning coffee table book in plain text. Much as you might hate it, InDesign is your tool of choice. And that's ok.

(Also, he's just plain wrong about not being able to get his content out of wordpress. There's a solid and very well supported XML export format for all wordpress instances, even wordpress.com...)

Came here to post a similar comment. From the perspective of the user, a Blogger or Wordpress site is far simpler than writing Markdown (in vim, no less!), generating the site, checking it into git, and uploading/pushing to the web server.

Arguing that vim + markdown + static site generator is simpler, and therefore superior to a content management system or blog engine is like arguing that a dirt bike is simpler, and therefore superior to a car. Yes, mechanically, a motorcycle is far simpler than car. But simplicity of implementation leads to complexity of operation, and it's no surprise that most people prefer cars or SUVs for their daily commute, even though the innards of a car are tremendously more complicated than the innards of a dirt bike.

If a basic blog editor like Medium is interesting there's an open source clone of it on GitHub (yabwe).

I was looking into it for personal blogging I do like the basic formatting and drag-drop image.

Working with content editable is not too bad, turn images to base64 for live preview... but there is also this nice editor already.

Equating content management systems with SUV-s doesn't do justice to CMS-s or your argument in general, considering the multitude of environment and other issues with SUV-s.

Also, car's simplicity is only an illusion. Anything is simple when other people fix and maintain it for you.

Micro note: today I learned that "IIIF" is the International Image Interoperability Framework [1], a standardized way of, uh, delivering images over the web. You pronounce it "triple-aye-eff" (which seems like a failure of tradition, since I2C is "aye-squared-see" then IIIF should be "aye-cubed-eff", right).

[1] https://en.wikipedia.org/wiki/International_Image_Interopera...

Yes :-)

There was me making assumptions about my audience after posting about knowing your audience...

IIIF is a cool approach that is growing in popularity in cultural heritage, the field I work in. The IIIF main site [1] is a bit baffling, but the long and short is it allows for reusable media that does nice stuff like zooms, pagination, commenting, etc. An "IIIF manifest" (examples: [2]) is just some json, which means you can grab IIIF media and re-use it in a viewer wherever you want to.

The demo page [3] has a bunch of links.

[1] https://iiif.io/ [2] https://ronallo.com/iiif-workshop/presentation/example-manif... [3] https://iiif.io/demos/

oh hey that's pretty cool. I was just wondering what the best way would be to store a bunch of image annotations in a really accessible way. Will dig deeper.

And since Computer Geeks are the ones making all the tools, of course there's 100 times more of these "superior" geeky tools than there are tools for the common man.

The fact that I have to struggle to find just a simple WYSIWYG GUI to edit a website for static site generation is nuts. It's not like these are particularly advanced tools that are technically incompatible with static site generation. It's just that computer people would rather hand-craft a website with Markdown and CSS code than compose visually appealing content using a mouse without code.

It seems nobody is creating technology that is both simple and easy to use, it's always one or the other.

I think for the handcrafted markdown people, writing it is easier than GUIing it up. Keyboard-driven workflows that don't depend on bloated graphical environments and browsers are popular among power users for valid reasons.

Have you ever seen what happens when those "normal people" start using Word for anything non-trivial? They _think_ they are making the document look better, but end up with a hard to read, inconsistent mess.

> even wordpress.com

I much prefer a self-hosted WP instance over the wordpress.com offering. WP.com injects tracking cookies and ADs in their free tier, and even with a paid version with your own custom domain, there is still some tracking going on. If you care about the privacy of your visitors, self host WP & don't opt for WP.com

You combine these tools into a GUI app? Right now, I am working on a feature that compare corpus size of my note database over time.

At the base of it, my notetaking apps sits on top of a git repository and markdown files.

If every piece of technical literature had to be applicable for all use cases, there would not be such thing as technical literature.

> To ask my clients to "just boot up a jekyll instance and commit your content to GitHub" is the most wildly hilarious thing to expect of an editorially focused non-technical set of individuals.

Perhaps a missing piece of software is a WYSIWYG interface front-end that hides MD, GitHub, Jekyll and other back-end technologies from the user, but still uses plain text in the back end.

There is nothing more durable than plain text, it might be the only thing that you can still read in 50 years.

> Perhaps a missing piece of software is a WYSIWYG interface front-end that hides MD, GitHub, Jekyll and other back-end technologies from the user, but still uses plain text in the back end.

No, this won't work for a simple reason: MarkDown isn't expressive enough for regular users.

They want to play with grids and set backgrounds: SquareSpace, Wix, and some Wordpress themes allow that with ease. They want to place a picture precisely there, which MarkDown also don't allow. And finally, users wants to have pixel-level control of their content. While it's a foolish endeavour to a seasoned WebDev, what everyone else offers blows out MarkDown and Jekyll.

You basically need to either extend MarkDown, or invent a new intermediate language for these.

> You basically need to either extend MarkDown, or invent a new intermediate language for these.

You mean like some sort of HyperText Markup Language?

This thread is about replacing WordPress with a static site generator, so far we've added a dynamic application with a GUI for site editing, WYSIWYG HTML for site content and layout adjustment. My guess is the next addition will be a form or comment input that requires making the front-end dynamic as well with solid caching as a stopgap. At some point further down the line someone will realize why each "complicated" piece is in WordPress.

Yes, your comment is spot-on. Most programmers will view WordPress with scorn because they see it as a bloated mess, comparable to seeing Word as a bloated mess compared to TeX, Markdown et al. But most of them don't believe - or worse actively deny - that Word's "bloatedness" is simply a consequence that some might use it as a simple document writer, some as a templated document (for use in receipt printing for example), and some will use it for things that I haven't even heard of. Actually, dmje, the grand-grandparent of the comment, has said it succinctly: HN seems often incapable of thinking about how audiences and use cases differ.

>a WYSIWYG interface front-end that hides MD, GitHub, Jekyll and other back-end technologies from the user

This exists and is called a "headless CMS". There are plenty out there, I can't speak for all of them, but I once migrated a company blog from wordpress to NetlifyCMS and it was... just ok. The visual editor was good enough (at least compared to WP), but there were a lot of more advanced things that the only way to to them was by writing some React components and referencing them in the markdown. But it allowed a writer -> editor -> publication flow, the github abstraction was well hidden enough, and in case anything went wrong it was pretty easy for a dev to get in there and fix it -- all the content lived in a repo after all.

But again, you admitted that you're at least a team. SquareSpace and Wix (for example) is appealing precisely because most of their users are solely the one maintaining the site, at least when it comes to the editorial and design side. They precisely don't want to know the warts of manually-maintained CMS (and I knew Joomla, it's not pretty) or how to maintain HTTPS, they just want it to act as if it's Word or Photoshop.

Reply on news.ycombinator.com