We started the class with the related presentations on structured authoring and single sourcing. What these related presentations did was remind us that content needs to be managed and using these techniques allows organizations more efficiency in that management. It also reminded us of the separation of form and content and why CMSs can be useful in helping organizations produce, edit, and distribute content to multiple channels, platforms, and forms.
I was way impressed of your critique of visuals you created. You were fair and critical to both your own work and the work of others. You did a great job in pointing out that Daniel’s (*.png) was the best visually in large part because it showed the forward movement of the process, while Emily’s (*.pdf) did the best job at summary. (and it was great that Emily’s opened our initial discussion of accessibility since it is true that I was unable to really read it without doing some techno-magic to it!).
The presentations also lead is pretty easily into the discussion and debrief of the CMS analysis assignment. The ultimate goal of that assignment was for you to get experience in a number of systems and to start to understand how you can learn new systems by drawing on knowledge that you have. It’s that transfer thing that we’ve been talking–making sure you’re bringing existing knowledge to bear on current topics. It’s also building your technological literacy, which for me has always included how one approaches and learns new systems by bringing in existing knowledge from other systems. I loved the comment by Hannah that Sharepoint was pretty easy to get a handle on because it integrated and felt like other Microsoft products. That’s an important point to remember that you know things from other software/systems that can always be put to use in learning new ones.
Our summary of systems didn’t work out like I had hoped it would, but that’s ok. I somehow forgot (doh!) that as eight unique people you would find eight unique approaches! But, what I think we did end up agreeing on–summarizing if you will–was that some systems are easier than others and it’s important to match the pros/cons of the system to what you’re trying to accomplish. When Courtney pointed out that Drupal was so much more technologically advance, i.e., it seemed more for folks who really wanted to customize it, she gave us a valuable insight in that not every job/organization will require that kind of technological sophistication. When comparing that CMS to WordPress or even CQ5, there’s a wide disparity between the technological knowledge one needs to get something done. One of the other big takeaways is that sometimes you just have to be 85-90% satisfied and then move on because otherwise you can waste a lot of time trying to find the “perfect” solution, which really isn’t possible. Finally, we have to remember that the management of the content should be secondary to the content itself, which moved us into the discussion of web writing.
You had to complete a web writing exercise by taking an old *.txt file that the EPA used and making it more user friendly for people in a situation where their water has been compromised. (Think Flint, MI for a current example.) In large part, you did good on the exercise because some of the big writing and design issues were addressed in your products.
The one big takeaway to remember, though, is that it is ok to delete. New professional writers often have a problem with “letting go of the words” so this exercise is always a good one to show how the final product is actually more usable when most of the words are deleted.
From the three examples below, the most important information that should have appeared in the header is the safety of needing to disinfect the water and potentially the reminders of cooking, drinking, and brushing teeth. The rest could go. Later on, it’s probably ok to just focus on the boiling or bleach since those are the items most people have on hand.
Here are three of them that I did screen shots on (all open in a new window):
Example 1 (*.png)
Example 2 (*.png)
Example 3 (*.png)