Skip to content

Instantly share code, notes, and snippets.

@mertkahyaoglu
Created March 8, 2018 19:11
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mertkahyaoglu/394c265e284f8cb31857cf176e9c7b73 to your computer and use it in GitHub Desktop.
Save mertkahyaoglu/394c265e284f8cb31857cf176e9c7b73 to your computer and use it in GitHub Desktop.

'GUI/Administrative interface for Jekyll' Proposal

Table of contents

  1. Who am I?
  2. What do I want to do?
    2.1 Introduction
    2.2 Project Goals
    2.3 Benefits
  3. How am I going to do it?
    3.1 Implementation
    3.2 Demo Application
    3.3 Timeline
  4. Why me?
    4.1 Projects
    4.2 Open Source

1. Who am I?

My name is Mert Kahyaoğlu. I’m a fourth grade Computer Science student at Muğla University in Turkey.
Website: mert-kahyaoglu.com
Github: mertkahyaoglu
Email: mertkahyaoglu93@gmail.com

2. What do I want to do?

2.1 Introduction

Jekyll is a nice and easy solution to create and publish static websites and blogs. Static site generators are becoming popular due to these kind of sites being lightweight, fast and unhackable. For developers, they are much easier to setup and maintain compared to using a dynamic CMS like Wordpress, Joomla or Drupal. Deploying static sites are also simpler, cheaper and may be even free if Github Pages is sufficient for you. Jekyll, which arguably have a hand in this popularity boom, not only gives the developers all the required features as a generator but also has a strong ecosystem of plugins, themes and a vibrant user base. Jekyll's design choices makes it easy for developers to be flexible and extend it for non-trivial use cases. Another factor for static sites to be a good alternative is you can push many traditionally back-end tasks to the front-end nowadays. Javascript libraries got more mature, powerful and 3rd party services available (i.e. for comment management you can use Disqus or Facebook's Comment Plugin) frees the developer from committing to a full-stack architecture.

Despite all these advantages and its simplicity for a developer, Jekyll can be still quite confusing and hard to deal with for a non-tech person. For one thing, command line is a scary and at the same time magical environment for such uninitiated users. In order to setup and get along with Jekyll, you have to know/learn some commands and how to issue them. As simple as this may seem for a developer, it is not fair and reasonable to expect this skill from non-tech people. This means if your client or coworkers did not use command line before and they need to interact with the site in some capacity then you can not use Jekyll even if it will be your ideal choice for the aforementioned reasons.

The goal of this project is developing a graphical user interface for Jekyll with these kind of users in mind. Wide usage of CMS applications like Wordpress proved that once a site is setup, ordinary users can maintain, populate and extend the site through a well designed interactive GUI. My aim is to create such an admin panel for Jekyll so that non-tech users can also use and enjoy this great tool. As a side note, once an interface like this is available I believe there are ways to make it also interesting and useful for advanced users.

2.2 Project Features

The core features of this proposal are listed below. Through using the administrative GUI, Jekyll users will be able to;

  • create/delete projects and export/import existing ones
  • manage the building process and built-in development server
  • deploy their projects to Github Pages or an existing host by sftp
  • change configuration settings (We should probably have separate pages for different levels of users based on a setting's functionality)
  • create/edit/delete content (In Jekyll, content is not just pages and posts. Collections, data files, partial markdown files to be included in other files are also building blocks of site's content. Ideally, our GUI should allow the user to create all of these kind of files)
  • install/delete plugins from Jekyll plugins site (related to #105)

In addition to these core features, I am planning to add other features that will make Jekyll more attractive to both non-tech users and developers. I do not feel proficient enough with my Jekyll experience at this moment to propose concrete items so these features should be carefully determined after discussions with my mentors and polling the Jekyll community for their needs. Nevertheless, I want to point out some directions this project can expand into:

Since the interface will be implemented by Javascript (see section 3), JS libraries and jQuery plugins will become available to ease website development with Jekyll. For instance, some image plugins may be incorporated to the system to prepare images (i.e. clip, resize, automatic thumbnails) for web consumption. For non-tech users, a plugin can be found or written to convert csv files or spreadsheet cells copied to clipboard to markdown's table syntax which may be confusing for some people especially with big and/or irregular tables.

Another option is to package a lightweight database like sqlite with our new application. Having a database for a static site may at first seem useless or counterintuitive, since users can not submit queries, but I believe a database may help the developer in some other ways and used to enrich site's content. An example for the former use case may be implementing a version control system for site posts for people who need it. For the latter, generating static listing pages (i.e. posts belonging to a tag, posts from a certain time period, posts of a certain user) will become very easier with the help of a database. Jekyll sites typically are not very big in content amount (otherwise a dynamic CMS would be chosen instead) so I believe having a lightweight DB and generating some extra files to enhance site navigation will be found feasible.

Currently after creating/editing a post you need to go to the browser (assuming development server is on and changes are being watched), refresh/open the page and check the results. Found a small typo, go back editing the file and repeat the same things. This workflow of switching between programs can be improved in our system for productivity. Whenever a file is saved, our application can simply pull the newly generated (or a specified) static file and display it at the same screen area where you are editing the file. This will not be exactly live edit, since you do not want to run the build process after each key stroke and Liquid special commands will throw syntax errors while they are incomplete but it will be a close experience.

2.3 Benefits

When the project succeeds, I believe we are going to have the following benefits:

  • Users from all levels of knowledge will be able to use the features that Jekyll provides from our interface. Although the primary goal is to make Jekyll accessible for non-tech users, there will be also benefits for developers. A well designed GUI and carefully chosen features can also help developer productivity.

  • I will try my best to design and implement the project so that it has a long and fruitful lifespan. The code base should be easy to maintain and extendable. I am also hoping the project will attract skillful developers for future contributions because of bleeding edge technologies like Electron, React, and Redux involved in it.

  • As explained at the end of the previous section, our application can incorporate novel features to take Jekyll into new avenues. Things that were not possible or very hard to establish may suddenly become quite in reach.

3. How am I going to do it?

There are three ways to complete this project that all suits me very well. First one is to create a stand-alone application using Electron. Second way is to build the project as a web application that users access via their browsers like Wordpress' wp-admin section. Third one is to create an Atom plugin. This one can limit the users if they are not using Atom as their primary text editor but it is still an alternative.

I'm capable of achieving this project with any of these methods if mentors would like it to be done with a specific one.
My main proposal is to build an Electron application for this project. Electron is currently very popular and cross-platform. It will be very beneficial in the long term because it is easy to maintain and extend and also it can pull a lot of contributors for the future.

3.1 Implementation

I will use React.js for implementing the user interface of our Electron application. I chose React because it enables creating single page applications in a structured and clean manner. Its component system, data flow logic and efficient updating of the HTML document via virtual DOM makes it an ideal framework for a project like this. React's large community makes finding solutions easier when you got stuck and having a big company behind it means stable long term support.

Along with React.js, I will use Redux to make the application behave consistently and make it easy to test. Redux provides a predictable and well behaving state container for JavaScript apps. The whole state of your app is stored in an object tree and the only way to change the state tree is to emit an action describing what happened. Then you need to write reducers to specify how a particular action transforms the app state. These reducers are functions that take the previous state and an action, and return the next state ((previousState, action) => newState) instead of directly mutating the state. I believe, using Redux disciplines the developers and makes collaboration much easier and bug-free in an open source project. Its role is similar to having coding conventions and standards in such projects but at a higher semantic/design level.

Electron application will be serving only one html file since the whole application is going to be single page. React Router will handle all of the routes like Project List, Edit Post, Add Collection etc.

I will use Webpack for bundling and already created a demo application (section 3.2) to see if and how I can use all these technologies together.

Next, I want to give some more details regarding the main challenges to implementing the project as I described.

3.1.1 React + Redux Flow

First of all, I will create React Components of each View (Create Project View, Post List View, Edit Views, etc.). Secondly, I will write actions which describe events for each Component (e.g. createProject action for Create Project View). Then I will write reducers (e.g. Project reducer that specifies states for project related actions). For testing, I will follow this guideline from Redux.

3.1.2 Handling Jekyll Commands

In order to issue Jekyll commands like creating a project (jekyll new myblog), starting development server (jekyll serve) from the application, we can use child_process module from Node.js and write action creators that return corresponding child_process functions.

3.1.3 Storage

Since Electron is based on Chromium, we can use HTML5's new localStorage API to store simple data. So we can keep track of all Jekyll projects that are created or imported. We can also store Github credentials and similar persistent data with this approach.

3.1.4 File System

There are some actions that involves writing to files (e.g creating a post), reading from files (e.g. reading configuration file _config.yml). We can use Node's fs module for these operations. For YAML/JSON conversions, we can use yamljs utility module.

3.2 Demo Application

I have decided to create a demo application to give you an idea of how this project can go and also to see how Electron, React, Redux, Webpack combo works for this project. You can check out the demo project here. If you just want to see what it looks like, there are some screenshots in the repo or you can download the releases from my Google Drive.

3.3 Timeline

Before starting coding I would like to do some preparation. This preparation involves:

  • discussing my system design and the GUI,
  • if needed to produce use case and sequence diagrams to make sure we are on the same page,
  • brainstorming with mentors and the Jekyll community about what extra features could be added.

GUI/Administrative interface for Jekyll ( From June 6 until July 23 - 7 weeks)

1. Setting up the project (0.5 week)

TODOS

  • setting up the development environment (Electron, React + Redux, Webpack and determining modules to be used).
  • collecting project assets (images, fonts, etc.).
  • forming file structure.
  • specifying routes according to the design.

2. Home (1 week)

This view includes actions such as;

  • creating a project
  • importing an existing project
  • listing created/imported projects

TODOS

  • Writing components and containers (DOM structure and CSS files).
  • Implementing actions and reducers.
  • Implementing utility functions for file system operations. These operations could be creating Jekyll project, storing imported project information, reading from local storage to list projects, checking existing/deleted projects.
  • Writing tests and documentations.

3. Project (1.5 week)

This section includes;

  • a sidebar showing the current project's information and links (Posts, Pages, Collections, Settings, Plugins)
  • project configuration
  • project operations (renaming, deleting, deploying)
  • starting development server

TODOS

  • Writing components, containers, actions and reducers.
  • Implementing edit configuration functionality. This process includes updating _config.yml file.
  • Implementing general project functionalities. This one includes writing utility functions for git operations and storing/reading user credentials for git, file system operations for renaming and deleting a project and issuing commands(jekyll serve, open project on browser).
  • Writing tests and documentations.

4. Content (2 weeks)

This section includes;

  • listing posts/pages/collections on their separate pages
  • creating/editing/deleting a post/page/collection

TODOS

  • Writing components, containers, actions and reducers.
  • Managing contents. This process includes parsing/converting (Front Matter, _config.yml, etc.) and file system operations (writing to files, reading from files).
  • Writing tests and documentations.

5. Plugins (1 week)

This section includes;

  • listing installed plugins
  • searching and installing plugins from plugins site
  • deleting plugins

TODOS

  • Writing components, containers, actions and reducers.
  • Writing general functionality. This process includes file system operations (creating _plugins folder, editing _config.yml and Gemfile files) and issuing commands
  • Writing tests and documentations.

6. Final Touches (1 week)

  • Testing and reviewing

Depending on how it goes up to this point I am willing to spend time on extra features not mentioned here but since these are not yet determined it will be hard for me to put time estimates. Nevertheless, I want to prepare the code base for making such extensions in a modular and fast fashion and I will work on them even if they fell out of the scope of GSOC.

4. Why me?

I'm really interested in web development. I am very passionate about learning and staying up-to-date with the latest technologies. I love improving my coding skills, writing open source code, contributing to projects on GitHub.

4.1 Projects

First of all, I would like to mention my projects related to this proposal. I'm quite familiar with Javascript/Node.js and web development tools like Webpack, Grunt, Gulp and so on. I have created bunch of applications with them.

As a React.js project, I built my personal website. I created my own old-fashioned content management system that I control the content of the website with JSON data. This project made me really interested in React.js because creating user interfaces with it was very easy and fun.
Before React.js, I was using Jekyll for my personal website. I forked a Jekyll boilerplate (that is why I now have so many contributors in my project's repo) to quickly deploy my website to Github Pages. At some point, I wanted my website to be dynamic, so I migrated to React.js. But I have had enough experience with Jekyll and become very familiar with it.

Another key project related to my competence for this task is the Atom Chat plugin. The main purpose of this plugin is to help programmers communicate with each other while coding. The plugin has been built with CoffeeScript and Socket.io for communication with the Node.js server. With this project, I had improved my Node.js skills quite well. I am currently working on a similar plugin to make video chat available in Atom.

Other than these projects, I have published some Node modules for the community.

In addition, I have created lots of websites with PHP using Wordpress. Therefore, I have a deep knowledge of how content management systems work and how an admin panel should look like. I believe this knowledge will be also very helpful when it comes to creating an admin panel for Jekyll.

You can see the full list of my projects from here.

4.2 Open Source

Most of my time, I hack on open source. I have contributed to several projects on Github. The main ones are React.js and Atom. Besides contributing, I published all of my projects as open source on GitHub.

You can see my contributions here.

What attracts me to this proposal is that it both fits my experience and I will be learning very useful things along the way. In addition, it will result in a useful tool for the open source community and make some people's lives easier. After using all the awesome tools this community produced, it will feel very good for me to contribute back in this manner.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment