DEV Community

Cover image for OOPS! The Accidental Blog Platform
Joshua Willuhn
Joshua Willuhn

Posted on • Edited on

OOPS! The Accidental Blog Platform

Wordpress. Drupal. Joomla! Wix. CGI. Macromedia Dreamweaver templates. AOLPress. GoDaddy. Frontpage. ColdFusion. Instr html toolz. ActiveX. CoffeeCup. React. Tripod. Macromedia Flash. Geocities. Vue. HomeSite. Jekyll. Gatsby. LAMP, MEAN, JAM or maybe Java spring.

Whatever you use, a website is the result. In October 2019 I started planning a replacement for the landing page for my app, MOTOrift.com. Until then I was using a combination of Medium’s native apps, VS code and the time tested good ol' copy and paste framework with the ctrl+c/curl+v plugin active. It did the job but I’m taking my app from a beta free version to a premium product and it needs a better website as part of that.

I'd like to offer in app chat support and in app help articles. I need a native app to write those articles with, one I can trust won’t lose my articles. I need to get serious about producing content people can use to learn about my apps.

When I really question why I choose one tech product over another 9/10 times it’s because of the documentation or help. Depending on the product, without documentation nobody will stick around to use the app.

Landing pages, blog articles and in app help. It needs to do everything and supply it’s own toilet paper.

With the basic requirements set out, I went looking for solutions to build a website. Admittedly I’ve been so busy with developing MOTOrift I haven’t kept up on the headless CMS revolution, static site generators or the like.

It turns out, if you want an app or a content management system for a static site generator it’s a separate thing that sits on top of the site generator.

I was looking for “a gatsby editor app” and that’s hard to find, because...

Static Site generator != CMS.

I feel old. These kids have technology I know nothing about 😐

That's the 411 on blogs these days or at least that’s the gist of it. I feel even older knowing what 411 meant in the 90s 🙄 but then I did start this article suggesting Macromedia products AND AOLPress. TBH I might as well sign up for AARP and save money on my cell phone bill/car insurance in the process.

The world is moving past Wordpress, Drupal and Joomla. I was never too impressed with them anyway.

Back in this decade, you can use any CMS that supports the SSG you're using. The best list I found from Gatsby is here.

Some options like netlify, ghost and contentful stood out. They typically work with Gatsby competitors too. They sit on top of the site generator as the interface you use to edit content.

Some stood out for their amazing price tags like $800-2000 a month 😂 I have a Mustang budget not a Bugatti budget. Some were more realistic around $7-40/month.

I need something highly usable that I won't hate. I need something I can improve on. I need something that works.

I have to wonder what kind of amazing product you'd get for $800 a month but I guess it'll stay a mystery. Eventually, I concluded I need something custom made. Maybe I don't need something custom made but I want something custom made.

Sometimes that has to be a good enough reason.

You might be thinking "wow, 85,439 options exist and this dude/bro is making number 85,440". Yeah, that's how it is. I could plunker down $8 a month or find something free and everything would be done in an hour. I'd probably drift towards Ghost or Gatsby.

Part of it is purely pride and building your own tools is a time honored tradition across different kinds of crafts and trades.

Software is no different than anything else. It's a craft like what a blacksmith or a carpenter does. I like side projects, the keep me learning and pushing my limits.

On one hand I genuinely have better stuff to do, I'm not trying to make a blog platform to distribute.

On the other hand, I need something I'll use and won't hate using. I need it to just work and not slow me down too much (once it's built and in use).

I don't want it to bump into my web app or be another DNS mess to deal with like some solutions. But at the end of the day I'm just looking for excuses to justify making something custom.

I want to make internal tools for MOTOrift. I want it to be something that deserves a custom built CMS SSG thing.

It's some kind of a milestone. I outgrew the crappy blogging process I was using. My little app is all grown up now 😢

And so I began, by planning.

I accepted the fact I won't know what to call it. Is it an SSG? A headless CMS? A page builder? ERP? CRM? Blog platform? Does it deserve such a title? All of the above?? I don't know what to call it! Luckily, it doesn't matter.

I also accepted the fact I need multiple apps.

I need one app that's just a blog platform for help articles. It needs search tags and support for writing longer articles (like this one).

I also need a page builder for landing pages that has more structured content management and better design options that might slowdown a blog article. It wouldn't be productive to expect either to do both but they need to look the same and the end result can't feel cobbled together it should work seamlessly.

Feature lists, landing pages, download pages, things like that need a different type of page than a blog article or support article. But they need to look the same or similar and work together.

Blog articles need to be in an index in the app and I don't want to mix it up with the non blog help articles.

I also want a support chat thread for the website (new customers) and in app support or more of a support ticket style help for people already using the app. The app is already partially a web app and native app so I don't want a second set of logins.

As much as I love chat bots, they were the first thing I ever programmed (AOL+VB3+Genocide+MONKEFADE) and felt that awesome feeling of accomplishment as a kid that started it all for me, I don't like the conversational ones. It's a computer, it should have a command list so the person can use the 🤬 thing or it's a computer guessing how it can help me based on input and life is too short for that nonsense. I try not to subject the people using MOTOrift to anything I'd find annoying.

I really don't want a company reading my conversations either. I hate that Facebook insists on monetizing private messages with my grandma and that was what tipped me over the edge into avoiding Facebook products. I can't have a corporation "learning" about my customers from our conversations and I don't want to trust chat bot companies when the functionality isn't overly complicated for what I want.

The typical website chat bot add on is probably doing something similar to Facebook especially on the cheaper end of their service options. I've even seen a couple that basically sold "not snooping on you" as a premium tier feature.

So I'm making a chat screen too 😂

Out of everything I need, the most important thing is a native app to write blog articles with. It's the deal breaker for me.

So I started with a very basic Android app. It has a couple EditText boxes and a menu button. The menu button opens a menu with .... menu options 🙄

I battled between using markdown and just going for pure html and in the end html won so I can have more flexibility.

The menu:

On the server side it saves some text to a file in one end point and combines it with a template on another post end point. Truly revolutionary 😐 I open the text file so I can edit it separately from the website. I save a reference to a database too. The whole thing took a long weekend to make the basic version of.

It's unpolished.
It's crude.
It's unpretty on the outside and slightly ugly on the inside.
It's perfect 😍

I used Node on the server and Java spiked with Android on the app side.

I followed it up with a quick web based editor.

One end point saves the blog text to a file with just editable content. It has another end point that takes two partial html files and combines them and the text into a final html file. That way I can have a common menu on each page and only edit it once. In the event I do decide to change the header and footer files I'll have to rebuild each page for them to match. But it could be worse. It doesn't rebuild every page every time I save, just as needed.

I have another end point that saves the blog article name to the mongo database I was already using.

The Android app is my favorite part of it. It opens to full screen editing as soon as you hit the icon to fire it up. It saves locally without having to do anything but use the app. It saves on exit, activity changes, anytime it closes it saves. The loading is seamless too it just loads whatever it last saved.

Open app - write - close app - that's it. There's an option to save to the web and load an article edited on the web in the menu.

I didn't want to put the effort into keeping track of which article was edited where and when to load from the web or local so I do some of it manually.

I didn't want to put too much effort into it or I'd start to feel like I'm neglecting my baby, MOTOrift. I can remember to refresh the article from the web version instead of editing the local copy if I need to.

If you ever used Dreamweaver templates to create websites, I wanted it to be reminiscent of that basic process. Content and layout are separate. You can write and add html like a pro. You could save a template upper and lower files and then edit the rest of it independently. Dreamweaver might even still be around 🤷🏼‍♂️ it was high class web authoring software back in the day.

"If Dreamweaver were modern and mobile what would it do?" Probably 8000 things I don't need and four that I do. If it did only the basics is what I wanted to make.

I went back and fourth on having markdown support or not but in the end it's really not a big deal to write a few html tags while I blog so I dropped it because I added some buttons to quickly throw in some html tags. It supports hashtags in the in app support chat and that was more important but it was bumping up against the headline # and parsing the hashtag as a link to search. Plus it gives more flexibility.

It was about the time I got to that point that I knew it would either be very worth it or very NOT worth the effort I put into it. That was probably the most complicated part of the whole app, hashtags and hashtag links. It works and I like it, those were the requirements.

Next up? I need a page builder.

I started with making a pretty basic "section based page editor". You can choose from a few options "one column, two column three column" and that opens up an individual editor screen for that style of section.

For a two column section the left and right column text is saved as text only so you can edit just the text. Then choose from options to save as "two column style A" or "two column style B".

The combined left and right column html is smashed together to form a single two column section. That complete section with html is saved to a file as are the left and right individually.

Then to save the page there's an end point that puts each section together into a single page html file.

It's very similar to the blog app with another layer on top of it. I let the app generate quite a bit of my html and left an area to edit it in pure form html before I save the section.

It's unpolished.
It's crude.
It's unpretty on the outside and kinda ugly on the inside.
It's perfect 😍

I will say it could be better, but everything I make could be and this is an internal tool so at least this time I won't get any one star reviews 🙄

The rest of the team (dog) is excited about it too 😂

The server side consists of saving some files, nothing too crazy. It's functional. I don't have anything to automagically regenerate each page after changes to the upper and lower page template.

It could be better. But if I put too much time into it I'll lose focus completely.

It sits server side and minds it's business. There are no npm installs or updates. It relies on Node's filesystem library and the Android app. It could be done in any language or framework that supports such a complicated task as saving files to memory.

It's pretty basic. But it does the job and I might not have learned very much per say but I probably didn't forget too much either.

With that it was on to the chat system. I wound up building two. One for the website landing page and one for the app once you're actually logged in and using it. I did that because I don't want new people to have to log in to chat.

If they want to chat let 'em chat with just an email address and a name. If they're actually using the app and want help with a feature, it should be more of a support thread style help not a chat box. Small but important difference, a subject line and the expectations the 'send a message' screen sets forward.

In the app it looks roughly like this

On the web it looks like this

Compared to slapping together a gatsby site and throwing a chat plugin in the corner, it took significantly more work but I'm happy with it.

Update 4/27/2020
I've used this on a couple websites now and I might even make another version soon. It's been about six months since I started the project. Though I just finished writing this article this month.

Top comments (0)