What's considered a good blog? We have trainings that we can do and write about, but there's not really much to offer since they're pretty straightforward.
What's considered a good blog? We have trainings that we can do and write about, but there's not really much to offer since they're pretty straightforward.
Hi!
Everyone will have different ideas, but here are some random suggestions, feel free to override with your instinct or any other advice you get from others. I think the ideas here will at least get you started, or spark some ideas hopefully!
Type of Content
Personally I like reading blogs when people have something to say (rather than just a photo or two and little text). Hopefully leave readers informed and if possible delighted.
Definitely check the competition page and any rules regarding what you're supposed to write and focus on. I have not checked, but if it is flexible on what you write then I suppose it could be stuff like what you learned in the training. For instance, if the training explained how memory is connected to the processor, then you could write explaining what memory resources are inside the device, and show screenshots of how memory gets connected, and what it could be used for (for instance, explain if the memory inside the device is sufficient for Linux or other operating systems, what features work with it. Maybe even how you would test the memory to ensure that it is connected properly and so on. I think the training just shows the steps, but doesn't really discuss the benefits or reasons why you'd want to do certain things, so that could be an opportunity for the blogs, if that is in alignment with the competition rules. Also, it's not always worth automatically assuming people know what Zync is or what FPGAs are and so on. I'm not suggesting going to first principles for everything, but sometimes a sentence or two to discuss the basics before going into more detail can help.
Contents
The contents can be auto-generated using the Contents option in the Editor toolbar, provided your content uses headings.
Good title
Maybe also use a sub-title, for instance with a colon separator. For example "Getting started with FPGAs: Installing Software and creating a Blinking LED", so that readers are already becoming aware what the blog will be about, without even reading the introduction.
Preamble/Abstract
Some people (see some blogs by Jan Cumps ) write a short boxed piece of content. I wish the editor tools would automatically do this sort of thing, but instead it is up to the user to create this if desired.
Introduction
A few paragraphs indicating what the blog post is about, and some of the key points that will be explained in the blog.
Main body
Use simple language. Use abbreviations only after they are used fully expanded, because not everyone knows what the abbreviations mean (unless it's an extremely obvious abbreviation such as i.e. or AM or PM or etc.).
Sections
Occasionally have sections with simple questions,such as "What is an FPGA?".
It's good if sections can stand on their own (this isn't always possible) so people can skip parts or read things out-of-sequence if desired.
Diagrams
Always worth explaining things in a diagram if possible! It makes it easier for readers.
Charts
Charts can be nicer for seeing large amounts of data, rather than large tables.
Photos
Ideally non-blurry. And ideally at least a few. One could show the whole project, and the remainder could show focussed detail.
Code
Consider inline code (using the Editor toolbar) for a few lines of code. Consider using the code tool, or GitHub, for longer code. Zip files are irritating (although they might end up necessary for some things), since users need to download and extract just to browse code, and it's not always easy (especially on mobile).
Videos
Short to-the-point videos perhaps. Personally I like those where the presenter doesn't talk for long! Time is short : )
Hyperlinks
Blogs are not printed documents, and any references can be within the content, instead of at the end of the blog (where it then lacks context). Hyperlink text should relate to the thing that you're linking to, i.e. a good hyperlink in a sentence could be "For this project, VHDL was used", rather than "For this project, VHDL was used. Click here for information on VHDL". The text "here" isn't a good thing to hyperlink.
Summary
This is an opportunity to re-iterate the reason for the blog and the findings, ideally in slightly different sentences, so that if readers didn't understand it the first time, they may understand the summary. You could suggest next steps, and any suggestions for exploring further could be good here.
Spelling/Grammar
There are free tools like Grammarly, that can be installed in (say) Chrome Browser, and will provide advice within the text editor.
Editor Tools
It's definitely worth exploring the editor tools. This diagram is old, but you can get an idea about the sort of things that are available in the editor from this diag:
I believe there's one missing here that's worth highlighting:
Your opinion.
It can be very easy to be pulled into simply posting technical documentation, manuals, specifications, clinical results.
It's very easy to miss and overlook your opinion on what you're doing, why it was done that way, what your methodology was, how you were feeling when you were doing it, how you feel now that it's completed.
Expressing these are also important alongside the rest of the factual data, else every blog will definitely look like a cookie cutter copy and paste. There should be an aspect of your personality expressed within the blog, as these aren't strictly whitepaper journal articles.
Great and very good indications of shabaz and cstanton
It is also recommended to read randal's suggestions in the following thread:
Tips on Writing the Final Summary Blog and Winning the Big Prizes - element14 Community
Brief summary: A blog should be an enjoyable read and should tell a story.
It is very difficult, even so in the elment14 community there are great masters telling stories.
All suggestions below are great tips.
Here's my take on blog writing for Path to Programmable 3.
I see blogs could cover these themes:
You can earn up to 40 points per blog. Something that is more complex or is substantive such that it can help other people will get more points than simply a general update (e.g., I received my kit blog)
Randall
--element14 Team
You can earn up to 40 points per blog
I think it'd be best if we said a minimum of 40 points per blog at our discretion, what if someone feels they're having to hold back?
cstanton I just was curious about this, so asking here. I see that some of the blogs with a solid effort on the contents are getting 40, same as other blogs with a minimal amount of effort with some photos and general information. Do you have any kind of rubric on how you are distributing points for a blog?
<layman's perspective>
To me it seems no-one likes seeing blogs that are just filler blogs (i.e. blogs with no real content, just padding to try to get points without much benefit to readers). Us blog readers are not blind, we can see when we are being short-changed when it comes to reading a blog, so contestants are only losing out themselves by gaming the system by writing minimal content. Just keep in mind that blogs should help people, not be filler stuff.
For what the interim blogs could contain, Randall mentioned that in a comment earlier. And keep it helpful/interesting if possible. I think generally if a blog author, design challenge or not, has got something to say in a blog, then just say it, i.e. keep it authentic/real. People see through fake stuff!
On the other hand, if people write filler blogs with no useful content, then sure they might get some points, but I wonder what they will do when it comes to writing any longer final blog, which carries quite a lot of points. They will have no decent interim blogs to help them, if all they have is filler content.
To me it seems that anyone who wrote reasonable, authentic content throughout, will have a lot less work to do to collect their thoughts and summarize and present their key bits of info.
So, if two people both get the same score of 40 for their interim blog, nevertheless, the person who wrote more authentic and useful content, will benefit, because they will find it much easier to write the final blog and score highly with it.
Also, I can imagine it puts less pressure on you during the Design Challenge, because if you end up thinking you need to write a ton of content for an interim blog, then you might not spend much time actually doing lots of engineering work for the project. It's a balance.
In the past, some Design Challenges needed 10 blogs, and that seems like a lot of pressure throughout. I think if you try to think about point-scoring too much during the challenge, it's not good for you, and not good for the challenge, and not good for the readers. It's like going back to 10 lengthy blogs in that case. I bet you'll do better by simply keeping it authentic/helpful and don't stress yourself out either.
You'll then be in a great position to write with clarity about all the work and findings in the final blog.
</layman's perspective>
element14 blogs are public, anyone can access them and although there is a certain anonymity think that future employers, or department heads or even your children as is my case will be able to read them and you will want to be proud of your job.
My recommendation is not to think about the competition but to focus on learning and telling what you have learned and above all enjoy the training.
I think the important thing is that your blog has meaning and serves as a help to you and to the other participants beyond being too long or too deep.
Seeing that practically all the blogs have the maximum punctuation I think is very good to generate a good atmosphere in the training. I am comfortable with that.
Do you have any kind of rubric on how you are distributing points for a blog?
I'm not the person marking them.
However you can pull together an answer to this from these places:
Tips on Writing the Final Summary Blog and Winning the Big Prizes
Semi-related with good advice:
How To Write A RoadTest Review
And let's throw in some SEO advice from Google:
https://developers.google.com/search/docs/fundamentals/creating-helpful-content