Loading…
 

Tiki Times

My ideas, challenges, tasks and so on related to the Tiki Wiki CMS Groupware project and software.

Getting a new start

admin Tuesday November 15, 2016

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.

Thinking about responsiveness and the mobile view

Gary Monday February 23, 2015

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.

A tortuous task updating some interface text

Gary Thursday February 5, 2015

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.

Groundwork to implement FiveAlive-lite enhancements

Gary Tuesday January 27, 2015

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.

Ideas about info.tiki.org

Gary Friday January 16, 2015

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



A problem that was just a vague memory returns and gets fixed

Gary Wednesday January 14, 2015

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

Refixing an old fix, and fixing a parallel case.

Gary Wednesday January 14, 2015

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.

The start of a new year

Gary Tuesday January 13, 2015

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.

User friendliness and program flexibility trumps code efficiency

Gary Thursday January 8, 2015

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.

Enabling Bootstrap themes to color Tiki's superfish menus

Gary Wednesday January 7, 2015

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.

  • «
  • 1 (current)
  • 2