Even as an engineer people keep on underestimating me (although sometimes they overestimate me : ). Here are some examples:
- telling accounting a number of times that they've forgotten a rather large PO.
- telling a network vendor they have a huge hole in their firewall only to be ignored until I contacted one of their huge customers which I also knew. They could have saved themselves a good deal of embarassing attention I guess.
- etc etc
Last year at JavaZone theee was an interesting talk by someone who was an early employee at a crowd funding company. He was a non-dev but talked about how he enjoyed being able to update copy in the web app (not just front page IIRC) directly after the devs had set up git, an editor and explained the basics.
If you are making the next google you'll want things to be extremely easy-to-use.
Making a google.com level UX for business apps might be smart. Or it might be insulting.
I do see the compromises wp puts us into but for me, the benefits of static seem awfully abstract at the end of the day. If you want me to buy it, please show me an authoring experience I actually want to live in. I haven't seen one yet.
It's not about over- our underestimating people. It's about whether the technocentricity you are selling is worth it. For some of us, it is, sure.
For one, I just hate writing with markdown. Compared to WYSIWYG (i.e. just writing), markdown's syntax is a distraction. Writing is both visual and storytelling to me, why should I exclude the visual to a separate stage of the process? Just doesn't make sense to me.
Authoring is about input to the system, static is about how the contents is given to the visitor. There is no technical reason a rich author experience cannot be coupled with a static approach to content delivery.
In fact, the article focuses mostly on page bloat, not so much server-side processing. The amount of bytes a Web page weighs in at should mostly depends on its contents, not on the author tools used to create its content.
How would you allow a user, while creating a blog post, to add commenting to the post in a way that enables progressive enhancement i.e. doesn't require javascript, with static site generators?
If you can't, what is your justification for the sacrifice in accessibility?
If you can fulfill this basic requirement, please show me the experience of using the system and show me how it is better than wp as a whole.
Of course this should be possible to turn off for certain content and moderated, but it still seems artificial to not have the discussion on the same page, compared to the original post. HN is beautiful, for instance. :)
Have my upvote.
You can pay a teenager to set up WP or netlify or more. What people pay me and possibly most HNers for is knowing what and when etc.
In a small team or just for an individual this might boil all the way down to personal preference.
Isn't the ascetic authoring experience provided my markdown just as much a result of deciding on which set of personal values are and are not important for your users?
guess it depends who you work with. Had a recent experience where I spent half an hour for an user who has trouble with basic filesystem navigation - even though he's been using computers since close to three decades.
The more generic point here is that developers build better tools when they properly understand their audiences. In this case, the audience is almost always “a non technically skilled editor”.
IMO most young technical startups would do well to remember this too.
Checkout Jekyll admin, it provides a simpler interface than Wordpress, but with WYSIWYG editing capabilities for a static site. It is very powerful and can be designed to scale large-sized projects.
Basically it's a file manager for .docx files, but more importantly, it can generate static site* out of your Word documents, and style them nicely with bootstrap.
Yes, that's something I'm working on and I'm close to the end of a beta release! https://docxmanager.com/
Remember Dreamweaver? Made great static sites. Good WYSIWYG editor. Nothing but static pages on the server. "Round trip HTML" - it took in HTML, edited it, and put it back out. If you created the HTML with Dreamweaver, it could put in some comments which told Dreamweaver not to change certain parts. This let you have page templates.
We can't have that any more. CSS is too much of a mess. The era of CSS flush/clear/div layout broke WYSIWYG editors, and the web took a big step backwards. We went through the "tables are bad" era, and eventually got them back as "layout tables". It might be worth defining a modern subset of HTML/CSS and having a Dreamweaver-like editor for it.
Markdown? Markdown is comparable to HTML 1.0. Or BBcode. It's gaining features and complexity as people demand more HTML features in Markdown.
That's the party line. Now do a View Source on some web pages.
Unless there is a compelling reason, don't do at runtime what you can do at build time.
[1] or dozens of other sources.
But. They're developer reasons.
What almost everyone who piles into this support of static stuff seems to completely ignore is the audience here.
Who do you think is editing your website? Amy the developer who has no problem committing stuff to Git or learning Markdown or Dave, who is a marketing manager and spends most of his life in Word writing press releases and social media posts?
The entire point of a WYSIWYG editor is that it doesn't require any developer experience.
If you genuinely think a corporate website can be run out of a Git workflow or a requirement to learn Markdown, you're basically in the wrong room. This is the whole "IT bottleneck" that content teams have been battling for years: it's back to the early 90's days of "yeh, we want to update our homepage but we need IT to do it for us".
Somewhere in the middle is the holy grail: performant sites that are also editor friendly.