Loading...
 

Tiki Times

My ideas, challenges, tasks and so on related to the Tiki Wiki CMS Groupware project and software.
Published by Gary on Mon, Feb 23, 2015 Gary

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/ (cache)
http://mediaqueri.es/ (cache)

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 (cache)) 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.

Published by Gary on Thu, Feb 05, 2015 Gary

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.

Published by Gary on Tue, Jan 27, 2015 Gary

As of last week's webinar (cache), 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 (cache) 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 (cache), but hit a JavaScript error and didn't spend time to figure out the problem.

Published by Gary on Fri, Jan 16, 2015 Gary

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 (cache):

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



Published by Gary on Wed, Jan 14, 2015 Gary

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).

Published by Gary on Wed, Jan 14, 2015 Gary

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.

Published by Gary on Tue, Jan 13, 2015 Gary

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.

Published by Gary on Thu, Jan 08, 2015 Gary

I had a good idea about adding a Bootstrap class to suckerfish menuSection items (a menu item that has a submenu dropdown - "section" here refers to a (sub)group of menu items) that would automatically make a nice dropdown box and make Bootstrap and suckerfish menus more similar in appearance. After I committed the change, people started reporting they were seeing empty menu dropdowns now. I said the dropdown is only being produced under menuSection items, which are intended to have children. But Tiki has never objected if you make a menuSection item and don't put child items under it, and previously there was no downside or artifact if you did "break the rule". But this "enhancement" that I added assumed the rule was followed, that every menuSection item has children.

But to keep things flexible and people happy, I reverted the change. This is kind of like the theme options discussion - sometimes human preferences outweigh sheer efficiency.

Published by Gary on Wed, Jan 07, 2015 Gary

I noticed that some of the themes had menu color contrast problems. Seems like two approaches to fixing this kind of problem is to make a new CSS rule, or to add a class in the HTML so that an existing rule can cover it. For stylesheets that aren't made with Tiki in mind, like the Bootswatch themes, the second method is especially useful. So in commit r53425 I added a few Bootstrap classes to the menu code and, voila, they get colored by the theme stylesheet. I also removed a few rules from the superfish menu styles because they didn't seem to be needed for Bootstrap menus, and after checking I found they weren't necessary.

There was also a 5px margin at the top and bottom of each dropdown menu, which didn't look good when the list (menu) and list item background colors weren't the same, so I removed that rule, and added top padding to the top men item and bottom padding to the bottom menu item, to preserve the extra space at each end that looks good in a list.

Published by Gary on Mon, Jan 05, 2015 Gary

Back and forth on the theme option idea

When the shift was made to Bootstrap and to using the Less CSS preprocessor, the idea of theme options seemed kind of retro, since minor changes can be done easily by changing a few variables. But there was a reaction to that, as some people won't be using Less and want an easy way to add a variant style to an existing theme. As a workaround while the theme option idea wasn't implemented, I made the theme options at least work in a kludgy way by adding an import-the-parent-theme line to some theme option css files, or by importing all the less files that full themes use, essentially making these regular themes.

But since we decided to have theme options again, I undid those steps today, with the exception of Didiem, which seems more appropriately a full theme since it has so much of its own code.

Going forward

I need to think through the best way to make theme options, using Less, for the Tiki docs. Maybe something like this:

  • Step 1: Identify what CSS rules are needed, i.e., what visual effects are wanted.
  • Step 2: Identify what Less file (or what rule in a Less file) produces that CSS.
  • Step 3: Make a tiki-selectors.less that contains the CSS rules, that either has values already in place, or that has variables that are defined in a variables.less file.
  • Step 4: Define the variable in the variables.less file, if used.

This is needed for Bootstrap's files and for tiki_base.less and tiki-selectors.less. What files the themeoption.less should import depends on what is needed in its stylesheet, but as a reference, a fivealive-lite the option .less file has these:

@import "../../../../../vendor/twitter/bootstrap/less/mixins.less"; // To apply variables defined in bootstrap-variables.less.
// These two files are theme-specific:
@import "bootstrap-variables.less"; // A copy of the Bootstrap variables.less file but using only color settings.
@import "tiki-selector-variables.less"; // Provides values for "legacy" Tiki CSS selectors (not covered by Bootstrap).
@import "../../../../base_files/less/tiki-color_selectors.less"; // Tiki non-Bootstrap CSS selectors related to color
// @import url("../jquery-ui/options/plum/jquery-ui.min.css"); // Currently needed for popup styling, textarea width, etc.

// These files are used/shared by all FiveAlive/FiveAlive-lite theme options:
@import "../../../less/bootstrap-less-for-options.less"; // Contains relevant Bootstrap .less file sections to expose variables for the theme options to provide values for.]
@import "../../../less/tiki-selectors-for-options.less"; // Contains CSS for styling Tiki elements not covered by Bootstrap.


It's kind of hard to find a rationale for using this method rather than just making a CSS file directly, unless maybe there is a set of theme options and it'd be convenient to use variables. But maybe my explanations can be clearer, and the process further streamlined so it doesn't look so intimidating.