New how-do doc

Hi,
I've uploaded a first draft of a how-to doc:
     "How to Create Ad Posters Using LibreOffice Draw"
As there is currently no /libreoffice/english/howto/ folder (and I didn't feel I'd been around long enough to create one), I just dumped the doc in /libreoffice/english - anyone who wants to find a better home for it is welcome.
Also welcome are any edits, criticisms, and comments.
Regards,
David Clinton

I've created a suitable folder and moved the file there:
http://www.odfauthors.org/libreoffice/english/how-tos-tutorials

I probably won't find time to look at, edit, or comment on the
contents until next week, though.

--Jean

Quick response: This is great. I'll probably make some minor editorial
suggestions when I have time, but otherwise it's obvious that you know
what you're doing with both the program and the writing. Please carry
on with more.

And if you've got any suggestions for topics for other people to work
on, do say so.

For the benefit of others: David's how-to is longer than many I've
seen, toward the "tutorial" end of the scale. Some how-tos can be
quite useful in just a page or two. It all depends on the subject
matter. When people ask me how long one should be, my reply is:
however long is necessary to say what needs to be said on a topic; no
longer, and no shorter. Some benefit from a lot of screenshots or
diagrams; others need very few images.

--Jean

I can only reinforce what Jean said in another email.

I don't have all that much experience of draw so I just followed the the steps in the doc. These were easy to understand. Well laid out and easy to follow. Nothing else to say really. Well done.

Cheers

Thanks. I appreciate it.
What is the process we follow for moving a doc to actual publication? It's rather obvious from looking around the site that Jean somehow manages to be involved in an awful lot what happens here (not to take away from the contributions of many others), but even she probably can't steward every doc through every step of its journey...
David

We have a process, which mostly isn't followed due to too few people
to do the work. I try to go through work by new contributors and then
turn them loose if they don't need or want supervision. In practice, I
generally publish everything, often because people are waiting for
others to review or edit and I decide to just publish anyway, ready or
not.

I (and Hazel, and Peter, among others) try to edit and enforce some
consistency among chapters in the users guides (particularly in a book
which is not all being done by the same person), but authors of
stand-alone documents are welcome to deviate from the "voice" of the
user guides. You are also welcome to publish your docs whenever you
feel they are ready; if I or anyone reviews it and finds anything that
needs improvment, we'll suggest changes to the author or simply make
the changes (typos etc) and replace the published version.

David, I'm working my way through your first how-to, mostly using it
as an opportunity to point out how we do things in the user guides,
which you can choose to follow or not.

I've not had a chance to consider what's the best place to list
how-tos on the wiki. Quite a lot of the available material is poorly
organised and difficult for people to find. Suggestions welcome. As
longer-term members of the team know, we keep attempting to improve
the organisation of the wiki; it's definitely an ongoing process.

--Jean

Thanks for the details.
I wonder if a how-tos menu link might not fit somewhere towards the bottom of the Contents menu in https://wiki.documentfoundation.org/Documentation/Publications (perhaps before or after FAQ).
The bigger question might be whether it's possible to add a link to a single hub page linking to some of the orphaned material (like Reference Cards and Video Tutorials, along with how-tos) in http://www.libreoffice.org/get-help/documentation/ - perhaps there could be a link beneath "Other books coming soon" to a page that, in turn, links to "Other Documentation"
David

Thanks for the details.
I wonder if a how-tos menu link might not fit somewhere towards the bottom of the Contents menu in https://wiki.documentfoundation.org/Documentation/Publications (perhaps before or after FAQ).

That was more or less my idea.

The bigger question might be whether it's possible to add a link to a single hub page linking to some of the orphaned material (like Reference Cards and Video Tutorials, along with how-tos) in http://www.libreoffice.org/get-help/documentation/ - perhaps there could be a link beneath "Other books coming soon" to a page that, in turn, links to "Other Documentation"

That's certainly possible and indeed has been one of the ideas I've been considering. It's always a toss up between "too long a page" and "too many clicks to get to a page".

I've also been considering trying out some additional pages of collections, grouped by component, to supplement the pages grouped by document type. However, it's not a good idea to have too many pointers that need to be manually added or updated, so I need to look up how to embed (include) a page of info into several display pages. I've done this before, but not for several years. Or perhaps someone here is familiar with that technique? Clayton, perhaps?

Anyway, it's not solely my decision, or my job to do, so if someone wants to take an idea and run with it... It's a wiki. If you muck it up completely, we can always revert the changes. :slight_smile:

--Jean

That's certainly possible and indeed has been one of the ideas I've been considering. It's always a toss up between "too long a page" and "too many clicks to get to a page".

Thanks. I'll try to give it some more thought...

I've also been considering trying out some additional pages of collections, grouped by component, to supplement the pages grouped by document type. However, it's not a good idea to have too many pointers that need to be manually added or updated, so I need to look up how to embed (include) a page of info into several display pages. I've done this before, but not for several years. Or perhaps someone here is familiar with that technique? Clayton, perhaps?

If it's html you're looking for, something like this might work:

<iframe src="http://www.mysite.com" height=1100; width=1400></iframe>

David

No, not HTML. A wiki include statement that pulls in another page (or part of a page) on the same wiki. I'll find it, once I take a few minutes to look for it.

--Jean

Also, iframes with specified heights are evil. Many of us increase font sizes and badly done iframes cut off bits of the text.

--Jean

Back in the OOo Wiki days we used an extension called Labeled Section
Transclusion http://www.mediawiki.org/wiki/Extension:Labeled_Section_Transclusion
This allows you to mark and transclude a section of one page into another page.

I don't know if that extension is available on the LibO Wiki (haven't checked).

You can also do full topic/page transclusion without any magic or
extensions: http://www.mediawiki.org/wiki/Transclusion
Basically, this is what you are doing when you use a Template, but you
can do the same with pretty much any content... the limitation is you
get the whole page instead of a section of a page.

C.

Thank you! Your note is incredibly well timed. I was just looking that up. :slight_smile:

"Transclusion" certainly isn't a word that I would have thought of.

--Jean

This is the one I remember using, and it worked very well except for
confusing newcomers who tried to edit some pages with little or
nothing on them except the transclusion code.
Full topic/page transclusion: http://www.mediawiki.org/wiki/Transclusion

--Jean

Yah, "transclusion" is definitely not the first word any normal person
thinks of :slight_smile:

I looked through the installed extensions on the LibO Wiki... but I
didn't spot LST in there. So, it's probably not installed. This
means you can transclude whole pages, but (as far as I know) you
cannot transclude parts of pages. I don't know how interesting LST
might be for people. It has its good and bad points like any MWiki
extension.

C.

Hi :slight_smile:
I think it is widely agreed, by website designers, as being good practice to use percentages or proportional sizes rather than fixed sizes.  Sadly they/we still often use fixed sizes because it's easier for them/us to understand.  It's not just about font-height (although that is one critical factor) but also about 'screen'-size, or rather, how large the page is on the screen.  People are going to expect to be able to skim through wiki's on hand-held devices (tablets, phones etc).

Is it possible to 'fix' the size of frames, in wikis, as a percentage of the screen-size or proportional to font-height?  I think it is possible in html but i didn't even realise wikis could have frames at all.

Wiki-markup/down tends to be 'simplified' html/css so that 
<h1>heading</h1>
becomes 
= heading =
and
<h2>sub-heading</h2>
becomes 
== sub-heading ==

So, i think the wiki 'coding' look less cluttered and is easier to read (or ignore or work-around) while just editing the contents.  Some coders might say that is not important and having "yet another" mark-up/down just creates fragmentation and confusion but i think is fairly crucial that it is easier for non-coders to be able to read and edit contents.  It might be an insult and a shock to some people but not all coders are much good at writing content and not all great documenters can cope with coding.  Wiki allows un-coded content to look reasonably good and then other people can come along later and add or tweak the coding to improve the look of the page.  To my mind it takes at least 2 people to make a wiki-page look good and be useful.  
Regards from 
Tom :slight_smile:

PS (Jean is one of those people who often achieves 2, or more, people's worth so i'm not really contradicting what we see happen)

<snip />

No, not HTML. A wiki include statement that pulls in another page (or part of a page) on the same wiki. I'll find it, once I take a few minutes to look for it.

--Jean

Also, iframes with specified heights are evil. Many of us increase font sizes and badly done iframes cut off bits of the text.

--Jean

Regarding iframes: we don't use them, don't need them, and won't use them because transclusion will do the job if we want to go that way.

--Jean

Hi :slight_smile:
That is good new! :slight_smile:  I'm still not entirely conversant with good implementations of transclusion but it sounds good! :slight_smile:
Regards from 
Tom :slight_smile: