View Full Version : suggestion: one page per topic instead of one big page for all topics
HadroLepton
August 11th, 2006, 02:40 AM
i think that having one page per topic is better than one big page for all topics. i will try to elaborate, in no particular order:
size:
as it is now the page is quite big and i have a noticable loading delay on my computer (pentium3 700mhz 512mb, ok i know this is not the newest). i have dsl so the delay is not the download speed but the rendering time (processor load is at 100%).
redundancy:
there is a guide for dapper (6.06) and breezy (5.10) and soon there will be a guide for edgy (6.04?) and most of the answers will be identical (compare the answers in the ssh chapter). if ssh is in its own page it can be tagged as dapper and as breezy, and if the answers do not change considerably then it can be tagged as edgy and we are done.
more redundancy:
almost every questions depends on some basic answers, for example "Read #General Notes" and "Read #How to add extra repositories". these can be written once as macros/scripts and added to each page.
search:
currently searching for ssh will result in 0 pages. if every topic has it's own page then searching for ssh will find the ssh page.
maintainance:
it will be easier to track history of edits on separate pages. also dedicated editors can maintain pages with their favorite topic.
in short i think that one page per topic will make better use of the wiki engine and will reduce redundancy.
about the translations i think it is best done using namespaces. one namespace per language.
please discuss.
Rory
August 11th, 2006, 07:25 PM
I think all your points are fair. I would also add that separate pages reduce wiki-vandalism impact, which is an important one.
I don't find the page too slow to download, myself.
In the end, there is value to both approaches. Ultimately, I prefer the single page format as I tend to rely heavily on keyword searches within the page to find certain items that may not be included in the index. That couldn't be accomplished with multiple pages. I also find it easier to scan and move through on a single page, rather than constantly having to click back to an index and the off to a new page, back again, etc.
In the end, I don't think either is a bad option and it's really just a matter of preference.
sharperguy
August 11th, 2006, 07:34 PM
What about a choice?
The upside is that it will satisfy most people
The downside is that a script would have to be written to update one when the other was changed, OR the big page is the smaller pages added together in real time (slow).
HadroLepton
August 15th, 2006, 04:16 PM
as suggested by sharperguy, would it be possible to split the pages up and write a script or something that will parse all the single pages and compile one big page? by caching the compiled big page it would only need to be recompiled if one of the small pages change. but there must some sort of edit redirect, so people edit the single pages.
SUTO, Kanetaka
September 14th, 2006, 11:15 AM
For writers, the separate pages style is better solution, because the maintenance is easier. For readers, on the other hand, the single page style is better, as Rory pointed out the search issue. I believe the guide to be user-friendly.
However, I also tired out of redundancies when I tlanslate it. I wish each section has the last modified date so we can detect whether just copy or refresh the old version.
orvils
September 20th, 2006, 04:58 AM
I would like to keep this guide as simple as possible, so I think that one big page is the best solution. Users have got used to this approach. The complicated it gets the more risk of getting bugs, more chance that some new contributor that has good ideas, but doesn't know wiki well will break something.
For translators I can recomend working in some text editor like gedit and use "Search and replace" That could help with "General notes everywhere"
As for the changes you can see changes of whole page in "Histroy" tab.
I removed the useless Search box, so it doesn't confuse users any more.
Anyway thanks for your feedback, this idea is really good, but I am afraid that it might cause more problems than good.
orvils
September 25th, 2006, 03:02 AM
I have receaved couple of emails with suggestion to split the guide to several seperate pages. We will still keep the 'one big page' guide as the default, but there will be sepereate pages as well.
So far I think about having a sepereate page for every subsection. Add-On Applications, Other Desktop Environments, Eye Candy, etc. I think about creating a template for each section, so the same info cn be put in big "all guide per one page" page and in section pages.
What do you think about this? Any comments or suggestions..?
Rory
September 25th, 2006, 07:31 PM
I think there will always be the one-page fans boys and multi-page fanboys. It is difficult to satisfy both groups. My preference is to keep a single page and perhaps re-do the index in to different main sub-sections, though still on one page.
The value of single vs. a multi-page approach isn't an issue of right vs. wrong. It's simply an issue of preference. There are pros/cons to each approach.
I do worry about creating sub-section pages that also have to be synched to the single-page wiki. That could get messy. I also worry that adding a question to a new sub-section may not trigger the change on the main page index.
As the number of contributors grow, two things should be kept in mind:
1) ease of use for new contributors. The simpler it is, the less problems we'll run in to. People should be able to focus on contributing their addition/change, not using their energy to input the information properly, so it does not break the wiki.
2) central maintenance. As the guide gains in popularity, Orvils shouldn't have to increase his effort to keep everything running smoothly. If it is set up correctly from the beginning, it should be scalable. If Orvils needs to spend more and more time cleaning up things, fixing indexing issues as multiple pages grow, fixing mistakes, they we're on the wrong path.
As they say, K-I-S-S. Keep It Simple, Stupid.
The one thing I would add is that it would be nice if there was a way to make different questions "Edgy ready." The original message about "tagging" had value. The should be a way for users to verify a particular section works in Edgy and doesn't need to be changed. Currently, if it isn't touched, people assume it works, which isn't always correct.
orvils
September 28th, 2006, 08:18 AM
Fortunately there was a good and esay way to split the guide :)
So far Edgy's guide is in this "seperate pages" version:
http://easylinux.info/wiki/Ubuntu_Edgy
http://easylinux.info/wiki/Ubuntu:Edgy/TOC
Rory
September 28th, 2006, 09:23 AM
Any if you update a section the full version will automatically update and vice versa?
I do prefer the scrolling of the single page and less use of the back/forth buttons, but if you can split and keep the full version without adding workload in maintenance...
R.
orvils
September 29th, 2006, 12:46 AM
Yes when you upgrade any subsection the main "everything on one age" guide also updates, because Edit links in this page lead you to the topics on subpages
vBulletin® v3.7.2, Copyright ©2000-2008, Jelsoft Enterprises Ltd.