Over 24 years ago I learned about a Mac application called »Frontier«. This application taught me, that the Internet is actually a programmable environment.
I think originally it was created as an application development tool in 1992 for automating MacOS with a script language called UserTalk (before Apple came up with its own script language called AppleScript).
Frontier was a genius concept invented by Dave Winer, because it was not only a script language (called „UserTalk”). It also came with a object database and an editor to edit scripts as outlines (something some modern IDEs try to adopt to better organize source code!). The scripts were edited and stored as objects in the very same database. The database could contain other stuff like texts, outlines, binary data, simple values — all in a hierarchical structure. An object in the hierarchy would automatically be accessible in the script like a variable. It was all self-contained.
The hierarchy was fundamental: Everything was organized as collapsible and expandable outlines. The database, the scripts and some texts could be presented and edited in a text window in outline fashion. Outlining is a good way to break down things — and much of what we do in our heads is basically creating meaning by deciding what is inside or outside of a concept. We learned to think this way when we learned to think & understand (or use computers).
It even could interpret and execute AppleScript. But compared to Apples own AppleScript UserTalk was much faster in Frontier.
If Apple would have chosen to include Frontier in MacOS it would really have changed the Internet. AppleScript never really took off, because it was missing a good environment to develop and without a good object oriented persistent storage it always felt like just a macro language to automate some OS tasks.
End of Frontier?
In the 90ies there were other people working with Dave Winer on Frontier at a company called UserLand. Brent Simmons was one of them and he inessential.
UserLand was the company that continued to distribute Frontier (and some applications based on its scripting language). Dave Winer convinced UserLand to open source Frontier as Userland was marketing applications based on Frontier (Manila and Radio).
But there were only few people actually contributing to the Frontier base application. And while the operating systems evolve the original Frontier code does not compile on new OS releases. No one was maintaining it.
I was occupied with teaching and other projects, so I lost track of Frontier.
So what is the state of Frontier today?
The frontierkernel.org Community has not changed anything since 2007. There was effort to better talk with SQL databases. But this wiki has not been maintained and most of the pages are not accessible. There has been some discussions on the SourceForge site of the project though.
Hello World! Processing is a documentary on creative coding that explores the role that ideas such as process, experimentation and algorithm play in this creative field featuring artists, designers and code enthusiasts. Based on a series of interviews to some of the leading figures of the Processing open programming platform community, the documentary is built itself as a continuous stream of archived references, projects and concepts shared by this community.
It is the first chapter of a documentary series on three programming languages — Processing, Open Frameworks & Pure data — that have increased the role of coding in the practice of artists, designers and creators around the world.
The series explores the creative possibilities expanded by these open source tools and the importance of their growing online communities.
Apple has released the iPhone SDK. The 2.1 gigabyte download is free after registration and includes the latest Developer Tools as well.
I personally don’t use an iPhone. Being able to hack it (or get third party software for it) was a stopper for me. Another argument against the iPhone was the rather limited storage space — 4 and 8 gigs simply did not seem enough space.
Apple still wants to retain some control over which apps are pushed on the phone, but it seems the upcoming operating system of the iPhone has already been hacked. People may be able to install software independently from Apple (e.g. to remove a SIM card lock) on a hacked phone.
But looking at the developer site for the iPhone simply does it right. I get a clear product, a very readable documentation and easy to digest tutorials – developing hardware and software together again pays out in a consistent product.
The Android SDK on the other hand is lacking the simple question: How can I get started (I mean really)? What devices can I deploy an Android application on? In fact the Android FAQ states that there are no phones that Android is running on. So who is supporting Android? Why should I spend time on developing for a theoretical market? Android is nothing more than an approach to an upcoming problem that Apple has already solved from A-Z.
That is the reason why Apple is succsessful: They offer solutions – not concepts.
People that think the stylishness of their products are key to Apple’s success don’t know much about Design.
libavg is a very interesting package for multimedia installations:
libavg is a high-level multimedia platform with a focus on interactive installations. It is meant to pick up where Macromedia Director leaves off and gives you high-quality hardware-accelerated visuals as well as easy and flexible authoring, testing and deployment. libavg integrates well with other open-source solutions for sound, networking and hardware device support, resulting in a complete and well-integrated package. It uses an xml-based layout language for screen design and python as scripting language.
libavg aims to replace Macromedia Flash or Macromedia Director with following design goals: high-quality visuals, high-quality sound, quick authoring, support for a broad range of systems and openness for expansion (see also the features page for details).
And best of all: it uses Python, which is a clean, simple, fast and easy to learn object-oriented scripting language.
It took me longer to write this blog post than it took to create this Flickr application shown above (well, at least for the guy doing that demo). I’d like to see a demo of a similar applications that is as much fun to watch from the J2EE or PHP crowd.
As it currently stands, the framework is certainly not ready for prime-time, and if it’s the sort of framework you’d otherwise find useful, we’d encourage you to investigate it and offer constructive feedback.
Backbase appears to be a commercial but extremely clean and well designed framework with impressive examples (look in “Demos”) and documentation. But it is not compatible to Safari and Opera yet (which is bad for a 3.1 release I’d say, but they claim to be working on it). If a framework doesn’t take the burden of browser dependency away from the developer (or the user if the developer doesn’t care) then the nicest framework is worth almost nothing. It might be something to play with. Backbase works by applying styles and behavior to either simple HTML elements or custom Tags within an own XML namespace (a look at their Backbase explorer inside “Demos” shows what that means). There is a free community edition, but commercial licenses seem to be somewhat pricy.
Script.aculo.us has also some good demos – not as complete as Backbase, but much better than Dojo (see for instance the effects demos). It is distributed with some kind of MIT license (free to be used for anything but the copyright information must be kept). Script.aculo.us has also some connection to Ruby: Ruby on Rails uses the framework and they run their site with a Ruby-based Wiki called Instiki. This framework has also some prominent examples to show: 37signals.com obviously created their much-talked-about-lately applications with it. From the examples I have seen up until now Script.aculo.us seems to be fully compatible with Safari which would be a big plus compared to the other frameworks.
MochiKit seems to be very compatible as well. It is also distributed either the MIT license or the Academic Free Licence. This framework is more related to the Python community since TurboGears uses it to provide something like Script.aculo.us does for Ruby on Rails. The demos are better than the ones by Dojo but not as slick as the ones of Script.aculo.us or Backbase.
I imagine a future where a developer of a web application could say something like “take this dataset and provide it as shoppable items in a sortable table to the user with a live recording of all selections to the shopping cart” in few lines of code. The visual look of the resulting web page should be 100% CSS based. Developers happy. Designers happy. But I suppose it’ll take another 1-3 years to achieve that level of integration.
I think the next 6-12 month we will see an incredible buzz about web application frameworks – some on the server side and some on the side of the client:
OpenLazlo is competing with Macromedia Flex. for the so called “Rich” Internet Application market. I am somewhat sceptical about thie RIA-approaches. If you can establish a channel to deliver anything useful – fine. But these systems – while cutting development time – are extremely monolithic and they sort of hijack the user experience for you. And caring for the user experience is a differentiator in the market. I admit that Flex/Lazlo would provide a better experience often compared to using no interface toolkit at all – but generally I feel these systems are bloated and heavy trying to solve so many things at once. But maybe I am just not getting it right. Many internet applications would be “rich” if only they would be designed better and provide some sort of solution to a problem.
For the development of the backends on the server we see frameworks like Ruby on Rails, TurboGears, Twisted, Zope and so on. These can also really cut development cost by providing abstraction layers to common problems. These frameworks do a hell lot of things for a developer, but they usually have a steep learning curve and they also may have issues with reliability, performance and scalability. But from what I see, there are little options to avoid frameworks unless you are ready to invest the time in working around so many different gotchas yourself.
People were critizising AJAX to break the URL schema. I don’t think that is the case as long as you keep URLs as pointers to resources functional and constrain AJAX to improve the usability of a web application. I don’t want to have to reload a full HTML page or submit a complex form just because I unchecked an option.