Ah, much clearer now. My problem here was that you didn't say that you were only showing the API for a central but incomplete part of the A/B-test framework, one could say the controller interface of the MVC model. The management of tests and versions, their mapping from name to webpage, the logging (for example log_test_activity()), and all the statistical analysis is (in a strict view) part of the API too.
Just mentioning in that slide that "that is the function that selects which version of a test to show a person on the website" would provide context and make this slide so much easier to understand. That sentence may be obvious to a smal l or large part of your audience but would have helped the others to keep up (at least it would have helped me, 100% of this test group ;-). It is also not the whole truth about the routine, but its possible use in the statistics phase to map users to versions can be explained later
"don't have time to do real exercises": Do you mean test presentations or Moritz suggestion to provide examples? If the latter, you don't need *real* exercises/examples. A hypothetical example can be trivial and senseless, it is a way to ground the theory in the practical.
Look at the slide "Behind the scenes". Apart from the first sentence "This does what it says" (which has absolutely no information value at all) this slide could have been replaced with an example where you provide the same information in the context of your example.
Let's say you have (on a previous slide) given the example of a english to suaheli translation page and you want to test it with versions with green and blue background color.
----------------------------------
Peters first visit
------------------
Peter visits a page -> web server calls get_or_create_test_version(<pa
+ulsid>,'EtoS',['green','blue']);<p>
New User? [small picture of file cabinet with a arrow pointing to a '?
+'] YES.
[small picture of a dice or coin toss] -> random choice of 'green' or
+'blue'. Let's say 'green'. ->
[picture of string 'peter has green' with arrow to file cabinet ].
$version='green'
[ small picture of a green cube which looks like a webpage ]
----------------------------
Peters next visits
----------------
Peter visits a page --> web server calls get_or_create_test_version(<p
+aulsid>,'EtoS',['green','blue']);
New User? [picture of file cabinet with an arrow to string "peter has
+green"] NO.
$version = 'green'
[ small picture of a green cube which looks like a webpage ]
------------------------
Yes, this is trivial (and could be improved a lot). But this gives the same information as the replaced slide and because of the pictures and the concreteness is faster and easier to understand and remember.
I don't think that a picture on every slide is beneficial. This will distract many with questions like 'What has that picture to do with the message of this slide?', especially with long presentations. I would put pictures into introducory, title/heading/opening/closing slides (slides 0 and 47 for example) and easy/low complexity slides (slide 4). On all other slides there should be a picture only if it either:
1) contributes to the information on the page (slide 5 is a positive example), or
2) loosens up the presentation by showing a cartoon, a famous saying or a funny picture that has some relevance to this slide. This cartoon or picture must be the first thing on the slide (because it is eye-catching, everyone will read or look at it first) and you have to give the listeners time to view and possibly laugh about this picture.
Disclaimer ;-): All of this IMHO. And apart from the above I like your presentation and find it interesting, but you wanted to know about the bad not the good parts.
|