=== jsgotangco [DaWorm@ipdial-246-113.info.com.ph] has joined #ubuntu-doc [01:44] morning [01:44] good night :) [01:45] acckk [01:45] froud's email was long icckkk [01:45] but explained clearly [01:45] yeah [01:46] but golly, my edits still didnt show images i guess he's going to change global.ent [01:50] ok ill see you guys later im the one cooking breakfast today [01:50] bbl === hypatia [~mary@adsl-66-203.swiftdsl.com.au] has joined #ubuntu-doc === hypatia [~mary@adsl-66-203.swiftdsl.com.au] has left #ubuntu-doc ["Leaving"] === trickie [~trickie@203-173-47-188.dyn.iinet.net.au] has joined #ubuntu-doc === Burgundavia [~corey@24.68.134.11] has joined #ubuntu-doc === Cturtle_ [~Cturtle__@a213-84-50-38.adsl.xs4all.nl] has joined #ubuntu-doc === mpt [~mpt@203.86.197.132] has joined #ubuntu-doc === jeffsch [~jeffsch@fatwire-201-47.uniserve.ca] has joined #ubuntu-doc === froud [~froud@ndn-165-155-230.telkomadsl.co.za] has joined #ubuntu-doc [08:35] African Greetings [08:36] salut [08:37] everybody loves 4am meetings [08:39] hey froud [08:39] there is a booboo in the i18n solution :( [08:40] I did some research today to find out why jsgotangco's excellent updates were not working. [08:40] is not entirely correct. [08:40] The '%' makes 'language' a parameter entity. [08:41] Parameter entities can only be used in a DTD. [08:41] In the document itself you must use general entities such as '&language;' [08:42] Therefore, this is how it should be: [08:42] [08:42] [08:43] I tried it in yelp with 'C' and 'it' languages. It works like that. [08:44] I committed a couple of changes. Can you verify that what I did is correct? Then we can update the rest. [08:44] jeffsch: hi, just hold lemme test [08:49] yes you a re right [08:49] it is my fault [08:49] I did say use a param ent [08:49] bah. just a typo. [08:49] no I said use a param ent [08:50] I must send an update to that message I sent [08:53] froud: on a different topic: in yelp for quickguide, etc, xref's show up as block elements [08:53] they are larger fonts, on their own lines, etc [08:54] but on yelp with update manager they are correctly used as inline elements, with clickable links [08:54] Yes, I noted this as a bug after release [08:55] we fixed it at our meeting and then it was forgotten to include it in the releave by the devs [08:55] geeze I hate being dependant on yelp [08:56] it's what's there [08:56] do we have the power to change? [08:56] Sure [08:56] For now I would like just to use a plain web browser [08:56] and research into a new help viewer [08:57] must build consensus first though. will take some time. [08:58] Sure [08:58] did you read the message from JanC [08:58] I think a blend of wxWidget's/wxPython's help system + a 'system-wide' [08:58] indexing system like Beagle + maybe yelp could become a better [08:58] documentation environment... [08:59] yes, but I didn't look into it... was busy with entities... [08:59] Burgundavia: yeah 4 am is harsh [08:59] I will just stay up [08:59] I am the only person out my way anyway [08:59] I will update them in the other docs [08:59] What time is it for South Africa [09:00] Burgundavia: vancouver's not that far :) [09:00] ok [09:00] I forgot about you [09:00] The time is UTC and I only know GMT [09:00] utc = gmt,no? [09:00] ahh UTC==GMT? [09:01] is it? [09:01] so she means 10 pm GMT? [09:01] 4am here is 1pm there [09:01] on Sunday [09:01] according to WP it doews [09:02] 1pm in za [09:03] so then UTC is not GMT [09:03] confused [09:03] I hate the time zones [09:04] just use internet time [09:04] used it for 4 years [09:04] the same time everywhere [09:05] is there an ez web site work this tuff out [09:05] UTC is GMT [09:05] UTC is GMT. 1200 UTC = 1200 GMT = 1pm za [09:05] http://www.timeanddate.com/worldclock/personal.html [09:07] Oh cause we are =2 or something [09:09] Burgundavia: [09:09] Sunday, April 17, 2005 at 10:00:00 Sun Noon [09:09] Sunday, April 17, 2005 at 11:00:00 Sun 1:00 PM [09:09] so 10 is noon [09:09] ok [09:09] Hmm thanks for that web site [09:10] geeze internet time is so much easier [09:10] jeffsch: all updates are now done [09:10] jeffsch: thanks for checking that [09:10] np [09:10] ok I have a question for you guys [09:11] and anyone else who is listening [09:11] so far we are just going by the seat of our pants when it comes to deining documents [09:11] defining [09:12] I think it will be a worthwhile excercise for us to ask the users what they want [09:12] wiki is perfect for this [09:13] I want to get Content Specifications, User Analysis and that stuff [09:13] Lets actualy learn who the audience is and what tasks they want to know about [09:14] how long using linux and what problems did they have [09:14] put a poll up and ask for answers and provide place to give commnet [09:14] thoughts? [09:15] sounds good [09:15] let's just cut to the chase and design for users new to linux, but not new to computers. [09:15] aren't they the target market? [09:15] not really [09:16] you see we also have admins [09:16] and people who have used linux [09:16] people new to administering linux? or people new to administering ubuntu? [09:17] My normal, formal approach, to writing is 4 steps: [09:17] 1. Create goals and objectives for the publication [09:17] 2. Analyze the product, audience, and environment [09:17] 3. Analyze the tasks the audience wants to perform [09:18] 4. Organize the publications and prepare rational [09:19] This gives me: [09:19] that's pretty much what I learned in school. make a document plan - it has user-task analysis, TOC, etc [09:19] a. Purpose of the guide [09:19] b. Product Desription [09:19] c. Audience profile [09:20] d task analysis [09:20] from this I can outline to the exact user requirements [09:20] sounds good [09:20] jeffsch: yes, obviously it is more complex [09:20] mpt: hi, please to meet you [09:20] likewise [09:20] mpt: thanks for your feedabck [09:21] arg [09:21] I think by putting it open for contributions form the users we can get a better handle on what we should do [09:21] I meant to reply to Mary's message but it got lost in Thunderbird [09:21] we have not done this [09:22] Maybe people at Canonical can help us short circuit this if they have market and user analysis already done [09:22] mpt? [09:22] I doubt that [09:22] but that's not really my area [09:23] You'd be better asking jdub about that, I think [09:23] Then I think this excercise will have huge benefit outside the docteam [09:23] other than being the dominant Linux-based OS [09:23] mpt: nah I just ask Mark [09:23] that would work too [09:23] though it might be slower :-) [09:24] no he is responsive [09:24] if it seems important to him [09:24] another idea [09:25] I am really tired of Yelp [09:25] I mean it [09:25] so fork it [09:25] Oh yeah and develop it? [09:25] no, short circuit me = lazy [09:25] yelp is also gtk [09:25] me = focus on docs [09:25] Well, which would be quicker? Adding search to yelp, or writing a new help viewer? [09:26] using any browser XHTML/HTML + CSS and jscript [09:26] htdig search [09:26] is that the only thing wrong with yelp? lack of search? [09:26] jeffsch: no [09:27] poor custom abilities without editing the source [09:27] proprietry tags like ghelp [09:27] custom abilities like what? [09:27] Like Open the Keyboard applet for me [09:27] ? [09:28] use an dubuntu custom layer to style the resulting output not only that of yelp [09:28] invalid processing instructions like [09:29] lack of support for docbook 4.3 > [09:29] lack of support for SVG [09:29] thi slist is long [09:29] oh an dit is slow on mpt 's lappy [09:29] heh [09:30] and ... [09:30] chaps I think like this [09:30] you all know how the quick guide looks [09:30] ... 19 seconds! [09:30] imagine if you have associated tasks on the right side of the screencapt [09:31] a list that is dynamically built by jscript and formatted using css [09:32] Ability to do popups [09:32] ability to create comments inline to the help system [09:32] ability to share comments and send them [09:32] I'm trying to think of use cases for dynamically built lists and popups [09:32] mpt: easy [09:33] Apple Help uses HTML nowadays, but the result is that every non-Apple help file looks different, and that's bad [09:33] This is x app. It is use to do Y. [09:33] e.g. different font sizes for no reason [09:33] alongside all the tasks assocaited with the app [09:33] our stylesheets control that [09:34] Apple should use Docbook [09:34] wait, wait [09:34] So Apple should switch from HTML to Docbook, and Ubuntu should switch from Docbook to HTML? [09:34] :-) [09:34] mpt: no [09:34] we use docbook as a semantic format for storage [09:34] it is presnetation layer neutral [09:35] we transform from xml to html [09:35] or pdf or ps or rtf or what ever [09:35] yelp does this under the covers [09:35] that is one reason why it takes so long to load [09:36] Why does it do any transformations at all? === mpt knows little about yelp [09:36] yelp takes raw xml and transfroms it to html for viewing [09:37] xml is not a presentation format [09:37] XML+CSS is presentable [09:37] ah, but it's not linkable [09:37] it seperates the concrns of content and presentation [09:37] not so easy [09:37] XML+XSL even more so [09:38] mpt: let me explain [09:38] The Docbook XSLs are powerful [09:38] we can transform to XHTML, HTML, PDF, HTML help, JAVAHelp, etc [09:39] it has support for gen texts in i18n [09:39] the work is done [09:39] ok [09:39] we put Docbook XML and XSL into an xslt processor [09:39] that gives us a presentation format [09:40] the format depends on the XSL used [09:40] now we dont hack the docbook package sources [09:40] we create a custom layer [09:40] this allows us to change the standard formating provided by the docbook packages [09:41] when the docbook packages are upgraded we inherit all the updaes [09:41] and all we do is maintain our custom later [09:41] So can you get rid of those previous and next links at the bottom of each page, for example? [09:41] yes [09:41] hooray [09:41] but not in yelp [09:42] then what? [09:42] because we would have to hack the yelp xsl and compile it again [09:42] so I say screw yelp [09:42] it is to inlexible and give overhead [09:42] go to any browser [09:42] we have ful control [09:43] browser isn't much faster to load though [09:43] ok, but you're still going to need to make a help viewer, froud [09:43] in our custom layer [09:43] no [09:43] for now we do HTML Help [09:43] and CSS it and manipulate with jscript [09:43] this gives us a toc and pages [09:44] we have full control of the toc [09:44] a search facility is also easy [09:44] actual Web browser chrome, complete with bookmarks bars and "Send Link..." and cookie prefs and its own help menu that's mostly about browsing, just would not work as a help UI [09:45] mpt: atually most people spend there time on the web looking for help [09:45] thier [09:46] I thought most people spent their time on the web bidding on auctions and looking at porn [09:46] mpt, that is most office workers [09:46] amongst other things [09:46] mpt: I am not saying using a full web browser is the ideal answer [09:47] I amsaying that it is workable immediately [09:47] with a level of control to us [09:47] oneday, maybe somebody will build a good help viewer [09:47] but frankly I think the days of help viewers are numbered in single digits [09:48] I'm still waiting for a good one [09:48] but even Windows ME's one was better than a Web browser [09:49] mpt: by going this route we have another advantage [09:49] the help system can be loaded from a web server or local disk [09:49] That involves fun security considerations [09:50] like [09:50] like, the various security vulnerabilities in the Windows help viewer that, over the years, have allowed attackers to run arbitrary programs [09:50] I dont se the point [09:50] because it uses the IE HTML rendering engine [09:51] and can view remote stuff [09:51] and we will use any browsers rendering engine [09:51] I still dont see why this is a problem [09:51] ok, so [09:52] how do you get the search field into the UI? [09:52] loading a page from a web site is something mils of user do every day [09:52] Ah ha, XForms === claude [~claude@99.236.203.62.cust.bluewin.ch] has joined #ubuntu-doc [09:52] and andthing like cgi [09:52] even python [09:52] there are numbers of tools for that [09:53] Goodness we can even integrate google [09:53] or lucerne [09:53] the power is endless [09:54] for admins help can be installe don the server only [09:54] for home users on thier local [09:55] So, no help topic on "Troubleshooting server connections" then? :-) [09:55] topics need to be analyzed [09:55] and can be personalized === jsgotangco [DaWorm@info9-4.info.com.ph] has joined #ubuntu-doc [09:56] Do any other OSes personalize the topics in their help system? [09:56] froud: i screwed up? [09:56] That sounds like running before walking to me [09:56] jsgotangco: no I did [09:56] mpt: vision dude [09:56] it should have been & then [09:56] just caus ethey dont have does not mean it is not wanted [09:57] jsgotangco: yes, my mistake , sorry [09:57] thanks to jeffsch for spotting it [09:57] froud: you forgot [09:57] mpt: you complain about it but fail to look beyond for a better solution [09:58] I am changing them now [09:58] jeffsch: why does that need changing? [09:58] jeffsch: you mean in the i18n docs [09:58] froud: I'm not complaining, I'm wondering why you don't just take the first step first [09:58] froud: yes [09:58] what is that first step, where does it lead [09:58] froud: which is to start with the things most people will be wanting to know, most of the time [09:58] jeffsch: yes, thanks [09:59] froud: then if you get really smart later, you can personalize it [09:59] lets seperate things here [09:59] the help system app and the content it displays [10:00] for content I am proposing we do an analysis that includes user inpt [10:01] for the help system I am prposing moving away from yelp so that we can excert control [10:01] i'd go for the migrant's guide (like playing stuff, office work, etc.) [10:01] froud, unless you're going to collect that user input by sneaking up behind people using Ubuntu and watching them, I think you'd be better just to guess [10:01] mpt: yelp uses scrollkeeper to decide what goes in the first page [10:01] what's scrollkeeper? [10:01] mpt: I dont think so [10:02] froud: Because any other way you collect it -- surveys, wiki pages, mailing lists, whatever -- acts as an enormous barrier to entry. The kind of people who most need help are the kind of people who will never edit a wiki or post on a mailing list. [10:02] And in surveys in general, people will lie so as not to sound dumb. [10:03] mpt: as I said, this is why one has to understand the doc systems. I hear your grievances, I agree with most, but to get a solution I must think outside the box [10:03] are you saying we make our guide like a dummies book? [10:03] So, my suggestion is: guess. :-) [10:03] I want and educated guess [10:04] ok, I'll re-reply to Mary's message now [10:04] mpt: Uhmm, now you leave [10:04] eh? [10:04] mpt: you going [10:04] It's 8pm, the cafe closes in an hour or less [10:05] I'll hang around here while I can, though [10:05] I c you are in an Internet Cafe [10:05] Yes, no DSL at home yet [10:05] and Ubuntu doesn't understand the laptop's modem [10:05] Oh OK [10:05] yes heard that from a number of users [10:06] well team, what do you guys think of this conversation and the ideas we have bashed [10:06] ive tuned in late [10:06] i still want a dummy guide [10:06] js read the logs [10:06] jsgotangco, dummy guide ala the faqguide is coming [10:07] dummy guides are good but not like by all [10:07] dummy guides sell like hotcakes [10:07] I dontthink we can say what we want. We should ask the users to gleen what they want, then decide [10:07] i would think more of the migrating users [10:07] they must have something going for them [10:07] i still like "let's just cut to the chase and design for users new to linux, but not new to computers." [10:08] jeffsch right on target [10:08] Burgundavia: yes they do cause they address a need in one audience [10:08] people who install ubuntu know how to play around with their computers [10:08] froud, a very large audience, if the sales are to be believed [10:08] but for my user profile I want O'Reilly or SAMS [10:08] froud, so do I, but I don't need docs written for me [10:08] I can search the internet for that [10:08] The major market segment is huge [10:09] Burgundavia: no we use man pages [10:09] :-) [10:09] ugh, man pages [10:09] what a waste of time mostly [10:09] ickk [10:09] Oh no dude love man pages [10:09] ssh in to remote and you have help [10:10] i use them all the time. i always forget command line stuff. [10:10] I am speaking about no GUI here [10:10] I dont go to yelp for help on commnad stuff [10:10] true [10:10] I just man foo [10:10] dont we all [10:10] I like GUIs and the power they give [10:10] in fact, I like GUIs so much that I hate ugly ones [10:11] I wish more man pages had a couple of good examples at the beginning [10:11] Burgundavia: agree 1000% [10:11] ala xmms and mplayer and other gtk1 crap [10:11] then I wouldn't need to read the rest of them :-) [10:11] mpt, absolutely. Show me, in examples, the 4 most commons ways that program is used [10:11] mpt: man pages assume a level of proficeincy that is above our user [10:12] naturally [10:13] Burgundavia: if we use the HTML/CSS/JSCRIPT route I am proposing we can break from the top down vertical approach common in current help systems [10:13] froud, top down? [10:13] yes see a gnome manual [10:14] each topic is vertical [10:14] it would be nice to have side bars and tool tips [10:14] Some links dont have to be clicked [10:15] Just hold your mouse pointer over it [10:15] thats not possible with yelp but with a browser based system [10:15] and you see the text [10:15] froud, the thing about help is [10:15] jsgotangco: that is what I am saying [10:15] and help developers on every OS get this wrong [10:15] the thing about help is that it needs to be *alongside* what I'm doing [10:15] so it needs to be, maybe, 200px wide. [10:15] mpt: no problem [10:15] hmmm [10:15] otherwise I keep having to flip between the help and the program I'm trying to use [10:15] forward and back, forward and back [10:15] most programming envs have browser controls [10:16] and it's too much bother [10:16] alongside, is that similiar to a help system in MS Office [10:16] and every time I flip I have to reorient myself [10:16] Yes, Works and Office both solve that problem, in slightly different ways [10:16] mpt: acrobat 7 does that. 200 px wide on right hand side of screen [10:16] so we need support for dynamic shrinking [10:16] using the method I am proposing devs can embed a browser control at any position in the workspace [10:16] A pity that the actual OS help system doesn't :-) [10:16] jeffsch: yes and we can use that [10:17] jeffsch, adobe reader 7is evil [10:17] i not talking about reader. [10:17] Burgundavia: dynamic shinking is can be done [10:17] but images [10:17] ok if its 200 px wide, it shouldn't be as high as the actual application [10:17] jsgotangco, why not? [10:17] acrobat 7 for creating and manipulating pdf. reviewing docs. [10:18] jeffsch, the actual thing, not the reader, ok [10:18] Burgundavia you eat up real estate space on the application [10:18] dudes the technology is not important [10:18] jeffsch, I really wish they would rebrand the reader to avoid this kind of confusion [10:18] the concept is [10:18] jsgotangco, but the app has just shrunk 200, so that top corner is going to be wasted [10:18] froud maybe something similar to Opera's small screen rendering [10:19] jsgotangco: yes there is another idea [10:19]