First off, the service as it appears to you won’t change, except for a different commenting system. We’re not going anywhere, and the rate of posting won’t change outside the normal variations. It certainly won’t happen for a couple of weeks. Anyway:
Blogger seems to be intent on irritating us until we leave, so we’re considering obliging them and moving the entire operation onto our own server. I said a few days ago that the leading candidate is WordPress; MovableType is also in strong consideration with TypePad as a backup. BlogHarbor/Blogware doesn’t seem to offer everything and Scoop doesn’t seem to fit what we do (it’s a community platform instead of just a blogging platform, which we don’t need…yet).
Don’t get me wrong; Blogger is top-notch if you don’t post as much as we do (or we’d like to), if you don’t have your own server, and if you don’t have your own full-time tech guy. They turn the mountain of scripting and programming and server-side stuff and xml and perl and php into an exercise in writing instead of a constant battle of wits with UNIX. It’s no step down from other platforms and there should be no shame in a *.blogspot.com address; they’ve so far avoided AOLification.
Other things being considered:
1. Using a different newsletter service. I have a strong suspicion that at least some of the current newsletter’s 767 ’subscribers’ are bots, and while harvesting email addresses from our newsletter is not possible, it’s still a waste of effort on CafePress’s part. Plus, those who aren’t bots are probably getting real impatient with the bold text bug. This is one situation in which I settled for a quick fix, way back in July 2005, and I apologize to people who will have to re-register.
2. Moving the forums over to phpBB. Seeing phpBB in action at Energy from Thorium has convinced me that ours isn’t ready for prime time. This was another decision I made in July 2005, without any input from people who actually knew what they were doing. It wasn’t really a quick fix, but it will make it hard to upgrade, as InvisionFree doesn’t appear to be compatible with anything. The eventual establishment of a community site would be made much easier with phpBB, but this is not something we’re willing to tank–people have put a significant amount of effort into it.
3. Taking the time to develop a store instead of just using an iframe. The store currently looks like two pieces of Silly Putty mashed together instead of a website, and that is made worse by the fact that CafePress does not make creating sections easy. I accept that, in order to have all the control necessary to effectively run the store, there have to be six or seven settings on each section and subsection, and that they have to be created manually. But I don’t understand why it’s not possible to copy the first parent section after it’s done. It took me a full 12-hour day to set up the first one; doing that 25 times is impossible. It seems that the store is going to be our code, with our page on CafePress set up to redirect to store.niof.org in case some poor unfortunate soul stumbles across a page with 3,500 unsorted items. 3,500 sounds like a lot of work, but that amounts to about 25 batches that take about three to four hours each to fully create and edit (without having to worry about how they’re presented, that can be cut to an hour and a half). The sections are the hard part, but when the store is finally fully launched, it will be navigable. We won’t put up a maze, and for once, the image manipulation problems are out of the way. But, be warned, this isn’t Sam’s mess to clean up and I’m new to forms, so it’s not going to be ready by the 2nd anniversary (June 12).
4. We aren’t currently capable of doing the Nuclear NewsWire plus everything else. It, NIOF News Briefs, and Nuclear Regulatory Watch are going to stay on ice until we get more people and get a platform that can support them. Regarding Nuclear Regulatory Watch, if anyone knows a reliable person who knows the industry and regulatory system in the United States, has time to communicate regulatory developments, can write, and keeps risks in perspective, please contact us.
5. The tab layout, the code to subscribe to the comments feed, the radiobutton layout for the Nuclear Energy Search Engine, the labels section in the sidebar, subcategories, a less tedious way to do the Weekly Nuclear Poll (which means more time for content), maternity clothing at the store, the Energy Toolbar, the wider layout for the main site, transparent backgrounds on store items, the revised Go Nuclear Top 10 with its explanation, a wiki, the reindexing of the blog posts, the section of the forums for the discussion of NIOF pages, integrating the forums with the comments section, a rotating store stocking update, some sort of social bookmarking link code, the anti-nuclear links section (its nonexistence having been pointed out by a reader; I now have no excuse to dilly-dally on the reformatting), the A/V Library, resolving our email sending problems, the Nuclear NewsWire’s post page redirect code, a more accurate coal fumes death counter, the nuclear stamps, the site map, the book list, the updated copyright statements (2005-2007 instead of 2006), the FAQs, the rest of the Post Queue, the final site template, the Top Posts sidebar section, the index pages for the Regulatory Reform, One-Pagers, Economics, Letters to the Editor, and News sections, the explanations and corrections on old Anti-Nuclear Quotes of the Day, the PowerPoints for large- and small-group talks, the nuclear blogosphere aggregator, an email action alert list, press releases, the report/database on the First Bandwagon Market, writing a book, tmi30.org, the community aspect, a plan to organize college campuses, as well as the minor matter of the whole informational side of the site, are coming, as I’ve said before (42 unresolved issues). But again, they won’t be here until we switch platforms, and the last eight won’t happen until the rest are fully nailed down.
I grant that I made a total pigsty of this site while setting it up. I find it exceedingly ironic that its development mirrors the nuclear industry’s growth and subsequent performance problems of the 1970s (obviously on a much smaller scale), and we’re trying to produce a similar final outcome.
I’ve been talking to Sam about what we can actually implement on a tech level; in the meantime, does anyone have any suggestions?
Filed under Site