To add to our Naming conventions a rule about feature names, and make it universal on doc.tiki.org, dev.tiki.org and tikiwiki.org, it is important to have a common way of naming features. So we always know that doc:Newsreader is it does and dev:Newsreader is what we wish it did.

ML: I can live with any choice as long as we are consistent. Keywords page seems the way to go 😊 Let's decide on a masterlist and after, we clean up all the help links from the software itself and from other *.tiki.org sites...
Xavi: "I can live with any choice as long as we are consistent". Mee too. 😊
dthacker: throw this motion out, use the keywords page

Marc: I renamed all the pages. I hope it's OK with everyone.
MLP: Right on. I've refactored the motions. I concur.
chibaguy: I think the logical (common sense/normal usage) way should apply regarding singular/plural and keyword length. As "smiley" shows, plural is often better. Sometimes more is better than less, as with "User Tasks" vs. "Tasks." It's possible to simplify and standardize too much and lose meaning in the process. I think things that are commonly seen/used in plural should have their doc page in plural form: "Image galleries" when thought of as a feature is more natural than "Image gallery," "Comments" more natural than "Comment," etc. Sorry, but the new singular forms seem unnaturally truncated to me and don't have the immediate recognition that the plural forms do.
Xavi: I fully agree with Gary's comment. (chibaguy).

MLP: Ok "prefer the singluar" dropped in favor of a more natural approach.

chibaguy (after reading Skype log discussion of singular vs. plural for page names): [soapbox mode on] I think "natural speech" vs. "search term" isn't the best way to approach this question. People doing searches generally enter the singular form because it's the most common, most-root form and thus most likely to return good results. But there is a different rationale for page names. What is the logic for, for example, a page named "Comment" that has a title (h1 headline at page top) of "Comments"? This inconsistency shows there is something wrong with the page name, which doesn't correctly label the page content. If the page defines (the concept or whatever of) "comment," as in a glossary, then singular is appropriate. But the doc pages here are more comprehensive than that, and the plural form is often more suitable. This is the logic as I see it: reflect in the page name the use of the term in the Tiki context. People may search for "smiley" but they don't think "How do I use smiley?" An index will contain "smiley", but it will often refer to a page called "Smileys" or "Using Smileys" or whatever. That's the nature of that connection.

Keywords can still be (and generally should be) singular, but they can link to pages named with either the singular or plural form (or a multi-word term if that's appropriate). It's counterproductive to streamline for simplicity's sake if comprehensibility is reduced in the process. When I see singular forms of words where I (as a user of the language) expect them to be plural, it strikes me as taking a principle too far. The impression is skeletal output that needs a commonsense touch to make it (in this case) good English. [soapbox mode off]

This seems to have been implicitly approved? Forwarding to Editorial Board Meeting 2007 08 for explicit approval.

Footnotes ---> "My Notes" (in favour: ) or "Private Notes" (in favour: Xavi, chibaguy, dthacker) Approved
Inter-user messages ---> "Tiki Mail" or "Messages" (in favour: Xavi, chibaguy, dthacker) Approved or ""Message"
Debugger Console ---> Debugger (whatever: Xavi) (in favor: dthacker) Approved
Articles --> Articles done already. Approved

note we gotta harmonize it across atleast two, doc and dev.

ML: Let's be realistic! Let's get things going properly in English and the other languages will evolve organically.

MLP: Oui!
Xavi: Remember people tries to translate pages step by step in their language. And it's easier for them if empty pages for their language are available, so that they only need to edit that desired pagew and go translating. Otherwise, they need to request an editor/admin to add their pages to an structure... Review "fivos" case last week with greek pages (overwriting english pages)... (some info in the forum ) ML: Ok, this means the current UI is not clear enough. There should be a button "create a new page/translation" in one step...
dthacker: opposed

(you can wiki the motion, eh.)

(in favor: dthacker)

MLP: Use multilanguage features as they are now?
Xavi: I'd suggest to use intertiki, and french doc. being set at doc.tw.o. Granting editor perms to editors at fr.tw.o that write documentation, etc.
dthacker: agree with Xavi

ML: it seems like a good feature. Anyone object? If so, we can turn off,
Xavi: ok to keep it.
dthacker: keep it.

ML: Features are so different. Some need one page, some need 5-6. Better to start with one page and refactor as needed. But the goal is to still have a structure and ultimately use WebHelp to make offline copies and print from structures to PDF to make a manual at least as great as the Tiki 1.6 docs.
MLP: Agree - tracker for instance - really you need to walk people through screen by screen.

Xavi: However, I like the basic common structure for all pages (Feature User, Feature Admin, Feature Details). I would suggest to keep it as it is, and and new pages when and where needed. But for new documenters, that basic division in three basic pages per feature allow organizaing content, etc.
dthacker: do not create more than one blank page per feature. Agree

MLP: About the Tikiwiki documentation - updated.

Idea: have a nice quicktag for voting, which adds these nice icons:
http://microformats.org/wiki/icons

H2 {
	...
	border-bottom: 1px dashed grey;
}
H3 {
	...
	border-bottom: 1px dashed lightgrey;
}

Xavi: I suggest the example in the box below: dashed grey for h2, dashed light-grey for h3. no line for h1.

Xavi: I hadn't seen that before (just discovered it today), and I think it's not needed, or even that it diverts to much the places to invest energies for new documenters. I propose to use the plain Wiki way (most documentation bugs could be fixed by normal registered users, nowadays, since they can edit almost all pages).
dthacker: I thought I killed it already! agreed.
MLP: in favor documentation status is best for errors in documentation, bugs in code should go to dev.

ricks99: against. currently the __discuss_ link is being used by readers to log issues and request troubleshooting help. This creates a lot of noise (consider: http://tiki-view_forum_thread.php?forumId=1&comments_parentId=470).. if this site is supposed to be for compelted, factual info only, should this be removed? I like having the tracker

If motion is accepted, link from http://dev.tiki.org/Documentation to http://doc.tiki.org/tiki-view_tracker.php?trackerId=8 ("Doc Bugs & Wishlist") should be removed, and write Author Coffeeshop forum instead.

Latest news

I uploaded the Mittwoch theme files to this site. Please have a look and make suggestions. Use the URL http://doc.tiki.org/tiki-switch_theme.php?theme=mittwoch.css to use Mittwoch. So far I haven't been able to do this while logged in. Maybe there is a conflict with Intertiki. When I log in, I get switched back to the site's default theme.

The left and main column need a wider margin between, I think. And maybe the line-height should be increased a little. There is also a glitch with the module titles not being the right size.

About the colors, I don't know if the color switching will be possible here because Intertiki might insist on overriding the choice. But probably the switching isn't really necessary. We can use the switching while choosing which color to use here. So far I only tested in Opera 9.2. The switching was a little flakey, with the preference not always being remembered, and sometimes a flash of blue at the beginning of the display (maybe this is a feature, not a bug. 😉 ).

Congrats. Gary. 😊. I agree on you comments of needed changes, plus I would suggest:

• make a clear difference in the box to create a new page in structure navigation bar (bakcgroup of the box for that field is too similar to background of the structure navigation bar surrounding it). Same for fields of login box, search wiki pages, etc. (confirmed on all browsers Firefox, Seabird, Konqueror, and IE 6 on GNU/Linux).
• Options labels in drop down boxes as shown cut by the lower part, for me. Using Firefox 2.0.0.4. Less cut with Mmozilla Seabird, and ok under Konqueror and IE6 under GNU/Linux.
• Under Internet Explorer 6 (on a GNU/Linux platform) I see grey background for png images: text logo on header, icons on the "learn" and "write" columnes, etc. It's only me? (Xavi)

Older discussion

There are a few layout quirks to finish up, and some style issues need to be decided.

1. Which color should be used for doc.tw.o?
   • Proposing Blue: Xavi
2. If none of these colors is right, please make suggestions.
   • Xavi: They are right (and very nice, thanks Gary 😊. Looking at drupal.org and joomla.org, for instance, their sites tend to be more colourful. These Mittwoch themes are by far much better than many of previous styles in Tikiwiki (my personal opinion, of course - I love white background with colourful details here and there...), and I just wanted to suggest that for further improvements, to include some more color on top of white background (hec.css is quite in that way..., even if simpler compared to Mittwoch).
3. In some places (dropdown select) there may be contrast problems (i.e., not enough contrast), so those can be changed. I haven't checked on a variety of displays.
4. Is the small plus sign sufficient to indicate the page edit, etc., tools dropdown?
   • Xavi: I don't think so, if we think in new users, newbies in computer science, ... (usability). I would suggest a much bigger icon, or just a word like "tools" or similar (like in andreas09.css). However, usability geeks frequently complain about those hidden things (when thinking in potential new users with low skills of computer usage - remember talk from Alain in TikiFest198 ).
5. Or would people prefer the standard Tiki wiki page tools layout (for edit, print, etc.)?
   • Xavi: If this is going to be a standard theme for doc.tw.o only, then I would vote for this option (most tiki sites have standard layout for tools). If Mittwoch can be released as LGPl, then I would HIGLY encourage making this nice new theme as the default for 1.10 sites, and thus, also for doc.tw.o.
6. The horizontal navbar can be either static links or a PHP Layers menu, so this should be decided.
7. Styling is also done for a PHP Layers menu in the side column so that's an option.
8. The Site Identity header is done, to match the current one at doc.tw.o.
9. Other suggestions/changes/etc.?
   • Underline (dashed in greys) h2 and h3 headers in default css's for new tikiwiki sites
   • make some kind of "A+" "A-" "Reset" sings on tikiwiki site identity header (a new option) so that users can increase or decrease in a click the default size of text in the site. (similar to many more usable sites: example: http://joomla.org header...
10. ??

-- Gary/chibaguy

Thanks heaps Gary for your nice (and hard) work! (Xavi)

ML added a logout button, to be approved
ML added a module with explanation/link to register on tikiwiki.org, copied from themes.tiki.org to be approved.

• I would suggest to include an option in some admin interface: if intertiki is toggled on, then the login-box shows some content like the one in this box you made (something like done in http://edu.tiki.org/tiki-login_scr.php), but getting automatically the intertiki master site url and link to register there. (Xavi)

I mean all the subsections 5.x at All the Documentation and thus files/Tiki19beta.odt (files/Tiki19beta.pdf)...

Opinions?
dthacker: agreed. propose alpha sort
mlpvolt: disagree - we need to sort the features into categories, so people are aware of related/overlapping features. categories plus alphabetical is fine with me.

dthacker: agreed. I'll work on modules and plugins. I would like to do another test of 1.9.8 links before release. Maybe we can schedule
a hug day.

In order to increase visibility of the the doc.tw.o resources, I propose that we add doc.tw.o (and possible tw.o, too) as a custom search provider. This would let users search the docs from their web browser. This is supported in FF and IE.

I am currently implementing a custom search provider for my site, and user feedback has been overwhelming positive.

See OpenSearch for details.

Just an idea........

Next meeting: August 2007
This was a meeting of the editorial board.