Difference between revisions of "PC-BSD Wiki talk:Style Guidelines"

From PC-BSD Wiki
Jump to: navigation, search
(Desktop pages)
(Additional Resources)
Line 78: Line 78:
--[[User:Tigersharke|Tigersharke]] 23:55, 7 August 2012 (PDT)
--[[User:Tigersharke|Tigersharke]] 23:55, 7 August 2012 (PDT)
I guess that perhaps in general we can scrap the 'additional resources' within the handbook, but for other pages it would be fine. I tried to allow other text within the 'refernces' section, which can be done, but if it includes an external link, we are back to the same problem)s).
--[[User:Tigersharke|Tigersharke]] 21:54, 8 August 2012 (PDT)
== Desktop pages ==
== Desktop pages ==

Revision as of 21:54, 8 August 2012

This page may eventually get so large that it might need to be refined. It should eventually be used to create some examples, like the stub page, to partially replace some of the content here.

Perhaps a specialized template that could be called, which automatically highlights within its content, the portions referenced as examples. In this way, the example page could be extremely inclusive with built-in context to help clarify. This is starting to sound like a very cool idea. :)


needed markup for lists

Once ("official") again:

Style Guidelines (of our PC-BSD Wiki) are telling for lists, that we need a hard enter to ensure that the PDF and EPUB versions format correctly.

Does this count only for "unordered" lists? A change for a numbered list does not include hard enters.

Does anyone can check the result of the PDF and EPUB versions for it? Probably it does not format correctly, because they are also items (like for normal bullet), or not?

Maybe a <br> at the end of every (without the last) item would help (enough). (BTW: I did such a change preliminary.)

Here my example (as an offer) for the section Bullets:

To ensure that the PDF and EPUB versions format correctly, use a additional [[wikipedia:Help:Wiki markup#Line breaks|<code><br></code>]] between the items in a list.

== Bullets ==

There are two types of bullets in use:
# A bulleted list which begins uppercase. Whether or not it ends in punctuation depends upon the size of the list. For example:<br>
#* the [[What's New in 9.1]] list uses sentences to describe the features so ends in a period. Use this type of list when the list includes a description large enough to warrant at least one sentence.<br>
#* the [[Minimum Hardware Requirements]] list uses few words per item. Since the individual items do not warrant a sentence, this type of list does not end in a period.<br>
# A  bulleted list which begins with bolded text (typically the name of a menu item). The bolded section is capitalized to match the name of the menu item and followed by a colon (:). The sentence following the colon begins lowercase and should be worded so that the bolded item is the beginning of the sentence. An example is:<br>
#: '''Size on Disk:''' indicates the amount of space being used by the jail.<br>
#:: In this example, the menu item appears as "Size on Disk" (mix of upper/lowercase), "indicates" is lowercase and is worded so that it reads as one sentence (including the name of the menu item). Because it is a sentence, it ends with a period.

"in terms of collegiality"

-- Rg 11:55, 12 July 2012 (PDT)

I think I would be open to most any formatting of the bullets/lists as long as it can be consistent among variations and for the range of formats (html, epub, pdf, etc) and whatever is easiest/simplest and/or does not add a significant amount of work/typing. I generally do not deal with conversion to epub or pdf, so I cannot really offer any suggestions for that, and my methods may differ compared to how others might convert to those formats.

--Tigersharke 01:19, 13 July 2012 (PDT)

After more thought and comparison, I chose to swap your bullets section as you formatted it, into the text of the guidelines. (I agree with the format and use of it)

--Tigersharke 02:46, 18 July 2012 (PDT)

Overall size of document

The style guidelines page is good so far, and helpful with its completeness, but I think it will better serve if it were more brief. This can be achieved by transferring the examples to a page that would include context for all such examples. Also, it would allow for multiple examples to be shown while the hinted example could be highlighted. This would be possible via 2-piece wiki page. a simple page that sources a template perhaps, with the call to the template at each link to the example. Each example in this contextual example page would be numbered so that calling the page link would cause the specific example highlighting. Of course this is all still a really cool concept which has not been fully explored as yet- but doesn't it sound amazing?!

--Tigersharke 02:48, 14 July 2012 (PDT)

Headings vs CSS

This is the one part of our style guidelines that seems abused the most, with regard to how things probably should be done, versus how they have been done. I believe there is some issue of final appearance via heading markup that is preferred over the proper way of using headers. Due to this, if the actual desired results might be defined, then the wiki css can be adjusted to match, rather than skipping header levels or other such divergence. We may be stuck enforcing a non-standard heading formula if the CSS format is not determined or not switched in a timely manner.

--Tigersharke 02:59, 18 July 2012 (PDT)

Representation of dates and times

Maybe we should doing also wikipedia:ISO 8601 usage? :-/

--Rg 08:54, 1 August 2012 (PDT)

I think the built-in {{#dateformat:01 May 2012}} is about the best we can do, until the wiki software itself better conforms to ISO 8601. This was added to the style guidelines. A similar built-in for times could be used also, but I don't know where it is needed currently.

--Tigersharke 23:16, 1 August 2012 (PDT)

Additional Resources

In the article KDE4 the section title is removed. But what about PC-BSD for Linux Users#Additional Resources, PBI Manager#Additional Resources and other articles here?

Maybe it makes sense to create a "rule" in Style Guidelines.

--Rg 07:26, 7 August 2012 (PDT)

It may be that because we have the references heading, the 'Additional Resources' heading is "too much".

I don't always understand every edit Dru makes, and some I disagree with but I let them slide- although I usually fix the 'here' links. I agree with having a heading for 'Other Resources' or 'Additional Resources' on the KDE page, since the two links get kind of lost there and seem to merge with the last lines of the instruction portion. One possible solution that would negate the heading is related to the cite extension. Have you looked on wikipedia and seen their list of links on the bottom of the page? Some of the content there is not within the text. If i can figure out how to blend it with our current citelink and refheading stuff, and make a slightly different template for this new 'citelink' type situation, it likely would be the best answer.

--Tigersharke 23:55, 7 August 2012 (PDT)

I guess that perhaps in general we can scrap the 'additional resources' within the handbook, but for other pages it would be fine. I tried to allow other text within the 'refernces' section, which can be done, but if it includes an external link, we are back to the same problem)s).

--Tigersharke 21:54, 8 August 2012 (PDT)

Desktop pages

It appears that there is somewhat of a theme for how such pages should be constructed as a minimum. Screenshot of default (right after first install as the only desktop), description of how to reach the AppCafe® and other PC-BSD utilities (may include screen captures), and links to information from the desktop authors.

I think that we should not simply say "and here are some links for further information.." I think we should give some basic configuration/setup information for each desktop, and *then* say "for further info.." but this 'further info' could be within the new 'citelink' type (described above in 'additional resources' that drops it into the 'references' section at the bottom.

Personal tools