A new Starterkit for Kirby
With the release of 2.4.0, Kirby also got a brand-new Starterkit. We are very excited to share our ideas and thoughts behind the re-design in this article to give you an insight into the process.
Why?
The old Starterkit felt a little dated and limited. It was perfect for showing the basic functionality of Kirby, but since its inception, Kirby got a lot of new features and the web has also changed. While it is pretty obvious that a Starterkit can neither show every feature of Kirby nor supply a solution to every possible problem, we thought that a Starterkit should provide a better boilerplate for users who are new to Kirby.
Features
The first step was to decide which features should be included in the new Starterkit. We made our decisions based on the typical questions clients and the community ask our support team. A lot of solutions can already be found in our cookbook section in the docs, which was launched earlier this year to provide our users with instructions on how to solve typical problems when developing a website with Kirby. Those recipes are mostly solutions to real-world problems, so we thought that the Starterkit should also incorporate a small, but carefully crafted selection of common use-cases for our CMS. In the end, we had a list that can be summarized like this:
- Portfolio/Showcase: Not only designers but a lot of other businesses and individuals need some kind of project gallery. We called it showcase within the scope of this project, because the term is very generic and should work for a lot of different use cases. A showcase should include an overview with thumbnails and detailed views for every project. When users click on a project, they should be allowed to navigate back and forth between projects without having to go back to the index page.
- Blog: A lot of our users build a custom blog engine for both their personal and their clients’ sites with Kirby. Articles should be displayed on a paginated blog page , which shows an excerpt of every article and an optional cover image. This is also a great opportunity to show Kirby’s ability of numbering and sorting pages by their date.
- Pages: Static content pages are a good place to show different methods of content organization with Kirby. These can be used to show features like the structure field and subpages for creating the sections of a page.
Design
The old Starterkit took both the color scheme and the fonts from Kirby’s website, giving both websites a similar look. We decided to give it a distinguishable appearance from the official Kirby website this time. This way, the design of the Starterkit does not have to be updated to match our website. This independence also allowed us to be more creative on the Starterkit’s visual design.
Another important decision was to leave out any kind of graphics software like Photoshop or Sketch for the layout. This saved us from creating a design that would possibly have resulted in much more complex code. Remember: It is called Starterkit , so it should not be more complex than necessary — in our opinion it should nevertheless represent the beauty of a Kirby-based web design/development workflow.
We also took inspiration from current trends in responsive design. With a body font-size of 24px on desktop-sized viewports, the layout doesn’t feel lost-in-whitespace . The font-size goes down to 20px for smaller mobile devices with a viewport width of 480px at maximum to compensate line-length. We decided to use Vesper Libre as the primary font for body copy, while Montserrat is responsible for bold headlines and some UI elements like buttons. Both fonts are included in the Starterkit, so that it works offline as well. In conclusion: The new Starterkit features a more distinctive design with better support for devices of different screen sizes.
Code
Designing and coding the Starterkit happened mostly simultaneously, while the focus shifted from implementing functionality towards CSS and design tweaks as the project evolved. The last phase was mostly about commenting, documentation and quality control.
The Starterkit was never intended as a boilerplate for every project, but rather as a demo site for new Kirby users. As every developer prefers a different workflow, we decided to keep things straightforward. In an early project state, we decided that the Starterkit had to work without any JavaScript at all. Most basic requirements can be achieved with pure CSS nowadays, so why should we add more complexity than necessary? This also led us to the decision to move complexity from template code to CSS, wherever possible. As it is more likely that the templates — if clean enough — can be used as a starting point in a real-world project, the CSS file is more likely to be written from scratch (or using a framework). We also decided not to follow any CSS methodology like BEM, SMACSS or Atomic CSS. In our view, those are all very opinionated — which is fine, but we are staying true to our philosophy, not trying to push your front-end code into any direction.
The template files use simple semantic class names like .article-date or .pagination to improve code readability. Both the templates and the corresponding stylesheet now include more comments and explanations, also featuring links to relevant pages in the docs, whenever one of the more complex features is used. We also decided to go with real content in favor of “Lorem ipsum …” on most pages, so they can provide helpful information and links to the docs, explaining the features that were used to create that particular page.
However, there were also things we decided to leave out. The most obvious one is the use of responsive images for different resolutions. While it might have been tempting and relatively easy to show this feature by using Kirby’s Thumbs API, it would have added a lot of advanced frontend code. And as some older browsers are still around, our preferred solution of using srcset and maybe the <picture> element wouldn’t have worked in a reliable way without a JavaScript polyfill. HTML & CSS are already extensive enough nowadays. Like stated before, our goal was (and still is) to give our users a clean starting point from which they can evolve.
Summarizing
The new Starterkit is a huge step forward compared to the old one in terms of design, code and the features it demonstrates. It was both a challenging and a very interesting process. We thought a lot about common use-cases for Kirby and its growing set of features and how they could be demonstrated. Also, this was the first project where Fabian — our latest team member — was involved. We hope that the new Starterkit works great for you and if you want to give us any feedback or ideas for further improvements, don’t hesitate to send your thoughts to feedback@getkirby.com .
Have a great day!
Originally posted on: https://getkirby.com/blog/a-new-starterkit-for-kirby
