#0014: Tip for reinserting self-tapping screws into plastic housings
What is a “self-tapping” screw?
Whenever one removes screws from a device – especially a mass produced consumer grade device with a plastic housing; then chances are that the screws that were removed were “self-tapping” screws. As the name suggests, these are screws that are designed to cut their thread into the inner diameter of the plastic hole of the device housing that they are inserted into at the factory.
All self tapping screws have a few distinct qualities in common. These include: a relatively deep thread in order to cut into and grip the plastic, and a wide pitch between these threads in order to more effectively slide into the material. Additionally most self tapping screws tend to come to a sharpened point in order to to aid in aligning the screw as it is inserted into the hole.
So what’s the actual tip?
Well, when reinserting a self-tapping screw into it’s plastic receptacle. It is good practice to initially rotate the screw counter-clockwise (loosen) until you feel it pop or click into place. This process aligns the screw with the pre-existing thread, and in doing so means that when the screw is screwed in, it will slide into the already established thread and not cut a new thread over or across the old one. When aligned correctly, the screw should screw into the hole with very little resistance.
Why use this method?
The reason why this is important, is because repeated re-boring of the plastic hole will eventually strip it out of any threading. This is because each time a new thread is cut into the plastics it removes material; which in turn incrementally widens the diameter of the hole in the process. This can continue to the point that it can no longer effectively hold the original screw within it. Avoiding re-tapping the thread every time you reinsert the screw will minimise your damage footprint when repairing/working on the same devices repeatedly. Which is always good.
Video demonstration
Please note: although it may look like I am using force to reinsert the screw, I am not. It’s just the awkward angle and set up that may make it appear that way.
What to do with an already stripped or overlarge hole?
There are a few remedies to take if this advice is coming to late. The quick and dirty solution is to use a larger size self tapping screw that then can cut a new thread into the widened hole. After which one has to then absolutely makes sure to always realign the new larger screw with it’s thread before reinserting it. This is because any further damage to the plastic hole may make it entirely unusable. E.g. a plastic stand-off splitting entirely due to it’s enlarged hole.
The more intensive repair requires filling the hole with something that the original sized screw can then bite into. The most likely materials used here are either hot glue for a “temporary” fix; or melted plastic of the same type as used by the device for a more permanent solution. If you use the melted plastic route: I recommend filling the hole entirely, then drilling a new hole of the correct diameter. Followed by finally using the original self tapping screw to cut a new thread into this virgin material.
#0013: Repair of a game controller with fatigued dome switches
What is a dome switch?
In order to know what dome switch fatigue is, we must first identify dome switches. Dome switches are buttons that utilise a dome made from silicon, rubber, polyurethane; or a similar material with the same elastic properties. This dome effectively acts like a spring and pushes the button back up when applied downward pressure is removed.
A typical dome switch will consist of several parts. These are: a (usually) plastic keypad key, an elastic dome, and a graphite pad. The switch key (or button) is mounted onto the elastic dome, additionally the graphite pad is attached to the concave or underside of this dome; and finally, this assembly is sat atop a patch of unconnected unmasked circuit board traces. These traces essentially function as switch terminals.
The idea is that when the downward force is applied to the key, the elastic dome is compressed; causing the graphite pad to press down on the unmasked PCB traces underneath it. This graphite pad actively bridges an electrical connection across these traces, due to graphite’s electrical conductivity.
When the connection is made across these traces, a logic level electric current (around 3.3 volts) is either pulled down to or pulled up from signal ground. It really depends on the IC (Integrated Circuit) chip that is managing and interpreting the keypad array as to the specifics. Anyway, the point is, essentially that is how the computer knows which buttons are pressed and for how long. After the pressing force is removed, the elasticity of the currently compressed dome material causes it to reset to it’s original domed profile. And in doing so it lifts the graphite pad from the traces and breaks the electrical connection.
Example of dome switches within a handset phone
Diagram of dome switch in action
image taken from: https://i.imgur.com/5K9Uy.gif
What is dome switch fatigue?
Dome switch fatigue, or more specifically dome fatigue: is when the domes within dome switches, develop a fault due to extended use that makes them no longer effectively reset their position. I.e. pop back up after they have been compressed.
The main symptom of dome fatigue is button sticking. In other words, when a button is pressed down, it either takes longer than it should to reset, or it stays down all together. This is assuming that the keypad is actually clean, as there are many reasons as to why a button might stick other than dome fatigue. Accumulated grease or oils, foreign objects (like food), and dust build up can easily cause button sticking.
Once the device has been opened, the domes themselves can be examined. Look for stress lines: thinner (often lighter) areas of material that can indicate structural weakness. I recommend comparing the suspect dome to it’s known good neighbours; adjacent domes from the same device that occupy buttons that don’t stick. Since they are from the same material stock and often from the same actual moulding as well (as is the case here), it can make spotting any actual stress signs easier. Common sense right?
As you can see in the example picture, there is a stress ring on the one of the four action button’s domes. This dome corresponds to the “A” button on an imitation USB Xbox 360 controller. Now I don’t mean to go on a tangent but I will say that imitation products like this controller are generally made to a price-point. I.e. the manufacturer cuts certain corners to bring the unit price down.
This is done in a bid to undercut the original product and sell itself as a budget alternative. In many cases the cut corners and lower quality product is mostly acceptable to the end user, as it is reflected in it’s price. However, these cuts tend to including: the sourcing of lower quality, less durable materials.
I believe this to be the issue here, although I haven’t had this controller for long. (Approximately a year.) I use this controller to mostly play platformers such as Splelunky. Since the “A” button is used to jump, it is by far the most used button; and it seems like over the time that I have owned it, I have just fatigued this particular dome. Either by some kind of repetitive flex damage (i.e. general use fatigue), or by just pressing too hard on it in moments of panic or frustration during play.
Example of “sticky button”
Example of fatigued dome
Repairing controllers with fatigued buttons
Sadly, an actual and effective repair of the dome itself is outside my capabilities. I just replaced the knackered dome with a fresh one. Well… a less knackered dome from a spares unit. As you can see I chose a third party “4 gamers” brand PlayStation2 controller as a donor unit. This is because that is all that I had on hand at the time. Additionally I am generally unwilling to purchase materials for a repair unless I have to. And to be honest, when it comes to repairing budget electronics such as this controller, it really is hard to justify spending any amount of money for materials, when one could spend a little more and purchase a new unit.
With this repair, I initially intended to replace the entire action button array (all four buttons), with domes from the spares unit. This is because the different types of domes will have different force pressure resistances, and bounce back elasticity. Which would lead to users experiencing different levels of tactile feedback or “button feel”.
At this level, I don’t mind much what the exact tactile feedback of the spares domes are; as I doubt specifying tactile feedback was much of a concern for this budget controller to begin with. Ergo this slapdash replacement wouldn’t necessarily denote a loss in overall device quality or user experience.
However I would mind if the feedback of the grouping of action buttons wasn’t uniform (or near enough). I.e. if one button was noticeably stiffer or mushier. That disparity in tactile feedback may actually become a distraction during play. It may even negatively affect a player’s performance; due to the player becoming accustomed to the tactile feedback of one button and then because of that either pressing to hard or not hard enough when they move onto another button (with a different level of resistance) in order to perform a different action. It may cause a misclick; either registering two inputs, if the new dome is significantly weaker/squishier or none at all if the new dome is significantly stiffer than the previous.
Unfortunately, I ended up just replacing the tired dome and using the rest of the three originals. Even though I have a picture of all four action button domes replaced on the controller. I dropped one on the floor shortly after that; and after 30 mins of searching. I just adapted to this strategy. In this case the new dome and the originals have similar (although not the same) level of tactile feedback to them. They aren’t different enough to be an issue. Not for me at least.
Spares unit
Application of spare dome(s)
Demonstration of device repair (before and after)
Original fatigued dome switch (green “A” button)
Although tactile feel can not be conveyed: notice the mushier, softer sound from the green “A” button when compared to the others.
Replaced dome switch (green “A” button)
The sound produced from the replaced dome is similar to the other three buttons, although they are not uniform themselves. There is an acceptable level of difference within tactile feedback across the buttons. The sound of the buttons when pressed reflects this.
Final thoughts
To sum up my basic ethos when it comes to repairing a device with fatigued domes. One, one has to replace the domes. As far as I can tell the domes themselves are irreparable. Two, When replacing the domes, it may be better to replace known good domes in a bid to get a uniformity of tactile feedback on all the buttons on a device, or at the very lest on a significant button grouping. Such as action buttons or directional (D-Pad) buttons. That’s the takeaway.
That’s all folks. Thanks for reading.
References, links, further reading
“Diagram of dome switch in action” gif taken from: https://i.imgur.com/5K9Uy.gif https://www.mechanical-keyboard.org/advantages-and-disadvantages-of-mechanical-keyboards/ https://en.wikipedia.org/wiki/Keyboard_technology#Dome-switch_keyboard
#0012: A personal perspective on the end of the Adobe Flash era
What is Flash?
Adobe Flash is a multimedia software platform. However the term “Flash” is used as a catch all term for any software that utilizes this platform to output media. The Flash technology allowed webpages to host media on them in the form of embedded files; encoded into either the Flash Video (.FLV) or Shockwave Flash (.SWF) format. In order to run these media files, one required the use of a web browser plugin called the “Adobe Flash Player”.
Flash first became prevalent in the late 90’s, early 2000’s as an evolution on the static webpages of the time. Where it was basically used for every animated media webpage element (barring animated .gif images). Including (but not limited to) delivering: video, music, and animated advertisements (e.g. banner ads with audio). It also allowed for interactive media, namely internet browser games. It did this by allowing the browser media access to user’s system inputs (e.g. keyboard and mouse).
In essence if you browsed the internet during this time and interacted with web media. Be it watching a video, playing a game, listening to music, or watching text scroll on a fancy ad. Chances are good that it was delivered to you using the Adobe Flash web player. It can not be understated, that Flash was ubiquitous in it’s time.
The decline of Adobe Flash
Ever since Adobe’s 2017 announcement of the official retirement of their Flash technology platform, for the close of the year 2020; the internet has been abuzz with people both decrying and celebrating the end of the Flash era. Even within the years leading up to Adobe’s 2017 announcement, I have seen Flash’s relevance steadily drop off as the emergence of alternatives such as HTML5, ate up Flash’s market-share.
There are number of reasons as to why people migrated from using Adobe’s Flash player to HTML5 for delivering webpage media. Predominantly, this is because of the public’s perception of the Flash web player having numerous security issues. Whether this is true or not, or simply exaggerated; I can not much comment. What I do know as a former Flash game dev is that you can make whatever network calls you want, as well as access the user’s local system; in order to get at anything from keystrokes to cookies. Then wrap up that code into a fairly innocuous looking .swf file, and embed it into a webpage. Hmmm… I guess it did have security issues. But having said that I am not going to pretend to be in the know, when it come to network security of the 2010’s and Flash. I only used it to make browser games. The network calls to allow online game saves, the cookies for local game saves, and keystrokes for user input.
Flash’s security issues in my opinion were compounded by it’s proprietary and closed source nature. There wasn’t an easy way to check what that embedded .swf file was going to do until it did it. Consequently it made malicious code very difficult to find. HTML5 on the other hand doesn’t suffer from this issue, since it is largely open source. Although most developers these days use APIs (Application Programming Interfaces) or frameworks, such as AngularJS or JQuery to make sites, or Phaser to make games. I.e. they don’t code them from scratch; the code for these tools however is there and public facing if you are inclined to look.
The openness of using HTML5 (Javascript, CSS) based technology means that it is inherently safer than Flash. Since the browser acts as an interpreter for the source code, rather than just a medium for embedded compiled binaries (.swf files) where code can hide. I don’t generally like speaking in absolutes, because there are undoubtedly exceptions to this. However in a general sense this is the case when it comes to Flash and HTML5.
Additionally Flash had another issue and that was it’s lack of support for mobile devices; as it was designed for the prevalent desktop platform at the time (~2008). This was in my opinion the death knell for Flash, as the explosion in popularity that internet capable mobile devices had between then and now (2020); just meant that Flash’s market-share essentially shrank proportionally to this.
Steve Jobs (CEO) of Apple published in 2010 an open letter called “thoughts on Flash”, where he cites a number of reasons as to why his company does not use the Flash technology in their products. Namely their iPhones and iPads of the time. His reasons included: Flash’s security issues, it’s closed source nature, it’s lack of optimisation for touch interfaces, it’s negative affect on battery life, and more. Link below for the full article.
Considering what the Apple CEO thought of Flash, it was no surprise that Apple was the first company that outright disallowed Flash from their platform (iOS). This meant that at the time, Flash was only supported on Android devices; and even that dropped off in the later years since the issues that Jobs cited weren’t addressed to a satisfactory degree. In hindsight, it appears as Apple’s dismissal of Flash was a canary in a coal mine. A prelude to it’s collapse in general.
I should mention that I am not really here to talk about Flash’s history. I am not a Flash scholar, nor am I interested enough in it to become one. So take what I have said with a pinch of salt. If that is what you are looking for, there are better sources for that content. I suggest starting with Adobe’s official blog, then the wikipedia.org articles, then follow their sources and read those — as well as random blog posts by internet weirdos like this one — they are always fun. What I am here to do is to talk about Flash as it relates to my experience as a game developer. The games that got me interested in it, and the games that got me out.
About me
A bit of background about me. I attended school up until the mid 2010’s, and grew up (when compared to my working class peers) relatively poor. I.e. no home internet and I had to play outside alot. Gasp! I’ll keep it vague because this is isn’t really about me, however the information is relevant. My first experience with the internet in general was in the mid 2000’s. Where it was largely a utilitarian space as far as I was concerned. This is because I never had the time to explore it at my leisure. My access was always in a public place. Ergo monitored, censored, and timed. Either at school in ICT (Information Computer Technology) class using the “Yahooligans” search engine (remember that?), or at the local library with that creepy moustachioed librarian woman breathing down my neck. Occasionally I could even be found at an internet cafe paying £1 for an hour of uncensored access whilst some indian dude watched what I did from his master console. Hi Mr Singh!
Consequently, my use of the internet was always objective or mission based. I went in not to explore and learn, but with an objective. Especially when I was paying for the privilege (and it is a privilege). I remember being at the internet cafe and booting up my collection of anime sites that allowed downloads (RIP cyber12.net) to get the latest 360p Horrible Subs copy of the Bleach or Naruto episodes, that just aired the previous week in Japan. I recall cramming as many of those ~50MB episodes (.RMVB video format), as well as Final Fantasy wallpapers, low quality D12 or Linkin park MP3s, and “kawaii ecchi” jpegs into a 256MB thumb-drive that I got second-hand from me mum. I would then take this bullshit home to my HP Pavilion A320N in order to fill it’s massive 50GB 3.5′ IDE hard drive, for my repeated media enjoyment. Life was simple back then.
So, what was I doing while the media files downloaded at a blazing 120KiB per second download speed? Well, I was playing Flash games of course! Keep up. I remember each episode download taking roughly half an hour, although I don’t know if the speed and file size numbers that I gave match up… probably not. The fact that I still (mostly) remember these numbers a decade later should tell you how much of an impression the experience left on my young supple mind.
Anyway, While the files downloaded, I’d hit up game sites. Websites, like: Newgrounds, Miniclip, Armourgames, and of course Kongregate. The usual suspects. What games did I play? Games like “Rebuild”, “Epic Battle Fantasy”, “Bubble Tank”, “Sonny”, “Armed with Wings”, or puzzle games like the “Escape the room” series; as well as the clones upon clones of GBA (GameBoy Advanced) tactical games like: “Final Fantasy tactics” and “Advance Wars”. Additionally I played excellent point-and-click titles such as the “Reincarnation” series, or Clickshake’s “Ballad of Reemus” series, or Zeebarf’s “A small Favour” series. These same quirky point-and-click puzzle-adventure games inspired me to create my own.
Why? Well because up until then I had only played MS-DOS point-and-click games. Like Sierra’s various “-Quest” series games. Think: “Police Quest”, “Space Quest”, “King’s Quest”, etcetera-quest. Additionally I played “Simon the Sorcerer” 1 and 2, “Sam & Max: Hit the Road”, and of course “Leisure suit Larry”. As an aside, I never played the famous Lucas Arts games like “Monkey Island” and “Day of the tentacle” until I was an adult. I am a victim ;_;.
Although the MS-DOS games sparked the love of the point-and-click adventure genre, their Flash counterparts brought the realisation home that I actually could do it too. They were fun, they had the heart of the older DOS games, but the technology was much more accessible, and they were significantly shorter. As far as I knew MS-DOS games were made using ritual possession via offerings to the Omnissiah. It was hard enough to install them and get them working properly, let alone make the bloody things. The learning curve involved was just far too sheer for my young self to effectively engage.
Whereas Flash used ActionScript3, and an IDE: named Adobe CS3. Heh, even rhymed. Sort of. ActionScript3 was as friendly as abstract programming languages come, and there were a plethora of online tutorials, both in the form of textual articles as well as youtube and dailymotion videos. This abundance of guides and media motivated me to “‘ave-arr-go!” as they say.
Developing Flash games
Developer resources for Flash media were abundant at the time. My favourite of which, is the open-source IDE (Integrated Development Environment) Flashdevelop! This was my IDE of choice because: 1) I couldn’t afford an official copy of Adobe Flash Professional (or Adobe Animate as they call it now), and 2) I didn’t trust the “unofficial” versions that I found. So FlashDevelop became my de facto IDE of choice and the open-source Flex SDK (Software Development Kit) as my .swf complier of choice. I should mention that this was also my first practical interaction with community driven open software, and it really opened my eyes to the liberation that it offered.
That is, not being tied to any particular company for one’s productivity tools. No cloud subscriptions, no periodic reminders to renew the lease, no “””anonymous””” telemetry phoning home… It’s actually a rather dangerous thing to get accustomed to, because it spoils a person when you realise how shit a lot of proprietary applications become with this bloat. I mean I understand why a lot of it is there, it’s just a shame that it punishes (inconveniences) the paying customer and not the pirate. Who’s most likely running a cracked version (in a virtual machine) without the bloatware. It’s all academic though, because I couldn’t afford it anyway. So it didn’t really matter what I thought about it at the time (or even now really).
The main disadvantage I recall Flashdevelop having when compared to Adobe Flash CS(-whatever), is that Adobe Flash had an animation timeline that it centrally used. This timeline was designed to have various Class objects attached to it at various points or frames. In AS3 an object class is used to encapsulate an entire source file in general. With regards to games: the online tutorials would attach a LoadingScreen.as3 Class to frame 0, then the MainMenu.as3 Class to frame 1, and so on. It does this without necessitating verbose instructions to the program as to how to handle them, as this was done automatically using the timeline. The idea is that when one frame terminated, an automatic call would be made to move to the next frame, and then run the attached classes and the methods contained within.
FlashDevelop on the other hand had far less visually accessible components (like the various art tools or timeline) when compared to the Adobe Flash IDE; and consequently it was less user friendly. At least initially. However once the learning curve was surmounted, it proved to be a very robust IDE. One thing that didn’t help young me, is the fact that the vast majority of the online tutorials were create specifically using the Adobe IDE; and unwittingly used features only present within that IDE — such as the aforementioned timeline.
For example: it took me quite a while to learn the correct techniques to create a functioning loading screen in FlashDevelop because of this. There was a lot of chopping up of other people’s code, then trail and error to get it working. And once it worked, to then to try to understand why in order to reliably replicate the method in future projects.
I remember managing source files in the FlashDevelop IDE being similar to the C++ IDEs I used at the time. (CodeBlocks, Eclipse, Bloodshed Dev-C++.) For example, having to first manually import other code files in order to make calls to their functions or add their objects to the stage. This is in contrast to the Adobe IDE which glossed over much of this type of stuff by using the timeline and a drag-and-drop interface. Where Users would drag an image onto the stage and then click on it to open a box where they’d add in any additional code. The Adobe IDE seemed like an interface designed for animators first and for most. That’s because it was. Whereas FlashDevelop was more of a programmers IDE. Where a lot of the animation tools of the Flash IDE were absent.
I realise that this is more a criticism of me rather than FlashDevelop, however Speaking of FlashDevelop and inconveniences. I do not miss the tedium of manually embedding large volumes of images with this IDE. Then casting them as “bitmaps”, to then place them into individual “movieclip” containers. All with mandatory unique names, by the way. This, in order to allow manipulation of the asset when it was finally added to the stage. At which point I had to manually assign their dimensions (width, height), alpha (transparency), and initial stage (x,y) location. To then use an external tweening library (forgot it’s name) for actually animating these images. Think sliding alpha gradients for flickering lasers, and gradual increase/decrease of an X position variable to make sliding doors open/close. Doing this for every image in a game got laborious quickly, and if I had to do it again I actually would have created helper functions to do it for me. Young me laboriously hard coded it all, and consequently learned good lessons.
Lessons on the difference between working hard and working smart. In this case, on making the time to create utilitarian recyclable functions. Ones that can take the various image’s stats as arguments and return what I wish. The strength of them is their recycle-ability, which leads to cleaner code and the avoidance of long lines of repeated hard-code. It would be instead just one line for each new image: citing the function call and the specific image’s stats as arguments for that function. But I guess a lesson learned the hard way is a lesson learned forever.
Developer migration
It seems like around 2011-2013 was the time when the Flash exodus really begun. Known creators begun to either drop off or change to other things. Around here in my opinion is also when the golden age of Newgrounds effectively ended. You can see from the example of popular Flash animators of the time (Zone and Tiarawhy), how their content either dropped off and/or changed significantly in a bid to reinvent themselves.
example of a creator’s flash media submission fall off
I remember when it came time to move on from the Adobe Flash player and browser games in general. I tried out Adobe Air because like many developers who started out with Flash games, I wished to pivot to creating games for other platforms. For me it was the desktop. I wanted to make “proper” point-and-click games, and hopefully earn a buck or two doing it.
Even back then the public perception of Flash games, was as a means of getting a developer’s feet wet in making games and little more. Sooner or later if the person is serious about making games — and serious about making a living, making games; then they have to move on to another platform. Many migrated to making mobile games for iOS and Android. Even in cases where the developer’s still wanted to make browser games, there were better (more lucrative and future-proof) technologies/paths to that.
I have seen many developers move on to using the emergent Unity technology during this transitory period. Unity allowed the creation of multiplatform programs whilst still using the same core codebase; just exporting it into different media formats appropriate to their target platforms. This includes desktops (Windows, Macintosh, and Linux), mobile platforms (Android, iOS), and in this case even web browsers by using the Unity Web Player. At the time I opted to stick with my current tooling, because the idea of being “set-back” by having to learn another system (Unity and C#) would stifle my ability to actually finish games. Its only with time that I have understood that a person never stops being the student. In order to progress optimally in any discipline one should not shy away from learning new things when the opportunity makes itself apparent. If I did keep up with making games, I would have had to retool anyway. Better to eat crow while it’s still young and tender.
I believe my first introductions to the Adobe Air technology was via two games in particular. Edmund McMillen’s original “The Binding of Isaac” and Jasper Byrne’s “Lone Survivor”. Although other devs followed a similar path like Amanita Design and their game “Machinarium”. But the prior two are the one’s I had hands on experience with. Anyway, once I purchased a copy their games, I found the core .swf files in their source folder and a native executable that called them. Along with a bunch of Adobe Air library files. I remember that the .swf files could also be played using a local version of Flash player; bypassing the native executable in the process. Meaning that Adobe Air itself, as I understand it just wraps the .swf file with an .exe.
So in an attempt to ape them, I downloaded the Air SDK and used it. It wasn’t hard to import Air into FlashDevelop and create a desktop app using it. I recall there being minimal code alterations in the process. I should state that I did so initially as an experiment, but I will do so again and host the .zip archives on this site once/if I can find my source files again. For posterity, and as a means of providing anyone interested with a playable copy of my early games.
Closing statements
That’s all I really have to say when it comes to Flash. I loved the games I played as a child. They introduced me to many new genres of games. From Zombie shooters, to puzzle games. Consequently I have a lot of good memories with it. I never really cared or noticed when websites stopped using Flash for banner adverts or for delivering videos (like youtube.com), as it really didn’t matter to me. I did however notice, when Unity web player, Java web player, and HTML5 games slowly started to become more and more prevalent; or when Flash animation died. And for good reason.
Flash is very limited. I remember the frustrating media file size embed limits. Well, you might say that I should’ve just used a loader class to load in external media as needed, but that had it’s own associated issues. Such as the program not finding the files (once online) that you uploaded with it. And some sites at the time would only allow one file upload (the .swf file) with no supporting media files. Where others had a size limit for the actual .swf file itself. I remember having to strip out a lot of embedded music (.mp3) out of my game “Last Life: The Blue Key” because kongregate had a .swf file size limit.
For many reasons like this, Flash got over taken by it’s competitors in it’s space. Then for other reasons (think Steam games sales, Apple iOS games, and plummeting ad revenue), the market for browser games in general fell off. Making it a space largely for new developers to cut their teeth and little else. Now, I don’t think it’s even that.
That makes me wonder; what will happen to all these browser game sites like Newgrounds and Kongregate. Although they host games using various technologies; their decade plus backlog of games is going to be in the Flash format. Their games catalogue is going to get gutted. And I don’t think that many (if any) developers are actually going to back to a game they made (probably as a kid) 10 years ago and remake it for an unprofitable platform. I know I am not. I have moved on from games in general, and even if I got back into it (which I want to), I’d work on a new property. I’d honestly be surprised if these sites still exist in a couple of years because of this.
Still it’s not all doom and gloom. Although Kongregate seems content to let their Flash content die on the vine, Newgrounds created a custom Flash player just for this reason. Although it seems like a bit of a patchwork or stopgap measure. It is much better than nothing.
Anyway, the good Flash games, the one’s people loved from this era. They’ll be preserved. The online copies can be stripped from the web browser (while they are there). Saved, and played locally using a desktop version of Flash player. And for the one’s people didn’t care to preserve. Well, like so much else in life: they get lost to the sands of time.
Thank you for reading.
One more thing…
This made me laff, but mostly because Flash is Ded. RIP.
References, links, further reading
https://web.archive.org/web/20171202123704/https://theblog.adobe.com/adobe-flash-update/ https://www.cnet.com/products/hp-pavilion-a320n-athlon-xp-2800-plus-2-08-ghz-monitor-none-series/ https://www.flashdevelop.org/ https://blog.adobe.com/en/2019/05/30/the-future-of-adobe-air.html#gs.na44sx https://helpx.adobe.com/security/products/flash-player.html https://en.wikipedia.org/wiki/Adobe_Flash https://en.wikipedia.org/wiki/Adobe_AIR https://en.wikipedia.org/wiki/FlashDevelop https://en.wikipedia.org/wiki/Apache_Flex https://en.wikipedia.org/wiki/MS-DOS https://en.wikipedia.org/wiki/Open-source_software https://en.wikipedia.org/wiki/RMVB https://en.wikipedia.org/wiki/Edmund_McMillen https://en.wikipedia.org/wiki/Comparison_of_HTML5_and_Flash https://en.wikipedia.org/wiki/HTML5 intro to tweeining: https://www.peachpit.com/articles/article.aspx?p=20965 example of Adobe IDE specific tutorials: https://helpx.adobe.com/animate/using/shape-tweening.html “Thoughts on Flash” by Steve Jobs Primary Source: https://www.apple.com/hotnews/thoughts-on-flash/ Secondary Source: https://appleinsider.com/articles/10/04/29/apples_steve_jobs_publishes_public_thoughts_on_flash_letter Secondary Source: https://medium.com/riow/thoughts-on-flash-1d1c8588fe07 https://en.wikipedia.org/wiki/Thoughts_on_Flash https://en.wikipedia.org/wiki/HTML5#%22Thoughts_on_Flash%22
#0011: Copy-paste of “Thoughts on Flash” by Steve Jobs (2010)
Preamble
This is a transcription of an open letter written in 2010 on the subject of Adobe Flash by the CEO of Apple of the time: Steve Jobs. I paste it here for referential and posterity purposes.
Rather annoyingly Apple has since removed the original article from their official company website, so this is a copy from a secondary source. An archive website called: web.archive.org (A.K.A wayback machine). This was then verified by comparing it with copies from other website articles published around 2010. Check the links and references section for specifics. I think this is a good illustration of the fragility of information on the internet. When primary (controlled) sources can suddenly disappear; we have to rely on secondary sources and their general trustworthiness.
(START QUOTE)
Thoughts on Flash
Apple has a long relationship with Adobe. In fact, we met Adobe’s founders when they were in their proverbial garage. Apple was their first big customer, adopting their Postscript language for our new Laserwriter printer. Apple invested in Adobe and owned around 20% of the company for many years. The two companies worked closely together to pioneer desktop publishing and there were many good times. Since that golden era, the companies have grown apart. Apple went through its near death experience, and Adobe was drawn to the corporate market with their Acrobat products. Today the two companies still work together to serve their joint creative customers – Mac users buy around half of Adobe’s Creative Suite products – but beyond that there are few joint interests.
I wanted to jot down some of our thoughts on Adobe’s Flash products so that customers and critics may better understand why we do not allow Flash on iPhones, iPods and iPads. Adobe has characterized our decision as being primarily business driven – they say we want to protect our App Store – but in reality it is based on technology issues. Adobe claims that we are a closed system, and that Flash is open, but in fact the opposite is true. Let me explain.
First, there’s “Open”.
Adobe’s Flash products are 100% proprietary. They are only available from Adobe, and Adobe has sole authority as to their future enhancement, pricing, etc. While Adobe’s Flash products are widely available, this does not mean they are open, since they are controlled entirely by Adobe and available only from Adobe. By almost any definition, Flash is a closed system.
Apple has many proprietary products too. Though the operating system for the iPhone, iPod and iPad is proprietary, we strongly believe that all standards pertaining to the web should be open. Rather than use Flash, Apple has adopted HTML5, CSS and JavaScript – all open standards. Apple’s mobile devices all ship with high performance, low power implementations of these open standards. HTML5, the new web standard that has been adopted by Apple, Google and many others, lets web developers create advanced graphics, typography, animations and transitions without relying on third party browser plug-ins (like Flash). HTML5 is completely open and controlled by a standards committee, of which Apple is a member.
Apple even creates open standards for the web. For example, Apple began with a small open source project and created WebKit, a complete open-source HTML5 rendering engine that is the heart of the Safari web browser used in all our products. WebKit has been widely adopted. Google uses it for Android’s browser, Palm uses it, Nokia uses it, and RIM (Blackberry) has announced they will use it too. Almost every smartphone web browser other than Microsoft’s uses WebKit. By making its WebKit technology open, Apple has set the standard for mobile web browsers.
Second, there’s the “full web”.
Adobe has repeatedly said that Apple mobile devices cannot access “the full web” because 75% of video on the web is in Flash. What they don’t say is that almost all this video is also available in a more modern format, H.264, and viewable on iPhones, iPods and iPads. YouTube, with an estimated 40% of the web’s video, shines in an app bundled on all Apple mobile devices, with the iPad offering perhaps the best YouTube discovery and viewing experience ever. Add to this video from Vimeo, Netflix, Facebook, ABC, CBS, CNN, MSNBC, Fox News, ESPN, NPR, Time, The New York Times, The Wall Street Journal, Sports Illustrated, People, National Geographic, and many, many others. iPhone, iPod and iPad users aren’t missing much video.
Another Adobe claim is that Apple devices cannot play Flash games. This is true. Fortunately, there are over 50,000 games and entertainment titles on the App Store, and many of them are free. There are more games and entertainment titles available for iPhone, iPod and iPad than for any other platform in the world.
Third, there’s reliability, security and performance.
Symantec recently highlighted Flash for having one of the worst security records in 2009. We also know first hand that Flash is the number one reason Macs crash. We have been working with Adobe to fix these problems, but they have persisted for several years now. We don’t want to reduce the reliability and security of our iPhones, iPods and iPads by adding Flash.
In addition, Flash has not performed well on mobile devices. We have routinely asked Adobe to show us Flash performing well on a mobile device, any mobile device, for a few years now. We have never seen it. Adobe publicly said that Flash would ship on a smartphone in early 2009, then the second half of 2009, then the first half of 2010, and now they say the second half of 2010. We think it will eventually ship, but we’re glad we didn’t hold our breath. Who knows how it will perform?
Fourth, there’s battery life.
To achieve long battery life when playing video, mobile devices must decode the video in hardware; decoding it in software uses too much power. Many of the chips used in modern mobile devices contain a decoder called H.264 – an industry standard that is used in every Blu-ray DVD player and has been adopted by Apple, Google (YouTube), Vimeo, Netflix and many other companies.
Although Flash has recently added support for H.264, the video on almost all Flash websites currently requires an older generation decoder that is not implemented in mobile chips and must be run in software. The difference is striking: on an iPhone, for example, H.264 videos play for up to 10 hours, while videos decoded in software play for less than 5 hours before the battery is fully drained.
When websites re-encode their videos using H.264, they can offer them without using Flash at all. They play perfectly in browsers like Apple’s Safari and Google’s Chrome without any plugins whatsoever, and look great on iPhones, iPods and iPads.
Fifth, there’s Touch.
Flash was designed for PCs using mice, not for touch screens using fingers. For example, many Flash websites rely on “rollovers”, which pop up menus or other elements when the mouse arrow hovers over a specific spot. Apple’s revolutionary multi-touch interface doesn’t use a mouse, and there is no concept of a rollover. Most Flash websites will need to be rewritten to support touch-based devices. If developers need to rewrite their Flash websites, why not use modern technologies like HTML5, CSS and JavaScript?
Even if iPhones, iPods and iPads ran Flash, it would not solve the problem that most Flash websites need to be rewritten to support touch-based devices.
Sixth, the most important reason.
Besides the fact that Flash is closed and proprietary, has major technical drawbacks, and doesn’t support touch based devices, there is an even more important reason we do not allow Flash on iPhones, iPods and iPads. We have discussed the downsides of using Flash to play video and interactive content from websites, but Adobe also wants developers to adopt Flash to create apps that run on our mobile devices.
We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.
This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.
Flash is a cross platform development tool. It is not Adobe’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps. And Adobe has been painfully slow to adopt enhancements to Apple’s platforms. For example, although Mac OS X has been shipping for almost 10 years now, Adobe just adopted it fully (Cocoa) two weeks ago when they shipped CS5. Adobe was the last major third party developer to fully adopt Mac OS X.
Our motivation is simple – we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen. We want to continually enhance the platform so developers can create even more amazing, powerful, fun and useful applications. Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform.
Conclusions.
Flash was created during the PC era – for PCs and mice. Flash is a successful business for Adobe, and we can understand why they want to push it beyond PCs. But the mobile era is about low power devices, touch interfaces and open web standards – all areas where Flash falls short.
The avalanche of media outlets offering their content for Apple’s mobile devices demonstrates that Flash is no longer necessary to watch video or consume any kind of web content. And the 200,000 apps on Apple’s App Store proves that Flash isn’t necessary for tens of thousands of developers to create graphically rich applications, including games.
New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too). Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind.
