Hello Everyone,
We've completed the power point for the upcoming presentation after spring break. It includes a definition of descriptions, definitions and mac and cheese. Mac and Cheese, Huh? Yes, macaroni and cheese has a definition. It is our theme that helps us explain what descriptions and definitions are and where they are used. Hopefully it works to great effect for our audience.
Best Regards,
Mike
Thursday, March 6, 2014
Wednesday, February 19, 2014
Instruction Creation Project Topic
Hello Everyone,
The program automates the killing process of a character in the MMORPG Final Fantasy XI. It takes over control of the character for the player, so that he does not have to do the tedious work of killing creatures over and over again.
There user interface consists of seven tabs with names on the far left; names like Targets, Ignored and Routes. Each of these areas contains an interface that controls a piece of the program's functionality. We are currently looking at the grid of the Targets tab.
This part of the program controls what creatures the player should try to kill. When a creatures name is added to the combo box on the screen, the program will acknowledge that it should kill any creatures with that name. We can add, delete and clear all creature names for the combo box. The check boxes control under which conditions we can engage the targeted creatures (The creatures in the combo box).
As you can see, just by reading what I've typed, there are a lot of features jammed into one screen of the program. I need to build instructions for all of the screens and document what each screen is suppose to do and how to set it up to do it. Hopefully it won't take too much effort to do.
Kind Regards,
Mike
Sunday, February 16, 2014
Chapter 14: Creating instructions and avoiding angry customers
Hello Everyone,
Chapter 14 is about creating manuals and instructions. It's the one thing you dread when you buy a piece of furniture from Walmart: do I have to assemble it? You're caught in the moment and buy a futon, but do not see the lurking truth in the shadows. It contains a 13 page manual and the futon takes 3 hours to construct on a good day. Too bad it's already 9:00 pm...
We've all been there. That's what this chapter is about; how to create documentation that allows someone to perform a task safely and efficiently. It talks about how to design a document so it is easy to follow and easy to verify the user's success.
Many things come into play when designing one of these types of documents. You still need to consider the audience and see if they are from different cultures. You may be marketing to two audience that are continents apart and have to change the manual based on their culture.
It must be easy to follow and easy to read. Put graphics in with every step and use a direct tone of voice to convey instructions and to combat uncertainty. A lot of this chapter seems like common sense, but remembering all of this information when designing the document would seem next to impossible. The next time I receive a manual of decent quality for furniture, I'll be more appreciative of the work it takes to produce such a document and be glad I didn't lose may arm because I read the safety instruction at the start.
Best Regards,
Mike
Chapter 14 is about creating manuals and instructions. It's the one thing you dread when you buy a piece of furniture from Walmart: do I have to assemble it? You're caught in the moment and buy a futon, but do not see the lurking truth in the shadows. It contains a 13 page manual and the futon takes 3 hours to construct on a good day. Too bad it's already 9:00 pm...
We've all been there. That's what this chapter is about; how to create documentation that allows someone to perform a task safely and efficiently. It talks about how to design a document so it is easy to follow and easy to verify the user's success.
Many things come into play when designing one of these types of documents. You still need to consider the audience and see if they are from different cultures. You may be marketing to two audience that are continents apart and have to change the manual based on their culture.
It must be easy to follow and easy to read. Put graphics in with every step and use a direct tone of voice to convey instructions and to combat uncertainty. A lot of this chapter seems like common sense, but remembering all of this information when designing the document would seem next to impossible. The next time I receive a manual of decent quality for furniture, I'll be more appreciative of the work it takes to produce such a document and be glad I didn't lose may arm because I read the safety instruction at the start.
Best Regards,
Mike
Wednesday, February 5, 2014
Mishap In Paradise: Chapter 4 may be the assignment!
Hello Everyone,
I may have jumped the gun on the last post and wrote about the wrong topic. Chapter 4 was all about people. Who are the people? Where are the people? What are do they like? Do they like me? Do they like what I'm saying?
All of these things have to be considered when writing technical documents and it such a great relief that we such a great reference book. Because if I had to remember everything there is to consider about writing for an audience, my head would explode.
Obviously, my head wouldn't explode, but I might reach for that bottle of jack across the room to smite my sorrows. I feel like in order to write a document for someone, I would have to sit down with them for dinner so that I'd know if what I write in the next document would offend that person and they would have a hate burning like a thousand suns for me!
Hopefully the real world is not like that and the next time I give a presentation I'm greeted with cheers and not the sound of bottles smashing next to my head, telling me to get away from the podium!
Regards,
Mike
I may have jumped the gun on the last post and wrote about the wrong topic. Chapter 4 was all about people. Who are the people? Where are the people? What are do they like? Do they like me? Do they like what I'm saying?
All of these things have to be considered when writing technical documents and it such a great relief that we such a great reference book. Because if I had to remember everything there is to consider about writing for an audience, my head would explode.
Obviously, my head wouldn't explode, but I might reach for that bottle of jack across the room to smite my sorrows. I feel like in order to write a document for someone, I would have to sit down with them for dinner so that I'd know if what I write in the next document would offend that person and they would have a hate burning like a thousand suns for me!
Hopefully the real world is not like that and the next time I give a presentation I'm greeted with cheers and not the sound of bottles smashing next to my head, telling me to get away from the podium!
Regards,
Mike
Oh, Web Document Design, Chapter 7 Seems To Be The Chapter For Me!
Hello Everyone,
Chapter 7 really seems to be the chapter for me. Since the document I chose to analyze was a web document, there are just so many tips that I can apply immediately to improve the design it.
One of the suggestions that the book gives is to make a drawing of the document before creating it. For computer science and programming problems, I am constantly drawing pictures of user interfaces. Finding out that I can also extend that idea to document design is a welcomed suggestion and I will be using it.
I'm definitely going to add a FAQ section. No questions about that idea. I also read the part about introducing tabs to improve information accessibility. What if I created my own custom tab control for a web document? It seems like an incredibly striking idea.
Regards,
Mike
Chapter 7 really seems to be the chapter for me. Since the document I chose to analyze was a web document, there are just so many tips that I can apply immediately to improve the design it.
One of the suggestions that the book gives is to make a drawing of the document before creating it. For computer science and programming problems, I am constantly drawing pictures of user interfaces. Finding out that I can also extend that idea to document design is a welcomed suggestion and I will be using it.
I'm definitely going to add a FAQ section. No questions about that idea. I also read the part about introducing tabs to improve information accessibility. What if I created my own custom tab control for a web document? It seems like an incredibly striking idea.
Regards,
Mike
Wednesday, January 29, 2014
Document Chosen For Analysis and Design
Hello Everyone,
Today, I would like to tell you about the document I've chosen for the first assignment. The document is from a project of mine that I have been working on for the last three years on summer and winter breaks. The project was initially intended to help me learn how to program with the new .NET Framework technologies that Microsoft provides; more specifically C#, WPF, XAML and the MVVM Pattern.
Here is a link to the project's home page. On this page, it explains the main goal of the project and gives a short tutorial of how to use the application. It also provides a link to the current repository that I'm using on GitHib that contains all the source code used in the program.
The reason why I have chosen this document for design and analysis is so that I can improve it and provide a better service to my users. They deserve the right to good documentation. If you look at the posts in the comments section of the project's homepage, you can see the users ask questions like "How do I do X with the program". It shows that it is unclear as to how they can use the program for their own purposes.
Kind Regards,
Mike
Today, I would like to tell you about the document I've chosen for the first assignment. The document is from a project of mine that I have been working on for the last three years on summer and winter breaks. The project was initially intended to help me learn how to program with the new .NET Framework technologies that Microsoft provides; more specifically C#, WPF, XAML and the MVVM Pattern.
Here is a link to the project's home page. On this page, it explains the main goal of the project and gives a short tutorial of how to use the application. It also provides a link to the current repository that I'm using on GitHib that contains all the source code used in the program.
The reason why I have chosen this document for design and analysis is so that I can improve it and provide a better service to my users. They deserve the right to good documentation. If you look at the posts in the comments section of the project's homepage, you can see the users ask questions like "How do I do X with the program". It shows that it is unclear as to how they can use the program for their own purposes.
Kind Regards,
Mike
Subscribe to:
Posts (Atom)