Our product that we have chosen to write up documentation for is Blender. Blender is a free and open source 3D creation suite. Blender supports the entirety of 3D creation. This includes modeling, rigging, animation, simulation, rendering, composition, motion tracking and video editing. Blender is a very powerful tool that is commonly used for 3D structure modeling and game animation and resource creation.
The audience we have chosen to write for are developers and designers that have some experience with using blender. These people would have experience navigating Blender and would be comfortable with the user interface prior to reading the documentation. This approach of an audience is appropriate for the assignment because there is so much documentation for blender out there already that is very good at getting a new user started up. We have links throughout our documentation for if there does end up being a person that is new to Blender. These links will take the person to the official blender tutorials for the user interface and other needed pre-requisite tutorials.
Having an audience that has some experience with the product to begin with allows us to jump into instructions quicker without having to specify every single tiny detail. Using when we instruct the user on importing or exporting an object or file as an example. Instead of instructing the user all the way through the process of navigating their personal files to find the directory that they are going to be using for an export, or finding where the file is that they want to import. We were able to lump all that together into a short sentence of, “Navigate to the location of the file you want to import…” This allows us to include more of the technical details and information around the functions we were documenting.
Another way that targeting an audience that has experience with the product affected the way we wrote our functions is that we included some overall details in a summary of when you would use a function or what the function is used for in industry, etc. These summaries would be better read by someone who is using the software as they rely on some background knowledge and information that would be acquired from working with the software before.
Having an audience that was using the software already also allowed our images to be more product oriented. Someone who was brand new to the software would most likely have to take much longer scanning their screen looking for the locations of where our screenshots are taken from. A more experienced user would see one of the images attached and know exactly where, or around where that image was clipped from. This would allow a more advanced user the ability to scan the images to see the rough process they will be following for a given function.
In terms of content that we could include in this documentation, the possibilities for what we could demonstrate was quite large. If we were to include every feature included in Blender, we would likely end with a document with well over a thousand pages. Therefore, we had to limit what we demonstrated for the sake of time.
Most of our research was conducted by consulting the Official Blender Manual provided by Blender itself. While we did use our own experience with the application to formulate many ideas in regards to this technical document, the Blender Manual was an invaluable reference while writing.
We selected features based on what we deemed as basic functions any user of Blender would need based on our own experience with the application. This is why we included features like the import and export functions, rendering, basic transformation tools, and settings configuration. Other tools, like the boolean modifier, sculpting tool, armature bones and add-ons were included to demonstrate some of the more complex functions of Blender so that our audience would be able to get a preview into what Blender is really capable of as a 3D modeling and animation tool.
When it came to formatting a few key priorities were immediately set, the document should be accessible, easily read, and consistent. Luckily these goals all tend to feed into each other. We started by choosing the color palette, for this we wanted to ensure that the colors were accessible for people like me (Ethan) that are colorblind wont struggle with the colors chosen. For heading we choose to mic the blender logos official colors, #265787 and #e87d0d. For in image labeling we went with the most distinct red you can get ( #265787 , and the oranges are to be kept to #ff0000.) to ensure that it popped out against from blender grey color palette. Then for the color of the text of the body we went with traditional black on white. When it came to formatting we made sure to include plenty of distinct headers and sub-headers to maximize "skim-ability", as well as make it easier for people that struggle with low vision to keep track of where they are on a given page.
Speaking of people with low vision, I have a lot of experience of working with people with low vision from my time as a Medical assistant at a retina office. One of the common complaints i got when i was talking about working on website from people with low vision is content not properly formatted for screen readers. We spent a lot of time organizing the images to make sure that a person with a screen reader doesn't have to deal with major hookups, like repeated text explaining images. As a result we choose not to include headers and instead use 'alt tags' as that whats screen readers typically prefer, and are built for.
Additionally for the body text we choose to have 2 separate font styles for informative text, and instructional text to make them more distinct from each other. We choose to go with a sans-serif font for the instructional text, with times new roman for informational text. As well as increasing the font size for all body text from a traditional 11pt font to a 14 pt font to make it much easier to read.
In crafting the documentation for Blender, we attempted to maintain our awareness of our ethical obligations to our audience. That awareness helped us design our manual in a way that was ethically consistent with the vision regarding the content we wanted to create.
Acknowledging the diversity and expertise of our audience, we aimed to present information that was not only accurate but also respectful and inclusive. For instance, in discussing Blender's features, we emphasized clear, detailed explanations to prevent any misunderstandings. One part of our manual that shows this is in the beginning of 'Settings Configuration''s 'Preferences Menu' section, where we establish a base level of understanding by saying "To navigate to the the Preferences menu, access `Edit > Preferences' using the navigation bar at the top of the screen." This passage illustrates our commitment to detailed explanations, ensuring that users, regardless of experience, can follow and work with our manual.
Accessibility was another crucial ethical consideration. We endeavored to make our documentation inclusive, catering to users with various needs, including those with disabilities. An example of this is our detailed image descriptions and use of 'alt tags' which were designed to be screen reader friendly. A relevant section that shows this would be in the Armature Bones section, where we include a descriptive alt tag for each image included in the section. Many of these images are just displays of menu selections, with titles like "Add Armature Menu" and "Edit Mode". These alt tags show our dedication to accessibility across a wide, inclusive audience.
Intellectual property respect formed a cornerstone of our ethical approach. In line with Blender’s open-source ethos, we carefully credited sources when used, linking to each of them in our Sources page. These links can be easily viewed by going to that page, and we hyperlink to each source to ensure that we appropriately direct traffic and credit to the useful documents contained there.
In weaving these ethical considerations into our documentation, we not only aimed to educate users on Blender’s functionalities but also to subconsiously instill a sense of inclusivity and responsibility. Our goal was to empower users across a wide range of backgrounds to leverage Blender's capabilities ethically and effectively, helping to foster a community around the open-source software that values the things that open-source attempts to encourage in its design.
We loved this opportunity to reality structure out a more long form document, and really build out an entire project from the perspective from a users perspective. It was super fun to watch as the decisions for who we wrote this for informed each and every decision as we built out the project. From the format, to the features covered, to the formatting.
If we were to do it again I would have loved to interview some people that are involved in robotics to see what information is presently helpful, as well as what information they struggled to understand when they started out doing robotics when it came to 3d modeling. Knowing where they are coming from might have changed the way we tackled things, as well as what we tackled. I'm very glad with what we covered however there is only so much you can get from an outside perspective
This project was an amazing experience that was awesome as a kind of perspective shift into a much more user focused approach, as well as how those things, and having a clear end user really ease the collaborative process, and make it much more fulfilling to build out these things as the end user is always kept to the forefront of our minds.