This page originally came out of a need to break up a long version of "How to Shoot Dance" into chapters around subjects. I felt it would make the lessons and examples easier to digest, easier to update and easier to add sections. Then I added a few extras and longer form examples.
As I was doing that I felt it this page would be a good place to make a code example for lightweight code. So, I start with division boxes, each having a number of links to the video at top. I finish with two section of text talking about coding. And
Editing Multiple Cameras
Composer: Mood & Motion
Framing Rules for Dance
Shooting in the Music
Cutting on the Count
Shooting Video for Live Stage
Camera on the Sight Line
Hand Writing, Embodied Learning
Prologue to Dance Photography
(The Special Expertise Needed)
Rehearsals, Embodied practice
Getting (it) Across
Promos: Montage and Sampler
Close and Wide, Camera as Partner
Notation and Recording
Tap Jam, Arts Bar 2014
Setting Up an Interview Show
You Need Dance Lessons
Speed of Sound and Synch
How Eyes & Cameras See
"Persistence of Vision" (not)
Real motion detection is in the brain,
not the retina - or "The mis-education
of generations of film students."
24 fps The Real History
The result of engineering decisions,
not any aesthetic decisions, none.
What production is not multiple?
Invention of a new term (1966)
for very old practices.
Representing & Shooting Dance
(full length, 2hrs, all chapters)
Ballets of Antony Tudor
Doc, 59-min intro to
the Tudor curriculum
for the Tudor Foundation
"Why White Men Can't Dance"
(Mockumentary by Phil Cacioppo,
writer, director, producer, actor)
Most video is by me.
2012 Tour of Bolender Center and the Ballet Ball
The new home (2011) of KC Ballet, with doors opened by Executive Director Jeff Bentley, and William Whitener (then Artistic Director) as the company dances through Bolender for the Ballet Guild's Ballet Ball on 12 March 2012.
Behind the Scenes: New Dance Partners 2022
Starting with a rapid slide show this moves to interwoven videos of each company as they move through rehearsals in locations, to in theater to excerpts of performance, each sequence begining with drone footage for each off-site rehearsal location.
Dance On with Billie Mahoney (Sampler)
Billie Mahoney started her Dance On program in 1981 in New York City recording more than 300 programs. She re-started the program in April 2011 with myself (Mike Strong) providing cameras, shooting, editing and other equipment. The program is aired (cable broadcast) weekly on Time Warner in Kansas City (Channel 17, I think, the Arts Channel). Although it is 1-hour 14-minutes this is only a tiny sampling of some of the many bits and many guests across the 2011 through 2015 period. Except where noted the added video and stills are by me. Some are contributed by those interviewed. At the start I include my own setup routine at Kansas City Ballet's Bolender Center's conference room.
Note 1: more links to more chapters (about 35 in all) will be added in the future as I break down the video into
component parts, some of which I will edit and add to.
To see the entire 2-hour video, go to the link in the Bonus section below.
Note 2: I say this maybe once in all the chapters, so just to make sure you don't miss it, I've never known any shooter to deliberately do a lousy job, but I've seen a lot of shooters with no exposure to dance at the knowledge level I'm talking about. While this is not easy, the usual reason shooting is painful is because you don't know how to shoot a particular subject. This is a hopeful attempt to fill in knowledge and to get shooters into dance lessons. (brief aside: My grandfather was a dentist and when he and my grandmother met people they saw teeth. My step dad had a glass shop and he would always look at windows, the glass and the mountings. A guy who made the cabinets in our house, would always, always look at our cabinets each time he came over. Shooters see cameras, framing, editing, unless they know the subject. Anybody can look, but what you "see" is a matter of what you know. In turn, what you know depends on what you do or have done.)
Note 3: This page is designed to be run anywhere so you can download it to a local disk and it will still run.
First Version (prototyping stage) - created and hand coded entirely in the text editor Notepad writing code from scratch. The video is both example and teaching for dance photography and videography as a specialty which is more intricate and demanding of expertise than most other photography. It is deliberately plain rather than decorated. That can always be added, once it functions properly.
In that spirit, this page, is intended as an example of lightweight code (16 kb, original - 34 kb with added text explanation below) avoiding massive libraries, such as JQuery. You can see this page's code by right clicking and choosing "view source " or use the browser menu to get to "View Source".
I've also written in the full style sheet rather than linking to the stylesheet file, so that you can see the styles applied. I normally link to my 3 kb style sheet (also hand coded by me), which is my best practice. Here I leave that stylesheet link in the file, commented out between <-- and --> so that it isn't called, but remains visible in the file as an example.
While I normally use a link element to bring in a style sheet, allowing me to change just the style sheet when I want to change the look in all my pages which pull in the CSS file, here I've included my style sheet so that you can see it. It is far more compact than almost any CSS file you can see on most pages, I could slim it down a good deal to be more efficient but figured this is typical, so I left it.
This was adapted in January 2022 from a simpler version (the original) that I wrote for Jennifer Tierney in 2018 to show her ballet curriculum for small children to her ballet teachers, using local mp4 files from a USB, CD or personal-computer hard drive. You can see that original page in this link from my resume site:
On this page, I've retained code, as examples, for parts of two earlier versions,
(1) the original with local links to the original local mp4 file ballet lessons and
(2) the second [1st adaptation] with hard-coded Vimeo links going to the photo lessons.
You will find those parts in commented out sections <!-- and --> You can only see those using "View Source." to see the code changes from local files to hard web links to the data-array links used in this page.
You might also note that I've used the deprecated <font> tag and bold and italic tags. Three reasons, 1) to show the "tag" :-)), 2) all browsers still have to render these tags or lose billions of older pages and 3) these are usually much shorter than their updated, hipper, "superior" inline-style versions (just sayin', clever and cool have often turned into a massively worse version of the old thing they were meant to improve - especially css, divs and spans - of which divs and spans I've really come to hate).
I am pulling out each of the chapters in the 2-hour version number 32 of "Representing Dance," as separate, short videos intended to be informative and educational. Eventually there will be close to 30 chapter links in the boxes above.
You can see the full 2-hour video by clicking the link for Representing Dance in the Bonus box at the bottom.
When done I intend to reassemble the parts in a changed order with a few updates for a new 2-hour piece.
This provides a very straight forward example of my programming, my photography and my videography as a clean functional page for resumé purposes.
As stated above, I've kept this page plain, only slightly decorated. The reason is that I want to emphasize making sure the page, any page, functions first. Once that is solid you can add all kinds of fun stuff with little worry about introducing errors. Development is actually a lot faster this way with less debugging and fewer repairs.
As much as it seems a losing battle to slim down and simplify code, I feel strongly that this is needed to
1) increase delivery speed to every device on the internet, connected through the web and
2) fit on every device without strain. Those two items alone make it easier to get digital access to everyone.
I commonly code-strip pages, sometimes just to make the point (and once in a while to get around a paywall), and usually wind up with pages with content size being anywhere from 40 to 100 times less than the code in the downloaded file, most of which is either unused code, i.e. never called, just-in-case-someone-wants-it functions or is code calling other files which total to as much as several hundred times the size of the actual delivered content. This is a tremendous waste of energy (data charges, electricity, yes, even global warming).
A simple structure allows better access to everyone, including screen readers. Those who are blind can expect that their screen readers will not be thrown off by the overcoded bells and whistles and outside reference calls to other files used to assemble the final page.
Learning to handle the simple code demonstrated here should be, I would hope, a way to demostrate the satisfaction of being able to handle HTML code without leaning on a top-heavy CMS method. In my class years ago at PACE called "Web Writing" my first objective was to get students to hand code a working, functional page, one they could control with just a few devices, the basic HTML tags and some very basic CSS style sheet code.
It always lead to a surprised delight at being able to exercise control from "under the hood," and helped to get over "fear of coding." Figuring out the intricacies of each CMS's options and controls is far more effort than simple coding.
Always make sure the page works before you decorate it. Otherwise you will waste time, and frustration, stripping out and debugging yourself. Debug as you go, each time you change a tiny bit. Once you have a solid working page, then add decoration. Otherwise, I find, again and again, that you will spend so much time on decoration that your page fails. You can always decorate.
CMS systems include a kitchen sink's worth of code as well as the entire kitchen-sink factory, just in order to have bell-and-whistle options they can sell their customers. Most of which are never used by the customer who may not even be aware they are adding useless overhead. My motto is that if you know enough code to call a JQuery function you already know enough code to figure out your own function, minus the overhead of all those other functions you'll never call. It also means you are not limited to someone else's idea of function. For example, I really don't like carousels which keep circulating headline items. I do like carousels for some display uses, like a slide show. I also want to give the viewer control over whether it plays, next, previous, by category, from number such and such, and so forth. Nothing "out there" worked that way. I wrote my own. You can see it on both KCDance.com and MikeStrongPhoto.com.
I am strongly for keeping programming local, that includes the files for your site. When I started, you always built your web site on a local machine, usually referred to as your "dev box." First, you made sure it worked in your office, then you uploaded the files to the actual site location on the web.
That way you always had control over your own files if they were messed up "out there" or if an ISP went out of business (happened in the early days). Just like partner dancing, you are always balanced, not leaning on your partner, so that if you and your partner lose contact, you are still standing and balanced.
In those early days you learned what I called "defensive website development" (named after "defensive driving"). If you need to move your stuff to another host, you can do so immediately - usually.
Local control includes the people doing the coding. We are wasting a lot of great, close-to-the-ground talent who should be working on the interfaces and systems, rather than hiring outside large firms, to do custom work. Generally I find that the outside outfit is good on shiny (And, to be honest, they are hard working and sincere. No one wants to do a shoddy job.).
"The locals" may or may not be as "shiny" but they are closer to the user and are often the user. So they have a better feel for the needs of the program, the user (i.e. teachers) and the user's customers (i.e. students). Not everything can be covered by questions and descriptions of need. It always takes practical work.
Right to Repair - You should be able to repair the software you use. You should be in control of your own shop. You know your own needs best and you need to have staff who are capable of, and knowlegeable about the software which is essential to you.
Avoid version obsolescence - Says it all there, almost. The hidden problem with new versions of software is that often new version either fix problems which didn't exist or add functions which don't add usefulness. The main reason for such software updates is to churn the market and force you to keep buying, regardless of how well the product is working for you now and regardless of how well your staff and users know the current product.
As a programmer I learned decades ago (specifically in 1983 creating a mailing program for Clinic Masters which used temps to type in the data) that as the programmer, when my program is not being understood by the user (our temps) I had 2 choices
Extra training, which is also an extra load on staff and entails correcting the same mistakes repeatedly with each new person
Change the program (which was almost always the best choice for longterm impact and the easiest to implement) to avoid the errors before you have to do cleanup on the files and records.
You have to watch over user's shoulders to make sure your design works as intended. A good worker will try to figure out anything they don't understand and may come up with work arounds to fit the input to the form. But, in being a good worker, they might not recognize when they should bring you for a fix to the program. As the program designer you always want to know whether your design was understood by its users: whether your design intentions "got across."
If not, you need to know what was understood instead of what you intended and then modify it to meet the user's expectations. This will also tell you whether you need other fields or data and what to rethink about your program or data design.
The arguments for CMS systems are that they have a lower learning curve. So does Dreamweaver (an HTML editor). The only thing extra you need to learn in Dreamweaver or other HTML editors is to be aware of locations on the web. By "protecting" you from location awareness CMS systems cripple you. You should understand both local and web paths like the back of your hand.
Frankly, if you know MS Word, or any word processing software, you are more than capable of handling the learning curve for Dreamweaver. More importantly, your files and all your work are not "out there" in case anything goes wrong and you are cut off or lose your work.
There is no magical "cloud" although there is a very good fuzzy sales device convincing us this is some sort of magical "cloud" into which we can all meet up. The actual "cloud" is just another server (computer, used as a host) in someone else's building somewhere in the world, you don't necessarily know where, or to whom you hand ultimate possession of your work. As a habit, this gets easier to do as you go along, forgetting that where you are putting your precious work could close down. Remember, possession means ownership. Those may be "your" files but they are on someone else's machine.
Simplicity is its own reward. It is easier to write. Easier to debug. Easier for another programmer to work with. Easier for your users to use. You always need to write for future changes and debugging. Commenting and clear code formatting are important to yourself (because you will forget some of the purpose of your own code) and important to other coders who come after you, or in addition to you, to work on the code.
Simplicity, therefore, saves time developing code and breaks less. Complexity is too often merely showing off and complexity is just asking for bugs. I do understand the thirst for bells and whistles. Really, I do. Always design for the most minimal user (customer!) you can expect to need this on a regular basis. Don't put on even one bell or whistle unless you have a truly good reason.
No shiny, super hot-performance development machines. Tempting, as they are. And seemingly justified when you are "the developer." I learned decades ago that the best machine for development is the minimal-performance machine you can expect your customers to be using. Basically, as developer, if there is an "pain" using your software, you need to experience it before you issue a release.
I pulled the beta back and developed a separate API binary file in assembly to do file reads and writes, that I could call from the program rather than the system calls I was making. Without all the system layers the new program was now 20% faster than the old DOS program written in Borland C. From then on, I made sure my development machine was creaky enough that I would catch user experience problems, such as processing times or hardware compatibility, at the origin, my desk.
Clever code versus direct code - By this I mean a consideration for how the machine will process a formula and what that means for processing speed.
Clever Code: a = (b + c) * z) looks more compact than:
Direct Code: these three lines look awkward by comparison:
temp = b + c
temp = temp * z
a = temp
Or the same, droping the last transfer
temp = b + c
a = temp * z
The slicker-looking clever coding requires the machine to stop and perform the steps by examining the statement and pulling it apart, inner to outer, calculating the value of each part and putting them together.
Writing the code in discrete steps does that task for the machine and gives the same result without having to stop to interpret the statement each time it is encountered. The spelled-out steps may look clunkier but they run faster because we remove some of the (detour) work the computer goes through, which is hidden "under the hood." This is especially impactful if this code is used in a loop (a repeating structure) which could repeat the step thousands of times.
Ethics; no trackers. Dozens to hundreds of trackers can infect a page, including media sites. In 2019 a New York Times article titled "This Article Is Spying on You" noted that any reader of a NY Times medical article "might encounter tracking technology used by nearly 50 different companies, including BlueKai, a firm owned by the massive company Oracle that sells user data for markets to target those with 'health conditions' and 'medical terms.' "
As you might guess, these trackers contribute a huge amount to page weight and to overall internet traffic, to bandwidth clogging, to large data charges and energy use, an environmental no no.
Such surveillance does not stop here and I find it hypocritical, not to mention angering when public radio stations tell you to "ask your smart speaker." A few years ago a German newspaper interviewed an ex-STASI (secret police) agent about these things. These were a dream appliance, a wet dream the STASI never thought about, he said, but would have loved. Skullduggery sold to eager surveillance targets. No need to tap wires, covertly follow or spend extra money on those spy standard trenchcoats.
Hidden code: Again, often trackers and data miners sell the data they collect on your site, using your honest face as a front.
Third, fourth, etcetera party support code: This software often relies on further external code, which changes as those outside programmers want. Do not expect any terms to be adherred to. This is all opaque and just too tempting to companies whose sole reason for existence is to monetize everything they can get their hands on. Even when changes are announced they are usually lost in the fog.
Complicated and extended download and activation times: Each of these
external-sourced pieces of code come from different servers, each of which has to be sent a download request from the visitor's browser before the browser can load it into its document object model (DOM) to fully assemble and display the page at your end.
Outsourcing code: You are handing off your customers' private information to external outfits over which you have no real control. It is all too common for such an outfit to deal with you on one side and to use the same information for sale or other purposes, including surveillance, credit checks, health denial, and a raft of other unexpected possible impacts on your life.
Note the furor over ID.me and the IRS' attempt to submit every person in the country to facial recognition, a technology which is still very flawed with a match rate which is definitely far less than %100. Even were it 99% that would mean 3.3-million people who are out of luck for benefits, income, banking, health coverage and other things you thought you owned, not mention it is a technology not available to everyone and that the requirements (stills and videos) are not evenly producible.
SEO - Search Engine Optimization - a shotgun whack-a-mole attempt to "game" search engines into promoting any particular page. Time to be simple. SEO is a way to spend a lot of effort for largely unverifiable, but highly touted, results. It is also something which has to be kept fed, just to stay ahead of the SEO vs Search Engine forever war.
Text URLs versus QR Codes - This is a new security problem. Once again a great, fun, handy piece of tech is bought into, making it ripe for exploitation. QR codes produce a graphically-coded URL your phone's camera can read with an application. They also send you to a direct payment. You can also take a regular picture and drop that picture into a web site which will decode it and jump to that site. The problem, is that you have no idea where the QR code comes from. Even if your most trusted friend produced the QR code, you can't be sure they used a secure site or method. For that matter, with the large number of sites which offer, often for free, to generate a QR-code image for you, you have to ask why? Who is this being done for and who gets what out of it.
After cautioning us for years about clicking on uncertain or hidden links in emails, we are suddenly throwing all that experience out the window with QR codes. Unlike a text URL (make sure you are seeing the link and not a different title attribute masquerading as the link), there is no indication of what this links to. Another site, a virus, trojan, worm, predator site? Who knows? The destination is fully opaque, which is a perfect lair for malware to lurk within.
Sorry to say, most users of technology seldom think even once about network security, or security on your phone. With the large amount of personal information most people have on their phones, this is just too tempting for scammers. Tens of thousands of dollars worth, sometimes at a time are being stolen. And, for the most part, this is not being reported on the news, nor are QR codes leaving us.
The rule about QR codes is don't, just don't. Don't download QR scan/decode applications. Don't read QR codes. Don't generate QR codes (because even if your generation of a QR code is safe, and you can certify the safety, you are pushing the use of a very insecure technology and telling your friends this is cool and they should get with it, like you). This is recklessly unsafe technology selling unsafe behavior. Use a standard anchor tag with full-text URLs as best practice.
Dependencies in libraries or 3rd-party codes (i.e. QR codes) and SDK's (software developer's kit) - see items above on complexity and libraries. DJI drone software recently, briefly, bricked a lot of drones with an update. Something in an SDK for Android was off and suddenly there were a lot of "orphan" drones, mine included. The same thing happens in other complex software which is a call to code written elsewhere, which in turn is dependent on yet another bit of code from yet another party.
You never know just when one of those parties will decide to put in a few lines of tracking or diversionary code. Often, those apps get their other, their real money, by selling your data on to another, unseen party. X-Mode claims to cover more than 25-percent of the US adult population each month, scooping up tracking data, selling it, in turn to private corporations, IRS and DHS. The point is, if you are not writing your own code, you never really know when dependency code is hijacking your usage for their own.
All items copyright Mike Strong, all rights reserved