What is the new Puppy website's advantage to a Puppy user or Puppy newbie compared to the actual situtation?

What benefit will get the user/newbie from this new website?

The answers should be more than
- that www.puppylinux.com is unclear to newbies (because it isn't)
- that everything is under the same domain name (because that doesn't matter and is an inherent character of the web)
- the design looks more pretty (content and functionality is more important than design).

What is the new Puppy website's advantage to a Puppy user or Puppy newbie compared to the actual situtation?

What benefit will get the user/newbie from this new website?

The answers should be more than
- that www.puppylinux.com is unclear to newbies (because it isn't)
- that everything is under the same domain name (because that doesn't matter and is an inherent character of the web)
- the design looks more pretty (content and functionality is more important than design).

Well usually you design a site map first so you know where your folders and pages will be, then a site layout starting with the index page, then add content eg Lorem Ipsum and finally add mock pictures.
do a little site testing and hand it in for approval or changes, once you get the go ahead then remove the Lorem Ipsum and mock photo's and replace with real content and resized and compressed photo's. After that do some site testing eg http://validator.w3.org/ and http://jigsaw.w3.org/css-validator/
and your good to go, Thats really a cut-down version but should work well Once that is finished backup the temp website and package it up and give a link to Barry to upload. I don't think that he should ever have to hand over his keys to his Linux Kingdom.
ttuuxxx_________________http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games

(3) Barry's site www.puppylinux.com has all relevant links at the main page. In my opinion it is very easy for a newbie to get all relevant information.

I disagree strongly with this. There is not really an obvious path to use the site for someone with no knowledge.
click downloads
you are told to read the release notes before downloading, this link actually points to Barry's blog archive which is useless a reference/guide.

There are more examples of this sort of thing. IMHO Barry's main need for a community is to do testing. The community is now established and big enough that he doesn't need to publish release notes, he relies on the established community to pass the required knowledge around. This is not good for a newbie.

If you know what you are looking for you can probably find it on Barry's site, if you don't have a clue I think it is hard to use.

oli wrote:

(4) The wiki is out of date (broken links, referring to old Puppy releases), fragmentary and (sorry!) almost useless for newbies (that's why I wrote a manual and created the website www.puppy-linux.info)

I agree, the current wiki is no better for newbies than Barry's website. Contributors have not appreciated the valid lifetime of what they have entered this could be cured by some editing standards, including puppy version information with posts.

oli wrote:

(5) Caneri's offer of a server is well-intentioned but download speed is very slow (87 kb/sec).

I see this site could provide a valuable repository mirror in N.America. Especially if PSI can be enhanced to consider download speed and availability

oli wrote:

(1) We should do nothing without Barry

Then nothing will get done. We should develop this as a community and demonstrate that it works and we can manage it and then give Barry full control with the idea that we already have people in place to maintain it.

oli wrote:

a virtual Puppy organisation. Then I would be willing to integrate the manual into this page and to carry over www.puppy-linux.info to this organisation (and could be one of the maintainers for the manual).

virtual Puppy organisation sounds like a foundation!
I vote Oli for chief manual editor, please can we find a more effective way of creating the manual than emailing stuff backwards and forwards. Any sort of online collaborative environment, cvs, subversion or wiki.

oli wrote:

(4) We should empty the wiki and build up a new wiki (for example, every article must be marked with the Puppy release it refers to). The old content of the wiki should be checked and - if it is allright - brought into the new wiki.

We should mark every page as stale and reqiring editing NOW and ask page owners or anyone really to ensure that the page is brought up to standard. This approach avoids throwing anything away but the reader is aware that what they are reading may be out of date.

raffy wrote:

1. Page design - Tom has offered a page design and has already received a good deal of suggestions. Could we have a simple page design that someone can easily get and publish? It should be simple enough for the average Web enthusiast to get and deploy. (This last point is relevant especially because the Puppy Web is kept by volunteers.)

No no no no no no. This just creates a load of similarly looking clone sites with variable quality content that the newbie will find even harder to make judgment on its validity.

raffy wrote:

Yes, Whodo, we will do the test site at puppylinux.org.

Good. If the intention is eventually to replace the content at puppylinux.org this avoids the problem of adding to the number of sites.

LOF wrote:

Surely your answer is the wiki? Then all that would be needed would be to compile it into a PDF at the time of each official release and label it as the official manual for that release.

Is it possible to compile a wiki into a pdf or even single HTML file?

If we are going use a wiki how about using the editing standards employed by another successful wiki.

One of our web developers, prit1, has created a web site-based Software search facility that uses the underlying file lists of MU's PSI to provide access to Puppy software packges.

Do you have a link?

I didn't want to be showing this before prit1 and tombh are ready, but since you seem so keen, here is the link.
http://www.tombh.co.uk/puppysite/?q=node/77_________________Actions speak louder than words ... and they usually work when words don't!
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com

This just creates a load of similarly looking clone sites with variable quality content that the newbie will find even harder to make judgment on its validity.

Hmm, having "clone sites" is not in my thoughts when I said "Could we have a simple page design that someone can easily get and publish?" What I mean is to gather as much of the design ideas as possible and implement these in a simple way, at puppylinux.org.

In this regard, I go for a "Yes, let us see how that will come out".

Anyway, we still have to answer Oli's questions. The distinction of the site is about making available Step-by-Step guide to users, as written by experienced enthusiasts. I for one want such pages, for example, in getting new fonts into Puppy, or in using DOS emulation or one of the Virtual Environments. Think of the best of the How-Tos made available in one place and in an easily accessed fashion._________________Puppy user since Oct 2004. Want FreeOffice? Get the sfs (English only).

If we make a new website I would add my manual. But I would like to find an easier way for me to update the manual and to translate the manual into the different languages. I could ask my translaters if they can maintain the manual for their country or other users can tell me if they want to be a maintainer. (I think all maintainers should be confirmed by the community before they are maintainers).

Does someone knows a good program to manage such a manual in different languages? Is a wiki (with permission to edit the content limited to the maintainers) a good choice? It should be easy to use and it should have a function so that every maintainer can see (is informed) when new stuff is added. It should manage different versions of the manual (corresponding to the different Puppy releases) in different languages.

In detail I would like to organize the manual this way: For each language there is a maintainer of the manual. The reference-manual is the English manual. If one of the maintainers add new stuff to his manual he translates the stuff into English too and send it to the maintainer of the English manual. He corrects mistakes (grammer, wording) and add the text to the English manual (it would be best if some users would now test the new stuff to make sure it is allright. If something is wrong with the new stuff they correct the stuff an inform the originator of the new stuff). Then all other maintainers are informed that there is new stuff in the English manual. The maintainers translate the English text into their language and add the new stuff to their manual. So we make sure that every manual has the same content.

If someone else of the community (not the maintainers) has new stuff for the manual he should send it to the maintainer of the English manual or the maintainer of his country. Therefor we should publish contact information with the manual. (I think all maintainers (forum, wiki, manual, repositories, webhosting, security, design, ...) of the new Puppy website should be mentioned with an email address to contact them).

Everytime a new Puppy version is released the old manual is copied as base to the new release and is then adapted to the new release. The maintainers could partition the manual (eg maintainer A proofs chapters one to two, maintainer B proofs chapters three to five, ...) and check what has to be changed in the new version of the manual. This would hurry up the time till the new manual is ready to be published (and I have not to do everything ).

P.S. I like the look of the test site. Great work, Tom.

P.P.S Can we make a list of duties and responsibilities due to the new website and ask who wants to be the maintainer?

P.P.P.S. We could consider to translate the whole website into several languages, too. But please no automatic translation, it is horrible to read for a native speaker.

Oli,
we meanwhle have a new server for HTML-pages http://muppy-linux.de (one for isos follows later, as this one does not have unlimited traffic).
I will give you FTP access so that you can store the manuals there.
I'll send you the required login-data in around 2 weeks, when I'm in Bielefeld again.
We then will overwork the site and do the documentation related stuff for Muppy.

I think my server can help PSI speed up downloads from N American users so I hope MU keeps this. Also countries that are banned from US servers can easily access Puppy stuff from here.

Sure.
All new packages go to both servers, the german and the canadian.
Many thanks again

When we finished Muppy 008.3 and other things in around 3 weeks, I hope I find Time to rewrite PSI using Gtkbasic.
This would make it easier to add a grafical interface to manage mirror-servers and such.
Mark_________________my recommended links

Does someone know a good program to manage such a manual in different languages?

This could be a starting point: http://blog.ianbicking.org/2008/02/05/a-simple-cms/

This is what I use for my sites, a simple PHP script in one page that does WYSIWYG editing. You keep the files in one folder. So one language should be in a separate folder and maintained separately. One page = One link in the site (see http://minipc.org/safepup/ for example links and pages). Each page can be about a function (like Printing) or a version (3.01). Colors and font sizes are controlled through the page CSS.

(I think all maintainers (forum, wiki, manual, repositories, webhosting, security, design, ...) of the new Puppy website should be mentioned with an email address to contact them).

I think that's a good idea. I suggested it before, but could I also ask again that all instructional content be dated with the date of creation and date of last revision and that what it relates to (ie what version) be stated?

IMO, there is a place for information relating to earlier versions (a lot of people still use them), as long as it is marked. I think that it would be a shame if, in the revision of the wiki, everything was jettisoned in favour of what is deemed current, as that will be outdated too in short order. Keep everything that has some value, but make sure it is clear and what it relates to is identified. If it is not clear, ditch it.

Could there be some system of editorial review of new wiki content for clarity?

Could there be some system of editorial review of new wiki content for clarity?

That's certainly possible IF we use the wiki feature of Drupal, which is tombh's preferred CMS. OTOH, raffy wants to use wikkawiki's latest version (same wiki updated) and I don't know yet what is possible for that in terms of control levels.

The ideal would be to allow open member access to most things for community updating, but restrict access to the manuals to a list of identified editors. Manuals have to get it right, so the sort of circumspection that oli and his compatriots engage in is to be preferred IMHO._________________Actions speak louder than words ... and they usually work when words don't!
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com

I really agree with a lot of what has been said recently and can't wait to see what we all come up with.

On the wiki side of things, here's my suggestion:

A new empty wiki with a distinct hierarchy could solve a lot of problems. The manual team could have their own "manual" section with sub categories accordxing to translated languages. (My opinion on the manual is that everything be submitted in english and then translated out to avoid any info onnly getting put into say the chinese version.)

Then each new release could be sub-categorised (think along the lines of how community editions have been made, art/bugs/code/suggestions all neatly under the one release)

This would mean the archiving of old versions with all the details on them in their own catergories.

Then there would be some obvious overlap category with news, puplets and other general information.

The problem is that I don't know if a hierarchy system is possible to do with Wikka. The category feature is the closest thing that I know of but this has proved very confusing to orchestrate. I also would suggest not going with a Drupal extension wiki as realistically the wiki needs to have the power of a dedicated content system. Would a change of wiki software be possible? I know that http://moinmo.in/ (used by Ubuntu wiki) is capable of doing subpages (e.g. .../Manual/French)_________________Cheers,

Does someone knows a good program to manage such a manual in different languages?

The extreme technical solution might be to use DocBook and a subversion repository and have forks for different languages. I have no experience of it but from my reading I think this is how the gnome documentation project do it. It looks like setting up the document compile chain is involved. DocBook is an XML language and so looks similar to writing XHTML.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum