Tiki Times

The themes that can be selected to be used at this site are at various stages of being upgraded. The themes that come in the Tiki package are the farthest along, and are getting pretty close to being fully updated for Bootstrap 4. But some page elements such as menus and navbars are still being worked on so may look broken in some or all themes.

Other themes that will be available as aftermarket installs aren't as far along. The ones that are updated significantly can be selected, and the ones whose Bootstrap 3 stylesheets are still being used (they haven't been overwritten by a Bootstrap 4 SCSS compile yet) and look ok can be tried out here. Other themes aren't so far along and are more or less broken or otherwise not a good example of how the dev version looks and works. These themes aren't yet available to choose in the Switch Theme selector.

Probably all the themes at the site (those in the Tiki package and aftermarket themes that will be available at Zukathemes) will be ready by the time Tiki 19 is released in October.

This site is currently running the trunk development version of Tiki Wiki CMS Groupware, which will be Tiki 19 when it's released in October. For this version, Bootstrap 3 has been updated to Bootstrap 4. That means there are many changes to make in Tiki's files to maintain compatibility with this latest Bootstrap CSS framework version. In particular, not all of the visual themes at this site have been updated yet, so if you select a theme that seems broken or has elements that don't seem quite right, it's one of those that need updating, and it will be fixed before long.

After having some trouble with resetting passwords amid different file and database versions, I decided to do a clean sweep of this site, create a new database, and check out a fresh Tiki installation. My previous database was years old and had grown to 291MB. It contained a lot of kruft - long-gone users, way out of date content, log records that aren't relevant any more, etc. So I started with a clean database and have been adding back some of the old one's content, going through the old .sql file to retrieve blogs and blog posts, forums, and so on. I'll get some of the wiki pages but, again, many are way too old to be interesting any more.

This process did lead me to downloading gvim. Nothing I had on my computer could open a 291MB file, so this application was good to find and try out.

We've been looking at the site logo, title, top menu, search and so on that are typically at the top of the page of a Tiki web site, and thinking about how to make them responsive. There are various ways to handle this, by reducing the size of items or not displaying them at all, and so on. The challenge for a web application like Tiki is to provide a good default behavior, and also provide ways for its users to customize it, because no single responsive behavior and appearance is going to be the right one for every Tiki site.

Here are some good resources, to see possibilities and examples:
http://bradfrost.github.io/this-is-responsive/
http://mediaqueri.es/

Currently in Tiki 13 and the soon-to-be-released Tiki 14, we provide the standard Bootstrap navbar, which can scroll along with the content or be fixed to the top of the page. Other layouts are also provided, to continue the legacy Tiki site appearance, but the strategy for these to be responsive isn't really worked out or document yet. As with past matters of site layout, I imagine it'll be a combination of pre-set functionality and docs on how to configure the site. Site admins can choose the theme, layout, modules, and so on as before, and then use appropriate CSS classes on the modules of the top and topbar (and footer) module zones to control the size and visibility of the site's page header and footer content.

Tiki, as a veteran web application, has its roots in desktop computing rather than mobile. That said, the mobile phone view was enabled over 10 years ago (see https://doc.tiki.org/Mobile) and has evolved along with mobile devices. The current focus on improving the mobile experience for smart phones and tablets is another challenge along that path. Already it's possible and even fairly pleasant to access a Tiki site with a mobile device, but we want to further improve the quality of the experience.

I spent a lot of the day yesterday changing some text in Tiki's interface. We decided to update the term "avatar", replacing it with "profile picture". In the earlier days of online discussions, in forums and so on , people had avatars - small images that represented the user - at the top of their posts along with their user name, which again wasn't necessarily the real name of the person. There images usually weren't an actual photo of the person; more often they were some super hero or other character, or even an abstract image. But the image soon became associated with the identity of the writer.

Now in the "social networking" age of the Internet, people often use their real identity - as "required" at Facebook, for example - and an actual photo of themselves as the identity image. In this context, "profile picture" is a more accurate term for the image than "avatar". I imagine it didn't occur to most of us working on the project that the old term should be changed, but a new user brought it to my attention and so I asked on the developers' mailing list and got agreement to change it.

Normally it's a little time-consuming to do the search-and-replace but yesterday was a nightmare. For some reason, the editor, PhpStorm, wasn't doing the search and replace correctly. Instead of a clean replacement, it'd often past the new text into the center of the text to be replaced, or make some other strange combination of old and new. Fortunately, it did the botching fairly consistently, so I could copy the bad text string and replace it in another cycle of correction. This had to be done several times to correct all the bad text.

I got a warning at some points from PhpStorm saying it was running out of memory and I should input a higher amount in a modal popup, but apparently at that point it didn't have the resources left to accept the higher memory setting because after inputting it and restarting the program, a little later it would stall with exactly the same message. Oh well.

Finally it was finished and I hoped that my SVN checkout hadn't become out of date during all that editing time; I could commit the changes with no problem, at last. I've found more strings that definitely need editing, to correct spelling or other errors, but am a little hesitant to start what could be another long and frustrating session.

As of last week's webinar, I had made style sheet changes in the FiveAlive-lite theme and its options based on luci's images, toward improving the theme for use on the Tiki project sites. Although we already have the "social networking style" layout template, I wanted a method that relied completely on module admin, and not have any hardcoded content display code in the template. But the method i used to place the modules at the page top, for the static header, wasn't really practical. It involved making a custom module zone and then putting that module zone's name in a layout template. Obviously we don't want people to have to do that, so I retreated and put together a couple of layout template strategies that are actually workable in real life.

Of course at the webinar the view was expressed that the static header could/should be done using a custom module zone and not requiring a special layout template. I'm open to that if it can work (and I'll help to make it work), but what i like about the layout templates is that it's an easy site administrator one-click step to switch layouts.

Things got a bit nutty over the weekend as I worked out some trial methods. With cautions against making new templates firmly in mind, I did one template method that appears to be a new layout in the L&F selector, but in fact it's just a new layout directory whose layout_view.tpl only Smarty-includes an existing layout_view.tpl. But by virture of being in a new directory, it gets a new listing in the selector and a new CSS class on the body tag. So the admin selects "Moving headers" (the new layout template directory name) and actually is using the not-new layouts/header_middle_footer_containers_3-6-3/layout_view.tpl and, voila, gets a new layout. CSS makes all the changes. Any differences in the display of the top and topbar modules in the "normal" layout and "fixed header" layout can be handled with CSS rules. So this kind of combines the benefits of template switching and reliance on CSS for distinct layouts. In the layout selector in the Tiki trunk demo at this site, you can select "Moving headers" to see how this looks. (The "moving" aspect mostly isn't there yet.)

I made a second method trial because I noticed, when checking around for ways to do the header moving, most of the examples showed the elements being moved were all on the same level in the DOM. I didn't know if it'd work with our current layout which has the topbar menu within the middle div. So I modified our three-containers, three-columns template to have four containers: the topbar module zone I moved out of the middle div to a new "topbar container" div. The template now has header, topbar, middle and footer containers. This provides another option for the coming javascript part of the project. I tried briefly to get things to move with Scroll to Fixed, but hit a JavaScript error and didn't spend time to figure out the problem.

It seems like the consensus is that Tiki's public pages, especially the home pages that visitors see first, should be simpler with not such a huge amount of information. This is what I've been thinking too. There are two things to take care of related to this. First we need to have an updated theme that doesn't look out of place among other similar kinds of web sites. Second, we need to trim the content and number of links to a reasonable level, so the page isn't cluttered and confusing.

People have written about this, about the best content for a good first impression, for blogs or web sites in general. Here are the main points of one post from http://www.creativebloq.com/web-design/planning-your-users-journey-121413693:

01. Avoid too many links
02. Menus send mixed messages
03. Study heat maps
04. Use images
05. Keep it clean

I could recall, just vaguely, that in some circumstances I couldn't edit a wiki page, several months ago. But for one reason or another the problem went away and I didn't notice it again. Then someone reported it, that if you had a module in the pagebottom module zone, somehow the page's edit textarea couldn't be accessed; it was covered by something apparently.

This sparked something in my memory, and I checked and realized that the grid column class given to the edit form causes it to float to the left (as with all grid divs). This float allowed the next thing down the page to rise up and conflict with the div, in this case covering it and blocking it from being accessed (SVN r53439).

A few bugs squashed today. luci reported that the Cosmo theme had some text at the top of the page that didn't belong there. I had forgotten but, back when we first put the Bootswatch themes in Tiki, they were placed as theme options, under a parent theme "Bootswatch_themes". I think this was just a convenience in the theme selector. I liked them all in one group like that. But "Bootswatch_themes.css" doesn't have any real content, so if someone selected just that theme without a theme option, they'd get basically a CSS-free page. So I put a text warning in the stylesheet as CSS content to tell users to choose a theme option from the selector as well. The theme options, in turn, overrode that rule to erase the text. But in the Cosmo theme I forgot to add the import statement to get the rule, so the strange text printed at page top (SVN r53491).

Also there was a problem of images running under the right-hand column from the center column, in trackers. I thought this had been fixed, but what I was remembering was SVG files. The wiki plugin PluginImg didn't have the fix, so I added there also. Now an image displayed with this plugin matches the size of its container, and when it's small, the image resizes accordingly - no more column underlap.

A new year, a new feeling

I have a good feeling about this year. My time is freed up and I can really focus on what I want to do. As I was walking with Koa (our dog) around the pond near our house, enjoying the feeling of the day, and the sites and sounds, I said to her, "Hey, all my days are going to be like this!" My calendar is clear - or at least it's clear of obligations to get out of the house and go someplace to work for someone else. My new calendar, and it does have weight, is in my email, in OneNote, in my Rollbahn 2015 notebook. But this calendar records things I enjoy doing. In this calendar I put the projects I'm involved in with people and the work I contribute to the Tiki project.

I've decided this year to continue to get up fairly early (as I did on "crack of dawn" days while teaching) and get into things right away each day. I feel better when I don't sleep in, really, even though getting out of bed isn't so easy especially on dark, cold winter mornings. Now, if we can just get financial ends to meet, it'll be a very nice year.