Monday, September 21, 2020

On doing good presentations and slides

Are there any rule for doing good slides in hydrology ?  There are plenty of resources to learn how to do nice slides for a presentation, and the material I present is just a summary of ideas I copied from others I cite plus a few from myself. 

What is a presentation for ? 

Really there are different situations to cope with. You can be at a scientific conference (usual time 12 minutes plus discussion), you have to present for an examination or to get your graduation (time depending of which one, from few minutes to 45 minutes plus discussion). Each one of the occasions is different and your contents have to be tailored to it.
As Academia StackExchange writes, you have to answer a few questions:
Who is my audience? What is their prior knowledge? Why are they there and what are their motivations for attending/reading? What do they want to take away from you provide them with?
What is my own motivation? Do I want to teach them something new? Do I want to illustrate how smart I am? Do I want to give an overview of a field that everyone in the audience should understand, or do I want to impress a few key people?
After having answered those, you can start. There are some general rules of thumb though:
  • Put your  audience at the center
  • A presentation is not a paper (even if it can share it overall structure)
  • Do not overwhelm the audience (with data, formulas, concepts)
  • Tell your story
  • evoke questions
  • encourage people to learn more about your work
Milka Kostic says about a conference presentation: "Now that you know what I don't want to do, here is what I would like you to do for me. The type of scientific talk that I want to hear from you is a talk that takes me by the hand and gently leads me through a single, yet interesting, idea. You shouldn't assume that I find your idea to be interesting, so help me appreciate the wonder that motivated you to go after that one idea, and let me feel the delight that you must have felt when you made your discovery. I also want to see the genuine pleasure that you feel being in front of me and having this opportunity to guide me through your work.
A starting point in your process of stepping away from the PowerPoint precipice I can recommend is some cool advice from David J.P. Phillips. In his entertaining and informative TEDx Talk, David shares five design principles that will cognitively and psychologically optimize your PowerPoint slides. These design principles are:
  • One message per slide
  • Use slides as props for you to deliver your message, not the other way round
  • The most important part of your slide should be the biggest
  • Use contrast to focus the viewer's attention and a black slide background
  • No more than six objects per slide “ (My note: I use at most three and standardize some places where people know where to find lateral or further information)

Personally blessing Open Science, I also add some further attentions:

It is quite obvious that my rules are “complementary” ones and you ca have a nice presentation even without them. An initial summary is not necessary if you are able to respect the timing. A written sequence of standard rules can be found here.  Many of them are about planning you presentation (assuming you have something to convey). All presentation advisors agree that there are a few general action to take (almost all of this is taken from the cited reference):

Planning the contents

"you find that your research has two or three broad research subjects, then plan to give separate presentations that allow time to develop and discuss the issues surrounding each subject.”  This is a good rule, especially if you are presenting in a Conference. Maybe you can give more than one presentation, if the conferences’ rule allow it.  The case is different if you are preparing lecture talks where you have room for more than one argument. In the latter case, however, you cannot pretend your audience stay awake longer that 25 minutes or so and, therefore, splitting your teaching in parts could be advisable. Obviously the masters can violate the rules: but do not assume too much for your case. 

"The best presentations generally follow the guidelines of a published paper, with sections like Introduction, Methods, Results, and Discussion/Conclusions/Significance. However, you will have only a couple of minutes per section, or a few sentences on a poster, so you might have to run through that 25-words- or- less exercise for each part of your presentation. For each section, ask yourself, “What is my central message?”  Personally I think that the above scheme has to be followed at the initial implementation, in a second phase, the real restriction is the time you have, and you probably have to decide to cut parts, shortening some, and increasing the more important ones.

Planning the graphics

Actually I often start from the graphics, since a presentation is a visual fact. There are a few aspects that regards graphics. 
  • One is the design of the layout of your slides. I prefer simplicity over complicate layouts. As already said, no more than three objects in a slide. I usually have two bands, at top and bottom, and usually a white core. On the to band I put the title of the slides or a phrase that helps to connect it to others, or sometimes, a joke or a comment. On the bottom I put the mane of the slides’s Authors, the copyright (in my case creative commons) to let know the people that the can reuse my slides, following some rules (not sure that people respect it). 
  • The other is the graphics, plots, drawings, that contains scientific messages. These graphics have to be self-explanatory, clear, with fonts larger than those on papers (if possible). For other informations of figures in scientific writing see, for instance, here
 Myself, I usually first  put the graphics which represent the core of the research (if applicable) and then I build the narrative around.  

More technical instructions (all robbed form the reference above)
  • Use very few words. We recommend no more than six lines of type per slide, with at most seven words per line. Try translating statements into bullet statements or an outline. Keep the wording tight; use simple language, minimal jargon terminology, and short, uncomplicated sentences. Even removing small words can make a big difference (e.g., say “assay results” rather than “results of assays”). Remember that you will also be speaking to your audience. These slides are visual support of what you are saying, not a substitute for your oral presentation.
  • Choose the right font. Use a typeface that is easy to read, such as Times New Roman, Arial or Courier. If you are a Macintosh user avoid fonts that do not go across platforms, such as Helvetica. Studies show that text written in all capital letters is hard to follow; it is better to use bold print than all caps. Use the same typeface throughout your presentation. We recommend using 1.5 spacing so that the lines are easier to follow. Then use a font that is about as large as the slide will accommodate, for example title lines size 44, major text 32, and minor text 24.
  • Choose the right color(s), keeping in mind that 1/8 of your audience is color blind, on average. We recommend using contrasting colors, light type on a dark background or vice versa, like white on cobalt blue, or dark green on a pale yellow. Avoid red type - it looks good on your computer but is virtually impossible to read off of the slide screen. And at all costs avoid bright yellow as a background, it is blinding for everyone.

Prepare your oral

An oral presentation is a performance where, willing or not, you are acting. If the material you are presenting is, and remain, the more important thing, it is also important you posture, how you use your voice, how you are able to manage  and keep the attention by interleaving the presentation contents with “soft” comments that help to maintain the attention, creating suspence and interest. I do not know If I have all of these qualities, but I am certainly aware that I have to work of that side. 

This website suggests that you have to convey your excitement about what you are doing and the research you are pursuing. There is a point here: if you aren’t, why you are doing it ? Other interesting suggestions at the link.
Often, it is said that focusing on what you want want to say, instead of what the audience is interested in hearing is a pitfall. However, you do not have to misunderstand this message: the audience wants to hear about your research. "Tell them  “One of the most common mistakes I see in people giving presentations is that they present only information I already know. This usually happens when they spend nearly all of the presentation going over the existing literature and giving background information on their particular case. You need only to discuss the literature with which you are directly engaging and contributing. Your background information should only include what is absolutely necessary. If you are giving a 15-minute presentation, by the 6th minute, you need to be discussing your data or case study. At conferences, people are there to learn about your new and exciting research, not to hear a summary of old work."

A useful summary of rules and attitude can be found here. As it happen, while the content of the slides is really OK, the realisation is quite questionable ! Do not do slides like those (try to list three “principle” those slides violate).
Finally "presentations often include interactions in the dorm of questions and answers. This is a great opportunity to provide whatever additional information the audience desires. For fear of omitting something important, most speakers try to say too much in their presentations. A better approach is to be selective in the presentation itself and to allow enough time for questions and answers and, of course, to prepare well by anticipating the questions the audience might have.

A last topic

The last topic I want to cover is the presence of equations in your slides. I found on Academia Stack Exchange the following that I share:
"I teach in a mathematical field (statistics) and I always encourage my students to minimise equations in their presentations, and never present equations that they are not going to go through and explain clearly to the audience. Sometimes basic equations showing your model form are useful, but sometimes you can give an explanation without the aid of mathematics. In any case, you should only show equations if they assist the audience in understanding your work, and if you are willing to take time in your presentation to go through each equation and explain it.
Including mathematical equations in a presentation solely to "show the complexity of the research" (i.e., show off) is academic masturbation. It bamboozles the audience for the purpose of aggrandising the speaker. Don't do it --- push back on their suggestion to the contrary.”
I have to say that sometimes I did it (maybe was an overreactions) with the intention to contrast the idea that my discipline was sliding to much towards a descriptive aptitude that I see as a betray of its core based on physics. I strongly believe that equations are necessary, but they are a highly specialized compressed form to represent physical reality and explaining them requires a lot of time and, probably requires different technicalities with respect, to the more general scientific discourse. Therefore I encourage you to be aware that when you put an equation you have to meditate about it. As Bill Dietrich once said to me: one equation and you loose one reader (was referred to papers), one graphic and you gain one.

Convey the meaning of equations and their treatment in slides requires another post, I guess.

Other websites and references:

Tuesday, September 15, 2020

DevOps - Or about streamlining what is needed to do modelling carpentry

This morning I learnt a new word: DevOps, which seems to be the contraction of software Development and IT Operations. got it from the presentation my former student Daniele Dalla Torre gave at the Biennial iEMMs 2020 conference (find his presentation and others about his work here). He captured my attention with the following picture you find below

Wikipedia comes to help in understanding what exactly this means by listing the following items:

  1. Coding – code development and review, source code management tools, code merging.
  2. Building – continuous integration tools, build status.
  3. Testing – continuous testing tools that provide quick and timely feedback on business risks.
  4. Packaging – artifact repository, application pre-deployment staging.
  5. Releasing – change management, release approvals, release automation.
  6. Configuring – infrastructure configuration and management, infrastructure as code tools.
  7. Monitoring – applications performance monitoring, end-user experience.

The figure contains some further information by annotating some tools. Also note that he intelligently added "Plan". So the steps are actually 8, not 7. Planning in his figure is under the OSF , the Open Science Framework, the place where we upload the material of our projects, literature, thinking. Some other colleagues use Slack for this, but on the latter I do not have much experience. Certainly a place where all the material regarding a project and the interactions among people is preserved is necessary. In Coding he puts Git. Github is the public repository where all of our software is uploaded. Git is a "Control Version System" (CVS), a place where  researchers upload the versions and modification of their software, maintaining. Ghere exist other, like, for instance, Mercurial, but we use Git.  There is actually a misuse of Git among my students. While it is thought to be used continuously along the process of development, they use it only at the end of the process, to upload a reasonable version of their work. I think it does not exploit the good of a CVS but that is the state-of-art at the moment. When you have written your software (in contemporary practice is quite obvious that you used a IDE for doing it - Eclipse, Netbeans or IntelliJ in our case) you have to build your software, which means, compiling and assembling it in some executable.  Naive and simple building is made inside the IDEs but complex software building needs a builder. Our chain of tools uses Gradle, whose symbol is a small elephant. In turn, Gradle means learning a further DSL language, for making the build. Testing means two things: preparing tests for assessing the correctness of the code and running the tests. Also this practice is not so common in scientific practice. One reason is that our models usually have complex outputs which is difficult to characterize but this happens mostly because hydrologists are ignorant of good software building practice. For instance, in the Figure is mentioned JUNIT 5 which is quite a natural choice for who is working with Java. If the software pass its tests, it is supposed to be packaged in a releaseTravis CI symbolized by the a mustachioed face should do this pass. In fact, I believe it does only part of the job, which goes back to run the test and providing a final compiled version of the code. Actually this sort of packaging is not completely operational, since the software can be eventually brought to a computer and installed in it with the right switch for working. Docker  (the whale in Deploy) simplify it by providing a standard client to any computer (with some problem for MS Windows, indeed). It works fine in my Mac Computer, and calling it from within Jupyter lab notebooks provides a nice solution. However, I feel the problem of the distribution of the software (through a tool like Anaconda's conda can be)  and treating all the dependencies among the libraries, is still an open question.  Configurations and maintenance of the code and the details of configurations of the software is the further step. 

Finally comes the application performance management (APM) is the monitoring and management of performance and availability of software applications. APM strives to detect and diagnose complex application performance problems to maintain an expected level of service. APM is "the translation of IT metrics into business meaning ([i.e.] value)." This latter maybe is not so central in scientific applications for which other types of tests, screening and case studies are probably more relevant. 

Monday, September 14, 2020

iEMSs 2020 In Brussels but mostly on-line

 iEMSs stands for international Modelling and Software Society. Every two years, on the even years,  the Society has its own conference which was held, so far, once in Europe and once in North America. iEMS is home of very interesting information regarding Modelling and Software in Hydrology and Water Resources. Due to Covid-SARS-2 (a.k.a. as Covid-19) this year conference in completely online. You can access it at

At the website you will find the schedules structures per day -> per room -> convening block/session. Timing is given in CEST (Brussels local time).

In the CVENT app, the presentations are organized according to submission sessions. The timing is adjusted to your own local time. You have received installation instructions in your mailbox.
You can also access the CVENT programme via the web version for your PC/laptop

We have been shifting abstracts between sessions, especially for the abstracts that were submitted within the A0…F0 sessions, but also to take into account differences in time zones of presenters. But at the end of the road both tools should lead you to the same schedule. So in either way you should find your way to the right room at the right timing. To start, I hope to see you all during the Opening Ceremony at 14:00 Brussels time!
The password to access the ZOOM room is iEMSs2020
The sessions will be recorded and will be available to all in case you miss an important session.
You can obtain documents and video recordings of the presentations from the Moodle platform of Open Water Network: by logging in at Your username is your ‘email address’ (all small letters) and your password is iEMSs2020.