13 Oct


Kiwitrees-nova, the next major version of the kiwitrees software, designed for all device sizes.

It was pointed out to me recently that I have not added any blog posts for ages. So I thought I should use this medium to tell everyone about progress on “kiwitrees-nova”. To start I should explain what “kiwitrees-nova” is.

Simply, it is the next major version of my kiwitrees software. The current version 3.3 will be the last major version I will release in the current format. There will be more minor versions such 3.3.2, 3.3.3 and on as I will continue to maintain it, keep it up to date for security issues etc. for as long as users need to keep using it. But I am hoping that might be less than two years. 😉

Kiwitrees-nova is primarily a rewrite of all the display code. The underlying processing and storage code is pretty stable now so I will be leaving that alone as much as possible.

New ways to view web pages

More people are now using phones and tablets to view their kiwitrees pages. I have tried adapting the existing code to accommodate this, but the reality is that the code is just too old and never designed for it.

Kiwitrees-nova uses the excellent “Foundation 6” framework to replace all the old display code. It is designed from “responsive first” principles. It provides all the structure necessary to ensure kiwitrees looks great on any viewing platform. It also makes it easy to selectively hide features that are just not practical for the smallest screens, without losing any of the key functionality.

The principal component of “responsive web design” is to have a clear definition of the devices and their screen sizes that are being targetted. It is not practical to have a different display for every device or size, so they are usually grouped into three categories: small, medium, and large devices. For kiwitrees-nova I have settled on the definitions for each group shown in the information block to the right of this page. As this blog progresses you may want to refer back to that to be sure you know what is meant by each category.

Device sizes


up to 768 px wide (mobile phones, tablets in portrait mode)


769 to 1024 px wide (tablets in landscape mode, most laptops)


1025 px wide and greater (desktops and large/wide laptops)

- Admin -

Nothing is sacrosanct

In rewriting much of the old code I will be reviewing what needs to be improved, what can be improved, and what should remain as untouched as possible.  None of the legacy code is likely to be completely untouched but at the same time, I have no interest in removing or degrading the existing functionality.  I am also very conscious that I am doing most of this in isolation, and my opinion is not the only one that matters. Your feedback through this process will be vital. There will also be decisions made about things that can be excluded from small device screens and different ways to do some things. So I will attempt to keep this blog updated as I progress, and will be pleased to debate any of the changes and decisions as they come up. No “decision” will be so permanent that it can’t be reversed!

A firm foundation to build on

Apart from the requirements described above, the current version of kiwitrees is very stable and achieves most of its original goals. So here are some of the things that will NOT be changing unless something external to kiwitrees forces a rethink:

  • System requirements – these will remain as they are for kiwitrees 3.3.1. In simple terms that means any version of PHP since 5.6, and MySQL (5.0.13 or later) or Maria databases.
  • General appearance – the home page with movable blocks, main menus in the header etc.. all remain broadly the same.
  • Overall concept – the intent of kiwitrees to be a web-based, internationally collaborative (in usage and development), open-source free software.
  • Customisable – the ability of a kiwitrees site administrator to modify parts of the system both by the use of configurable options and simple-to-use custom modifications of styles, layout, language etc..

Progress so far

I hope to provide a demonstration site for kiwitrees-nova soon, but for now, will attach a couple of screenshots of some of the pages I have made progress on. No particular logic to the ones shown first. Fairly naturally I started with the home page, but then I have taken a slightly more random approach. Probably not ideal. but I do need to ensure my motivation gets enough interest to keep going. There is a LOT to do!

The major change to the home page is actually an invisible one. I have created a “template” for the block layout, stored as part of each theme folder. This allows different themes to have different layouts. One might be like current kiwitrees (large blocks at the top, small ones below), another more traditional (large blocks to the left, small to the right), and another as shown here in reverse (small to the left, large to the right). Even a mixed layout would be possible.

In terms of themes, I prefer not to exactly transfer any of the existing ones over to kiwitrees-nova. I still hope to include at least three in the first release, and they can have some similar general colour styles to the old, but beyond that let’s have some fresh new looks. For now, to make life easier, I am only working with one theme. But the framework being used (including “SASS” for the technically interested) makes it pretty easy to adapt for different looks later. As you can see this first theme is very different. I don’t even have a name for it yet. Any ideas?

Home page

small home page


medium home page


large home page header

Large (header only)

large home page

Large (full page)

Note that the small screen loses things like the kiwitrees-nova logo to save space. The medium size loses the space left and right of the block area that the large screen has. Like most such decisions these are all choices that can be changed in other themes.

Basic List pages (notes, sources, repositiories)

small list page


medium list page


large list page


In this case the small view is restricted to a single column, as anything more would render the font so small it is unreadable.

About The Author

Personal Website


jacoline » 25 Oct 2017 »

Looks interesting 🙂

You have a beta we can look at?

Theme name: Nova, Fruit or just Kiwi


kiwi » 25 Oct 2017 »

Beta will be ready “soon” 🙂


Roy » 25 Oct 2017 »

Had a concern that the new name, Kiwitrees-nova, was a reference to the use of the programming language “Nova” or “Supernova”. “Foundation 6” is visibly alive and well but the Nova projects don’t appear to be.



kiwi » 25 Oct 2017 »

🙂 Nothing so complex or obscure 🙂
Just the Latin for “new”.


pab » 26 Oct 2017 »

Exciting! Once upon a time at a University I used an ePortfolio system called Mahara which was developed in New Zealand and was a Maori word for …
There must be other such words you could use … such as:
Tupuna or Whakapapa …
… but what would a mackem from Sunderland know!!!


    kiwi » 26 Oct 2017 »

    That’s a very interesting idea. I shall give it more thought.

    “Mahara” in the context you used it would probably translate as “memory”. Context, as well as intonation, are essential ingredients in Māori translation.


uti » 26 Oct 2017 »

For me it is more a technical and design development or not?
This may be nice and necessary but not in functional sense…
Whats about new functional features as you announced?
– New place functions – or GOV integration
– better interface to import MYHeritage datas like Census
– compare of trees
– expand of append funtion – note when data allready exists.. and so on….
– new sanity checks like – child is older then parents
– Development for media – bulk uplod of pictures
etc… whats on your “whis-list….


    kiwi » 2 Nov 2017 »

    Questions about other plans are not really relevant here, but for completeness….

    “New place functions – or GOV integration”:
    A new top-level PLAC record will be added, but it is a huge task. The new framework will help. It is also important to remember that not all users believe it is beneficial, as there is no GEDCOM standard for it, and therefore no reliable way to transfer it between programmes. The (primarily German) GOV system will not be part of this development.

    “better interface to import MYHeritage datas like Census”
    If MH records it in a GEDCOM standard way then it will import fine now. If they don’t there is no possibility I will be doing any work to solve what is their problem, not kiwitrees.

    “compare of trees”.
    I have no plans to work on this at any time in the foreseeable future. See also the following point.

    “expand of append funtion – note when data allready exists.. and so on….” Absolutely not. That is too close to “merging”. My views on that are well explained elsewhere (FAQs). Appending is a simple process, and will remain so.

    “new sanity checks like – child is older than parents”
    I am always prepared to consider additional “sanity” checks. The new framework development does not prevent this at all. But surely “child is older than parents” already exists as “Birth after their children”? If parents are born after their children, then the child must be older than the parent!

    “Development for media – bulk uplod of pictures”
    Like places. media changes will be easier in the new framework. But this is another huge task, so will take time. However “bulk upload” is not part of the roadmap. I see no need for it. Kiwitrees users on their own hosting use FTP for this. Kiwitrees hosted clients simply need to ask and I will do it for them, as I do when setting up new clients. But uploading is the tiniest part of adding new media. Linking to people or events still has to be done, and cannot be automated. The roadmap plan is for bulk changes such as moving files between sub-folders and deleting.

    If further discussion on any of these points is required, please use the forum. Comments on these posts are blocked once a new progress/update post is released