I have been subscribed to both channels for some time and absolutely love the informative content and the entertainment factor. All three of you are wonderful. P.S. Happy #SepTandy
If the C64 Manual was written today, it would consist of: 1) 40 pages of legalese. 2) 20 pages of generic safety guidelines. 3) A “Do not service this product” statement spanning a whole page. 4) A glossary of words everyone knows, but omitting all words that are used in an unusual way that are specific to this product. 5) A single diagram of the system and all parts, viewed from a weird angle and in very poor contrast, with every letter of the alphabet and a corresponding table that gives highly technical names for each thing with no explanation whatsoever of their purpose. 6) A sequence of actions to take to get the system started - with no explanation of their purpose, which do not match the software that shipped with the system. 7) The same repeated in 9 languages.
@@TassieLorenzoAgain this is to do with printing costs. There’s a reason why Apple is one of the most highly valued companies while also paying out dividends
@@jsizemo It's not about the cost-cutting - it's a generalized attitude that folks like Warren Buffett calls an “economic moat” - basically, ways to prevent competitors from entering their space, as well as making it hard for users to leave that relationship. Contemporary life is littered with situations like these, where customers are coerced in economic relationships that they cannot easily leave, and those providers of services aren't invested in making their end-user lives better because those consumers can't leave, and even don't have options to go to anyone else. It's something I've heard Matt Stoller calls a “monopoly crisis”, which has wide-ranging knock-on effects throughout the economy, but also in our political lives.
"The manual is angry at you for needing it!" That is a classic line, and as someone who teaches a course in technical writing for product documentation, I hereby confess I MUST steal this line for when I teach the course again later this month!!
I've written so much documentation and I wasted so many hours going back over stuff, reorganising and restructuring it, re-wordsmithing to adjust the tone: I wish I'd been able to take a good course in technical writing instead of futzing about having to learn from painful experience how to communicate complex concepts to a bunch of people who really didn't want to have to know this stuff. Both my time and the users time would have been better used had I known a bit more about technical writing. You're doing a good thing.
@@dingokidneys So much of writing a good manual involves knowing the reader, and having some empathy for them, and all three hosts showed they really understand that! I may just add the video to the suggested viewing list for the course!
@@dingokidneys I think this is that moment where I need to point out that prevailing assumption you have of “people who didn't want to know this stuff”. I learned this early in my career, there are reasons why people don't know these things, or want to know these things. One is yes, they don't have the time to learn these things (and that the time was spent learning other things, things _you_ yourself didn't take the time to learn). Two is that they're actively kept away from learning some of these things because it is convenient. Sometimes it's for a good reason - your users don't need to know the configuration details of the network appliances on your network, and they sure as hell don't need to know what the administrative credentials are for that system. But for others, it's more because it was decided for them that they _didn't_ need to know… even if it benefited them in some way. In many cases, sometimes you have more in common with the end-users who are asking you for help than you do with whoever it is that owns the software that runs both your lives. And so when I get irritated with end users who are often also irritated and stressed out, I usually take a deep breath and a step back, and remember whose side I'm on.
I shared this video on Facebook precisely because I have friends who teach courses labelled technical writing (it's really business writing rebranded, not documentation as you describe) who might be able to use it.
There's a tendency to think of late Millennials and Zoomers as "digital natives" in academia. But everything they do treats computers as appliances. And how many of us really understand our microwaves or dishwashers or toasters on an instinctual level? That's what we're asking these kids to do. When I teach, concepts I bring up and explain are inevitably something nobody has explained to them before even though it's assumed they just know them.
Just a reminder that even the youngest Millennials are right now well in their way to starting their own families, and that the oldest Zoomers have at least had five years in the workforce (the cut-off age for both is, get this, 1996, which was 28 years ago). So these generations have literally grown up being treated like they Intrinsically Know Things About Computers, and that product design has been treating them as appliance-users for most of their lives.
Seeing how many people fumble with microwaves and toasters (and cars and TV remotes, etc), I would suggest that reading the manual is still a relevant skill.
@@DissertatingMedieval I think the _worst_ part is that folks growing up during that period _are_ accustomed to being treated as intrinsically needing to be surveilled and monitored all the time, and are deliberately indoctrinated to being treated as hostile interlopers and potential criminals into systems. That's _exceedingly not right_ and it shouldn't be okay.
I have at my parent's home Reader's Digest "The fix-it-yourself manual", and thanks to it I could understand how works an old dishwasher, vacuum cleaner or toaster.
When I read 'hit the enter key' and think about some of the people I've had to try to teach these concepts to, I visualise them pulling a hammer out and whacking the hell out of the keyboard. My preferred verb is 'tap' although some people might still go to the bathroom, forcibly remove a faucet, bring it back to the computer and bash it with that. Malicious compliance was a feature of some of the people I've had to deal with.
I got an original IBM PC in 1982 when I was 19. The manuals were amazing. The trouble-shooting guide included an assembly language listing of the BIOS. Everything in half page 3 ring binders.
I remember the DOS manual I got when my parents bought our first computer. It was massive.And there was so much useful stuff in there, along with less useful things like how to change the colors of the command prompt. I think a lot of why that stopped was simply the result of the internet allowing half-finished products to be shipped and as a result there wasn't the same kind of time to develop proper documentation. These manuals were often times being developed in parallelt to the later stages of development so they had a clear cutoff time just before the final touches were completed.
I think that hardware/software manuals have returned to what they were in the mid-1970's (in a way) for the kit computers. Those assumed a level of technical skill was already present in the reader (a casual person from home wouldn't be buying a kit computer to solder and put chips on, etc.). The transition to the home/personal computer (an already fully assembled "thing") meant that manual writers had to assume that Jane/Joe public was now buying these and would not have any background in engineering, programming or even typing (I remember in the mid 1970's being one of the few kids around who even had a manual typewriter). So showing things like "What is the Spacebar" makes a lot of sense. It's like telling someone who has no previous musical experience to play an E note on a guitar; they have no reference to know what an E note is, never mind how that translates onto a guitar. The TI-99/4A guide you showed is somewhat telling in that the original TI manuals from Texas Instruments themselves were still a little too complicated for a new home user (the Apple II manual was like this too, I remember not understanding parts of it when I first saw it back in 1979). The one you showed is not by TI at all but by Consumer Guide, which, being a series of magazines for general consumers for a variety of products, had to aim to the lowest common denominator (ie someone who knows nothing about computers) and start teaching from that level upwards. Heh... loved the COBOL / Matrix reference... I laughed out loud at that. One set of manuals for early home computers that I found as one of the best (note: I may be *slightly* biased) is the original TRS-80 Color Computer manuals ("Getting Started With Color BASIC" and "Going Ahead With Extended Color BASIC"). The later condensed Coco 2 manuals, while good, were not quite at the same level. They had friendly illustrations, made the reader comfortable that they can take as much time as they need and refer backwards to previous lessons, has little question/answer and problems at the end of each chapter, and made a lot of the lessons fun rather than dry programming examples. They first of the two can be found on the Color Computer Archive online. P.S. As you can probably tell from my rambling sentences above, no one should *ever* let me write a manual for public consumption. lol.
Thanks for the shout-out! I will be spending the next year writing the user guide/manual for my HyperCard text adventure game and game editor. It's a labor of love.
I worked for an OEM in the early 2000s that had a great insight, which you talked about, where they had a “technical writer” who did or could understand the subjects and write the extrapolated version into a “Manual”. That’s the way to do it.
Veronica, the time you spend explaining concepts without assuming I have a high level of knowledge on them, and also not being patronizing about it is really pleasant. As is your positive approach to things. Having you, Taylor, and Amy together is just an absolute delight.
Love the chaos Taylor and Amy bring to your video! More of this! I actually liked this topic very much as a "newbie" user. It is true, sometimes the docs say "do this command if wanna X" - "Do this other command if you want to Y" but for some reason, nowadays, things being more complex, sometimes you can't X or Y without Z first, which maybe the doc didn't tell you because it assumed you had done it or already have it. And now you have to scour the internet and forums and ask community to help you, which often times they do and it's the beauty of this sphere. But for a BASE (not basic) piece of software, the docs should be 1:1 or 99% close to that with what you'll get.
The Apple II user and reference manuals were amazing. Full circuit diagrams. Timing charts. Complete assembly dump of the ROMs. Sample programs. You could understand the complete system.
That looked like you were having a hoot, which is great. Documentation is difficult and, speaking as someone who has written a lot of documentation, it's a thing that you need a lot of practice and feedback to start getting right. You need to be humble enough to accept when people tell you that it's wrong or difficult or whatever, Having a really good structure to the document that you are writing is also very important as that can make both the writing and the learning much easier.
I just want to say, the Arch Wiki is some of the best documentation I have ever read and you're right that even when using other distro's i have followed the Arch Wiki instructions from time to time. I also miss the days of good documentation :(
I love the little quips in old computer manuals/books. One that has stuck with me is this one from the 1987 AppleSoft BASIC Programmer’s Reference Manual: “Be as creative as your own internals will let you be, remembering that poets also plan.”
Finally, I understand why I love my car’s user manual so much! It does everything you explained as the “right” way to write a manual. It’s patient, succinct, and it doesn’t assume you already know how to repair something, but it doesn’t talk down to you. The writers definitely understood that you’re most likely reading it while you’re in a stressful situation.
Thanks for the memories. I used to have a $100/month budget in the 80's for computer books and magazines and spent hours a week in the university library. It was inefficient and wonderful. We have definitely lost so much as we've gained just as much. The pace of change makes documentation in printed form impossible. I often miss that pace.
All hope is not lost: For people who truly do want improved documentation for the open source projects they use: These projects often accept Pull Requests that improve their documentation! I work on an open source project that has *OK* documentation. It could definitely be better, but the dev team (including me) is more interested in making features, fixing bugs and just having fun with developing the project, while writing documentation is usually one of the most un-fun things you can do, especially since nobody ever praises the documentation work and instead people are either skipping it entirely, skimming it and getting things wrong and then instead of re-reading it ask on the discord, or just complain that the documentation is bad without making any effort to improve it themselves.
Dear Veronica, Taylor and Amy, this has to be one of the most entertaining videos you've ever made! And yet one that at the same time addresses a good and important topic - the value of excellent documentation! Thank you so much for this video! As someone at the tender age of 64, I witnessed the early days of computer documentation in the early eighties.... Today, I'm thinking about learning Linux in my retirement (after MS-DOS, OS/2, Windows) - do you know of a good manual? :)
Firstly, this was so much fun to watch, your guy's joy really came right through my screen :D 16:55 I feel this so much. I am about to turn 25 and for me computers have always been a means to an end. There was nowhere (and really no need I guess) to learn about the nitty gritty details of how your programs ran when I was first self studying programming in high school. Of course people can and do still learn this types of things, but to me it felt all too advanced and like the information just wasn't meant for me to know. I am also passionate about documentation and have found that older manuals are a great place for me to do much of my research, and a I feel like this video really confirmed that idea. Hopefully one day the ipad babies will be able to read something I wrote and feel a little less anxious about their computing journeys. I will definitely check out the other channel too!
Much of the documentation was written by programmers for programmers, not for the general public. The TI99/4A was my first computer. The manual spent a lot of real estate in the various keys, because the public was used to typewriters, but computers don't use the keys in the same exact way sometimes. Before those, hobbyists were building their own simple computers that used op code, or assembly to program their machines. The introduction of BASIC changed everything into a more human kind of language. I did all of those kinds of coding, I've upon a time.
I was an Atari guy but sometimes wish I also had a Commodore... I still have my Atari 800XL, 1200XL, ST2 Mega... I still have the manuals to them too and a few companion documentation... Those were the good'ol' days...
@@akmartinez1 Same here. Started with the Atari 800, have a 520ST which I upgraded by soldering more RAM piggyback style, Mega 4 with upgraded CPU and Spectre GCR. These days I just use Debian on a Blackview Mini PC, with WINE. All my Atari stuff sits in plastic tubs in the basement for my kids to go through after I die. Duckduckgo is my manual of choice these days!
i never really appreciated how difficult it is to write a manual until i had to do it myself for my projects. technical writing used to be a thing that consumers could enjoy along with the product!
It's a lot easier to do if you've got access to people that are completely ignorant of whatever system you're writing about to try the instructions. It's still not at all easy, but it greatly reduces the likelihood of missing things due to just assuming that people won't do that.
i used to run IBM Mainframes, ran JCL and other Job Control languages, the manuals were an entire book case. like dozens of binders. Back then hard drives were as big as washing machines. for a few Megabytes.
It's wonderful to see you three nerds again, on a different channel! Friendship is magic, or sufficiently advanced technology. Damn awesome manual. Fraaaaaaaaaaaan-tastic indeed! Makes me wonder how many successful careers it started. Modern technical writing seems to lack this old style strive to get the knowledge across to different kinds of audience. The realization that we come from various backgrounds, some of us know microelectronics and the inner workings of arithmetic machines while others can barely type, and still making a manual that helps everyone. While people know how to use the computers without having to learn extensively, there's a downside to this: they don't understand how the computers work on a fundamental level. Same with phones, cars etc. - they have become magic boxes that do their stuff, no questions asked. And when they do a thing that wasn't expected, frustration arises, with no knowledge about the root cause and optimal solution. Been using Debian for 12 years now... Time flies like a Saturn V back in the day! 14:30 well, that's indeed farfetched a tad. I guess the authors watched Star Trek just a bit too much, haha.
The Commodore 64 Reference Manual was my best friend for a couple of years. It contained clues that allowed me to figure out how to do "impossible" things. Thanks for reminding me of the 1980s, my favorite decade!
I had the bad fortune to be introduced to the Macintosh almost immediately. Today, while I'm comfortable in the command line, I rarely use it. I took BASIC (Applebasic) but I don't remember any of it. Now I am slowly relearning how to use a computer, 40 years after first using a computer. :) My College CSCI instructor in 1985 advised me against learning COBOL because it was dying out. :|
I got a very brief stint in COBOL in 1991. But even by the early 2000s there was an extensive code-base in COBOL. Especially the financial sector still has a huge legacy of COBOL code,
So fun. At a former employer, I was responsible for final documentation. Just me, for the 10 million dollar automated manufacturing project. So fun...yeah anyway. This was a customer complaint, "Why don't we have more explanation of the *insert process*?" Because I never had time to sit and spell out each process with error and error fixes. It was just me. Most of the docs I provided were just component base lit that came with the component. Because of this job and my trying to get into Linux again, the video really connected. So much truth...provided in a very fun way. Thank you.
Loving the joint videos with Taylor and Amy - they look like you three had such a lot of fun making them. The TI manual describing keyboards for a time where typing was not a ubiquitous skill reminds me of technical documents, manuals and even reviews trying to describe bitmap screens and the mouse to equally unfamiliar users. It’s quite a skill in its own right to be able to introduce these things to an audience who’d have no prior knowledge. While I don’t especially lament the passing of shelves full of paper documentation in 3-ring binders, the modern attitude of a discord or forum plus Google providing answers instead doesn’t pass muster. We’ve also lost the discipline of keeping information up to date for our users.
"The TI manual describing keyboards for a time where typing was not a ubiquitous skill" I find that wild! But I guess where used mechanical typewriters are (mostly) a very cheap and fun collectable today as supply *far* exceeds demand, in period at full RRP mechanical typewriters were quite expensive? Were mechanical calculators even more expensive and even more of a luxury? Hence most engineers and scientists using slide rules and there being no pushback against the key layout changing from mechanical calculator convention to the 3x3 of electronic calculators? (Unlike typewriters keeping their existing layout even though without physical levers, there is no reason for the rows to still be offset.)
You three restore my faith in humanity. You had me at spiral bound and glossy cardstock. I no longer feel alone in this world. It's not a lonely big blue marble anymore. People get it. I'm Gen X, I wasn't fortunate to be exposed to the C64 or it's much rumored on the school bus memory upgrade! My first exposure was building my own 386 clone and using a 9600kb modem to log on to a local BBS that I found unlabeled, but posted on the local community college hallway cork message board. Lots of text based dungeon crawlers and ascii art was downloaded let me tell you. Thanks for the flashback to better times imho. I do think we've lost some level of critical thinking skills>>|Douglas Rushkoff, Program Or Be Programmed,| If not read then read it. Seriously, I love your channel and I will def go sub to Taylor and Amy's channel. Don't ever change Veronica.
This was amazing! I haven't laughed this hard in a while 😂 I also love early 80s spiral-bound computer manuals, started on the VIC-20. It was a necessary and fun stepping stone to more advanced books later on.
@@robinpettit7827 RF means simply Radio Frequency . The signal is RF travelling down the cable . Only and when cable hits an antenna It is “broadcasted” over the air to any and all receivers in range.
Even without that it was still possible. My friend's Leading Edge computer forced Mario to jump into a pit. Nobody was even touching any buttons and there Mario goes to the nearest pit to end it all.
This is why I really appreciate things like the Arch Linux Wiki. The documentation there is fantastic and in depth. Almost every other distribution can learn a thing or two from the Arch Wiki
This is one of the best episodes I've seen in youtube for a while! Itś like three old friends having fun! :D :D Oh, and youŕe right about debian's website!
The 1988 movie Beetlejuice had a great line in it, complaining how the "Handbook for the Recently Deceased" read like a stereo instruction manual. Some things never change.
From a UK viewpoint, the BBC Micro and ZX Spectrum manuals were VERY good. Logically laid out, and took you step by step through BASIC and the machine. By the end, you knew how to program.
Since Veronica connects to Taylor and Amy, I, a die-hard ZX Spectrum enthusiast, now feel urged to get into Linux ;) I must admit I probably won't (have used it in the past, so hope that counts!), mainly because I don't have time to get through my creative backlog already anyway. I do wonder how a guy would survive being a guest at Taylor and Amy's.. Loads of fun!
First off, I just watched this video and yet I have already sent it to SO many people, shared the link on almost every single social media platform I belong to, etc. No joke: this should be required in every single computer science class under the sun, period. Anyhow, speaking as a former journalist, who started in the world of print and retired just as the entire online news ecosystem was starting to really fall apart, I hate to state the obvious, but the pivot away from print is the real culprit behind the degradation of documentation. Having your words committed to a physical object that could not be changed after the fact was like a gun to your head, one that demanded that you think everything out. Now it's just so easy to just phone it in, and promise others (or yourself) that you'll fix things after the fact. I can't help but be reminded of one of my earliest jobs, I was the resident video game expert for Nickelodeon Magazine, and I had to explain to kids some of the underlying tech that drives software. And my editor kept getting on my case about how I failed to properly explain what a polygon was; I naively assumed a kid would know, "they're so tech savvy these days" I reasoned. My editor was 1000% correct btw, obviously. The lack of an editor is also a major reason behind the current situation as well.
Great video Veronica as usual. I just subscribed to The Taylor and Amy Show as well, they are great too. I too miss the old days of great manuals, and do agree, today we don't teach the right way anymore.
Here in the UK we had Acorn BBC Micros and Zx Spectrums, Dragons, and a few other UK computer companies, and NONE of them could match the amazing manuals made by Commodore in the USA. The VIC 20 manual is amazing and the best user manual ever made. Loved this video thank you.
The Apple IIe had a two-sided floppy disk which provided information about the earliest steps of using their computer. Side A was an intriduction to using the Apple IIe from a user perspective. Like the TI manual, it went to the level of a space bar and identified the use of the Open Apple and Closed Apple keys with a little minigame. The arrow keys tutorial was a pair of minigames designed to have you guide some characters through small on-screen mazes. Side B was a complete introduction to the architecture of the Apple IIe. You followed some mini-lessons and then played a trivia game at the end to understand the difference between a CPU, RAM, ROM, and I/O ports, for example. Myself at 5 years old was just eating this up; yeah, I read very early in life, and my parents (who taught in the 1980's) bought one when I was 5. I spent *so* much time on it playing Oregon Trail and Where in the World is Carmen Sandiego, as well as programming in BASIC. It was truly the influential device that has led me to working in IT as a cloud systems engineer today.
Good to see this topic being covered, and in such a fun way. I think the issue of good documentation applies even in the more complex realm. I remember one version of R:Base having the best introduction to relational database concepts that I've ever seen, better than any text books (of the time anyway). Oh, and it was a strange flashback seeing Multiplan as a product, I used to sell the CP/M version for the Microbee (Australian 1980s computer).
I'm actually really proud that the company I work for still writes detailed manuals like this for our products. We're in the theatrical lighting industry, so we're a bit niche, but our technical writing team does a great job continuing to help our customers understand our products!
OMG! TOO FUNNY ! As I thought, I am fortunate as a Senior, grew up with the tech, and went to school for it, but so many other Seniors, NEED GOOD MANUALS, with PICTURES ! Just like the need for our children : ) I remember the HeatKit computers with a built in Hex Pad, Yep, I am that old :) THANKS AGAIN for all you do and share! : ) Cheers !
This was hilarious! Explaining the 'space bar' as if people had never seen -- oh say a typewriter? Still the 'first computing experience' manual I had was the Timex Sinclair ZX81. It really helped and in the pre-pre web era the manual was that guide that everyone needed.😅
Through working in IT for about 30 years I’ve made friends with a number of technical writers, the people who used to write the manuals. According to them the main reason that the quality of manuals has gone down is the rise of technology books and training during the 1990s and early 2000s. Why, as a software or hardware manufacturer, would they give you, for free, a manual that tells you everything you need to know when they can put that same material into a series of books and training courses that you will have to buy.
Great topic. Also Commodore computer mags taught so much stuff, back in the day. When I started college, I tested out of the entry-level computer class simply because I knew hexadecimal because the magazine used it to number the tech tips. OK, now we'd like Veronica on every Taylor & Amy show video, and vice versa.
I appreciated manuals that did go through the "theory of operation" on a device, specifically when I was repairing them. Although, I did get a few laughs in some of them. One in particular was the manual for repair of a Sony Trinitron TV set. When reading the section on the high voltage section, and the theory of operation, in the circuit there is a transformer that takes the horizontal output voltage and boosts it to around 30KV. That transformer is called a flyback transformer. In the manual it was called a fryback transformer. It was obvious that the person translating the Japanese manual was verbally dictating the manual, and it was being transcribed by someone that was listening to the tape recording that just put down what they heard. The real pun there for me is that when there was a failure in the high voltage system of almost every TV made, that flyback transformer would burn up. Hence, the "fry" part of the transcription made me laugh out loud when I read the manual. (Non native english speakers, whose native language is Japanese sometime have trouble with "L", making it an "R".)
It's multiple "man pages" ... at least that's what we called them, back in the early days of Unix, inside Bell Labs, in the 1970's, when we got our latest Unix versions on 9 track tapes from Ken (Thompson).
100%. 200%. 1000% with you three. To this day, all documentation I write is in the form, style, and voice of Commodore's programmer's reference guides. (Especially those little "cloud bubbles".) It's effective, illuminating, and kind.
Thank you for the support, and yes, those Commodore guides are exactly what we need more technical writers to be excited about. In addition to just needing *more* technical writers. Thanks for doing what you do!
This was so much fun! And as someone who grew up with the 5150's manuals (plural) in binders in a boxed set, and the TRS-80 manual that included a schematic of the Model 1, I agree completely about manuals. Is "tech writer" even a career anymore - and by that I don't mean a journalist but the person who wrote manuals and other documentation intended for users. They were typically English majors.
The adapter with a switch looks like mine analog guitar pedal which is a remake of a 1970s one. That thing looks ancient. I wasn't born yet, but I am fascinated by these old school tech.
Eons ago, when I taught in classroom, I was in a room teaching about MS-DOS. At the back of the room, was 30 seats with IBM Selectric typewriters used for a typing class sometimes scheduled in the room. I was assuming that most of the people in my class knew what a typewriter was and how it basically worked, even if they weren't marginally proficient at using it. At the break, I let students come to me and ask questions that they didn't feel comfortable asking publicly. I had a student come to me during break who asked a simple question - "What's a typewriter?". I noticed he had an accent. I asked where he was from and he said, "Siberia" (this was just after the fall of the USSR). So I showed him one of the Selectric machines at the back. Unfortunately, he didn't get it. He left the course. However, I learned that not everybody knew about all comparative technologies. I would stumble over this only one more time - a student didn't know what the triangle for "play" meant in a media component on a programming project. I believe he was from Haiti (around the time of the earthquake we got more students from the islands). You try very hard as a teacher to find common ground to build knowledge on with students, however there are times when you are surprised to find people with no foundation.
When I worked at Digital (DEC) the manuals were *epic*. I took a couple of technical writing classes to help formulate those epic manuals, all arranged in three ring binders where the pages could be swapped out when there was a software upgrade. Not to besmirch Linux, but man pages don’t come close and don’t get me started on having to consult Discord or Reddit. Those manuals spawned a generation that knew how computers worked because we had to RTFM. Great video!
Some manuals from the 90s were so good I still remember the authors names. Mel Croucher and Stephen Hill wrote a bunch of inforrmative, detailed and often humorous manuals for software on the Amiga (AMOS, graphics / game programming etc). The quality of those manuals was as good as any book and I still have a few on my shelf. If those guys name was in the credits it was actually a selling point for the game/software.
This was fun! I still have my Ti99/4a, Speech synthesizer, Peripheral Expansion Box with a couple of cards, about 10-15 cartridges,...and most importantly... the documents! I even have the book for programming Ti Assembly Language that came with that cartridge (which I also have). It was so much fun back in the day when I got it. Dialing up my friends on a 300 baud modem, who had Comodors or Coleco Adam, and trying to play the same games! Dialing up BBS's and communicating with people around the world!
"Computer Intro" was fun. It was easy to find the cartridge, but finding the manual was tough. That's where I got my start. I don't miss that membrane keyboard though.
I have to say that the Ti99-4a manual was very welcome in 1981 when I was sat with my sister and mum on the living room floor in front of "The TV" (singular) trying to figure out what this computer (the only one in our street or among our friends group) was all about and how it worked. Sure, it seems overkill today but back then it was worth it's weight in gold. Schools in the UK didn't have computers yet and most offices only had one or two typewriters and they were used by trained typists. I love your videos though :D
When I first started learning 3D animation I went to school for Lightwave 3D. I got my copy of the software story a paper manual that was like 400 pages. I sat down and read the whole thing, cover to cover.
One of the all-time best manuals I've ever encountered was the HP-41C calculaor manual. Everyone can also take a lesson from Digital Equipment Corporation's (DEC) manuals.
Where were these women in my peak geek years? I missed out. My generation was a bunch of GUYS. Hey ladies, so glad to have you in the geek world! Have daughters and grow more female geeks! The American tech sector needs more like you.
I first learned how to write simple programs in the late '90s by reading my graphing calculator's manual and experimentation. Computers and calculators have become so ubiquitous that I suppose companies figure that elaborate manuals are no longer necessary.
I hope the people at Ubiquity watch this video. I recently set up a Unify system and while it's "super easy and intuitive" they included zero documentation which made the experience less than what it should be.
