Session Start: Mon Nov 13 22:02:56 2006 Session Ident: #twiki_edinburgh [22:02] * Now talking in #twiki_edinburgh [22:02] * Topic is 'http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x11x13' [22:02] * Set by SvenDowideit on Mon Nov 13 15:12:21 [22:03] all at once [22:03] Ho Arthur, Lavr [22:03] hi Kenneth [22:03] Hello everyone [22:03] hi arthur, harald, kenneth! [22:03] hi sven (here?) [22:03] evening all :) [22:03] long time no see at meeting sven! [22:04] yep, long time, no sensible TZ [22:04] GMT+1 is sooo much better [22:04] They should send you to Zürich more frequently [22:04] i wish [22:04] this is probly the last time too [22:04] how long will you be in zurich this time? [22:04] mid jan [22:04] so, not long [22:05] Well, a couple of release meetings though :-) [22:05] hehe :0 [22:06] is crawford going to join? [22:07] don't think so, he's busier than an ants nest [22:07] +5 min, sahll we start? [22:07] fine [22:08] http://twiki.org/cgi-bin/view/Codev/EdinburghReleaseMeeting2006x11x13 [22:08] anything to add to proposed agenda? [22:08] some shameless self promotion - http://blog.wikiring.com/Blog/WebHome [22:09] on the side, or as part of agenda? [22:09] it fits to the basicUI thing - but i presume thats for 4.2? [22:10] http://twiki.org/cgi-bin/view/Codev/TWikiBasicMode [22:10] ok, lets add a "basic ui discussion" at the end [22:11] i volunteer to be the facilitator [22:11] And I am on the minutes already [22:11] ok, thanks [22:12] +10 min, ok lets start [22:12] ---+ 1. Review Previous Action Items [22:12] - Peter and Kenneth to provide feedback for Sam on PostDakarTrackingAndDiscussion [22:12] i just did that at http://twiki.org/cgi-bin/view/Codev/PostDakarTrackingAndDiscussion [22:13] Did not see it yet [22:13] kenneth, please review and change as needed [22:13] OK [22:13] (see bottom; reload page if needed) [22:14] - Kenneth to make short description of the requirements for the script to create the zips with only the changed files [22:14] - Kwang will use the above and make a stab on making the script. [22:14] what is the status on this one? [22:14] I did not prioritize that yet. I have been using the little time I has on building beta which caused some problems [22:15] ok, so lets carry that a.i. forward [22:15] * ktwilight has joined #twiki_edinburgh [22:15] hello hello :) [22:15] (lets skip all "done items) [22:15] hi kwang [22:15] - Kenneth builds a quick and non-unit-test-passing beta to get testing started outside pseudo-install. [22:16] I spent last weekend on that but did not finish due to problems with build script [22:16] this is stalled on Bugs:Item3098 [22:16] That is resolved. [22:16] ok [22:16] But there is new issues all the time. Tonight it is /var/www/Build04x01/templates/edit.iejs.tmpl does not exist [22:16] lets discuss build on agenda item 3 [22:17] Build now fails on the smallest problem. [22:17] that is all on open action items [22:17] ---+ 2. Review Proposed Features of TWiki 4.1 [22:17] http://twiki.org/cgi-bin/view/Codev/TemplatePathIsCounterintuitive is first [22:18] Thomas has worked on it. [22:19] I am not sure what is missing now. [22:19] doco? [22:20] any idea what tests have been run? [22:20] cos from the topic, i really don't know what Thomas has done, or if it will help / hinder [22:21] I am loking for the bugs item. He did check in code. [22:21] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item2907 [22:22] I think Thomas is waiting for feedback to what he did. The only checkin was 11941 on this one [22:22] imo i can't give feedback until i see some docco [22:22] (ie, what he intended his code to do) [22:23] He implemented a template search path in configure [22:23] r11941 is only a change in unit test [22:23] there must be another change [22:23] Maybe there is an additional bug item. [22:24] Let us ask Thomas [22:25] to provide us with some pointers [22:25] i think that calls an action item for thomas to update the codev topic with starte of implementation and to document the enhancement [22:25] s/starte/state/ [22:26] move on to the next item? [22:26] there is one more ready to discuss: [22:26] http://twiki.org/cgi-bin/view/Codev/TemplateAffectsTextarea [22:26] Yes. This one is still pretty open. [22:27] I found the %TEXTSTART% syntax pretty geeky. [22:28] i have the feeling that like a number of Thomas' recent things, that there is another way to achieve his end [22:28] it is a renamed SPLIT [22:29] Noone has really told Thomas how to do a WORKING alternative to his proposal. My reservation are mainly related to the syntax. [22:30] actually I couldn't find another way, but intuitively I dislike the syntax [22:30] heh [22:30] while i wonder if this sort of rarely used thing should be in the core [22:30] Yes. It starts a section of something without any clear definition of where the thing started actually ends., [22:30] as it will be hard to test and to maintain [22:31] it looks like this needs some more discussion [22:31] thomas has a real need for his SectionalEditPlugin [22:31] his needs should be addressed in one way or another [22:32] I agree. [22:32] yes, but the work i do in inline edit acheives the same sorts of things [22:32] without needing to chang e the core [22:32] I fail to see that this has to do with InlineEdit [22:32] which makes me somewhat puzzled by his sudden needs [22:32] sven: since you have done that sort of things already could you help out thomas? [22:32] inline edit and sectional edit are almost the same thing [22:33] just that inline is alot more generic [22:33] but uses javascript and ajax to remove server round trips [22:33] They are pretty far apart. If you want a static text defined by a template and the user only edits a part of is - that is not really the same scope as the sectional edit. [22:34] shrug [22:34] sectional and inline is what i'm talking about - as referenced by PeterThoeny [22:34] Thomas wants to be able to have some template defined content which you do not edit when you hit the edit button [22:34] yep [22:35] And his problem is that the normal TWiki features do not work when defined in templates. [22:35] yep [22:36] And his proposal is to start rendering when you meet the %TEXTSTART% variable in the template. It solves the problem but I do not like this syntax. It is hopeless to understand and document. [22:36] You almost expect a TEXTSTOP tag to match it. [22:37] And TEXTSTART does not really tell anyone what it really means. [22:37] his proposal is to add more syntax - that's part of the trouble [22:38] well its like SPLIT [22:38] that is not documented either [22:38] and awful to maintain [22:38] So do we reject the whole idea or propose a better syntax? [22:39] i'd suggest that 4.1 is too soon [22:39] I would like to see a better syntax [22:39] unless i misunderstand the hoped for timeline [22:39] could a specially named section fill the needs? [22:39] that's what thomas rejected [22:40] but it seems better maintainable [22:40] actually, it could be a special formfield type thing [22:41] or a meta setting [22:41] as thier visibility is already controlable [22:41] i think we are not ready to make a decision at this meeting [22:42] so the view.tmpl would have the %FORMFIELD{'hiddenfromedit'}% [22:42] to help thomas we should discuss this further and point out alternatives [22:42] This topic has been open for long now so at least we need to give Thomas some directions. [22:42] agreed, he needs feedback [22:42] actually [22:42] a META setting [22:43] setting HIDDENPRE and HIDDENPOST [22:43] and the view tmpl contains %HIDDENPRE% %TEXT% %HIDDENPOST% [22:43] did i just solve it with zero code? [22:44] sven, i do not follow [22:44] Neither do I [22:44] ok, you know how you can set topic variables from the 'more topic actions' [22:45] and they go into %META:SET or something [22:45] topic templates can define them, and they get carried over to the created topic (i did this a few months ago) [22:45] then those variables can be used in the view.tmpl [22:46] and when they are not set, they are '' [22:46] sounds like a good proposal to put forward [22:46] "Edit topic preference settings" on oops more [22:46] this presumes i've understood his requirements [22:47] ok - i'll add it to the topic [22:47] I still do not see how this enables what Thomas needs. [22:48] i understand the hidden topic settings, stored as META:SETTING, but i do not see the connection to _where_ in the text you want to start edit the content [22:48] it makes it possible to have topic text that is rendered in view, that is _not_ in the edit textarea [22:48] which is what i understand the topic to say [22:49] I have the understanding that Thomas want to use a template doc for certain topics that adds some default text before or after the editable area [22:49] yep [22:49] thats exactly what you get with my suggestion [22:49] as i understand, thomas needs a way to mark a position in topic text where anything up to the marker is rendered for view, but not shown in edit [22:50] snap :) [22:50] (bu suvives an edit/save cycle) [22:51] How will he then edit one template which affacts maybe 1000 topics? [22:51] set the HIDDENPRE to %INCLUDE{somewhere}% ? [22:51] oh, i get it now, yes, the hidden PRETEXT is set as topic preference, and rendered by view [22:52] Sven will you add your proposal to the TemplateAffectsTextarea ? [22:52] ok - i've added it, hopefully Thomas can grok my oddness :) [22:52] And in case this is not what Thomas needs - do we have some directions for him? [22:53] kenneth: the hidden HIDDENPRE setting may also INCLUDE another topic, that way you can change it for a set of topics in one location [22:53] if it does not, then in my case i've not groked his need [22:54] IF Thomas accepts a SECTION approach - and he codes it - will it have a chance to be accepted? That is the least we have to give him of feedback. [22:54] _I_ would vote to reject any new syntax that can be shown as un-necessary [22:54] i can sense (and i agree) that the unitary TEXTSTART will not be accepted [22:55] can sections be nested? [22:55] its a cruel concept wrt editing [22:56] i hope to get there one day, because it matches how somethings are conceptualised, but it means you are doing cross merging, within a single version [22:56] and thus is awkward [22:56] oh, sorry, nested y [22:57] overlapping is the nasty [22:57] STARTRENDER - STOPRENDER could be an alternative as well which at least I would find easier to understand. [22:58] so we can suggest thomas two aletrnatives: [22:58] - svens idea of hidden topic settings [22:58] - named section in template (might have additional sections in body text, nexted) [22:59] i think it is too early to decide on this, lets give thomas time to address the suggestions [23:00] I take this to the minutes... [23:00] * Meeting participants agreed that we do not like the %TEXTSTART% syntax as proposed. [23:00] * Sven D adds a proposal to meet Thomas actual need with existing features. [23:00] * Thomas should evaluate and see if this meets his need. [23:00] * Kenneth proposed STARTRENDER - STOPRENDER as simpler alternative [23:00] * All needs to give Thomas more feedback. [23:00] ok [23:00] Next is TWikiJavaScriptRefactoring. [23:01] is http://twiki.org/cgi-bin/view/Codev/TWikiJavaScriptRefactoring ready for discussion/decision? [23:01] Is there anything to decide? Seems all agreed. [23:02] this looks good to me [23:02] as long as things fall back gracefully [23:03] I think that is not proposed otherwise. It is just a proposal of refactoring and API naming. [23:03] lets all talk about ArthurClemens like he's not here :) [23:03] sorry [23:03] was away for a sec [23:04] gnr [23:04] the idea is to slowly move out twiki.js, once all is done [23:05] DO you expect this done for 4.1? [23:05] the current process is to use unit tests [23:05] yes [23:05] so by then we will have a solid js utils API [23:06] Sounds good. [23:06] I have recorded the proposal as accepted. [23:06] Next is http://twiki.org/cgi-bin/view/Codev/DocumentedDefaultParameterValuesForInclude [23:07] i'm just adding 3 q's to that [23:07] And my initial reaction is that in its full proposed content it does not belong in core. [23:07] I am confused for several reasons: [23:07] sounds like it can and should be delveloped as a plugin [23:07] the docco is really not clear as to what it does [23:07] why are you limiting yourself to doccoing just INCLUDE - shouldn't all TML tags be doccoed in the same way? [23:07] * PeterThoeny_ has joined #twiki_edinburgh [23:07] * PeterThoeny_ is now known as PeterThoeny__ [23:08] sorry, my wifi died [23:08] but lastly - it seems that there is still discussion on what its going to acheive - so i'd vote for plugin / defer to next release [23:08] I still do not get the main reason behind the proposal [23:08] I can see the need - in core - for being able to have TWiki vars in an included topic which have a default value unless redefined in the INCLUDE statement. [23:08] ah [23:08] mmm, i think we already have that [23:08] what topic are we now discussing? [23:09] http://twiki.org/cgi-bin/view/Codev/DocumentedDefaultParameterValuesForInclude [23:09] tks [23:09] BugsContrib does soethign like that with named parmaeters [23:09] and default settings [23:09] If you have a topic which you have included many places and then add a new TWiki var in the "macro" topic then you will have this var undefined and shown as %HJHJHJ% [23:09] And I have not found a way around that other than adding the extra parameter to all the INCLUDEs [23:10] IF there is a way to do that then the proposal has little value. [23:10] like %INCLUDE{ [23:10] "Bugs.Tabulator" [23:10] STATUS="New" [23:11] http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Tabulator?raw=on [23:11] Hmmm. Yes we do something in the bugs web. [23:11] has defaults [23:11] and then http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/NewItems?raw=on uses that MarcoTopic [23:12] I think that one of the points Niels made was that he wanted to add documentation in a "formal" way [23:12] I tried something similar and could not make it work. [23:12] ya, formal docco would be nice [23:12] but then his propsal needs to be a little more formal [23:12] :-) [23:13] But you can also just document your "macro" in the topic and made a "document" section. [23:13] I doubt many will really use this feature in actual TWiki apps. The look of the table will never be right. Or you need additional columns. Etc [23:13] Lavr: Correct - I'd also doubt that the documentation alone would justify another new core TWikivar [23:14] i have a hard time understanding this proposal [23:15] if it is the lack of inheriting topic settings when including another topic, how about a new switch in INCLUDE, such as inheritsettings="on" ? [23:15] we already inherit settings from teh included topic [23:16] that's right, so the other way around: evalsettings="on" [23:16] Niels wants to write topics which are intended to be INCLUDEd from many topics and which use many topic variables - which are intended to be passed in the INCLUDE variable [23:16] HaraldJoerg, how is tha tdifferent from the 2 BugsContrib url's i posted? [23:17] (which i think do exactly that) [23:17] SvenDowideit: Yep [23:17] Yep. And those not in the "parameter list" are given defaults. And that is difficult to get to work. [23:17] I think it works in the Bugs app because of the URLPARAM [23:17] Lavr, next time you have trouble - raise a bug [23:17] it should not be difficult [23:18] yes, but iirc cdot added something in dakar to be better [23:18] Bugs is cairo-able [23:20] * PeterThoeny has quit IRC (Read error: 110 (Connection timed out)) [23:20] * Lavr is searching for my simple example topic [23:21] Found them. http://www.lavrsen.dk/twiki/bin/view/Sandbox/IncludeSectionTestMaster and http://www.lavrsen.dk/twiki/bin/view/Sandbox/IncludeSectionTest [23:23] IncludeSectionTestMaster includes IncludeSectionTest with only one var set. And the included * Set .... have no impact. [23:23] And I am sure most normal users stop trying there. [23:23] ok Lavr i won't diagnose it now :) [23:23] but i betcha... [23:24] If there is an easy work around we should document it. [23:24] ok, how should we proceed with this proposal? [23:24] We agree that the original proposal is not desired (incl documentation). RIght? [23:25] i'd suggest the options are 1)plugin 2)better docco of the proposal, nothing for this release though [23:25] yes, i can sense that the current proposal raises some eyebrows [23:26] His proposal is pretty well doc'ed. That is not the issue. The issue is that the proposal is not what we normally put in core. [23:26] niels needs more feedback from us [23:26] train for 4.1 left station [23:26] But if there is a work around then even the simple proposal without doc is not worth considering. [23:27] Lavr, for me, its really not clear what he's really proposing [23:27] if there is a feasable workaround, that that should do it [23:27] sounds like the solution was there before a proper problem was defined [23:28] i suggest to give him the feedback from this meeting on alternative solution, and give him time to address it (in any case not for 4.1 release) [23:28] is that ok? [23:29] He actually did write the code and he made the deadline. 1 hour before last release meeting so we have to treat it by the process. [23:29] The immediate answer is - * Documented Default Parameter Values For Include - is rejected. Does not belong in core as proposed. [23:29] And new proposal is for 4.2 in this case because of time. [23:30] y, though a plugin sounds more appropriate [23:30] As it is proposed now - it is a plugin type feature - yes. [23:31] Or maybe a TWikiFn (if they ever resurrect) :-) [23:31] i would say, yes, as plugin (but it might not be possible as plugin due to rendering sequence) [23:32] ok, shall we move on? [23:32] any other proposal items to discuss? [23:32] +90 min [23:32] One more. [23:32] PluginHandlerForContentMove was never really fully concluded. [23:33] Would anyone code it for 4.1 or can we defer it to 4.2? [23:33] last time i read that topic, i couldn't make out if it was decided that it was needed or not!! [23:33] i firmly believe we need this, twiki is a content management system and thus needs an official way of notifying plugins of moved content [23:33] it lacks a driver though (me) [23:34] oh, PeterThoeny__ you don't already have a solution for TagsPlugin? [23:34] i have a horrible hack now for the tagmeplugin [23:35] ah, ok - i needs somthign similar one day, and hoped it was solved :/ [23:35] but i sure won't have time for 4.1 [23:35] comparing topic name in init to topic name in commontags handler, [23:35] roger :) [23:35] which works most of the time, but not in all cases (such as statistics script) [23:35] which promptet me to exclude webhome from rename detection... [23:36] i guess that means its defered til we find a coder with time [23:36] so, if i find time for 4.1 i will implement it, if not lets defer it to 4.2 [23:37] Good enough since 4.2 doesn't sound like 2008 to me [23:37] Anyone want to vote on it to get the formal decision (and avoid futher arguing in future)? [23:38] vote: [23:38] 1- yes, new plugin handler [23:38] 2 - no new plugin handler (workaround hack is needed) [23:38] 1 [23:38] 1 [23:38] 1 [23:39] 1 - 4 new handlers, with ability for a plugin to veto action [23:39] 1 [23:39] sven: that sounds like a useful enhancement to the new feature (e.g. one step at a time) [23:39] ok, anything else before we go to release timing? [23:40] i suspect that as you'll be calling store [23:40] it will be easier to do both as one call fro store [23:40] now that i engage the brain [23:40] yep, that callback is from the store at time of rename [23:40] so intervention is doable [23:41] ---+ 3. TWiki 4.1 Release Timing [23:41] and the rename of the topic and that of the attachment (ooo, and web?) are probly in similar / same places [23:41] yep [23:41] tomorrow!!!! :D [23:41] time check: +100 min [23:41] I just tried to build the beta during this meeting. But I will have to hack MANIFEST first to make it work. [23:42] i have a hard deadline at +120 min [23:42] hack/fix... [23:43] * Flenser has joined #twiki_edinburgh [23:43] every release i did was the same+fix 10-20 unit tests & some testcases [23:44] f\\\i ended up building a private release every couple of days just to keep on top of the tests people ignored [23:44] Yes. I am building again now. Last weekend the build script was broken. It worked for plugins but not for TWiki. [23:44] yep [23:44] snafu. [23:44] ok, lets use the time here for scheduling, and lets take build issues offline [23:44] are there any blocker bugs for building beta? [23:45] I will know in minutes. I am building now. [23:45] Ah. That is the build part. I still need to do a minimum sanily checking to see that it can run. [23:45] so, no blocker bugs (except possibly for build itself) [23:45] so you're really saying beta will be out any time soon [23:46] depending on who stuffed up what :) [23:46] Unless there are surprises then I will put in on twiki.org tomorrow. [23:46] great! [23:47] on last meeting we said "Code freeze about one week after beta - then only bug fixes allowed" [23:47] so, code freeze possibly in a week [23:47] excellent. [23:48] OK. We also need the translators mobilized soon. [23:48] and rc1 in about two weeks, e.g. 2006-11-27 [23:48] do we create a release branch when we freeze? [23:49] possibly wait with release branch a bit, as an incentive to focus on bug fixing first? [23:49] I would keep it as it is during bug fixing. [23:49] is there any work being done on the TWiki performance testing? [23:50] * Flenser has left #twiki_edinburgh [23:50] HaraldJoerg, Lavr ? [23:50] Currently I'm rather "testing" than "performance testing" [23:50] I have been benchmarking very recently and we are as slow as always. At least we were one week ago. [23:51] i did some performance improvement on the "topic not found" page [23:51] how does 4.1 compare to 4.0? [23:51] ok but can we check on some code parts that are heavy weights? [23:51] Any significant performance improvement is way out of 4.1 [23:51] Peter. Did you also address the issue with search engines that triggers the oops? [23:51] yes [23:51] Cool. [23:52] There is no single culprit to blame for poor TWiki performance [23:52] but there is still one search left, and it needs to be in there: alert of topic rename [23:52] HaraldJoerg, yeah there is - the code :) [23:52] :-) [23:53] wasn't that the one that triggered search engines? [23:53] i think there are many small things where we can tune performance [23:53] 'alert of topic rename'? [23:53] arthur: the red text pointing to the new location of the topic [23:54] * ktwilight_ has joined #twiki_edinburgh [23:54] that needs to work in a regular url, e.g. when clicking on a twiki link in an old email [23:54] I had the impression MD blamed that link [23:54] the "similar topics" list search is now only done if you use the jump box [23:55] * ktwilight has quit IRC (Nick collision from services.) [23:55] no, the big culprit was the create tpic form in the "not found" page, it has two searches [23:55] The issue is when a search engine hits deleted topics (and that happens often because many are deleted spam topics) then it triggers load on the server. There must be an Apache way to avoid that [23:55] * ktwilight_ is now known as ktwilight [23:55] Lavr, not really [23:56] back to schedule [23:56] anything else to discuss on schedule? [23:56] the real answer is to return a topic moved / removed status [23:57] http://www.home.org.au/cgi-bin/view/Blog/BlogEntry2006x11x09x06x10?skin=zengarden;cssfile=http://www.csszengarden.com/080/080.css [23:57] ok, we are done with schedule [23:57] ---+ 4. UI Discussion [23:57] (i have to leave in 5 min) [23:58] and the 'next design' link loads the next submitted css [23:58] so you can browse the zen garden repository [23:58] http://twiki.org/cgi-bin/view/Codev/TWikiBasicMode [23:58] this started in an irc conv [23:59] I started to write a long reply to this. I do not really agree on this Basic Mode as being a great idea. Session Time: Tue Nov 14 00:00:00 2006 [00:00] Lavr, you will need to explain - in graphic detail [00:00] I do not think it is the UI that scares anyone. it is the TML. [00:00] user or developer point of view? [00:00] This is not about UI, but about interaction with twiki [00:00] My point of view [00:00] i think interaction is UI [00:01] Lavr, wikiring is still working on wysiwyg and other editing techs [00:01] depends on how you define UI :-) [00:01] t.o is dead [00:01] but there's a need for more funding, to get some momentum behind it [00:02] perhaps Colas can pay you instead [00:02] we're in 'talks' [00:02] ok [00:02] but his budget is very specific to his needs [00:02] so yes, WIKIWYG is one [00:03] but a lot of options one does not need is two [00:03] What I mean is that removing half the buttons from the normal PatternSkin when in view mode is not going to help anyone. [00:03] PeterThoeny__, are you bouncing t.o's apache? [00:03] and Sven has taken it further to mean also simpler skin editing [00:03] i just restarted apache [00:04] we had 100 views [00:04] cool [00:04] but it does. it is the difference between scary and handy [00:04] point is we always leave it up to the implementers to do something with twiki [00:05] actually, not just - i intend to remove options from the default view screen too [00:05] the result is we never question fundamental issues [00:05] to let people focus on editing [00:05] ok, i need to sign off now, sorry [00:05] slowly things are added [00:05] i keep logging... [00:05] but never removed [00:06] yep [00:06] ok, thanks peter [00:06] later [00:06] c-ya peter [00:06] and doccoed and comments added [00:06] The only thing I see wrong now - for a good and bad reason - is that we have both the edit and WYSIWYG buttons. [00:06] the register form has a giant piece of text [00:07] we also have Raw [00:07] and we have backlinks web and backlinks all [00:07] And they are good features for a Wiki like TWiki. [00:07] and history and incremental histories [00:07] main thing, is not all users / sites are the same [00:07] we are defaulting to power users [00:08] and twiki currently only caters to the more technical [00:08] all the time [00:08] rather than a suite of users [00:08] and actually we have made it very difficult to tune the interface [00:08] including the not really capable of css guy that wants a wiki, but wants to customise it, and then just use it for docco [00:08] easy once it's clear in docs. [00:08] These are essential features in a Wiki. Problem is that people try to use TWiki as something it is not really supposed to be. And that is fine but we should not sell the key TWiki features because of it. [00:08] because of all IFs and MAKETEXTS the templates are hard to edit [00:09] Lavr, it sounds like you're telling me that i should not be using twiki [00:09] seriously, i've no idea what twiki is really supposed to be. [00:09] What I am saying is that we should not reduce the default TWiki UI to a crippled version of TWiki. [00:10] then we offer a "personal sidebar" that is quite hard to maintain [00:10] all i know is twiki has a power to be anything it wants to be for different wiki cultures [00:10] s/cultures/subcultures [00:10] mmm, _if_ one decides that Lavr represents our majority usership, _then_ there is nothing wrong with our UI [00:11] _but_ i posit that Lavr is _not_ the majority, nor mean, median or mode [00:11] there's no cripple, or substandard or wahtever version, it's all 'bout customisability. twiki shouldn't stop simplification. [00:11] If we hide e.g. raw view what do you win? [00:11] I can't tell - I am offering a crippled version of TWiki to my users :-) [00:11] simple UI that's less confusing to users [00:11] raw view is one of the things I've moved to "more" [00:11] simplicity and stronger focus on core function [00:12] People will edit the page and cancel out to see the source. Noone will go to More... [00:12] my advisors slapped me in the face when they noticed that TWiki/TWikiRegistration is completely different from my current web [00:12] Lavr: Yes. So what? [00:12] how does that help? none. only cause confusion and issues [00:12] oddly, hitting edit&cancel is actually more user-expected [00:12] thats how you have a look at whats in a word doc too [00:13] Problem is they do not cancel. They always back out. [00:13] no problem [00:13] People get a lock warning then. [00:13] browser back should be hooked to a cancel anyway [00:13] its really not hard to answer each of your issues :) [00:13] It seems more intuitive for them to "edit" than to divine what a "raw" mode would be [00:13] And if you have no edit rights - then you need raw view. [00:14] what's the purpose of raw view? [00:14] buggerit, raw moe is a strawman [00:14] i don't see any reason for a normal wiki user to use raw [00:14] most of the actions on the default view skin are used less than 90% of the time [00:15] For users to see the code of other topics and steal the good stuff. Users do that all the time. [00:15] ktwilight: Let people who can only "view" but not "edit" copy nifty tricks from foreign pages [00:15] and taht of itself is a sign that the UI is over-emphasizing them [00:15] then something else is wrong. why would they need to see the code of others? where does the originator get it from? [00:15] i doubt the first person who started it didn't crawl on another page's raw [00:15] if that's true, then something is wrong with the Help section [00:15] doesn't sound like a common problem [00:16] zactly [00:16] all the docs seems worthless if everyone needs to check out the raw. [00:16] If you need a table format from a table that has the right size and setup, why start from scratch? Or a nice search that is 99% of what you need. [00:16] Actually it is not just about this button or that button. It is about the general attitude of twiki. [00:16] and the horrid nerds like me, never click, they type into the url [00:16] ArthurClemens, exactly [00:16] then we should have a plugin that saves certain common settings [00:16] like how Word does with macros [00:16] the zengarden work is showing that the default skins need re-doing [00:16] So I am happy with the current movement [00:17] ktwilight: I have to disagree. People usually see some interesting trick, want to check out how I did it - and only afterwards look at the doc [00:17] so that we can all use them as building blocks [00:17] well, for that, i agree with you, HaraldJoerg. but the frequency of such things for a normal wiki user? [00:17] Rare, I'd say [00:17] puttin' it to More or something would be cleaner [00:17] So why not present the raw view as option when edit is not allowed? [00:17] Yes, that's why I have it on "more" :-) [00:18] and once ya know how, ya don't have to keep going back, the Raw function is obselete [00:18] right now twiki's ui is like having format HD on the start bar in windows [00:18] all very handy, but i just don't do that very often [00:19] Yep. I've removed raw, history, backlinks, wysiwyg from my navigation [00:19] i like the customised sidebar, that's where such specific-user-common-functions should be in [00:19] I do not believe hiding UI is good UI. It helps the newbie the first 60 minutes of his use and pisses him off the next 10 years. [00:19] nice and easy. [00:19] Lavr: I don't think so. [00:20] Just take the HATED hide feature in Windows XP and Office XP. [00:20] we don't really need to vote :) [00:20] you have to look at context [00:20] People hate it and all turn it off. [00:20] hah, if they would find where to turn it off [00:20] surprisingly, everyone i know who uses XP like the hide feature [00:20] I agree, that is awful [00:20] i like to hide XP, in a bottom draw [00:21] worst is, they even know how to unhide easily! [00:21] I like to hide windows [00:21] unopened [00:22] looking at context, you will find that in most cases Quiet Save and Checkpoint lead to confusion [00:22] they are nice options for a Bugs system used by programmers [00:23] y - don't even use them there [00:23] so even preview is not handy if it doesn't happen below the edit screen [00:23] Yep. Quiet save is just superfluous IMHO. [00:23] Quiet Save is not used by us either. Checkpoint is not used because people do not know what it is. Once I teach then they start using it. [00:24] grin [00:24] the preview/edit part is handy [00:24] yes, in context of editing [00:24] presonally i'm thingking remove checkpoint, replace with a timer based bit of JS [00:24] teaching takes time and effort where time/effort can be spent elsewhere :( [00:24] I looked at the stats in the Apache log. Preview is used less than 1% of the time. [00:25] Lavr: Most people do edit/save/back and use the fact that "back" is pretty fast [00:25] on the other hand, in Edit mode it is often handy to be able to attach an image, or to retrieve the image name [00:25] But you'll know why you have "preview" if you start with XXXXXXXXXX topics [00:25] ??? [00:26] ...? [00:26] never used preview for that either [00:26] Ok: Edit XXXXXXXXXX -> Save. Get a number. Go back, edit XXXXXXXXXX again. Save again, get a new number. [00:26] maybe there should be a PatternLight :) [00:27] PatternGrave for the current :-) [00:27] or we go PatternZero! [00:27] mmm, instead of going back, why not finish editing? [00:27] always nice to follow coca cola [00:28] one of the reasons why i like inlinedit, it's straightforward, bang on [00:28] just gotta teach people how to double click though [00:28] SvenDowideit: "Back" in the browser is way faster than anything else [00:28] not any more [00:28] no way! [00:28] there's a [edit] link generated by the JS [00:28] like in mediawiki [00:29] and there will be more [00:29] that's nice too :) [00:29] great [00:29] please, not too much [00:29] contextual, like tiddlywiki [00:29] but withought the fade [00:29] tiddlywiki is good [00:29] i hate it [00:29] the fade sux [00:29] its too slow [00:29] that's true, but i meant the functionality of it, not performance [00:29] grin [00:30] i was tempted to use tiddlywiki, but it wasn't powderful enough [00:30] twiki with zen&inline kills it dead [00:30] can't we fix the stupid textarea in Bugs web? [00:30] fix? [00:31] irritates me every time [00:31] i didn't know there was a problem [00:31] it should be hidden [00:31] but it isn't [00:31] oh? [00:31] wonder what broke [00:31] there should be a template way to do this [00:31] there is [00:31] but EDIT_TMPL does something else [00:31] several in fact [00:32] create a skin? [00:32] there's an edit_form option to edit cgi, the css based option i used, and a few others [00:33] where is the edit_form set?> [00:33] yes, creating an edit templ to use for that form too, but i'm less thrilled with ti [00:33] in the url [00:33] (don't quote me on how the opition is spelt) [00:34] action Optional. Use the editaction template instead of the standard edit. If action=text, then hide the form. If action=form hide the normal text area and only edit the form. [00:34] ok, another time [00:34] http://develop.twiki.org/~twiki4/cgi-bin/view/TWiki/TWikiScripts#edit [00:35] seems we've lost Kenneth as well in the violent storm [00:35] grin [00:35] no hard feelings? [00:35] sleep for me, 2 hours after my jetlag normally kicks in [00:35] hard? [00:35] hehe [00:35] yep, going to find a sheet as well [00:36] I was studying something else. Not lost :-) [00:36] :( [00:36] ok, cy guys, good night [00:36] main thing is, that the tmpl work isn't for 4.1 anyway [00:36] nite [00:36] nite nite :) [00:36] * ktwilight waves [00:36] * ArthurClemens has quit IRC ("Leaving") [00:36] i should retire too [00:36] Good night. [00:36] * ktwilight waves [00:36] * ktwilight has left #twiki_edinburgh ("I'll be b-a-c-k") [00:37] Have been away for a minute and it seems that it's about closing time? [00:38] Which I wouldn't mind :-) So good night everyone [00:38] * HaraldJoerg has left #twiki_edinburgh [04:25] * PeterThoeny__ has quit IRC ("Computer decided to hibernate without asking") [04:26] * PeterThoeny has joined #twiki_edinburgh [06:33] * SvenDowideit has quit IRC (Read error: 110 (Connection timed out)) [06:36] * SvenDowideit has joined #twiki_edinburgh Session Close: Tue Nov 14 07:50:59 2006