IRC chat at 20 April 2015 between Gary (chibaguy), Mette (amette) and Torsten (fabricius) about the JS no-script requirements of Tiki.
Main important conclusions between 15:21:24 and 15:45:04
13:15:56 - chibaguy: I do think it's interesting how strongly people feel about javascript. It was a surprise to me when the objection was raised recently.
13:16:11 - chibaguy: Seems to be kind of a regional thing, also.
14:46:05 - fabricius: chibaguy: yes, indeed it might be a regional thing. and it might be a thing of certain user groups and types of NGOs ... yet Frank, Mette and myself strongly feel that they ave to be adresses and shaould not be left behind or ignored
14:48:33 - chibaguy: fabricius, i was just doing some research and one site said that no-javascript users are 2% in the US and 1.6% in France and Spain (just some examples). I thought the percentage was higher in Europe based on our little community here.
14:48:49 - chibaguy: (The figures are a few years old.)
14:50:34 - chibaguy: Seems like there are case-by-case workarounds, like these: http://stackoverflow.com/questions/22153388/bootstrap-no-script-fall-back-for-drop-down-button 14:51:22 - fabricius: chibaguy: we (mainly Frank, Mette and myself) are talking about basic stuff - navigation, browsing content, editing a WikiPage, stuff like that. It should at lest be possible for site admins to offer fallbacks for that without the need to completely rewrite the templates (and then maintaining te full set).
14:55:22 - chibaguy: Hopefully the template modifications (or lib/smarty_tiki modifications) aren't too extensive.
14:55:31 - fabricius: chibaguy: as we have the opportunity to create navbars in custom modules manually, those workarounds can do the job for that. module_menu has a bootstrap=y/n option, which is quite good. Lindon just committed a css behaviour for ellipses for the preference "switch off javascript", which is not really what we need, but indeed a step furter
14:57:20 - fabricius: we need to find a standart procedure, a method that is not too complicated for ellipses, drop downs, wrenches in the templated - I do want to prevent blowing up the templates
14:57:35 - fabricius: /s/templated/templates
14:57:45 - chibaguy: I suppose it'd be a "selling point" if we can say Tiki works without javascript, for sure, even if that isn't an issue for 98% of site users.
14:59:06 - fabricius: a good point, even if we should say then "Tiki works without JS to some extend" ;-)
14:59:31 - fabricius: actually chibaguy: extend or extent ?
14:59:38 - chibaguy: extent
14:59:41 - fabricius: ah ok
14:59:43 - chibaguy: extend is the verb.
14:59:44 - fabricius: thx
14:59:52 - chibaguy: sure
15:02:06 - fabricius: but as you are very deeply involved in the templates chibaguy, do you know how the parameter "bootstrap=y/n" is implemented for the menus? Do you think that could be a "hook" to make the dropdowns, ellipses etc. css when JS is not detected?
15:04:29 - fabricius: I feel, that switching off JS for the whole site would be kind of a crude workaround (better then nothing), which allows a no-script perspective. I'd wish more that those elements fall back to "css mode" if no-script automatically - and for the preference approach there is some code for every affected dropdown anyway
15:04:47 - fabricius: what do you think would be a path worth to try?
15:05:17 - chibaguy: well, I only know the menubuilding varies depending on the bootstrap=y/n switch. I imagine a check for javascript can be integrated into that.
15:05:49 - chibaguy: Well, CSS is what hides the hidden elements to begin with. If you switch off both JS and CSS, everything is visible on the page. ;-)
15:05:55 - chibaguy: But ugly.
15:06:43 - chibaguy: Sometimes I do switch off CSS (in Opera 12, you can switch between "author style" and "user style" which in my case means no style).
15:07:11 - fabricius: my idea would be kind of a general method - some documented code snippet(s) or so - which "tell" tiki, that if JS is not detected parameter bootstrap=y falls back to parameter bootstrap=n, even if default setting applies (no parameter set manually)
15:08:06 - chibaguy: Someone needs to reply about that, who actually knows how it would be implemented ;-).
15:08:44 - fabricius: actually we do need to find out how we can and then how we want to implement it
15:08:48 - fabricius: humm
15:09:04 - fabricius: very first we ave to deside if we WANT to implement it
15:09:14 - fabricius: /s/ave/have
15:17:40 - fabricius: chibaguy: Even if it might be an interesting question and helpful to know, why site visitors or users wanted to stay no-script, the more important question is, if we want to respect their desicion at least to an extent and if we want to respect the requirement from consultants to adress tis target group
15:19:59 - fabricius: you aswell mentioned no-script capabilities as possible "selling point" and that only about 1.6% to 2% of might be the figure of users who use no-script. I think about how many users that would be a absolte number and how many possible customers that could be.
15:20:39 - chibaguy: I think it's important to know the reasons why people don't want sites to use javascript, to help us decide the priority of no-js functionality. A much larger group than noscript people is probably using IE 7 or 8 and we don't support them any more because there's no valid reason for them to not use modern browsers, I suppose.
snip
15:21:03 - amette: polom
15:21:15 - chibaguy: hey amette.
15:21:24 - amette: yeah, I think the "valid reason" is the reason - not activating JS is quite valid imho.
15:21:25 - fabricius: what would be, if that would be about a few hundretthousand people and if there would be projects to try to offer them collaboration and knowledge/document management, but those projects would not find appropriate software
15:21:30 - amette: hi chibaguy and fabricius 15:21:34 - fabricius: hi amette
15:21:37 - fabricius: how are you?
15:21:44 - amette: fine thanks, how are you?
15:22:03 - fabricius: not too bad, but the JS discussion is eating time - massively
15:22:15 - amette: I believe so.
15:22:21 - fabricius: very good, that you pop in and add comments
15:23:11 - fabricius: gives me some relieve, cause I am not mainly advertising for myself, but more advocating other users requirements
15:23:15 - amette: chibaguy: I'd guess that people using the Tor Browser Bundle are probably an easy to imagine group of people that don't want JavaScript for security/privacy purposes.
15:23:55 - amette: I don't think that everything in Tiki needs work without JavaScript (and that's impossible, I understand that).
15:24:22 - amette: But if people just trying to privately research information on the web, can't do so without risking their security, then Tiki went too far.
15:24:37 - amette: And imho it mustn't be impossible to display information wihtout needing JavaScript.
15:25:23 - fabricius: +1
15:26:03 - amette: If one wants to use advanced features on a Tiki site, then one most probably trusts that site already. At this point one would activate JavaScript and the burden turns over to the sysadmin of the site to use HTTPs and other technologies to make JS-injection impossible.
15:26:08 - chibaguy: search at a tiki site doesn't seem to require js in the browser, so that's good.
15:26:39 - chibaguy: I think displaying information is ok, too. Probably navigation is the main problem.
15:26:53 - amette: So I imagine a good rule of thumb being to "keep the information accessible" to people without JavaScript. This includes navigation, etc.
15:27:01 - amette: chibaguy: yep, I see you get me 15:27:04 - chibaguy: Well, some presentation of information needs js now - the modals and dropdowns.
15:27:29 - fabricius: where we maybe able to find methods
15:27:33 - chibaguy: also maybe file uploading? I'm not sure.
15:27:34 - amette: Please don't take the "keep the information accessible" as set in stone yet, but I guess this could be kind of a 1st rule for non-JS design.
15:28:06 - fabricius: and get selling point, as then Tiki has Bootstrap with noscript fallback, what is requested out there every here and then
15:28:13 - amette: Good point! File uploading is probably not really included in the "keep the information accessible", but it should also work without JS.
15:28:43 - fabricius: appears to be a start of a priority list
15:29:07 - amette: Modals and Dropdowns should (could?) have kind of a generic fallback solution as fabricius mentioned? Code once, fallback happens automatically?
15:29:27 - jonnyb ~anonymous@94.8.241.235 entered the room.
15:29:49 - fabricius: we are discussing that - here a bit with chibaguy, Frank and myself with Lindon, me yesterday with Nelson ...
15:30:06 - amette: So I think that this would be a nifty design and implementation issue for some things once, but then we get 80% of all issues figured out.
15:30:45 - fabricius: the question is, if we find a standart procedure for that, which does not blow up the templates and does not requieres double coding all over the place
15:31:13 - chibaguy: Whoever would do the implementing needs to check into that, I guess.
15:32:03 - amette: Yes, I think so. Sadly I am so far away from code recently, I fear I'm of not much help with that. :-/
15:32:12 - chibaguy: fabricius, are you thinking of this as a trunk/tiki 15 thing?
15:32:50 * amette thinks Tiki 15 is enough and a must at the same time since it's LTS again
15:33:25 - fabricius: we cannot pour code with a watering can over the template, as this would insult the massive work on templates done by chibaguy and a few others
15:34:29 - chibaguy: I think most of the changes won't be in the templates so much as in lib/smarty_tiki where the functional parts are put together.
15:34:39 - chibaguy: or similar places
15:34:46 - fabricius: chibaguy amette: If we would agree, that we really want it and we agree a decent behaviour, agree a priority list and minimum requirements, kind of an agreed plan, I am convinced that it would be ok to do that stuff on trunk and leave it out in 14
15:34:49 - amette: Terminating this for 15 does not mean though that one can push forced JS into 14 and then these parts of Tiki don't have to be 'fixed' for 15 - I got that impression from Lindon on the devel-list, I might have misunderstood though.
15:35:50 - fabricius: amette: I did not understand your previous sentence
15:36:45 - amette: chibaguy: Ok, cool, I hoped so that it could be done in lib/smarty_tiki. And those pieces of code would then basically also give a guideline for template writers.
15:37:05 - amette: fabricius: then forget about it - I went into ranting mode a bit
15:37:44 - amette: terminate is the wrong word though - schedule is right 15:37:54 - fabricius: ok, we leave it. I had controversial discussions there, but aswell mutual appologies ... no point to take it into the community
15:38:42 - amette: Terminate is a really bad false friend for a native German speaker when talking English! *GG*
15:39:37 - fabricius: hehe, yes, like "handy" for "mobile phone / cell phone" or "public viewing" for "publicly watch football in a group"
15:40:00 - fabricius: watching
15:40:08 - amette: Indeed. So, but: I think that between chibaguy, fabricius and me here in this chat we more or less agree, don't we?
15:41:43 - fabricius: from my side yes and I am convinced, that aswell Frank would agree to that if he would be here - I will inform him about the status - we should recapitulate before we go and put that onto the wiki page.
15:41:54 - chibaguy: I think so. I think it would be good to identify the things in Tiki that currently use (depend on) javascript. Then decide which are "essential" to provide a no-js fallback for. If we can all agree on those, it'll make it easier to go forward.
15:42:09 - chibaguy: Speakaing of go, I need to go take a shower now. bbl.
15:42:23 - amette: Indeed. So, but: I think that between chibaguy, fabricius and me here in this chat we more or less agree, don't we? 3. Implement it all for Tiki 15 LTS.
15:42:38 - amette: what happened with my last line of chat?! :P
15:42:44 - fabricius: chibaguy and amette would you be ok, when I put this IRC discussion added to the wikipage aswell?
15:43:34 - fabricius: amette, maybe too many independand lines / linebreaks
15:43:41 - fabricius: say it again amette
15:44:04 - amette: Plan of action: 1. Create a minimal set of rules that helps grasp the core concepts of non-JS, like "keep the information accessible" 2. Codify that. 3. Implement across the board for Tiki 15 LTS.
15:44:33 - fabricius: Codify you mean write the code?
15:45:04 - amette: And first step for point (1.) in my action plan is actually what chibaguy said: identify things in Tiki that currently depend on JS (and shouldn't).
snap
15:46:22 - amette: fabricius: yes, codify is sciency speak for 'turning intangible information from the minds of people into readable/transferrable code (like natural language or computer code)'
15:46:28 - fabricius: amette for clarification: with "depend on and shouldn't" you mean that needs a fallback?
15:46:39 - amette: yes
15:46:44 - fabricius: ok
15:47:09 - fabricius: so I agree to that recapitulation
15:47:29 - fabricius: gary? chibaguy
15:47:42 - amette: ok, cool - and yeah: feel free to add this chat to the page - IRC is logged anyways, so I think you don't have to ask
15:47:53 - fabricius: ok
15:48:45 - Cr0vaX 3e1cfae9@gateway/web/cgi-irc/kiwiirc.com/ip.62.28.250.233 entered the room.
15:49:35 - Cr0vaX: polom
15:49:42 - fabricius: Gary seems to be showering already. So we take it from here. Thank you very much amette .. you appeared at the right time at the right place ;-)
15:49:51 - fabricius: hi Cr0vaX
15:49:56 - fabricius: bolow
15:50:12 - amette: you're welcome fabricius *bow*
15:50:21 - amette: *ninjamettevanishesagain*
The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.
Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.
;){kind=link}
;){kind=link}
;){kind=link}
;){kind=link}
IRC chat at 20 April 2015 between Gary (chibaguy), Mette (amette) and Torsten (fabricius) about the JS no-script requirements of Tiki.
Main important conclusions between 15:21:24 and 15:45:04
13:15:56 - chibaguy: I do think it's interesting how strongly people feel about javascript. It was a surprise to me when the objection was raised recently.
13:16:11 - chibaguy: Seems to be kind of a regional thing, also.
14:46:05 - fabricius: chibaguy: yes, indeed it might be a regional thing. and it might be a thing of certain user groups and types of NGOs ... yet Frank, Mette and myself strongly feel that they ave to be adresses and shaould not be left behind or ignored
14:48:33 - chibaguy: fabricius, i was just doing some research and one site said that no-javascript users are 2% in the US and 1.6% in France and Spain (just some examples). I thought the percentage was higher in Europe based on our little community here.
14:48:49 - chibaguy: (The figures are a few years old.)
14:50:34 - chibaguy: Seems like there are case-by-case workarounds, like these: http://stackoverflow.com/questions/22153388/bootstrap-no-script-fall-back-for-drop-down-button
14:51:22 - fabricius: chibaguy: we (mainly Frank, Mette and myself) are talking about basic stuff - navigation, browsing content, editing a WikiPage, stuff like that. It should at lest be possible for site admins to offer fallbacks for that without the need to completely rewrite the templates (and then maintaining te full set).
14:55:22 - chibaguy: Hopefully the template modifications (or lib/smarty_tiki modifications) aren't too extensive.
14:55:31 - fabricius: chibaguy: as we have the opportunity to create navbars in custom modules manually, those workarounds can do the job for that. module_menu has a bootstrap=y/n option, which is quite good. Lindon just committed a css behaviour for ellipses for the preference "switch off javascript", which is not really what we need, but indeed a step furter
14:57:20 - fabricius: we need to find a standart procedure, a method that is not too complicated for ellipses, drop downs, wrenches in the templated - I do want to prevent blowing up the templates
14:57:35 - fabricius: /s/templated/templates
14:57:45 - chibaguy: I suppose it'd be a "selling point" if we can say Tiki works without javascript, for sure, even if that isn't an issue for 98% of site users.
14:59:06 - fabricius: a good point, even if we should say then "Tiki works without JS to some extend" ;-)
14:59:31 - fabricius: actually chibaguy: extend or extent ?
14:59:38 - chibaguy: extent
14:59:41 - fabricius: ah ok
14:59:43 - chibaguy: extend is the verb.
14:59:44 - fabricius: thx
14:59:52 - chibaguy: sure
15:02:06 - fabricius: but as you are very deeply involved in the templates chibaguy, do you know how the parameter "bootstrap=y/n" is implemented for the menus? Do you think that could be a "hook" to make the dropdowns, ellipses etc. css when JS is not detected?
15:04:29 - fabricius: I feel, that switching off JS for the whole site would be kind of a crude workaround (better then nothing), which allows a no-script perspective. I'd wish more that those elements fall back to "css mode" if no-script automatically - and for the preference approach there is some code for every affected dropdown anyway
15:04:47 - fabricius: what do you think would be a path worth to try?
15:05:17 - chibaguy: well, I only know the menubuilding varies depending on the bootstrap=y/n switch. I imagine a check for javascript can be integrated into that.
15:05:49 - chibaguy: Well, CSS is what hides the hidden elements to begin with. If you switch off both JS and CSS, everything is visible on the page. ;-)
15:05:55 - chibaguy: But ugly.
15:06:43 - chibaguy: Sometimes I do switch off CSS (in Opera 12, you can switch between "author style" and "user style" which in my case means no style).
15:07:11 - fabricius: my idea would be kind of a general method - some documented code snippet(s) or so - which "tell" tiki, that if JS is not detected parameter bootstrap=y falls back to parameter bootstrap=n, even if default setting applies (no parameter set manually)
15:08:06 - chibaguy: Someone needs to reply about that, who actually knows how it would be implemented ;-).
15:08:44 - fabricius: actually we do need to find out how we can and then how we want to implement it
15:08:48 - fabricius: humm
15:09:04 - fabricius: very first we ave to deside if we WANT to implement it
15:09:14 - fabricius: /s/ave/have
15:17:40 - fabricius: chibaguy: Even if it might be an interesting question and helpful to know, why site visitors or users wanted to stay no-script, the more important question is, if we want to respect their desicion at least to an extent and if we want to respect the requirement from consultants to adress tis target group
15:19:59 - fabricius: you aswell mentioned no-script capabilities as possible "selling point" and that only about 1.6% to 2% of might be the figure of users who use no-script. I think about how many users that would be a absolte number and how many possible customers that could be.
15:20:39 - chibaguy: I think it's important to know the reasons why people don't want sites to use javascript, to help us decide the priority of no-js functionality. A much larger group than noscript people is probably using IE 7 or 8 and we don't support them any more because there's no valid reason for them to not use modern browsers, I suppose.
snip
15:21:03 - amette: polom
15:21:15 - chibaguy: hey amette.
15:21:24 - amette: yeah, I think the "valid reason" is the reason - not activating JS is quite valid imho.
15:21:25 - fabricius: what would be, if that would be about a few hundretthousand people and if there would be projects to try to offer them collaboration and knowledge/document management, but those projects would not find appropriate software
15:21:30 - amette: hi chibaguy and fabricius
15:21:34 - fabricius: hi amette
15:21:37 - fabricius: how are you?
15:21:44 - amette: fine thanks, how are you?
15:22:03 - fabricius: not too bad, but the JS discussion is eating time - massively
15:22:15 - amette: I believe so.
15:22:21 - fabricius: very good, that you pop in and add comments
15:23:11 - fabricius: gives me some relieve, cause I am not mainly advertising for myself, but more advocating other users requirements
15:23:15 - amette: chibaguy: I'd guess that people using the Tor Browser Bundle are probably an easy to imagine group of people that don't want JavaScript for security/privacy purposes.
15:23:55 - amette: I don't think that everything in Tiki needs work without JavaScript (and that's impossible, I understand that).
15:24:22 - amette: But if people just trying to privately research information on the web, can't do so without risking their security, then Tiki went too far.
15:24:37 - amette: And imho it mustn't be impossible to display information wihtout needing JavaScript.
15:25:23 - fabricius: +1
15:26:03 - amette: If one wants to use advanced features on a Tiki site, then one most probably trusts that site already. At this point one would activate JavaScript and the burden turns over to the sysadmin of the site to use HTTPs and other technologies to make JS-injection impossible.
15:26:08 - chibaguy: search at a tiki site doesn't seem to require js in the browser, so that's good.
15:26:39 - chibaguy: I think displaying information is ok, too. Probably navigation is the main problem.
15:26:53 - amette: So I imagine a good rule of thumb being to "keep the information accessible" to people without JavaScript. This includes navigation, etc.
15:27:01 - amette: chibaguy: yep, I see you get me
15:27:04 - chibaguy: Well, some presentation of information needs js now - the modals and dropdowns.
15:27:29 - fabricius: where we maybe able to find methods
15:27:33 - chibaguy: also maybe file uploading? I'm not sure.
15:27:34 - amette: Please don't take the "keep the information accessible" as set in stone yet, but I guess this could be kind of a 1st rule for non-JS design.
15:28:06 - fabricius: and get selling point, as then Tiki has Bootstrap with noscript fallback, what is requested out there every here and then
15:28:13 - amette: Good point! File uploading is probably not really included in the "keep the information accessible", but it should also work without JS.
15:28:43 - fabricius: appears to be a start of a priority list
15:29:07 - amette: Modals and Dropdowns should (could?) have kind of a generic fallback solution as fabricius mentioned? Code once, fallback happens automatically?
15:29:27 - jonnyb ~anonymous@94.8.241.235 entered the room.
15:29:49 - fabricius: we are discussing that - here a bit with chibaguy, Frank and myself with Lindon, me yesterday with Nelson ...
15:30:06 - amette: So I think that this would be a nifty design and implementation issue for some things once, but then we get 80% of all issues figured out.
15:30:45 - fabricius: the question is, if we find a standart procedure for that, which does not blow up the templates and does not requieres double coding all over the place
15:31:13 - chibaguy: Whoever would do the implementing needs to check into that, I guess.
15:32:03 - amette: Yes, I think so. Sadly I am so far away from code recently, I fear I'm of not much help with that. :-/
15:32:12 - chibaguy: fabricius, are you thinking of this as a trunk/tiki 15 thing?
15:32:50 * amette thinks Tiki 15 is enough and a must at the same time since it's LTS again
15:33:25 - fabricius: we cannot pour code with a watering can over the template, as this would insult the massive work on templates done by chibaguy and a few others
15:34:29 - chibaguy: I think most of the changes won't be in the templates so much as in lib/smarty_tiki where the functional parts are put together.
15:34:39 - chibaguy: or similar places
15:34:46 - fabricius: chibaguy amette: If we would agree, that we really want it and we agree a decent behaviour, agree a priority list and minimum requirements, kind of an agreed plan, I am convinced that it would be ok to do that stuff on trunk and leave it out in 14
15:34:49 - amette: Terminating this for 15 does not mean though that one can push forced JS into 14 and then these parts of Tiki don't have to be 'fixed' for 15 - I got that impression from Lindon on the devel-list, I might have misunderstood though.
15:35:50 - fabricius: amette: I did not understand your previous sentence
15:36:45 - amette: chibaguy: Ok, cool, I hoped so that it could be done in lib/smarty_tiki. And those pieces of code would then basically also give a guideline for template writers.
15:37:05 - amette: fabricius: then forget about it - I went into ranting mode a bit
15:37:44 - amette: terminate is the wrong word though - schedule is right
15:37:54 - fabricius: ok, we leave it. I had controversial discussions there, but aswell mutual appologies ... no point to take it into the community
15:38:42 - amette: Terminate is a really bad false friend for a native German speaker when talking English! *GG*
15:39:37 - fabricius: hehe, yes, like "handy" for "mobile phone / cell phone" or "public viewing" for "publicly watch football in a group"
15:40:00 - fabricius: watching
15:40:08 - amette: Indeed. So, but: I think that between chibaguy, fabricius and me here in this chat we more or less agree, don't we?
15:41:43 - fabricius: from my side yes and I am convinced, that aswell Frank would agree to that if he would be here - I will inform him about the status - we should recapitulate before we go and put that onto the wiki page.
15:41:54 - chibaguy: I think so. I think it would be good to identify the things in Tiki that currently use (depend on) javascript. Then decide which are "essential" to provide a no-js fallback for. If we can all agree on those, it'll make it easier to go forward.
15:42:09 - chibaguy: Speakaing of go, I need to go take a shower now. bbl.
15:42:23 - amette: Indeed. So, but: I think that between chibaguy, fabricius and me here in this chat we more or less agree, don't we? 3. Implement it all for Tiki 15 LTS.
15:42:38 - amette: what happened with my last line of chat?! :P
15:42:44 - fabricius: chibaguy and amette would you be ok, when I put this IRC discussion added to the wikipage aswell?
15:43:34 - fabricius: amette, maybe too many independand lines / linebreaks
15:43:41 - fabricius: say it again amette
15:44:04 - amette: Plan of action: 1. Create a minimal set of rules that helps grasp the core concepts of non-JS, like "keep the information accessible" 2. Codify that. 3. Implement across the board for Tiki 15 LTS.
15:44:33 - fabricius: Codify you mean write the code?
15:45:04 - amette: And first step for point (1.) in my action plan is actually what chibaguy said: identify things in Tiki that currently depend on JS (and shouldn't).
snap
15:46:22 - amette: fabricius: yes, codify is sciency speak for 'turning intangible information from the minds of people into readable/transferrable code (like natural language or computer code)'
15:46:28 - fabricius: amette for clarification: with "depend on and shouldn't" you mean that needs a fallback?
15:46:39 - amette: yes
15:46:44 - fabricius: ok
15:47:09 - fabricius: so I agree to that recapitulation
15:47:29 - fabricius: gary? chibaguy
15:47:42 - amette: ok, cool - and yeah: feel free to add this chat to the page - IRC is logged anyways, so I think you don't have to ask
15:47:53 - fabricius: ok
15:48:45 - Cr0vaX 3e1cfae9@gateway/web/cgi-irc/kiwiirc.com/ip.62.28.250.233 entered the room.
15:49:35 - Cr0vaX: polom
15:49:42 - fabricius: Gary seems to be showering already. So we take it from here. Thank you very much amette .. you appeared at the right time at the right place ;-)
15:49:51 - fabricius: hi Cr0vaX
15:49:56 - fabricius: bolow
15:50:12 - amette: you're welcome fabricius *bow*
15:50:21 - amette: *ninjamettevanishesagain*