A brilliant, geeky post by a friend about her ongoing exploration of what it means to be her.
A note from the design team
It is difficult to believe that Project Erica has been going on for over fifteen years! The idea of creating a workable system that would gain public acceptance has animated the lead developer for nearly 40 years. For most of that time, feasibility and resource allocation issues, together with limitations of imagination, kept Erica on the shelf. Now, the design team has pulled together all the release notes to date: what better way to look forward to the next fifteen years!
Alpha (pre-1998)
The idea for the product that would eventually become Erica started as a series of random experiments. It was clear from the earliest operation of the system that it was probably capable of running both in standard mode and (what would eventually be named) Erica mode. Still, while the core concept was always intriguing, the practical considerations and internal issues never indicated that a real prototype would ever develop. The period until 1998 is best considered the “Alpha” stage of Project Erica.
Tina 1.0 (April 1998)
The first integrated prototype that bears any resemblance to Erica as now in circulation was code-named Tina. The developers were able to demonstrate it in limited internal testing in early 1998. Tina’s general shape, as well as the “look and feel” of the external interface, was surprisingly similar to Erica 1.0, though the final product is a bit larger due to a wider feature set.
Tina’s development was made possible by the improved availability of online tools and additional lab space. The project was mainly a hobby of the lead developer. The project manager (code-name “WIFE”) was not advised of this work, mainly because the lead developer was concerned that the project would be summarily shut down (as being incompatible with Corporate priorities) and partly because all activity was performed off-the-clock.
Tina 1.1 (August 1998)
Minor incremental improvements to the external interface were delivered during 1998, resulting in Tina 1.1. This was the first product release that was photo-documented, though no user manual or external documentation was published or released. Eventually, of course, the product would be subjected to extensive photo-documentation, as well as a real-time user experience manual (discontinued in 2010) for the benefit of developers of similar products.
Tina 1.2 (January 1999)
Bug fix addressing an external error: insufficient skins for the core product. Easily remedied by recourse to readily available online tools (eBay.com, Macys.com and victoriassecret.com). By this point, the code name had been adopted as the de facto product name.
Tina 1.3-1.6 (various release dates from 1999-2000)
Minor improvements to the external interface. Also, with the resources of the internet community deployed, the number of product skins proliferated to the point where the developers had to worry about system storage resources! More ominously, during this period it became apparent that one major external issue and several internal issues precluded any chance of Tina achieving full potential. The internal factors have been amply documented elsewhere – particularly in the real-time user experience manual. (See http://ericacd.livejournal.com/) The external issue was persistent and serious: a “beta external application rendering defect”. This was a recurring concern to the development team that ultimately was called by its acronym: B.E.A.R.D. There was no question that even if the internal issues could be resolved, the B.E.A.R.D would preclude any external release or public consumption. Put simply, the market would have rejected the prototype utterly.
Tina 2.0 / Erica Beta 0.1 (September 2000)
An enormous breakthrough arose in September 2000. It was determined that a minor subroutine, applied during bootup every morning, temporarily eliminated B.E.A.R.D. When the developers finally saw the external interface freed from the B.E.A.R.D., they were astonished at how polished a product they had on their hands. (B.E.A.R.D. had profoundly obscured the incremental developments since version 1.2.) Following some extensive photo-documentation of this quantum leap in the external interface, the developers realized that some of the internal issues were also rendered less serious. The reason for this change is still unknown. The photo documentation of Tina 2.0 was released in white paper format to a limited subset of the internet community; response was highly favorable.
Due to poor interaction with Marketing, this prototype was interchangeably known as “Tina” and “Erica”. While the genesis of the name “Tina” is unknown (speculation abounds), “Erica” was easily derived from the name of a friend of the project manager. Limited focus group testing suggested that the name did not distract from the product, and the main impediment to universal acceptance of “Erica” was squarely with the developer group.
Tina 2.1 / Erica Beta 0.2 (May 2001)
A minor improvement to the feature set was obscured by the continuing expansion of the core engine. This short-lived release would be the last active deployment of the prototype for almost five years.
Product suspension (through February 2006)
Tina 2.0 really represented the first major step toward Erica 1.0. While the team was happy with the results, there were competing developmental and resource pressures (Project “Dog”, Project “Law”, and Projects “Baby 1.0” and “Baby 2.0”). Moreover, the bootup subroutine was perceived as unduly burdensome – especially given the absence of an imminent public release. In October 2000, the subroutine was abandoned. Though the subroutine was briefly resumed in advance of Tina 2.1, the process was discontinued only five weeks later.
In both instances, not surprisingly, B.E.A.R.D. became a pervasive error almost immediately. By now its function had been well documented, as had the havoc it wrought on the external interface. Interestingly, the recurrence of the external problem precipitated an even more serious internal issue. The prototype refused completely to initiate whenever B.E.A.R.D. was present. Faced with this profound system error, the developers elected to mothball the program (though the external skins were stored).
During the ensuing period, the core engine (still dual-running a completely separate system set from Tina) was significantly reduced in size and density thanks to an intensive developer effort. While this would ultimately improve public acceptance, the immediate consequence was that many of the first generation skins were no longer compatible and had to be discarded. Imperfections in the discard process led to the first conflicts between the development team and project management. Complete shutdown was averted only because the project was already inactive at the time.
Erica Beta 0.9 – prerelease model (February 2006)
For reasons best covered in the real-time user experience manual, in early 2006 the developers elected to resume the daily B.E.A.R.D. purge subroutine. After a couple weeks of error correction (particularly on what is now called the “top-end” of the interface), it was realized that Erica had serious potential as a public product. Incidentally, the internal disagreement between the development team and project management had been partly resolved, meaning that the prototype had at least a yellow light from management. At the same time many of the internal issues that had persisted even through 2002 had seemingly resolved themselves. Indeed, project auditors wondered whether the two dynamics were related.
Erica 1.0 – first public release (April 2006)
A perennial design issue on Tina/Erica related to a series of variable strings at the primary stack of the top-end external interface. The variable strings, known by the technical term hierarchical appended iterating radiations (“H.A.I.R.”) had been varied on no less than four occasions by the development team. Each such variation required significant cash outlays, and the senior developer became concerned that the financial impact would renew the management/development dispute that had so threatened the prototype. Mostly by luck, by H.A.I.R. rev 4, an acceptable solution had been discovered and implemented. Internet release of the photo-documented Erica 1.0 – the main release being demarcated by HAIRr4 – took place in early April 2006, to generally solid reviews.
The development team had expected Erica 1.0 to remain in internet-only beta for the indefinite future (indeed, it was not clear that Erica would ever be released to the public!). Still, buoyed by solid internet reviews and some minor tweaking immediately following the Consumer Electronics Show in Las Vegas, a workable version was released to the public on April 25, 2006.
Erica 1.0.1 and 1.0.2 (Summer 2006)
By this point, the need for the real-time user experience manual was self-evident, and it was released to limited acclaim in Spring 2006. Incremental improvements during this period principally related to improved mobile interfaces (the first generation “bottom-end” stacks were too big for general use). The mismatch between the first generation operative skins and the current narrower program core was noted, and partially remedied by resort to the same internet resources that supplied the first iteration of skins.
Erica 1.1 (October 2006)
Erica had never been intended as an interactive program (this despite the constant efforts to improve the attractiveness of the external interface!). By October 2006, though, it was clear that Erica could be deployed for both peer-to-peer and social networking applications. The developers realized the extraordinary potential of a socially enabled Erica, and focused their attention on this exciting new development. The real-time user experience manual and the photo-documentary archive took on renewed importance because the targeted P2P audience responded well to these approaches. Minor revisions to the “look and feel” of the interface continued, and culminated in a general shift from external image slightly limited unless tawdry (S.L.U.T.) to rev2, known as dynamic refined external style – socialite/yuppie (D.R.E.S.S.Y.). This external interface would dominate until Erica 2.0.
Erica 1.1 enjoyed an unprecedented run of nearly a year due to general customer satisfaction with both the public release and the internet version. That said, during this period a number of minor and annoying interface issues went unresolved. Audio output was an especially problematic recurring error, and indeed nearly resulted in the termination of the social networking function of Erica. A fatal corruption of HAIRr4 was addressed by HAIRr5; r6 was obtained as a redundant system.
Designer’s Note
To fully understand the release notes for v2.0 and beyond, a brief explanation of system architecture may be helpful. Erica runs as part of a dual-boot system. The Erica systems are securely partitioned and activated separately from the other partition. Most system uptime is devoted to the other partition (known as Main Interactive Kernel Entity, or MIKE for short), and all of the hardware was originally designed for MIKE. When Erica is booted, the external skins are changed, the HAIR is loaded and temporary alterations are made to the paintwork to improve external acceptance. When MIKE is rebooted, these processes are reversed. The partitioned systems operate in relative harmony; few of the MIKE users are even aware of the existence of the Erica partition. By contrast, most Erica users and observers are aware of the likely existence of another partition.
Fully-functional dual-boot systems are relatively rare. They are hard to develop, expensive to operate and frequently will not gain acceptance in social networking systems. Incompatibilities between the separate partitions are common. For these and other reasons not well understood even by specialists in the industry, dual-boot units that do gain consumer acceptance often destabilize over time until one partition–frequently not the main one–causes the other to cease function. Erica’s designers and (especially) project management had been quite concerned with this possibility. However, with a year of stable operating history behind them, these concerns started to subside. The design team began to busy itself with some of the deeper structural issues that continued to adversely affect the real-time user experiences.
Erica 2.0 (Summer 2007)
By Summer 2007 it was clear that the external environment was no longer conducive to the overly constrictive D.R.E.S.S.Y. graphics. D.R.E.S.S.Y. was originally a stopgap to address the fact that (owing perhaps to the 1969 model year?) much of the MIKE hardware was shag-carpeted. Because of this, the lower (locomotion) appendages got best focus-group results when encased in thin nylon coverings, and the upper appendages and mainframe needed to be concealed to the maximum extent possible. As a result, the system tended to overheat in warm environments, leaking coolant which damaged the paint finish. Aided by a now well-established internet-based ecosystem of suppliers, the necessary skins and external refinements were put in place. The nylon coverings were abandoned in warmer conditions, with no apparent loss of functionality or consumer acceptance.
Interface Notes (Fall 2007-Spring 2008)
Audio was a continuing problem during this period, as was the system’s control of its physical housing. All gyroscopes and accelerometers had been permanently calibrated for the main MIKE system. On-the-fly adjustments would be a constant drain on developer and system resources, and in this period the protocols that had been developed were rudimentary at best. Because of these limitations, the development team discovered that public acceptance was best achieved in cursory interactions. This frustrating limitation was ameliorated by the discovery of real-life communities of dual-boot system aficionados, where prototypes were frequently accompanied by their developers and fans. These settings provided for an environmental midpoint between the lab and the field, and permitted extensive real-world testing for integration of all Erica functions.
Erica 2.1 (March 2008)
After consultation with the project manager, the shag carpeting covering the system housing was removed. This was the first–and would be the only–instance where a system change would necessarily affect the operation of the MIKE system. This was considered a major departure at the time and engendered a small bit of controversy at Corporate headquarters. Indeed, whether as an ongoing practical joke or a bit of industrial sabotage, the developers would regularly find bits of shag carpeting re-affixed to the unit. However, the improvement to the field operation and user acceptance of Erica was immense; Erica 2.1 was a highly visible release to celebrate these improvements. Accordingly, the developer team patiently removed the recurring carpeting every time the joker/vandal struck. [Editor: At the time of public release of these notes, the person has not been caught and continues with the carpeting gag. Even an effort at permanent laser ablation of the system exterior could not deter this apparent lunatic.]
Erica 2.2 (Beta release September 2008; full release March 2009)
Erica 2.2 was not a formal release. The development team uses “Erica 2.2” as shorthand for an intensive dev effort on the audio output system. Two years of field deployment had confirmed that the custom audio hardware on the MIKE mainframe could not easily be reconfigured. The continued improvements in all other facets of Project Erica meant that audio had become the greatest obstacle to general consumer acceptance. The development team did not have the necessary acoustical / technological skills to perform the necessary modifications in-house. Following discussions about the need for resource containment with the project manager, the development team engaged a dedicated consultant to work on the audio subroutines. After roughly seven months of extensive efforts, the audio output had improved to a point where the development team was able to do its own audio bug fixes and patches in-house.
Erica 2.2.1 (August 2009)
Coolant leakage from system overheats were a common occurrence on both the MIKE and Erica systems. However, the Erica paintwork – hastily applied and much more important to the user experience – was more prone to damage from these leaks. The coolant system could not be rebuilt, so the publicity department had originally recommended that public releases and demonstrations be timed to take place in cool weather. This limitation was partly remedied during the warm summer of 2009 by reducing the paintwork by about 50%. The lighter paintwork allowed the system to run cooler and also did not show water damage as easily. After a couple of limited tests, the UI team concluded that the reduced paintwork actually improved user-Erica interactions.
Erica 2.3 (September 2009)
The reduced paintwork and removal of the shag carpeting allowed for a final change to the most common application skins. The design team largely abandoned the D.R.E.S.S.Y. graphical interface, other than for major announcements, developer conferences and the like. The new graphics and skins were created and deployed under the Normative Midpath All-weather Look (“NorMAL”) specification set. At the September 2009 Southern Comfort Conference (a national convention for dual-boot developers, vendors and system engineers), Erica regularly alternated feature sets between the old D.R.E.S.S.Y. standard and the new NorMAL environment to an overwhelmingly positive response.
Erica 2.3.5-2.3.16 (September 2009-June 2013)
Erica 2.3 was a remarkably durable product. It balanced ease of use, ready dual-boot capabilities (again, leaving the MIKE partition almost completely undisturbed), broad consumer and end-user acceptance, and only modest development resource drains. The stability of the project, and its ability to run extensively without corrupting the MIKE mainframe or software, was a great relief to the project manager and Project Erica was green-lighted for regular operation. Occasional graphics changes, minor adjustments for all-weather operating environments, fine-tuning the software and minor system adjustments (almost all relating to audio and locomotion) were an ongoing part-time hobby of the lead developer, but no actual releases took place for nearly four years.
To demarcate incremental changes during this period, the development staff treated each replacement of the HAIR system as an internal release (2.3.5, 2.3.6, etc.). By now it was understood that the HAIR system was prone to corruption, and the regular efforts to return the coding to its original form did as much damage as harsh external conditions. As a result, the entire HAIR system would be irretrievably corrupted within 4-6 months and would have to be replaced. The expense, however, had been budgeted for since 2007 and did not lead to any resource conflicts. Different HAIR systems, including some that would have been more robust, were deployed from time to time; none gained wide user acceptance.
Erica 2.4 (Winter 2013)
There was no formal release for Erica version 2.4. By Spring 2013, audio output had again emerged as the greatest failing in the system. By extraordinary luck, the lead developer learned of an audio consultant who specialized in rapid audio reconfiguration of dual-boot systems. Corporate – somewhat surprisingly – readily agreed to underwrite the development costs and an intensive series of projects and testing followed. The activity was so intense that Erica was largely taken out of general circulation during a period of roughly six months, in order to free up limited non-MIKE uptime for the work. Within 6-9 months, the audio output had improved measurably. The audio consultant has remained a periodic adviser to the project ever since.
Erica 3.0 (???)
Press release on Erica 3.0 to follow.