Archive for June 2020
Connecting Through Video – How To Engage Customers
Last month I talked about how easy it is to work from home, but to work from home effectively is hard. Likewise, making a video can be easy, but *really connecting* with your audience via video is hard. This is especially true for business videos. There is so much content that it is easy for people to glaze over your video and click away!At SSW we put a lot of effort into working out the best way to make business and technical videos. It’s been a super enjoyable journey and I’ve been learning and growing SSW TV for 11 years.
So how do you *really connect* with your viewers?
Tips:
#1. Quality: since the whole world is making videos now, not just the professionals, the only way to counter this massive increase in quantity, is to make *quality*. Today there is a tremendous range, from very poor, up to excellent quality. It is incredible to see some awesome quality unboxing videos, verses some shockingly poor business videos which can do a disservice to a company.
#2. Keep it light & consumable: many of us are reading news via social media, than from traditional sources. This means that unless you make a video that your friends are likely to share, no one will see it. BTW Australia is particularly susceptible to this problem, as we are one of the ‘leading’ countries in the world who consume their news mostly via social media.
Figure: Look at Australia, almost half (48%) of Australians read their news via light sources e.g. social media, so you can conclude that it is pretty important to make a video that is engaging and therefore shareable… and don’t make it too heavy obviously!Source: Digital News Report: Australia 2019
#3. Size matters: we are seeing the growth of multiple versions of each video – the 1 min version + the 10 min version for different contexts. You can use the 1 minute version for Twitter, and the 10 minute version for Facebook. See the example below of how an SSW TV NDC presentation that is 10 minutes long, can be trimmed to a 1 minute version that is more Twitter friendly.
#4. The script: it’s the same as building software, if you don’t plan, you plan to fail. Good storytelling comes from a good script. Once you have a good script, you can then focus on giving an excellent delivery.
#5. The editing: again it’s the same as software, if it’s a busy UI, it feels unfriendly. If it’s a complicated video, it is non engaging. Editors can help with this by following Richard Mayer’s “Multimedia principles,” and tighten up the video to make it more effective. E.g. People learn better when extraneous words, pictures and sounds are excluded rather than included. https://mylove4learning.com/richard-mayer-on-multimedia-learning/
#6. The cinematography: the importance of good lighting, framing, composition and sound cannot be overstated. The camera and the crew should disappear so that the only thing the viewers are focused on is the content.
#7. The Intro: getting the first 7 seconds right is critical, and the person who says it best is Geoff Anderson…
If you want to capture the attention of your audience with your video, you need to do it in the first fifteen seconds or less. People will visit a website for up to 7 seconds before deciding if they’ll hang around to find out more. Video can hold them for a bit longer – but not much longer. There’s a click happy finger out there looking for a reason to find a new video to watch. All of your video needs to be engaging but the first few seconds are critical. It needs to set the tone, show the style and cut to the chase.
Chapter 1, Geoff Anderson “Shoot me now: making videos to boost business” https://geoffanderson.com.au/shoot-me-now/
To see the above tips in action:
[embedded content]
Video: An example of a corporate video showing the team members in a great light. These team members are not actors, but with good direction, they come across as authentic and captivating. This video gets a lot of information across in a small amount of time. Most successful corporate videos are made by sitting down with the stakeholders and crafting a good script.
Our SSW TV team make awesome videos so get in touch if you’d like some help. We have guys on the ground in Sydney, Melbourne and Brisbane: https://www.ssw.com.au/ssw/Consulting/Video-Production
Ulysses Maclaren
Bonus – Interviewing Experts
Figure: Connecting with the interviewee and moving into the interview content without stating the interview has started – have a giggle.
#8. Warm up your subject: one type of video we really like to do at SSW is interviews, in person or remote. Even before lock-down we were recording people from all over that world. The lessons learnt there have been valuable, and apply to the current situation we all find ourselves in.Just like real life we analyse and understand people’s feelings and emotions through their body language. The aim of a good interviewer should be to make the interviewee feel as comfortable as possible; any signs of discomfort are visible through facial expressions and a person’s engagement (or lack of engagement).To make someone comfortable, have a light-hearted conversation with the interviewee and really connect with them. To do this, do not state the start point of an interview. Discuss normal conversational topics with the interviewee, and naturally start asking questions that relate to the interview. The aim is for the interviewee to not notice that the interview has even started. You’ll be amazed at how much of a difference this makes!
#9. Introduce the interviewee yourself: it’s more thoughtful to introduce someone yourself, and not to rely on the interviewee to explain who they are. You should know your subject, and give them a nice warm welcome. It’s not natural for someone to sprout their own biography (outside of a presentation), see Joe Rogan’s introduction for his guests.Bad Example:Interviewer: “Hello and welcome to the show, I have here Jason. Jason, please tell me about yourself.”Good Example:Interviewer: “Hello and welcome to the show, today we have Jason Taylor. Jason is one of the people who basically wrote the book on Clean Architecture and is currently doing many rounds of presenting all over the world, most recently at NDC. He is soon to release a new book which I have here, and it is awesome. Hello Jason welcome to the show.”
[embedded content]
Video: Here is an example of Marlon doing a nice intro of John Sonmez (from 0:20).
Summary
I hope these tips help you make better videos, and if you would like to know more you can read SSW’s Rules to Better Videos: https://rules.ssw.com.au/rules-to-better-video-recording
Hardcoding. Have your cake and eat it
2020-06-01CODING ·SOLID Principles
One of the core principles of software that is drummed into new developers is ‘Don’t Hardcode anything’. What if I told you that it’s OK to hardcode things? What if I told you that in some circumstances hardcoding is the RIGHT way to proceed?.As a junior developer, one of the key principles that were drummed into me was that hardcoding values is a BAD thing (amongst many other principles). But then more often than not, the pressures of deadlines, project managers and product owners don’t afford us the luxury of building an engineered solution the first time around. So we revert to simply hardcoding just to keep everyone happy and deliver a feature. What no one ever mentions is that there are two ways to hardcode values: the RIGHT way and the WRONG way.
I’ve seen developers new in their career, and even some more experienced fall for this trap. This scenario can play out in many different ways, perhaps it’s a Proof of Concept that “will just get thrown away”. Between you and me, rarely is code simply throw away, I’ve heard of too many POC’s that find their way into production.
Put simply, If somethings worth doing its worth doing right. Now, I’m not advocating wasting time implementing an over-engineered solution to prove a concept, or when time constraints (and PMs) don’t allow. What I am saying though is that when done correctly, we can have our cake and eat it too.
The WRONG way
Consider the following scenario: A junior developer has been tasked to implement a shipping cost calculator. Because of the time constraints, and the small target market the Product Owner is insisting that that solution must be simple, and hardcoding is fine, because “we can throw it away and do it properly when we have time”.
Being a junior, and somewhat naive developer they go ahead and implement the solution as follows:
public class ShippingService
{
//As per requirements from Product Owner, Hardcoding countries here, as
//These won’t change anytime soon, and we don’t have time to create a new database,
//and service and the added maintenance overhead.
public Dictionary countries = new Dictionary
{
{“au”,15M},
{“us”, 10M}
};
public decimal CalculateShipping(string country)
{
if (countries.TryGetValue(country.ToLower(), out var cost))
{
return cost;
}
throw new Exception(“Country not implemented yet”);
}
}
Clearly, the developer knows this isn’t the right thing to do, so they spent more time writing a comment justifying their actions… Now, what they don’t realise is that: a. The sales team has sold this feature to another 10 regions b. The Product Owner has identified another 10 different usages for country data, and not all of them are in the shipping service. Oh, and they’ll only tell you about them 1 at a time, over the next few months, to not overwhelm you. c. The backlog is so jam-packed there won’t be any time to go back and refactor any of the Country data anytime soon. Especially when the countries dictionary is so heavily utilised.
The RIGHT way
Luckily a more seasoned developer has had a chance to review the pull-request and offers the following solution:
public class Country
{
public string Name {get;set;}
public decimal ShippingRate {get;set;}
}
public interface ICountryData
{
Country GetCountryByCode(string code);
}
public class CountryData: ICountryData
{
//Hardcoded for now, Ideally provided by database
public Dictionary countries = new Dictionary
{
{“au”,new Country{Name = “Australia”, ShippingRate=15M}},
{“us”,new Country{Name = “United States”, ShippingRate=10M}}
};
public Country GetCountryByCode(string code)
{
if (countries.TryGetValue(code, out var country))
{
return country;
}
return null;
}
}
public class ShippingService
{
private ICountryData _countryData;
public ShippingService(ICountryData countryData)
{
_countryData = countryData;
}
public decimal CalculateShipping(string country)
{
var result = _countryData.GetCountryByCode(country);
if (result == null)
{
return result.ShippingRate;
}
throw new Exception(“Country not implemented yet”);
}
}
Notice that this extra work doesn’t cost much more to write. It doesn’t avoid the hardcoding. It doesn’t worry about databases or external dependencies. It just does the job, in a more ideal way.
Why is this a better solution
Adhering more closely to the SOLID principles we are working toward a more complete solution, as opposed to just solving today’s problem.
We are adhering to the Single Responsibility Principle, whereby the Shipping service isn’t concerned about the storage of country data.
We use the Interface Segregation Principle, along with Dependency Inversion Principle for the ‘ICountryData’ so that at any point in the future (when the budget allows) replacing the implementation won’t affect any of the calling code.
Importantly, the ICountryData interface, and even the Country class, aren’t fully defined just yet. That’s OK. No doubt these contracts will grow and evolve as the system grows. At least now we have somewhere to add this information.
Conclusion
When used in this fashion, hardcoding data can aid in the rapid prototyping of very complex systems. Instead of spending time and effort working on complex algorithms, and storage mechanisms etc, we should be looking to abstract out the complexity behind an interface and hardcode the simplest results. This way, we can move on with the rest of the system, without being blocked by some complexity that is not part of our immediate concern. Kick the can down the road, so to speak.