Published: Sunday, 18. March 2001
Note #1: With the release of Version 7.0 of Frontier, UserLand has brushed the documentation for Frontier a little bit. The article is still worth reading, but you will find the Getting Started with Frontier 7 document also a useful and very brief intro to the layer model.
Note #2: This text was written long before Radio UserLand 8.0 was released. It is still a valid text, but with no word I talk about the CMS functionality introduced with that release. The web application that comes with Radio has changed as well.
This article is intended for people who suffer from their “first impression” of a UserLand product. I am working with Frontier (and Radio) for quite a while, and I observed that newbies always have the same problems.
People look here and there in the application, poke around, use the trial&error routine – and get frustrated.
I’m trying to clarify a little bit – without replacing the docs of course.
Prologue: Know your assumptions
First: there are so many possible uses of Frontier and Radio, that for different people these applications may have different goals and purposes.
There are some ready-made functionalities and it may well be that it just suits your need. But if it doesn’t, don’t be frustrated. You are just simply not the lucky one who gets “his”/”hers” preferred feature.
In this case you may start to carefully look deeper into the environment – if you want.
UserLand currently does not try to draw the complex picture – at least not on the homepage. They rather focus on certain functionality they developed over the past months.
This is good and bad. Good is, that people probably will like the “small picture” more than the “big picture”. Bad is, that you can get into the latter pretty fast and be overhelmed by loose ends then.
Just the people suffering from that should read on. The others should consult the manuals as already suggested by the UserLand documents on the net.
1st: Don’t rely on trial and error
Usually software products for a consumer market are designed for a very specific task. For instance when you look at Microsoft Word basically what you expect to do with it is to be able to write a document, save it and print it. You need three commands for that: double click the application, “Save” and “Print”. From there you move on item for item.
What enables this is a congruent frame of what the application does and what you think it can do.
UserLand products are made by software developers for tasks most people even did not yet think about. But that’s also their innovative nature! So if you assume to do something in particular – you may fail, because your mental model may not match.
Before the trial&error routine leads to success one needs clearly to understand the conceptual basis and the fact that the application is not fitting a specific need of certain users.
2nd: Polymorphism
When reading the UserLand pages you have to include the fact that UserLand tries to sharpen an image about a polymorph application – which is basically hard to do.
So whenever you read something like “Frontier is this…”, “Radio UserLand is that…” be aware of the fact that the described functionality is just one possible way to use the application.
Its more a matter of product placement than actual functionality. To make a list of ALL possible uses is impossible and also would not help anyone to go anywhere with it.
What Radio UserLand or Frontier can do for you depends on the context you are trying to use it. There are some prepared features you’ll find if you first install the application after downloading, but remember: these are just examples of how someone could use the application. UserLand has always been open to people who want to move on from there.
3rd: So what does it offer what you can’t get elsewhere?
Short answer: nothing
Long answer: a lot
OK – I am kidding! Truth is that UserLand delivers Radio and Frontier not only with some core components, but also with a huge amount of macros and extensions that can speed up development of new web based applications.
In addition both Frontier and Radio UserLand each come with an already implemented Web-based application. In case of Frontier that is called “Manila” and can be used to maintain one or several websites. In case of Radio UserLand it is called “MyUserland on the desktop” (or just “MyUserland”) and is used for scanning the web for news and maintain an own news site (very likely independently from Manila).
These functionalities are provided by scripts that are stored in databases controlled by the application itself: in Frontier these are (currently) called “Frontier.root”, “mainResponder.root”, “manila.root” and “config.root”. In Radio Userland these are called “Radio.root” and “myUserland.root”.
Whenever you update a database with an update command, you may download and replace items within these central databases. That’s how you get constant bugfixes and feature improvments from UserLand – most of the time without the usual download/unpack/stop/update/restart-process.
4th: The core components
Frontier and Radio UserLand on a core level consist of four parts:
1. a hierarchical object oriented database engine
2. a scripting interpreter
3. a network interface
4. a graphical interface for controlling the application
This is basically an integration of parts you usually get when you install several applications – for instance Apache (as network interface), PHP (as interpreter), MySQL (as database) and an Editor (as a graphical interface).
When you just think for a moment, what “applications” you can define for the Apache/MySQL/PHP/Editor combination – you probably (and hopefully) will never come to an end.
5th: The levels of components
Depending on what type of user you are (a journalist, a designer or a developer) you may have to look at different levels and completely ignore others. I have invented the labels for the levels – they are not yet anywhere on the Userland documentation pages (not that I know of) or conventional names – so be careful if you use them in community discussions:
1. The core level
That is described above: database, network, script interpreter and editing environment. The databases can contain objects like text, outlines, scripts, values, a.s.o.
The databases (the “.root”-files) which come with Frontier/Radio Userland already contain a lot of data and scripts. Don’t mess them up!
Also: all of your custom settings will be stored in those databases (and not in the Preferences folder as many Mac users may suspect).
2. The macro level
With the UserTalk language, UserLand has implemented a lot of macros, which help performing certain tasks. When performance is an issue, Userland very often converts a macro into a UserTalk command (so it is implemented in the core level and runs much faster).
Example: Some of these macros implement the functionality to upload files via FTP to a remote site. That’s needed for publishing on a higher level (see below).
Sometimes developers in the community offer a single script or macro, which you can download and import into your own installation.
3. The service level
With that core and a bunch of macros the application would just sit there and do nothing after you started it. But there are things going on. For instance Frontier can execute scripts once an hour – so there is a scheduler running all the time. There is a webserver waiting for HTTP requests. It processes these through a number of scripts (called “responder”). Another responder simplifies the communication via XML messages in-between the local and a remote application (namely »XML-RPC« or »SOAP«).
It is completely open what services can be implemented. I have seen people doing a Telnet server for Frontier as such a service, so that you basically can use Telnet to connect to Frontier and execute scripts (but I think it was never really finished).
One of these services for instance is a complete Search engine (it is used to offer the search at http://search.userland.com/ and it’s delivered by Userland with Frontier).
Most of the hot items in the ongoing development debates reside in this level. For example all that gossip about XML-RPC, SOAP and .NET support. Mainly invisible – it drives lots of the features you may use without knowing. If you are a developer, you may use it for own purposes or developments.
4. The application level
Now all the above you basically can’t see. They are hidden in the databases and all the scripts interdependent to a high degree. What you can see is the contents of the database when you open such a beast inside the application window. You can add objects and move items around with the mouse (but probably you will break things if you don’t know what you are doing).
For instance: if you generate static sites with Frontier (or Radio) you will put objects into a database and use some of the predefined macros to generate HTML pages out of this and write them to your hard drive or via FTP to a remote server (in which case the hierachical structure of the database objects then would very likely look similar to the structure of the website you are rendering).
Some of the functionality of the web application level (see below) probably is also controlled from the menus in the application window – not just through forms on HTML pages. The application interface and the web forms in priciple can both manipulate the data in a database. Sometimes a menu command will simply chance a value in a database – and cause the macros and core commands behave differently.
On this application level Frontier and Radio can also be highly customized! You can insert own menus and also program own dialog boxes (but that needs some more advanced knowledge).
Just to not leave that out:
The Frontier/Radio Userland applications can also communicate with the operating system. So for instance you can call and control applications via AppleScript on a Mac or Visual Basic Script on Windows – maybe to generate hundreds of GIFs from a list of strings from a database with Freehand?
5. The application extension level
If someone uses the above levels to implement new functionality, he/she could program an extension to Frontier or Radio Userland. In case of Frontier these usually are called “Suites” (and mostly are imported into the Frontier.root) – in Radio these can also be called “Tools”. The latter will reside in an own database in the tools folder.
By the way: The Telnet server described above was distributed as a Suite. A suite basically is a collection of scripts and it offers a more complex functionality than a single macro would do.
Suites are also often developed by community members and very often offered for free.
6. The web application level
Here is where you need your web browser to connect to Frontiers/Radio Userlands built in web server. That web server by default can offer you the Manila application (if you talk to Frontier) or the MyUserland news scanning application (if you access Radio Userland).
When you access Manila, the scripts that create the HTML pages are mainly stored in the manila.root database; in case of MyUserland they are in the myUserland.root database. Once you access one script via the web browser you most likely will initiate a cascade of scripts calling each other. Don’t get lost in that script jungle.
The MyUserland web application in Radio Userland is called a “Tool”.
7. The web application extension level
There is a way to extend Manila or MyUserland. For Manila someone can program a “Plug-In” (see http://plugins.userland.com/). Such a Plug-In may have a web interface – depending on what the plug-in actually is doing within Manila (and whether or not the user needs to control its behavior via the web browser).
For MyUserland someone can implement a “Website Tool” which resides within the MyUserland web application (see http://radio.userland.com/websiteTools). Of course its irritating to call these Tools, because the MyUserland web application itself is called a “Tool” as well – the difference is that once you look at a “Tool” from the application level in opposite to looking at a “Tool” from the web application level. Therefore Userland calls the latter one “Website tools” and they are similar to Plug-Ins for Manila.
Whew. That are a lot of construction sites!
Besides of the core level – everything is in principle under user control. Usually you should not interfere with macros and scripts maintained by Userland. There are many places where you can put your piece of code or hook it into one of these “script cascades” described above. It’s just not so easy to explain in a sentence as you can imagine.
I think when people are disoriented in Userland products, than its mainly because they are looking at one level and trying to understand it from another levels perspective.
Simple solution: Just don’t try that!
Example: Radio as Manila Client
So one if the cool things on the application level is the outline editor. You can expand and collapse hierarchical text elements. This is used for writing scripts in an organized manner – but also to write up text and ideas.
Radio Userland can communicate with a Manila site to download and upload such outlines from the database of that remote Manila site. Once you upload an outline that can be processed by a script to generate HTML from that hierarchical structure.
You can also open a Manila site in Radio. This will download a particular outline in which the components of a Manila site are represented as outline headings. By double clicking or expanding these items you can maintain the Manila site (e.g. the page template).
Example: Radio as Frontier Client
There is a suite called “Webedit” in Frontier. If you enable it will start a service and allow registered users to access objects in any of the opened databases. Per default its not enabled, but if you look in the Radio.root you can find the webedit suite in the “suites”-subtable. If you run the init-script, you can use Radio as a client for Frontiers internal database objects.
This is useful for instance if you are developing a plug-in on a Frontier server remotely or maintain a static website.
Of course you can complain “Uah, but that is difficult to use!!” – but this would say nothing more than that you already entered a wide open field of possibilities without road signs and asphalt….
Metaphorically speaking: That is Userland! And that’s why there’s always the cow skull and the cactus… you’d probably want to stick with the coffee cup first!
Epilogue
So what you basically can imagine now, that there is a lot of mixture possible in this cocktail.
There are a lot of open issues. It’s easy to imagine that applications like this contain thousands of scripts and objects. Currently there is a handful of people at Userland doing all this and there are many developers around using the applications for own purposes.
In my own experience the people at Userland consider each development step very carfully and with all the experience in that business over years. As long as they know they won’t harm the process they basically are also pretty open, transparent and encouraging innovative ideas.
They may not be so responsive to feature requests or bug reports, but the reason for that mainly could be that either they are fixing things or they are already baking the “next insanely great thing”.
It may be that documentation is not quite right, or this-n-that feature is buggy – but as far as I am convinced today: It will always be that way – so don’t complain – just report the bloody bug in a nice tone to the discussion group….
Leave a Reply