|
Tuesday, February 5, 2002 |
|
DW keeps talking about this whole Radio / Frontier / Web Services thing as a Mind Bomb; as a friendly bomb that only hurts because of the sheer quantity of mental muscle that must be expended to digest the ideas (and handle the vast quantity of other ideas). I largely agree both with that opinion and with the opinion that this stuff needs to be made orders of magnitude more approachable. Before lots of folks can jump off the cliff, the climb to the cliff is going to have to be a hell of a lot easier... I'm no stranger to web services, web development, software development and general geekdom. I have been doing this stuff for a long time. Radio/Frontier is very cool stuff. However, it is unbelievably painful to use. I feel as if I'm running into a learning wall on the way to the cliff... I have documented a lot of my Radio introduction in a Category (of which this post is CC'd). It is mostly bugs, etc, and the occasional frustration driven bit of whining. I'm the first to acknowledge that Radio has achieved great things and that addressing a lot of the details/bugs identified within would have slowed down the evolution of the product. However, at some point, someone is going to have to take a step back and fix a bunch of the nagging problems that have driven a bunch of folks to just give up. They'll be back in a year or two, but they won't stay unless an improvement is made. What follows are what I consider to be some fairly key flaws that are holding the product back from wider acceptance. They are derived purely from my experience with Radio. Some of the mentioned items are possible to do/fix in the current product, but it isn't easy without a rocket science level of knowledge of Radio. This does not take into account that Radio is only $40. Offline Mode Clarification: By offline, I mean "without a network connection" and not "with Radio's web server turned off". The offline mode is sorely lacking. A lot of us initially use Radio on the train, while lounging in a hammock, or in other contexts where we don't have a network connection. 802.11 isn't ubiquitous quite yet! As it stands, it is impossible to install Radio, create some Posts, and have any clue how the posts are going to appear once they are pushed to the cloud unless they actually are pushed to the cloud. The closest I have come is to turn on 'Keep local backup?'. However, the end result is pretty broken in the context of being used as a means of previewing the content. Almost all image references across the themes default to weblogs.com derived absolute URLs and, as far as I can tell, it is impossible (without a bunch of coding effort way beyond the novice) to actually create a link to a category that works both in the local and in the cloud contexts. As well, not everything needed to learn and comprehend Radio is even installed on the local hard drive. Which brings us to: Documentation & Feedback The documentation is sorely lacking. While the help stuff covers the most basic tasks, it falls well short of completing the picture in many cases. Example: Including an image in a Radio posting. Figuring out how to do this was non-trivial. Figuring out how to do it such that the posted image displayed in both my desktop and my weblogs.com homepage was highly frustrating (see the mentions of imageref in previous entries in this category). Furthermore, the functionality within the Radio application itself seems to be fairly obtuse in terms of documentation or providing useful feedback. For example, if I hit cmd-P (which is Preview, not Print-- but that actually makes sense given that the content needs to be rendered by a browser, generally), absolutely nothing happens. But if I select Tools->Static Sites->Preview Page, I receive a error panel that states "Can't Coerce 'About Radio UserLand' to an address because it doesn't specify a valid object in the database structure.". Whoah! Database structure? Huh? I'm new at this, I'm flailing on obvious things to try and see what I'm creating and it is complaining about database structure? What the heck does that mean? (And why is the menu item even enabled if I don't have the appropriate object selected in the first place?) (The prefs system rocks, though, in that it is truly excellent to be able to see a bunch of documentation on that really important setting you are about to change before you actually change it.) Application User Interface The Radio user interface itself doesn't seem to follow any of the UI design patterns that any other App on my system (OS X) follows. Now, clearly, this likely has something to do with having to support an app that is released against two APIs (Win32 and Carbon) and three operating systems (OS X, Windows, OS 9), but it really detracts from learning the application. It would be incredibly helpful if the UI gave some better feedback as to what functionality is available at any given point in time; i.e. if the menu items were disabled when the associated task was not currently valid. Another example: There are four Save menu items-- all enabled-- and they all appear to do different or wrong things: - save: Saves a database (not sure which) - save as: Saves a database (not sure which, doesn't prompt for 'save as' as expected) - save as HTML / save to HTML: both bring up error panels. Selecting 'weblogData.root' causes 'em to bring up a save panel, but the save itself fails. Which brings up the subject of the window menu... why are there nearly a dozen items in that panel for windows that aren't actually on the screen or in the dock and what the heck are they?
I have a bunch more... I'm going to post 'em to the Radio Commentary Category as I can. For now, I want to get back to futzing with Radio. None of these are showstoppers, by any means-- just minor to major bumps in the road to falling off the cliff. |
|
The Great Not Upstreaming Mystery Saga Sometime last night, at least two Mac OS X users had upstreaming stop working. Now symptoms (that us relatively new to Radio could glean) or error messages. Pages would render, but they were never upstreamed. Jon Asata and I were the user with broken upstreaming and Jake Savin was the expert that helped us track down the problem. It seemed that the user.scheduler.prefs.runThreds setting had been set to false somehow; any ideas anyone? And this was causing the threads that normally handle upstreaming to never run. You can see how many threads are currently running by popping up the little menu in the 'About Radio UserLand' window and selecting the 'StatusMessage' option. If you only have 1 thread running, it is likely that upstreaming is broken. (?) Jake's eventual solution was to run the following in Radio's Quick Script evaluator [cmd-; on a Mac].
This seems to have fixed the problem. Thanks to Jake Savin for a quick and highly focused resolution of the issue. |
Last update: 1/5/04; 8:36:06 AM .
