So what I'd suggest as an alternate is that for core functions we have a common set of documentation. Then for desktop specifics, for example configuring a KDE destop to play mp3s then seperate links for the specifics. I suspect that most people, even those who have not installed the full desktop have most of it installed anyway to support those apps from the other desktop they cannot live without. K3b probably being the most common example of that. Gnome and KDE users may be unaware of really cool utilities that exist in the other desktop. So by having them in the same documentation it can be a discovery process for them.
So the main value is in configuration. Adding an app to the menu of different desktops is a very different process. Where something is located is different not only between desktops but also between versions of the desktop sometimes. Where is not important, the how is. How to configure your networking from GUI or from command line for example. When we are talking about command line we are talking about the same no matter what desktop you are running. So we have a common and redundant if we split the documents up piece of information relivent to all desktops. If we have multiple copies it is certain to get out of synch. So it needs to be embedded or linked. The core concepts of networking are again common. What IP ranges to use if you are creating a home network for example. So the boxes you fill in may look different or may be the same between desktops and only the steps to get to them are different perhaps. I'd have to look actually :) I do it all from command line myself.
So I'm thinking that embedded docs in the same framework will be better. When somebody wants to go to very desktop specific areas then split off. An example might be
When configuring a home network blah blah blah
link to KDE, Gnome, Command line with steps using each.
DNS configuration using blah blah
In this way the user scrolls down finds the relivent information, then has a link to follow for the method to accomplish the task. They might be using one desktop or another and find it will be clearer and easier to switch to the other desktop to accomplish this task. They might only choose the desktop they use and go with those docs or might do it from the command line and skip all the GUIs. The steps specific to a desktop might lead back to a common place. They might also be known to the user and that part of the documentation skipped over as they already have the proper app open already.
On 11/25/06, Karsten Wade <kwade@xxxxxxxxxx> wrote:
I went to bed last night thinking, "We need to add Kmail, Konversation,
and Konquerer to the DUG," and then I read this today from John:
> We will need an equivalent Desktop User Guide for KDE like what now
> exists for GNOME. See
> http://fedoraproject.org/wiki/Docs/Drafts/DesktopUserGuide.
> This should probably be a separate document for now.
I actually think we could just reorganize and put KDE and GNOME content
all into the same guide. Much of the surrounding content is the same
(logging in, etc.), so it would increase maintenance of identical
documentation. In XML we can more easily build custom DUGlets, that is,
a DUG with a specific desktop only focus. I think keeping all eyes on
one DUG with dual-WM support should do it. Does that sound reasonable?
- Karsten
--
Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project
Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject
quaid.108.redhat.com | gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
--
fedora-docs-list mailing list
fedora-docs-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-docs-list
BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.5 (GNU/Linux) mQGiBEVfRxMRBADdFrbSWN48kGrzLGyuewXPfgBWpYUshK4ReceLXpD+vkjfBo9+ edhD8WVhMtK2AZIv4z1HLWRjJ+2eUWISCd8EOraiRJTqDqfDDinw5YRSzoNaWtH/ 6H1e1kfd8qpSJo7R9v+IgRcwkbltItezThDXy8n3/oI2BCyr5sET3jqYTwCgiGCv YRodCmKE2PUB4/ZKhROJIRMD/jGHdiEucitNSHA0gzZBvDxtz4eR7kBuH3VplOHW Ds5SMcWgPsMDf9RkTgk1PxlsUw/Xw+oIny6TABhMUaXcbIf/nSkaRwGGoIHinlqB vdYKhMPUkbK1994tgtvUHf/NeAzJNvVm9XPC9ChV5g+rFLJUDBCuZkMXN/sPc8kG 32GBA/9TfBSMSzvnGQBdVSK/EmFmOeJOKz3OprRqIXkZskf6TG8XmuY+K8fhAk8m rvxmpKvkp4pnj0SFEl+tWMhaYkVbiUaQ+jcUCmJNa/834UQLEFqj5yrze4N25nlm vGIhJT5Ih+PxE9X5nm+VGg3v5m9EXBT8/KAAwf3l2UYv/twOEbQzRHJhY2lyb24g U21pdGggKG5vbG8gY29udGVuZGUpIDxkcmFjaXJvbkB5YWhvby5jb20+iGAEExEC ACAFAkVfRxMCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRCWjvq+59GzeJae AJsFwd03dp7ErbvytEPVqzP/ii6KUACfVvldwHFfUiCZ+kh+A9xK17dwQZy5Ag0E RV9HHxAIAIuVBPimStQnTi8aa+24S3O/mcJGM0bG/uKpj9WjwbZv5VKsdra3/Ij0 F9RMbTL/y865S75LEVzIPXMxm/t2Onqtt1tDCnbEYzgZLsHKkL2mJvIIwViXyCgj 1aZRqj4oAhupCIi4Dhr9fNdlZfxPZUW0/VCxsDSGBEoD+aXZk4CBdIzUqD3kVuIO Z2IAWgAbLG4ci9xypwzuOPqcZ6kaMviYTNzk/7MwbomrQhiCwljX/iZD2fK+62d8 NH5qLQ+E4K2SFWG4P4qt4Rff4Q1JT7jz+BTMT98oSfK0FGpEKOhkTMp40Hwd3cVJ IL0Q9iLiTEoHHcJAeQY1wYIieM+FG7cABAsH/1gNj3kNdqYoak2tNqUOdML8YFkB qqj704cLMsfKi78KgngljHZdXHLiSALstkcLJ8TxDBkwvHOpJUqads0HGAgTUXdq Q9QOFY2cydk/3m5xlrYhtaZdno9QVml7TKn/YaxiCGYD/csYc4ch/9NkviCP3H09 mSysHYFGK2fz4FD1CGK4QXBOafgAkPk+hiE8itmuzJWzcs8oDaVN2hC+GqMIgQzs qsuaGXxBdKLNlQ5yH+SCioDy6fZCMn3v7VfQECpYi4sbcRFplA5NiVTJ6WOfxa/c jH2Rd6BdPzK/4dNdY4PStlGWZGuVYImkOaiDAxPvhCOLvD5NU2UCMK8jrFWISQQY EQIACQUCRV9HHwIbDAAKCRCWjvq+59GzeMheAJ0Sej9k9+c7qelk5Phu9Bzl8KMD /ACfWE9dza11IzjCzGwhLEZqMnlGZdM= =14Kt -----END PGP PUBLIC KEY BLOCK-----
-- fedora-docs-list mailing list fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
