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:
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:
