|
Tuesday, February 5, 2002 |
|
Damn... train rides over and I didn't actually get to do what I wanted [fix my silly theme].
Another complaint: the user's data doesn't seem to be separated out in the Radio UserLand directory to the point of easily being backed up. Or maybe the answer is simply that I should back up the entire directory and always make sure to stick it back in the same spot because it has lots of absolute paths encoded within? |
|
...nope. Didn't render with upstreaming disabled. I suppose that makes sense, but it still begs the question of how to preview/view your homepage when not actually online! And I was all set to start playing w/some XML-RPC stuff. Nuts. Hmmm... if I enabled upstreaming, then invoked
It is now attempting to actually perform the upstream. Of course, that won't work, but it did save the rendered pages into backup/renderings. Not exactly a pretty solution and one that I never would have figured out if upstreaming hadn't broken last night and Jake Savin hadn't have been so incredibly helpful.
Of course, as I longtime developer, I have to ask myself: How much of this random evaluation of bits o' Frontier code can I do without getting myself [and my data] into trouble? |
|
How in the heck do you configure this thing to effectively for local previews when not connected to the cloud? I'm currently sitting on the train-- no net connection-- and I really want to mess w/the template that drives the look and feel of my homepage. After enabling 'keep a local copy of rendered pages?' (whatever it is) I *do* have a local copy of the rendered content on weblogs.com (all of the images are broken, but that could be fixed through the use of a few relatively links as opposed to the absolute urls currently generated by imageRef()).
However, it seems that the local rendered pages are not updated unless I post & publish? I wonder if that'll work with upstreaming disabled.... |
|
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. |
|
Moved to the "SoundWaves" Theme. It is closer to the basic layout I want and I can rip it out from here. However, it has some issues.
All of the image references are through my account on radio.weblogs.com. This means, by default, I have to edit the template heavily to even make it work if I'm using FTP upstreaming or if I'm rendering down to the local hard drive for the purposes of preview. |
|
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. |
|
It seems that the documentation for the internals of Radio are spread far and wide across multiple products that are related to Radio. For example, to figure out how to call the imageRef() macro such that it generated a specific set of height/width key/values, I-- through a very circuitous route-- ended up at a page within the description's of Frontier's built in verbs. Why can't I find a similar page anywhere in the Radio documentation, preferably on my local hard drive?
Further investigation reveals that the above document isn't totally applicable to Radio. It implies that one uses explanation:"alt text" to create an alt tag on the image. But that blew up. Instead, using alt: works fine. Odd. |
Last update: 1/23/03; 11:08:10 .
