Looks great. Thanks for allowing to test your theme. And for the hard work which was done by both of you.

Bugreport (I used your Demo):
"M1 14 Do you know at what date & time you were born?"

When using the date/time question the year is not transferred from the javascript date/time picker. "Y" is pasted into the field instead of 2015.

The picker is displayed when clicking into the field. It is not possible to enter the date/time via the keyboard. The date/time-picker is overlaying that area. Is that an intended behavior. Personal I like to be able to use both ways. Picker via Button at the side or entering via keyboard.


Not sure if missing IE8 support (with the developer hat on I wouldn't support IE8 too) is hurting usage in certain scenarios. Anyone with real life examples where IE8 was crucial for a project? WindowsXP was the OS with IE8 as a last release. The Windows OS flavors under active support are on IE11.

Oops, my mistake, this was a wrong setting in the advanced settings of the date question. I corrected this.

In my browser I can enter the date now. Could you try again and see if it works now?

if not, what browser are you using? We will on it then.

And yes: we will not support IE8, this is ancient. In previous projects supporting IE8 cost us about 20-25% of development time and we cannot afford to spend that time on a declining browser. But if anyone want to support us in doing so, we will.

tammo wrote: In my browser I can enter the date now. Could you try again and see if it works now?

The year is now transferred into the field.

But the picker is still shown when the field is clicked. A entering by keyboard is not possible. Which might relates to available screen estate. I always test browsing in virtual machines with different screen resolutions.

In this screenshot the browser window is 1092px x 856px and the viewport is 1084px x 679px.


Is that intended behavior (datetime-picker as the only input method to ensure correct format)?

OK, thanks. I've put it on our internal issue list.

Maybe this (large) date time picker is not a good candidate for larger screens. But we will see what we can do.

As it turns out, the date/time picker now is styled in a combination of standard jQuery (calendar) together with some of our styling elements (sliders). Because we want users to be able to fill in on tablets/mobile phones, the sliders must be a little larger than normally in jQuery. This results in a larger layout for the complete date/time picker.

For use on mobile phones we advise to split the question in 2: a date question separate from a time question.

We have implemented this in a new version of our test survey, to be found at:
survey.toolsforresearch.com/index.php/123456/lang-en

tammo wrote: Because we want users to be able to fill in on tablets/mobile phones, the sliders must be a little larger than normally in jQuery. This results in a larger layout for the complete date/time picker.

The silder size feels more like looking through an "ease of use" magnifer. I am not totally convinced of mobile first with surveys. These silders size looks "strange" with a desktop browser setup.

I cannot remember using a date/time-picker in a survey, so I will stop commenting on that picker.I am sure you will have a lot more "little" bugs on you todo-list.

I would like to see the gpl version bundled with Limesurvey to ensure better debugging. Not sure if a referral-program for the commercial template can bring the limesurvey project a few bucks too if they bundle it. Just louding thinking from a user.

Yes, we do have several little things still to do with the template, but little by little we will be getting there.

Thanks!

When importing the version 1.21 from GIT or your dedicated website the following error occurs:

"Unable to find startpage.pstpl to add {TEMPLATEJS} placeholder, please check your template."

The git archives are containing another directory. So the path for the imported template is then
tfr_responsive-121/tfr_responsive-1.2.1 instead of tfr_responsive-121.

Another point concerning data protection and tracking is the direct usage of google font api
You should add the fonts to the package directly (haven't checked the licence) or point out in a Readme/FAQ how to prevent using the external API and adding webfonts to the template locally.

You really should try to get the free version bundled with Limesurvey. There might be some conflicts but a broad distribution will help to fix bugs soon. Other commercial offers could join. But since you seem very serious with the design team doing this template we should acknowledge the invested time and money. Still not convinced about the proportions of some gui elements but a broader distribution of the template will show us what size is the optimum.

Thanks.

Hi Jelo,

we also saw the "glitch" in Github, therefore we now guide users to the download we host ourselves at:

toolsforresearch.com/limesurvey-responsive-template

The download you will find there does not have that ugly github-wrapper. Since LimeSurvey uses Github for it's own development, it would be nice if these problems could be handled, but the developers point all their energy into LimeSurvey itself, which is a choice I can understand (most of the time).

In the current version we did indeed use the Google fonts and a font of our own, but this became a problem, because the template editor did not accept font files (until the most recent build of LimeSurvey). Since many people still use older versions of LimeSurvey, we have to refer to foonts at some place on the Internet, we have even changed the upcoming release to fetch the font files from our own server. Of course this may change when the template editor accepts the font files at the majority of users.

Next week the commercial version of the template will be available through the template shop of Marcel Minke (Mazi). We now focus on that step. After that we can look into the possibilities of getting this free template into LimeSurvey, we have not yet taken any steps in that direction. I'll ask Mazi if this is something we should explore.

You also wrote about the error message around the {TEMPLATEJS} placeholder. I also saw this, but could not find out what was wrong. The template did seem to work. Do you know what could cause this error message to appear?

Thanks for you encouraging words. The template development turned out to be a much longer trip than we anticipated, we visited places in LimeSurvey that we even did not know that they existed, and still we feel that LimeSurvey is a city without a real map, a city in which we have visited the highlight, but far from every street and corner....

tammo wrote: we have to refer to foonts at some place on the Internet

Often I think it could be very great to have a Limesurvey CDN serving all major static files (including some extra widely-used fonts like open-sans)... It will be especially valuable for users with basic shared hosting packages where the most of the time, gzip compression is impossible to turn on.

This said, thanks again for this high quality new template!

tammo wrote: You also wrote about the error message around the {TEMPLATEJS} placeholder. I also saw this, but could not find out what was wrong. The template did seem to work. Do you know what could cause this error message to appear?

The Import/Upgrade routine is checking for placeholder {TEMPLATEJS}.
You could add that to your template.

In the templates shipped with Limesurvey you will lines like this:
As long as you add these files manually the placeholder won't be missed technically.
But you might get support calls because of this upgrade error message.
Marcel will be able to check that before shipping of the commercial version starts.
Make sure that you warn buyers about which browser versions are not actively supported.

I saw that the template editor expects all files that belong to the template to reside in the root of the template.

We never used the template editor, we always used the FTP-upload and never saw problems. We learned that multiple users cannot do this, since FTP-access is not available for them.

They have to use the template editor. This routine is defined rather rough, since it forces template developers into making a mess os the template root. We rather use several directories for different sort of files.

I already asked our developers to reintroduce the mess in the root of the template, since that will give the least trouble at the moment, but it would be worth looking into a better structure of the template directory and a smarter template editor that will look at the places where the files are stored, following the paths that are mentioned in the template files...