I have been using the Starterkit as the basis for most of my Kirby projects so far and was wondering what others have done/are doing to make their Starterkit-based sites more mobile friendly/responsive.
For my last site, I added a “scroll to top” button to reduce scrolling on small screens. Also, I switched off the subpage menu that appears when hovering over parent links in the main menu to make navigation more touchscreen friendly. Clicking on the parent page now opens an index page which contains the subpage links.
Are there any other suggestions you might make?
Also, if I want to keep the subpage dropdown menu at the top, is there an easy way to make it appear by “clicking” on the parent instead of “hovering” over it? That would give me the subpage links at the top but still keep it more mobile friendly, right?
Hm, that’s a very difficult question. One one hand, I agree with you that those optimizations would make it easier to get started with a slightly adapted version of the starterkit, but on the other hand, the starterkit was and is only meant to be a demo of the Kirby API that shows which file does what and was created as a starting point so that users can play around with Kirby.
I agree with Lukas, the starterkit is not really a theme like the ones that you can find here or here, or the ones you might be used to from Wordpress, Joomla and the like. It is a starting point to learn about how Kirby works.
In most cases, the people who use Kirby do not use ready-made themes, but develop their own for themselves or their customers. This requires some good HTML/CSS and at least some basic PHP knowledge, or the willingness to learn those skills along the way.
Clicking on the parent page now opens an index page which contains the subpage links.
That’s something I would not recommend. Have a look at how other sites tackle that problem. There are so many options …
Thank you for your feedback so far Lukas and Sonja and thanks for the links to help me get more up to speed on HTML/CSS and PHP.
I have to say that I am a bit surprised and disappointed to hear that you do not recommend using the Starterkit as a starting point for actual site and theme development. I would say that its basic functionality covers the needs of 90% of the projects I deal with. I mean isn’t the getkirby website a very strong example of a customization of the Starterkit?
I am not at all suggesting that the Starterkit be used without further customization (which makes each site and project unique) but I fail to see why you think it is not a good idea to use it as a project “starting” point. Perhaps you could elaborate further since I am now left with a feeling that I am missing some important aspect of Kirby.
Sonja, I’d also be interested in hearing why you do not recommend:
Clicking on the parent page to open an index page which contains the subpage links.
As far as I know, this has become a widely accepted practice for keeping sites more mobile-friendly and responsive. A good example of this type of navigation that is often quoted in responsive design circles is:
The Kirby website was created from scratch and custom-built to build its custom structure.
The design is similar, but that’s only because the Kirby website and the starterkit share Kirby’s corporate design, meaning that this was done on purpose.
I don’t think that the starterkit can’t be used as a starting point. Implementing more features like responsive design into it would actually prevent users from using it as a starting point because it would get too specific quite quickly.
I’m not saying I do not recommend using the starterkit as a starting point, all I was saying that it is not really a theme. Of course you can build on top of it, but each use case is different and you would want every website you create to be unique.
Edit: In your example page I do not see a submenu that is on a separate page. But maybe I got you wrong. In the example, the submenu is integrated into the page and not accessible via the main menu, i.e. you have to go to the subpage first and then go to other childpages from there. A common alternative would be to completely hide a menu with main and submenu on mobile and open it via a button. There is simply no one way to do that, because all depends on the number of items in your main menu and submenus; how much screen real estate you want to use for the navigation and a lot of other factors.
By the way, I did not submit my original message as a “suggestion” for the Starterkit. Perhaps someone switched the category?
I am completely happy with the Starterkit in its present form and am not looking for more responsive features to be integrated into the core package. I was simply looking for ideas on how to make a unique customization based on the Starterkit more responsive. Perhaps I was not clear enough in my wording. Sorry.
I fully agree with Kurt and basically don’t understand nor agree with the answer given by texnixe and Lukas, for the most part.
If the starter kit includes menu and sub menu, to me, it should work on mobile from scratch. Web on touch screens could be a better world if CMS’s would all include a full reponsive starter kit, at least for navigation, which is a must have.
I can only repeat: The starterkit is not a WordPress theme. It is a demonstration of Kirby’s features and can be adapted to any site, but we decided to keep it simple so that users can easily understand how everything works together. The main purpose is the demonstation and starting point to play around with it, but not to use it for an actual site.
We are currently working on an updated version of the starterkit however. Stay tuned.
It does work on mobile (you can reach every page on mobile devices). But responsive design means that you sometimes need to omit elements that just don’t work on mobile. Or does your smartphone support hover states?
Maybe @Martinus means that the submenu is not hidden on mobile devices with a larger screen, e.g. on an iPad, iPhone 6 Plus in landscape mode etc.?
I can still use the submenu when I tap on a menu entry on those devices; and if that’s not supported by a device, you can still access all subpages via their parent pages. So I don’t really see a problem here.
And as I mentioned in an earlier post above: There are many ways to create a mobile friendly menu, sometimes hiding certain elements of the main menu, sometimes hiding the complete menu.
The philosophy of Kirby includes not to force you to a certain HTML/CSS naming scheme. Wordpress – for example – comes with a menu builder, which has a lot of features out-of-the-box. But you cannot change the menu builder’s HTML output with ease (though it’s possible, but not actually fun …). And because the creators of a CMS can never know, which features are actually needed by a developer for a particular case. So the menu builder of WP adds a lot of classes to the generated markup to fit a lot of different use cases. But even this approach has its limitations and the resulting code is bloated and harder to understand. Another drawback: When you are working with WP, you have to stick to their naming conventions at least for the menu, widgets etc. and I bet that most Kirby users wouldn’t like that.
I also think, that a StarterKit can be a good starting point (no pun intended), but mostly something to demonstrate how certain functionality of the CMS actually works and how you can solve common issues like navigation, projects or maybe an about page or blog. There are so many approaches how to write CSS and JS, that it is impossible to integrate complex components while keeping the code readable. What, if you want to use the BEM naming convention, Atomic CSS, OOCSS or whatever you like best? Do you work with SASS or Less, have a Gulp-based build process or maybe you’re just writing plain CSS? Do you use jQuery or another JS framework? Because there are so many different ways of coding a website and so many different philosophies behind them, the StarterKit cannot handle them all. So the only option here is to provide something generic, wich can be tuned to fit your own needs. I’m very glad, that Kirby does not force you into a particular way how to write your front-end code.
Kirby is intended to adapt to your needs (which does not work without some knowledge about HTML/PHP/CSS and maybe JS), not the other way round.
With the new register set it would probably be possible to have the starterkit as a plugin. It’s possible to register templates, snippets, blueprints and more.
The benefit of doing so would be an easier way of get rid of it, by just deleting the plugin. Now the starterkit is kind of scattered all over the place.
That’s certainly possible, but I don’t think it is such a good idea. The purpose of the Starterkit is different from a theme or a blog engine. It is intended to show you how Kirby works, with the folder structure, the way templates, controllers, content files etc. interact; and in general, how to render content from your text files and images on your pages.
By putting all that into a plugin, the main purpose of the Starterkit is lost.
Yeah, and by doing that you dump all the nice templates and your stylesheets which you have just adapted/created in hours of work with the same names as the ones from the starterkit.
Maybe it would make more sense to mention the Plainkit in addition to the StarterKit as a minimal alternative in the docs? Currently, it is not listed on the Download Page in the docs.
