I recall many newsletters from the early days of computing (Apple II, Atari, Commodore-64).. These were little more than 6 to 20 page bulletins. Back in the 1970's we didn't have an internet or any way of disseminating information other than printed material through the mail. 300 baud modems were just coming out and BBS'ing was still a few years away. So we had few choices, printed material or a full-blown radio/tv show. Needless to say, printed material won. Especially on such a niche field of endeavor.
There was a great need for little publications and club newsletters. We looked forward to each and every issue. Some of these went on for many many years. Each issue had programming tricks, maybe one advertisement for another local start-up operation, a call-for-articles section, user Q & A, user program listing submissions.
Each issue of a particular "publication" sometimes had a "Letter from the Editor", perhaps a table of contents all of 5 lines long, updates and advertisements for classes & seminars, meeting times & places, Machine Language tutorials, in-depth product reviews, Q&A sessions, letters from readers, articles describing hardware projects.. And so on and so forth. Sometimes sections would be missing, or new ones introduced in successive issues.
The one thing that made these publications so important and vital in getting the computing scene "going" was they provided real, usable, and vital information that was available nowhere else. NOWHERE ELSE! Content was king and actual typesetting and layout took a backseat. Title cover graphics were often hand-drawn. Some of these "magazines" were formatted little better than an engineer's notebook. The actual layout and appearance evolved over time. But they got the point across. The authors inspired their readers to experiment and try things never been done before. The authors enlightened their readers. The authors presented material not previously available. You get the idea..
One of these publications is still running today! Its printing schedule varied across many time frames, has gone out of business and re-invented itself from time to time. It also has a nicely put-together website.
The magazine in question is C.A.L.L. A.P.P.L.E.
http://www.callapple.org/
View attachment 8233
View attachment 8234
You may want to take a look at the early issues of these newsletters.
Also, more relevant to our hobby is a magazine simply called AERO. It's a Boeing company-produced publication, it seems to also have an irregular schedule (either that or the archive is incomplete). It is short, maybe has 5 or 6 very well researched articles relevant to the aviation industry.
The general theme seems to be based around engineering and how it fits into commercial airliners and their operations. It includes industry trends and focuses on the big picture and details equally well.
It also talks about an industry that has something to talk about! Commercial airliners are endlessly complex, yet simple in principle. Everybody knows and loves them (except for homeowners near airports).
http://www.boeing.com/commercial/aeromagazine/articles/qtr_03_09/article_03_1.html
http://www.boeing.com/commercial/aeromagazine/articles/2011_q3/index.html
When I look here to read these rags, I don't really care about the name or the font or that sort of thing. I'm looking to learn something, to read something I can't easily (if at all) read elsewhere.
So, having said all that, why not get some content together, you start writing an article, get some volunteer contributors together and let the packaging and formatting take care of itself.
One article I might be willing to write would comprehensively cover the multitude of graphical formats, their advantages, disadvantages.. Why use one over the other? How it all fits in together for texturing ships and planets. What programs are good to use and in what situations. It would basically be almost a tutorial. After doing the first initial article I could interview the graphic artists for a second writing, and gain more inside info on techniques. Well, you get the idea!
Another one would be on managing multiple orbiter installations on one system. There are significant tricks to saving space and sharing the large texture files. Multiple installs is required to maintain compatibility if you're an add-on junkie.
Maybe an article on the psychology of the orbiter community is in order. Perhaps these can be explored and researched - What held it together over the years..? Is it growing in richness and complexity or getting too thinned out? Is it a borderline religion? Is the community now more interesting than the program around which it was founded and grew from? How does the orbiter community extend into your life when you're not looking at pixels on a screen? Is it possible to arrange meetings? What are the problems involved in that and how would they be overcome?
Meantime I'd like to introduce an older tutorial that is well put-together and it is what I learned on.
http://smithplanet.com/stuff/orbiter/orbitaloperations.htm That and many JPL publications were all very instrumental in painting the picture of practical orbital mechanics for me; such as the new and updated "Basics of Spaceflight" available in a nice and tight .PDF --
http://www2.jpl.nasa.gov/basics/index.php
I also ran into these NASA FACTS and found them helpful when printing introductory material for folks that want a little more info than what the typical public news provides --
http://www.jpl.nasa.gov/news/factsheets.cfm And finally I found this when searching for images --
http://en.wikibooks.org/wiki/Astrodynamics/Classical_Orbit_Elements#Orbit_Parameters AND [ame="http://en.wikipedia.org/wiki/Ephemeris"]Ephemeris - Wikipedia, the free encyclopedia[/ame] -- if you like that sort of thing. Or perhaps -- [ame="http://en.wikipedia.org/wiki/Orbital_elements"]Orbital elements - Wikipedia, the free encyclopedia[/ame] is more pleasant to read because of different formatting
You see - With so much information out there on the internet, we're going to need to work HARD, REALLY HARD(!) to come up with new things that have not been done before, or written about previously. In the meantime while we're doing that, we can look to, critique, and practice with current tutorials. Perhaps even revising them with the author's permission.
We must also be careful not to spend inordinate amounts of effort "reaching" for new things. Once that frame of mind takes hold, sorry folks, it's time to cash it in and call it a day.