There have been a few questions asked about why Kunena did not release a new template for Kunena version 2.0. As well as these, we understand that people would also like to know about Kunena Team's position in relation to the future of Joomla and the support of Bootstrap. We like to share with you how we are thinking forward for Kunena's design.
Kunena team members have been actively reviewing Kunena's current design. It was decided over a year ago that Kunena needed improvement to meet current web design practices including utilising new HTML5 and CSS standards, improving the perception about how website users should be able to interact in a web-based discussion forum context, and to draw Kunena closer to Joomla.
But how to do this? How to achieve a recognisable User Interface (UI) that is more flexible, adaptive and can deploy the software’s features more quickly while, at the same time, avoiding design conflicts with the other design practices in the “Joomlaverse”? How to improve the perception about how Kunena should be used?
Those answers were not very clear and required months dedicated to analysing past experiences and research into current standards and future web technologies. Some of those answers also depended on understanding what Kunena users really wanted from a modern web-based discussion forum. What we discovered is a term called “frameworking.”
Many template design frameworks exist that are not specific to Joomla. Some developers have created frameworks - particularly those who have created templates that are popularly used -that are more or less “adaptable” (in a “Joomla-specific” sense) but all these frameworks have one thing in common: to make template design easier and quicker. We wanted to keep Kunena as neutral as possible with respect to general web design practices and Joomla's current design practices. We did not want to take sides about what framework to use and we certainly didn’t want to re-invent the wheel or try to invent yet another framework!
We examined the techniques used in other frameworks that made them unique. Although this was not a driving force of reason to make a new design, it helped us to decide how the new Kunena template should be designed. An important breakthrough was that K 2.0 had already moved towards using the Joomla MVC (Model-View-Controller) code architecture. This allowed for decoupling the display code from the function code – essentially allowing templates to separated from the “core” of the component. By looking at these design practices, we were able to standardise some HTML and CSS that has made it easier to create Kunena templates. There is still a problem about how to support variations of HTML structure and CSS class-inheritance for common elements. Many components and modules do not blend well with current websites and we needed be more creative in order to incorporate new designs within an ever-changing Joomla environment.
As we began to design a new template that altered the look and feel of a Joomla component, we discovered that we required HTML structures that were similar to the Boostrap UI. Kunena borrowed heavily from these ideas and practices. Kunena team members were also discussing with other Joomla designers about utilising a standard UI; this lead to the prospect of using Joomla’s Boostrap. When Joomla announced official support for Boostrap in Joomla 3.0 we were excited about the possibility of a uniform UI toolkit. By way of an analogy, think of Apple's IOS UI toolkit as a platform that’s instantly recognised by millions of users and that can easily be used by software developers in that space. This was something Joomla had tried before but had neglected to follow through in later releases as the platform developed.
For all the reasons mentioned above, we've decided to use the Joomla “extended version” of Boostrap HTML structure and CSS classes but with our own “Kunena” HTML structure CSS classes; this is because Kunena is unique as a component in its layout. We are only going to include things from Boostrap and Joomla in ways that make sense to Kunena.
Mirage does this and supports key elements of Boostrap in some way; examples of these include HTML structure for buttons, dropdowns, menus, tabs, pagination, and progress bars. Mirage borrows many Bootstrap CSS classes that control the layout and style for this HTML structure. The first objective for the team of developers and designers, however, is to improve what Kunena could look like. Therefore, Mirage has not been structured directly on Boostrap CSS classes – it only borrows CSS classes – because Kunena itself requires a lot of work to retain its uniqueness. However, after the first version of Mirage version we will be moving to the direct use of Boostrap classes.
In developing Mirage, our concern is that we should not necessarily remain wholly dependent on what further work the Bootstrap design team has in store; this is because Bootstrap is still very new (and every new UI needs to be thoroughly tested for workflow purposes). Kunena HTML and CSS “frame-like” structure will remain atypically “Kunena”. For example, we are not going to use Boostrap Grid System because it does not make sense to use it. The Boostrap Grid System is mainly used by the Joomla template (i.e. in how the template reserves space for components and modules that people have chosen to install) and not necessarily to be used within those components or modules themselves. There are Boostrap tools that perform these functions but they do not play a role for designing Kunena. We will be doing our best and we’re quietly optimistic that we’ll make the transition to Boostrap more quickly when that time comes. That is the goal of Mirage V1.
Mirage is Kunena’s version of Boostrap and we’ll use the best parts of what has been standardised and will, in future, be used throughout the majority of the Joomla developer community. This is good news for other developers as well as it's good news for end users, too.
We are thinking forward and we hope that you are looking forward to Mirage – the next great change to occur in Kunena.