Greetings, Motley Crew! I have couple of sandboxed pages ready for your review/input at: http://fedoraproject.org/wiki/wiki/VladimirKosovac/StylingPage/WorkPage As Karsten suggested, probably easier to review smaller chunks - thus this call. Of course, all suggestions are welcome and appreciated.

Rahul Sundaram wrote: > Vladimir Kosovac wrote: >> Greetings, Motley Crew! >> >> I have couple of sandboxed pages ready for your review/input at: >> http://fedoraproject.org/wiki/wiki/VladimirKosovac/StylingPage/WorkPage There was an error in that uri due to me placing extra `:wiki` path when creating pages. It's all fixed now, correct uri is: http://fedoraproject.org/wiki/VladimirKosovac/StylingPage/WorkPage

Thanks to Thomas Chung for pointing this out. > I would like to see how this section fits into the bigger guide. So > using the drafts space seems to be better. Most certainly. Due to large number of trial-and-error edits on my part, as I was learning the basics of the formatting, I thought it would be better to move this section elsewhere, so edit notifications annoy less people - only four subscribers in alternate location :o). I'm inclined to move these few pages back into Drafts, consistency wise it is much easier for everybody. Do we follow the style of > exposing path and binary names anywhere as compared to highlighting the > menu entries in the desktop? This section would be good as a reference. I couldn't find any "prior art" to refer to and thought this would be good idea from the practicality point of view. We are supposed to show that commands are run "su -c" way. However, /usr/sbin is not in normal user's path, so we'd have to write the full path to binary for the command to work. I got around this with admonition on how to alter $PATH and use only binary, two pages further down: http://fedoraproject.org/wiki/VladimirKosovac/StylingPage/WorkPage/Accoun... I'll keep going and if needed make style changes later on. | vnk | > However a guide should cover tools from the administrative view point > and not just lump all the system-config* tools in a single page. > For example, if I am doing web services administrations, I would expect > to learn about system-config-httpd in that section along with the Apache > configuration details. > > Rahul >

Vladimir Kosovac wrote: > Greetings, Motley Crew! > > I have couple of sandboxed pages ready for your review/input at: > http://fedoraproject.org/wiki/wiki/VladimirKosovac/StylingPage/WorkPage > > As Karsten suggested, probably easier to review smaller chunks - thus > this call. Of course, all suggestions are welcome and appreciated. I would like to see how this section fits into the bigger guide. So using the drafts space seems to be better. Do we follow the style of exposing path and binary names anywhere as compared to highlighting the menu entries in the desktop? This section would be good as a reference. However a guide should cover tools from the administrative view point and not just lump all the system-config* tools in a single page. For example, if I am doing web services administration, I would expect to learn about system-config-httpd in that section along with the Apache configuration details.

Uttered "Paul W. Frields" <stickster(a)gmail.com&gt;, spake thus: > On Mon, 2006-12-11 at 12:52 +0530, Rahul Sundaram wrote: > > Vladimir Kosovac wrote: > > > I have couple of sandboxed pages ready for your review/input at: > > > http://fedoraproject.org/wiki/wiki/VladimirKosovac/StylingPage/WorkPage > > For example, if I am doing web services administration, I would expect > > to learn about system-config-httpd in that section along with the Apache > > configuration details. > That's an excellent point Rahul makes -- that our documentation should > be largely task-based. Relevant material should be lumped together > where possible and logical. Agree emphatically. What I detest is "feature-oriented" documentation that mostly walks around the buttons and menus of a GUI, or is an elaborated bullet list of each separate feature (even if the elaboration runs to pages or chapters). I'm as guilty as anyone about doing this ("My name is Tommy. Chorus: Hi, Tommy!") but I'm recovering ;-) Every button / menu / feature / asset was designed into the program to provide a service, with a reason behind that decision. Document the problem solved by the feature, et. al., and not the implementation. Answer the question of "how do I foo", not the question "what do all these buttons mean?"; then the "what are all these dials and switches" question becomes moot. So, instead of this: o The FILE menu has an EXIT button. I'd prefer to see: o When you are finished, click the FILE/EXIT button to save all your work and to gracefully terminate the program. Just my $0.02e+27, YMMV.

Paul W. Frields wrote: > On Tue, 2006-12-12 at 05:36 -0800, Tommy Reynolds wrote: >> Uttered "Paul W. Frields" <stickster(a)gmail.com&gt;, spake thus: >> >>> On Mon, 2006-12-11 at 12:52 +0530, Rahul Sundaram wrote: >>>> Vladimir Kosovac wrote: >>>>> I have couple of sandboxed pages ready for your review/input at: >>>>> http://fedoraproject.org/wiki/wiki/VladimirKosovac/StylingPage/WorkPage >>>> For example, if I am doing web services administration, I would expect >>>> to learn about system-config-httpd in that section along with the Apache >>>> configuration details. >>> That's an excellent point Rahul makes -- that our documentation should >>> be largely task-based. Relevant material should be lumped together >>> where possible and logical. >> Agree emphatically. >> >> What I detest is "feature-oriented" documentation that mostly walks >> around the buttons and menus of a GUI, or is an elaborated bullet >> list of each separate feature (even if the elaboration runs to pages >> or chapters). I'm as guilty as anyone about doing this ("My name >> is Tommy. Chorus: Hi, Tommy!") but I'm recovering ;-) Am I understanding these suggestions well if I then say that tables on the intro page are redundant. To me, they look just like the stuff we want to avoid - feature listing for GUI tools - although more obscure. Scrap them, then?