Adding an edit button to my static site on mobile

Published on under the Web category.

In my My static site editing bookmarklet blog post, I outlined the bookmarklet I made that, when clicked, automatically takes me to the GitHub page associated with a URL on my website. I use this link daily to edit the wiki-like pages on this website.

Today, I thought to myself: what would it look like to have an edit button on mobile?

I have not edited many pages on my site from mobile, but I would like to explore making small changes to the wiki-like pages on my website (i.e. my movies list) from my phone.

There was no easy way for me to edit a page before I started this project. Going to the GitHub app – which I can use to edit my site on my phone – and manually opening folders is a lot to make an edit, especially when I can go to Notion, the note-taking app I use, and write down an idea with a few taps or a swipe. In such a workflow, I can add the note to my site later. Also, mobile editing experiences, generally, are not great. I think there is so much room to make things related to editing on mobile!

I am hoping this project empowers me to edit more pages on my website while I am on the go. I don’t typically write blog posts on my phone – it is tricky to type long prose. But adding a note to a list or adding a relevant link I found to a wiki page? These are appealing use cases!

The UX

I wanted an edit button that, when clicked, would let me edit a blog post. The button should be easy to press on mobile devices.

I had a few requirements:

  1. The edit button should directly open the GitHub iOS app, from which I can edit the page I am viewing. My website is static. I use GitHub to build the site.
  2. The button should only show up if an “editing mode” is enabled.

Due to limitations in WebKit, the iOS browser engine, I could not use a bookmarklet. With this in mind, I decided to create a script that would make an edit button appear on a page if a cookie is set. I will be the main user of this feature and so the button doesn’t need to show up unless enabled.

Here is what the edit button looks like:

A blog post on my website with a white button in the bottom right corner that shows a pencil icon

When clicked, the button opens the GitHub app at the page I was viewing:

The source file for the blog post I was viewing, now opened in the GitHub app from which I can open the file editor and make changes

I can then open the file menu in the GitHub app and click edit.

How the edit button works

On every page, a script loads that checks for a cookie. The cookie is only set if you visit a specific page on my website. This lets me enable the editing mode on my device without surfacing a page that people can click. This is important because my repository is private and so the editing mode would open broken links for anyone other than me (because I am signed into the GitHub app as me). 1

If the cookie is set, an edit button is added to the bottom of the page. The href of this edit button is determined by similar code to what I wrote for my desktop editing bookmarklet. The script sets the href depending on whether the page is a post or a wiki-like page. Posts have the URL path /YYYY/MM/DD/slug whereas wiki-like pages use the pattern /<page>. 2

The final URL uses the github:// app handler to open a link. Here is an example for a wiki page:

github://github.com/capjamesg/jamesg.blog/tree/main/pages/templates/wiki/movies.html

When clicked, iOS opens the link in the GitHub application. The link opens directly to the file that I can then edit.

If I am on a 404 page, my app opens to the pages/templates/wiki folder so I can create a new file. The GitHub URL path to directly create a new file – with front matter pre-configured! – that I use in my desktop bookmarklet doesn’t work with the app handler. This means I will need to author the front matter 3. Or will need to have a page somewhere that stores the default front matter that I usually use so I can paste it in when making a new page. Or make a web page to generate the front matter for me that I can copy.

Conclusion

With this approach, I have an edit button that:

  1. Automatically takes me to a file that I can edit if the file exists.
  2. Takes me to my wiki folder in GitHub if I am viewing a page that doesn’t exist so I can create it.
  3. Only shows up if a cookie is set, so readers don’t run into the button while exploring the site.

One downside to this implementation is that I need the edit button code to load on every page. It is not ideal to load code that nobody but me will use. With that said, I am keeping the code as lightweight as possible. I load the code at the end of a page. This ensures the JavaScript loading process does not block other parts of the page. I do the same with the code that makes my seasonal emojis work, too.

You can view the source code for this project on GitHub. You can make the script work on your site by replacing the repository name and paths with those you use on your website.

If you have any ideas on how this script can be improved, please let me know! My next step is to add a feature to exit editing mode.

1

With that said, I could see myself using the same code I wrote for a site that I want to be editable on mobile (maybe airportpianos.org?).

[↩]
2

Not all pages that match the pattern /<page> are wiki-like pages. My archive pages, for example, use that pattern. But I don’t mind if the edit button shows up on those pages because they are automatically generated.

[↩]
Also posted on IndieNews

Go Back to the Top