(edited to extract the key points from the main reference)
Ian Parberry's guidelines were always essential for me. Firstly I will give a personal replies to your answers and subsequently I will extract the main points of the Ian's guidelines which are the basis for my answer.
What is an effective ratio of introduction / methods / results / conclusion slides?
My own rule of thumb is to allocate 2-3 minutes per slide, which gives max. 6-8 slides including the envelope (the "title" and the "end+questions?" ones). That is, we have about 5 real content slides of which for introduction I allocate 1 for motivation&context, and 1 to problem definition.
The body gets whatever it needs, but shouldn't exceed 4 slides, with at least a single one dedicated to a sketch of a worked example. The audience doesn't need to know how exactly I am doing the magic, I must however make them trust me and see what I am doing as plausible.
The summary/conclusion/future work gets 1 slide.
How can I balance the details of research without loosing the audience on key points?
Stress the motivation, the relevance of the problem and only sketch your solution so that an example which you provide will be plausible enough.
Your talk is an advertisement for your paper. You are doing your best to assure that people learn something and you imprint some key points in their heads (the problem description and a sketch of the main idea solving it). You don't need to explain the details, just sketch the main principles. You want to compel the audience to either read your paper that day in the evening and base their own work on it (hence citations!), or ensure that sometime in the future when they will face a problem, they'll remember that there was this guy speaking about something along the same lines, so let's check it (hence possible citations!).
What makes a "great" talk?
For me, it's grounding in reality. Show me what impact your stuff has on me. Speak about an application I might care for, even if it will be only a hypothetical one. If the result cannot be framed as a machine, or software, such as a lot of (non-computational) game-theory, then speak about implications to the society. Strike whatever chord, which makes your results tangible. It all boils down to answering a single question for every single person in the audience: Why should I care?!
But even if you do the all the positive advice right, there's a more important point, namely what you shouldn't do. For example I tend to speak a lot (see my posts at this site :-) ). My main drill during preparation of a talk is to throw away everything non-essential. Moreover, I am often writing down notes about what not to say. Many otherwise great talks are ruined by the presenter speaking too much* and **showing off. I don't want to be impressed by your smartness, or charisma per se, I want you to simply educate me!
And finally the key points from the Ian Parberry's guidelines
for giving a good talk, emphasis mine.
- Communicate the Key Ideas: select 1-2 main high-level ideas and present them in a crisp and crystal clear way.
- Don’t get Bogged Down in Details: do not even attempt to discuss the details, unless you you have brisk answers to possible questions you open that way.
- Structure Your Talk & Use a Top-down Approach: go the least-surprise path, i.e, the audience needs a story a wants to be able to follow it. The structure should stay crisp: 1) solid motivation/intro, 2) main points/body, 3) technicalities, if really necessary, 4) conclusion.
- Know Your Audience: allows you to skip some common-knowledge in the audience, as well as select what is important to them and what do they care for.
Structure of the talk
I added the emphasis to the points which I consider crucial.
- Define the Problem
- Motivate the Audience
- Introduce Terminology
- Discuss Earlier Work
- Emphasize the Contributions of your Paper
- Provide a Road-map
- Abstract the Major Results
- Explain the Significance of the Results
- Sketch a Proof of the Crucial Results
- Present a Key Lemma
- Present it Carefully
- Hindsight is Clearer than Foresight
- Give Open Problems
- Indicate that your Talk is Over