On Tuesday 03 August 2010 12:29:45 Brandon Philips wrote: ...
What are the advantages of a Portal/box model compared to a single page with sections?
I have read the Help:Portal and Help:Concept pages. The one possible advantage suggested in those pages is that Portals can be automatically generated. But, Portal:Distribution and Portal:Project look manually generated.
Advantage? Name. It is self explanatory that portal in entry point to the topic that stands after colon. Namespace is used so that we can direct traffic (search) where we want without much hassle. Despite outcry for links and search, old wiki was mess and it was hard to find anything there. If some article wasn't in bookmarks it did not exist. There is long list of problems: unguessable titles, lack of links in articles, almost no use of categories, no common style, no maintainers to articles, etc. Portals are not entirely automatically created. Navigation there is created from categories, so it is updated as soon as some article is added to category. There is template that new contributors can use to get basic layout. The rest is up to their needs, we provide lego pieces they can combine it the way that suits their needs. It is missing explanation what layout is preferred and why, but that will come. ...
How do we draw a consistent line?
One way is that wiki editors and article maintainers must together build criteria that will answer your question. There is no given way by some third party, it is a consent what should be presented to the user. There are some rules how to adapt article for readers on the web ( http://useit.com ), but when they are applied then content is all by article author.
I moved from being a user to a developer by getting in over my head little by little. Exposing someone to new information by serendipity is OK.
And how does a Portal solve this issue?
You have ability to give beginners directions (but that you can do that in any article), what Portal makes different is the name. Users with some experience with Wikipedia, will expect general overview of the topic as that what they know from there. ...
It is redundant and thus adds no self-discoverable information. That was my thesis when I started this thread. ... Is there the will to change it though?
Would you change name when you see this: http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion http://en.wikipedia.org/wiki/Wikipedia:Templates_for_discussion http://en.wikipedia.org/wiki/Wikipedia:Flying_monkeys http://en.wikipedia.org/wiki/Wikipedia:New_Zealand_Wikipedians'_notice_board openSUSE: is our meta namespace. We can discuss do we need some better naming for certain topics, or do we need another namespace to resolve funny combinations of openSUSE + something else, but redundancy per se is not a reason to change name. ...
Did an announcement of this discussion go out to opensuse-announce? Could you send me the archive URL? Perhaps my mailer dropped it.
http://old-en.opensuse.org/Welcome_to_openSUSE.org#New_wiki_on_the_way That should be enough :)
In general I wouldn't care but the output of this discussion broke URLs I use everyday in bugs and email.
I agree that there is a breakage, but we got choice: * use from now on http://wiki.opensuse.org and leave en.o.o where it was, using existing pages there as redirects to the wiki.o.o. Set en.o.o in read only mode and look what consequences that will bring. Probably change "Discover it" to message that wiki.o.o is a new wiki, with hope that they will see it. It would ruin lang.opensuse.org concept for sure which some did not like. It will create problem with casual visitors hitting dysfunctional wiki with old articles that no one maintained, and go away. There would probably more silent problems that no one will be aware as wiki team would look at a new wiki. * or move as it was done and fix problems on the go. Big pain for everybody, but some (majority?) problems are fixable if everybody want that and cooperate. It was choose your poison decision. ...
I don't have to contribute to the Wiki. I could just throw a README.Kernel in our kernel-source.git instead. It would take less time, I would have a URL I could count on and a simple document format I could quickly edit.
And not many will ever see that README.
I want to do the right thing by using the wiki.
Thank you.
... I apologize if I my emails are abrasive, it was not my intention, but I will try to do better.
I understand that a lot of hard work went into the new wiki. And it does look to be a good step forward. But, the initial launch of any project is going to have bugs and quirks. Discussing those bugs and quriks and possible solutions is part of the process.
Sure, although you overestimate our free time that we can put in the wiki, so we have to create something that we can handle. Defending your position is fine, but consider that we spent some time thinking and discussing. Is rsult the best, probably no, but with few people interested in discussion that is the best we came up with. Now when it is public everybody and his mother find better ways, but it is kind of late. ...
Is there a mediawiki special page that shows all incoming internal links to a page? Maybe a plugin could be written/installed to warn on page moves if there are existing internal links so that the mover puts up a REDIRECT.
Page move does put redirect automatically. Problem is that using old titles as redirects should be minimized otherwise we will have very soon all nice separation of content bypassed and search will give same useless results as it did in the old wiki. The special page that will list all that links to article is under link in toolbox "What links here" available on almost each wiki page. ***** article Kernel 1 ***** For instance: http://en.opensuse.org/Special:WhatLinksHere/Kernel * openSUSE:Kernel git (redirect page) (← links) * Kernel git (redirect page) (← links) * Kernel (← links) * SDB:Kernel of the day (redirect page) (← links) * Kernel (← links) Replacing: [[Kernel#openSUSE_Kernel_Git|openSUSE Kernel Git]] with: [[#openSUSE_Kernel_Git|openSUSE Kernel Git]] (this is in-page reference) Replacing: [[openSUSE:Kernel_git|Kernel Git]] with: [[#openSUSE_Kernel_Git|Kernel Git]] and removing one double redirect: was: Kernel git --> openSUSE:Kernel git < this is also redirect page is: Kernel git --> Kernel http://en.opensuse.org/Special:WhatLinksHere/Kernel shows now: * openSUSE:Kernel git (redirect page) (← links) * SDB:Kernel of the day (redirect page) (← links) * Kernel git (redirect page) (← links) which is pretty normal, not a Gordian knot of self references and redirects. And that is one of things that would happen if we "just" fixed old wiki. It was hard to maintain due to existing redirects, and we will create many more. I tried to fix some stuff in Standards and YaST and gave up (not once). Now we have new wiki, which is pretty clean and we have chance to think what titles we want to give to articles, so that we don't have to introduce redirects. ***** article Kernel 2 ***** Kernel is a good page, but too long for web readers (casual readers). It is good for casual readers up to "openSUSE Kernel of the Day". After that is too technical for them and kind of short as introduction to hacking. It is a problem to present information that requires some troubleshooting knowledge to casual reader without warning and explained prerequisites: zypper install -r KOTD kernel-default Someone can try that. Copy'n'paste is one of the first actions that people learn, far before they know how to undo kernel that doesn't boot. It is much more user friendly to keep KOTD usage in separate article that is labeled as for advanced users and keep links to basic boot troubleshooting on top of the article in section Prerequisites. That is another point to keep basic introduction in Main, or Portal (depends on size), and advanced in SDB. The openSUSE is really meant to keep meta information, not technical articles, but as you noticed we: 1) learning on the go, 2) don't have enough time to take care of each article. Someone with more "writing for the web" experience can give you more specific advices, I can only point to: http://www.useit.com/alertbox/9710a.html and in "Learn more" section: http://www.useit.com/eyetracking/ For more reading on usability of web pages and more: http://www.useit.com/alertbox/ -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-wiki+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-wiki+help@opensuse.org