The last major version of Christianity, released in the mid 1750's, was made primarily active only one day per week, in compliance with the major social architectures of the day. The "Sunday School" feature made it vastly popular. The new "evangelism" module, the most effective since the "mission" variant of Christianity 3 in the 800's, made release 6.0 and its variants one of the most powerful programs available at the time.
Christianity 6.0 was, however, made backward compatible with previous versions. 5.0 had been targeted at primarily agrarian architectures and therefore, while the program was structurally compatible with active users, the program did not disallow passive types. While this was attractive to users with large volumes of physical input offline, it was less well suited to a sedentary population. As the social architecture moved towards more static cycle times, many complained that Christianity 6 had serious "downtime" problems.
According to the Society's announcement, Christianity 7 will abandon compatibility of the user interface, although strict data and functional compatibility will be maintained. Previous versions were based primarily on batch input, and users with buffers of insufficient size often dealt with input problems, due to the lack of an implemented flow control, by rejecting all input in excess of the buffer size. This meant that the same batch input could be recycled as new input several times, and it often was. While this was acceptable to most users, those with faster platforms found it difficult to deal with. Over several releases, many of those wishing greater input had addressed the matter by "piping" input from several sources at once, but latterly users had been vociferous in their complaints regarding the bottleneck, and many simply abandoned the program for systems with greater input options.
The new user interface is stated to be much more interactive. As well, the user will have greater responsibility for the overall performance of the system. In the past, most system maintenance was done either by the vendor or by specially trained system administrators. As neither the vendors nor the administrators were able to work directly with applications on the system, requests for user support were often answered vaguely, if at all. The Society is calling for more training centres dedicated to user applications training rather than more training for system administrators. (It is interesting to note that this type of training was widely available in the late 1700's and early 1800's; the pinnacle of activity for release 6.)
Because of this radical change in interface, the Society is calling for assistance from both users and interface design experts in drawing up the specific features for the layout. All submissions are to be directed to: