By William Jeffrey Rankin, Thu June 16 2022
Stephen L. Moshier's venerable aa program (an astronomical almanac used to calculate planet and star positions), compiled for Cygwin (gcc version 11.3.0). It can be used interactively, or input can be directed from a text file.
aa - Astronomical Almanac, version 5.6 (aa-5.6.tar.gz, 161K)
Used interactively, simply ./aa. Or with input directed from a file, ./aa < Mars-2022-06.txt. Sample input file Mars-2022-06.txt to display data for Mars in June, 2022. The second set of numbers, ending with -1, tells aa to quit.
Longitude, latitude, altitude, and other local parameters are specified in the aa.ini file. Note: this file must reside in the same directory as the aa executable.
-84.17 ;Terrestrial east longitude of observer, degrees 39.95 ;Geodetic latitude, degrees 252.0 ;Height above sea level, meters 10.0 ;Atmospheric temperature, deg C 1000.0 ;Atmospheric pressure, millibars 1 ; 0 - TDT=UT, 1 - input=TDT, 2 - input=UT 0.0 ;Use this deltaT (sec) if nonzero, else compute it.
Refer to the read.me file included with the distribution.
By William Jeffrey Rankin, Mon Nov 8 2021
This past October I put together a list of what I feel are excellent stories to read this time of year—classic ghost, horror, and weird tales. There were 31 stories in all, one for each day of the month ranked according to quality (with the best saved for the end of the month), one story per author, and all freely available on Project Gutenberg and similar sites. Enjoy!
By William Jeffrey Rankin, Sun May 27 2018
Some thoughts on Star Trek: Discovery—which, having watched a few episodes, I didn't enjoy—and Star Trek in general. Star Trek is great because it can be a vehicle for many different kinds of stories: political/social commentary, action/adventure, comedy, sci-fi concepts (of course), or a combination of any of these things. But for Star Trek to be Star Trek, there are a number of foundational elements required:
Gene Roddenberry's vision was one of a united humanity working together to solve problems. The stories weren't always about that, of course, but the overall feel of the show was hopeful. The ensemble cast was an expression of humanity working together, with characters using their individual personalities and skills to contribute to the story. The episodic nature meant that lots of different stories could be told, rather than one overarching story resolved over several episodes or season.
Oh, and remember fun? OK, perhaps fun isn't foundational. Nonetheless, this is entertainment, therefore it's probably a good idea to make the stories fun now and then. Fun is the primary reason I've enjoyed The Orville which, while certainly not perfect, meets all the foundational elements of Star Trek.
By William Jeffrey Rankin, Sat May 19 2018
Some notes on why self-referential design is a problem, and why usability testing is important.
Notes:
By William Jeffrey Rankin, Mon May 7 2018
I had a conversation recently with analysts at a Columbus-based consulting agency regarding user research and usability evaluation. I was disappointed—but not surprised—to learn the agency didn't engage in either despite having a team of designers on hand. This isn't the first time I've encountered this phenomenon, and I wanted to put some questions and comments together.
So, assuming a lack of user research and/or usability evaluation for a project, these questions occur to me:
The client and/or product owner hopefully (but not always!) has a vision in mind, but how well-defined and realistic is this vision? How much research has been done? How many people have they spoken to about the product or service? Who are the competitors? If the amount of research has been minimal, the consultant needs to utilize their expertise in helping refine the vision by conducting some user research. It doesn't have to take a long time or be expensive (check out our user research cheat sheet for more information).
What if there's significant ambiguity about what's being built (there's always some)? Yes, the team can get together, ideate, and generate some stories. But are these stories anything other than assumptions if there's no data to back them up? So, take time to gather some data to help inform ideation/storytelling sessions.
In the midst of design, the team should take the initiative and conduct informal usability evaluation during the design sprints (or at some point that makes sense for the project). Just like gathering data for ideation/storytelling sessions, it doesn't have to be expensive in terms of time and resources. Formative sessions, with 4 to 6 users (actual users strongly preferred), and held over a day or two should provide enough data to ensure that the design is on course. Employ techniques with some level of rigor: Internal tests, 5 second tests, and similar techniques return questionable results in my experience.
We're the experts and shouldn't assume the client knows exactly what needs to be built. An interesting product/service concept needs to be developed, and we owe it to our clients to utilize the tools and techniques at our command. Part of this may involve educating the client (and perhaps internal people who manage the client relationship) about what needs to be done and why it will benefit the project. Instances of great ambiguity may involve forging ahead and doing the work you know needs to be done (sometimes it's better to beg forgiveness, than ask permission)!