Independent web developer. Graphic designer, web designer, Frontier developer, Manila hoster, latest project: intranet build for Government Office of West Midlands (UK), committed blogger since 1999.
See more details on services and more personal background who and where.
email 'spam free' or phone on: inside UK: 0800 849 6413 or outside UK: +44 1952 271 671 or mobile (and txt): +44 7903 940 427
Radio Userland is powerful, flexible and easy
This morning in my pubSub subscription for 'Userland' I saw another "I'm moving from Radio cuz it sucks" post.
Fed up with Userland the company I may be, and though nobody at Userland seems to care that ignorant bullshit like this is put out there, I felt it's time to refute some of the arguments put forward as "reasons for leaving."
- "Funky" HTML (good luck trying cleaning it up, Radio seems to do whatever it wants to with HTML). True, some of Radio's HTML is funky. But funky works, and works across all browsers. I've cleaned up some myself, Userland seems to be working to clean more. If I really needed to I could dive in and fix it all. All of Radio is available to edit, there's not a lot that's been kernelised, especially when it comes to the HTML. This really ain't a biggie in the real world.
- Userland's "Web Bug" gif embedded in RU generated pages (used to create the last 24 hour referrer logs) is extremely slow to load, making your whole site seem slow even when you "self host". I self host and now have zero to do with Userland's servers. I've removed the web bug, put comments on my own Manila server (since removed for other reasons than performance). I create my own logs using industry standard techniques, by analysing my own raw logs with Analogue.
- Lack of control over code. Sure you can make your own changes to Radio's Engine, but there's a chance they'll get written over in the next root update. This is the biggest, biggest misinformed error in these 10 problems. There's educated ways and fool hardy ways to edit code. Many things can be written by being inspired by Radio's code base, and those can be placed anywhere, never to be touched by a root update. The only place that could change in a root update is in the Radio.root, in the system table. Even then, most long term Frontier developers will have their own coping strategies for this. Mine is to use system.verbs.builtins.rootUpdates.update. I would then check what I've protected against new code, merge, then update the other servers I manage from the newly updated server. I don't do this everyday, it can be a big job. Mostly though it used to take an hour or so.
- Poor/Scattered Documentation - Userland should give users a free electronic copy of Roger's book with the first year's subscription to RU. There's a ton of dox. Find a Frontier verb, either look it up in Docserver, or look through Matt Neuburg's Frontier: The Definitive Guide available online. Or, use Google. I'm amazed that so many people forget to try Google first. As an FAQ Google will get your answer much faster than asking in the discussion groups. Remember the 15 years age of Frontier/Manila/Radio. Everything has been asked and answered before.
- Not a lot product development going on. Dave has moved on to other things leaving Userland and its applications in stagnation. Dave, gawd bless him, was both the worst and best thing about Userland. Now he's gone, I still hope that Userland will get on the right track. Dave Winer would never stop to fix bugs. He'd always find some other road to travel up in his discoveries of what Frontier could do. And some amazing discoveries were indeed found. But as I travelled those paths with him, I felt that I was always leaving the base camps ill prepared to survive on their own.
- Difficult to move you data to a different system ("lock-in"). It took me quite a while a a lot of tinkering to move my RU content to a less proprietary, more open format. Less proprietary? The only thing that's closed off from tinkering or rewriting is the kernel. And that's going to be open sourced pretty soon. More open? UserTalk was written to make code writing easier. If you've ever tried it you'll know what everybody says when they reminisce about writing code in an outliner, forget awkward curly brace notation for indentation and structure, the outliner takes care of all that, invisibly. Then it's the language itself: easy to learn, to look up verbs in either the ODB itself, or in Docserver, just control double click or option double click. Radio is open and accessible.
- Year old bugs have yet to be addressed. Four year old bugs have yet to be addressed, though this memory leak doesn't really affect the low use home user of Radio. But sure Userland really have missed the boat with bugs. For too long the response was, "thanks for the bug report, we've added it to the bug tracking." Even for minor typos. Many of us would correct the bug when we saw other's reporting, bypassing the company.
- Client Application is a CPU hog (at least on Mac OS X and Mac OS 9). This is an easy bug to fix. Well, I actually bypassed the problem, not fixed it. I switched off the check to see if anything is deleted in the local /www/ folder. Now, Radio only hogs when it does something, like aggregate the news, or check a folder for images or videos, or mp3s, or checks the mail, or checks other comment threads I'm monitoring, or... Otherwise, she just sits there. When you've a powerful content management system on your desk top, it's best if she's doing something.
- It's 2004 and no still SFTP available (unless you feel like creating your own tunnel). If you were using Userland's servers why would this matter to you? I use plain FTP just like 99% of the world.
- Almost impossible to do anything with comments & trackback entries if they're hosted by Userland's servers (which by default they are and there are no easy plug-ins to other services). Moving the comments to another service is a lot more difficult than moving your posts. No, moving to a different comments server, or service is piss easy. Getting your posts, from Userland, or any other service isn't easy for sure, but can be done especially if you'd use my Wipe Manila tool (BTW: no dox with it yet, nor free support.)
- (Bonus) You're pretty much forced to have a static pages (unless you really want to jump through some hoops) for your site (no php/python/perl/ruby interaction sorry). If you independently host, you can add any code to your pages, and interact with whatever you have on your server. However you want. Add the code directly to your template(s), include it as a renderObject on your desk top, or as an SSI. This is a daft point.
If you use Userland's servers, things are going to be slow. Uploading to a really busy server can cause time out problems. Comment servers were spread out more several months back, but have filled up again. Likewise with the web bug. Userland will always have problems scaling. Much better to use your own (rented) FTP server, a different comments service, or even another Manila site on perhaps your own server. And forget the web bug.
Mind, it's been over a year since I needed to update a Manila installation. And, since my licence for Radio expired this Spring, I've not needed to update that either. Next time I update Manila, say, I expect a long update process. Or, is that, that I hope there's lots of new stuff and lots of bug fixes and lots more from Userland?
There is still quite a bit of development still going on in the Radio world. I've brought out several tools myself, and other too have written some nice macros and tools. Several projects I've worked on are for my own personal use, I could release them as tools but the numbers just ain't there to make it work while. I particularly like my link in to Photoshop. Now, that's something that you cannot do with a server based blog.
Lock-in? How about exporting all your posts into one RSS feed? I built a tool to do just that. Others have merely exported their posts to text files and popped them into MT. I've even built a Wipe Manila tool that looks in Google for your Manila posts or Radio comments and either sucks them down and/or over writes them. There is no lock in.