This Blog post takes readers on a path of the process of publishing a book on Github and the bottom line costs. A journey of becoming a published writer can be a difficult one, that leads you down paths of rejections, financial struggles, and difficulty finding resources to complete your work of art. The author of this posts details his path of publishing his work, the resources necessary, and the people who helped to turn his book into a realty.
Collaboration and Contacts
The author reached to colleagues in her network to gauge if going the traditional route of getting her technical writing was an efficient way of getting the book to the public. Many of her colleagues offered to read her draft, however it would be a period of three months before she would hear back from them.
She discusses reaching out to similar minded professionals for the editing of her book, can help ensure her work has the technical accuracy aspect she aims for. The author has great contacts with equally formidable skills as her, these contacts are who she will use to help create a work of art she can be proud of.
What I thought was a great idea she had was, that she used templates from several online services to design the covers and layout of her book. I feel this can be a great money saving aid for new writers looking to save some money when first striking out. She provides links to the services she used to help her complete her project from start to finish. I feel these links can be helpful if you are a beginner, and you need some guidance in designing your first book. She also lists a high-end price lists of the starting cost of materials she needed to get her book published. Being mindful that these costs are for the higher end subscription and design offerings.
In conclusion, though I am not a writer by no means, I still was fascinated by this blog post. It delve into the process of how technical writers can get their book published in this new technology age. She was able to complete this book for only $823. You always here about writers suffering through rejection letters, and pounding the pavement to get editors to read their drafts in hopes of finding success. The direction this author chose, I felt exemplifies our new technology age of publishing. This is a very interesting read for you aspiring authors out there.
I believe that of all the topics covered in this class, I got the most use from learning about structure. I already knew to use appropriate language and give consideration to the audience, but I didn’t know how important structure would be in a document. A nice structure will lead to a nice outline, a nice outline is just filling in blanks. This only works for some documents, but structure is important regardless.
I will adopt this newfound appreciation for structure by spending more time focusing on it prior to starting to document. I will also be willing to revise the structure to fit the content if necessary – you can’t fit a square peg in a round hole. I see this helping me in the near future because I intend on writing many different kinds of documentation – processes, use cases, alerts, and config files are all things I believe I will be documenting this summer. Having a defined structure for each, and a way that they can all fit together (this is for a single project) will be fantastic when trying to write the documentation.
In Technical Writing and Editing, we learned about the four levels of editing: revising, substantive editing, copyediting, and proofreading. Learning about the levels of editing allowed me to get a better grasp at how to approach my writing assignments in class. In the past I have eagerly completed my assignments then struggled to find a rhythm when editing them. More often than not, it lead to me proofreading the paper then submitting it. After being assigned multiple 10-page term papers and numerous other small assignments this semester, I knew I had to find a way to establish a better method of editing and submitting my assignments in a timely fashion. As a first step, I now know to revise individual documents as a whole to establish clarity. If time is permitted, I then update the organization and design of the document. Lastly, I go through the document twice to ensure clarity and consistency and then to catch any grammar errors.
I believe I have been very successful this semester when revising and editing papers. I not only believe that this strategy is useful while I am still a student, but in the future as an engineer as well. Engineers often write reports, memos, and e-mails to coworkers, clients, and customers. For quick e-mails, it is important to quickly copyedit and proofread to ensure the reader will understand the purpose of my e-mail, however in reports and memos it may be more crucial to go through each level of editing. Knowing how to utilize the four levels of editing is a valuable skill as an engineer.
One of the topics that we covered in class that is most likely to stick with me through my college career was the topic of infographics. I found out not only what infographics can be used for and how to use them, but to actually create them myself. I tried various infographic templates to produce the ideal infographic, that still I could not come up with. I learned how things can work in your mind, but not in reality, exactly like mechanical engineering technology. Things can work perfectly in your mind but when you try and manufacture that part or mechanism, it might not work. And just like the infographic you have to just take a step back and approach it from a different angle until it is satisfactory. I plan on using infographics for future presentations and to show group members data I’ve found or collected as well. I think that learning how to produce infographics was one of the most beneficial topics we covered in this class.
This blog post by Save the Semicolon, entitled “Rules Are for Breaking” makes the very bold statement that there is no real rule or law that requires people to use proper grammar. It is instead only “very good advice.” The author says that one can break a grammatical rule and still be considered a good writer – if breaking the rule is what’s best for the reader. Although unconventional, this reinforces the idea of identifying the audience and taking it’s needs and characteristics into consideration when producing a document. The author provides a few examples, but for the most part leaves it up to you to figure out when to break the “rules,” and when to follow the “advice.” My title for this post may not be grammatically correct, but hey it certainly got your attention, didn’t it? Go on. Don’t play by the rules. You know you wants to.
– Matt Williams –