Chad Perrin: SOB

30 March 2006

WordPress Effluvia

Filed under: Metalog — apotheon @ 06:02

So my WordPress version for this weblog has been updated to deal with a security issue with the older version I was using. Unfortunately, the new version is aggravatingly WYSIWYGish, in the way that things like MS FrontPage are WYSIWYGish. It tends to try to hide source code from me, and does weird things with the first paragraph in a block element when I add such elements to my post entries.

A problem WP has had from day one, even with the older version, is the fact that it uses dumb-quotes (what most people, for some ironic reason, call “smart-quotes”) in the presentation of text. While such quote styles are appropriate and even preferable for hardcopy media (think “paperback book” and the like), they’re the Wrong Thing to do with electronic text media. For one thing, dumb-quotes aren’t particularly searchable. You can’t just hit a key on your keyboard in the little search box in your browser and have it find an apostrophe or quote mark that fits the “smart-quotes” description. Those little curly bastards just don’t live on a standard keyboard. For another, they’re not plain-text transparent — when you look at the source for a webpage with dumb-quotes on it, you see HTML entities or otherwise non-representative replacements for the actual characters.

Then, of course, if you try to copy the text into something using ASCII only, or view the page with a text-based browser like Lynx, or something like that, you’ll get nonsense characters in place of the characters you actually want.

Annoying. Dumb-quotes aren’t very smart in electronic media text presentations. So, I spent about twenty minutes or so today having to hack the presentation functions in the PHP source for WordPress to get rid of all those quote-replacement lines of code. This, of course, raises a question:

Why the heck didn’t the fine folks developing WP code think to include a configuration parameter for turning on/off dumb-quotes? In general, WordPress is great, but there are some minor niggling annoyances that are driving me up the wall. It’s just a little too dumbed-down for the common Windows-using know-nothing that uses Word for things like shopping lists when Notepad would be more appropriate. I guess the mindset that prefers Word DOC files for unformatted text must also prefer a weblog that makes the presentation of content nontransparent, nonportable, and sometimes nonreadable. It seems to be to these people that WordPress is mostly catering.

Then again, I suppose I shouldn’t be surprised. It’s a nontrivial web application, but they wrote it in PHP. Maybe that says something about the mindsets of its developers.

If any of you see any curly or slanted quotes or apostrophes (accent marks like á notwithstanding), I hope you’ll let me know so I can track down what bit of code is altering my plain text.

Also: I’ve decided to do some paragraph-indents. I don’t know how long I’ll keep doing that, but it amuses me for now.

29 March 2006

users as programmers

Filed under: Cognition,Mezilla — apotheon @ 09:59

Please see Users As Programmers for this essay’s new home.

Application development differs distinctly from some other types of development, such as OS kernel development, in a number of ways. One in particular is how one defines successfully meeting project goals. When writing an application, one seeks to solve the problems, and meet the needs, of its end users. Server and kernel development, meanwhile, tends to focus more on solving the problems and meeting the needs of interoperability with other software.

In some ways, it’s easier to write software to the standards of other software than to the standards of the end user. A key factor in this is the tendency of users, and people who are trying to spec out software requirements for user applications, to misidentify the actual problems and needs the application is meant to address. This sort of problem doesn’t exist (to the same degree, at least) for software that only interfaces directly with other software. An API is what it is, no more and no less. Software interoperability is a “how” problem: when you set out to solve the problem, all you need to concern yourself about is how to accomplish the very clearly defined goal. Sure, I’m oversimplifying things a tad, but in general that’s all there is to it.

As pointed out by TR user J.Ja in a blog post entitled Programming “How” versus programming “Why”, addressing the needs of a user application is not just about how to accomplish a given set of tasks. It’s also about why the user thinks (s)he needs those tasks accomplished. Once the “why” of it is determined, you can investigate the best way to address the problems and needs the application really should be addressing, which can lead to a far better “how” than the initial specification proposed.

This sort of thing is addressed by agile programming techniques when an application is commissioned by users, or by some entity that represents the users’ interests to some degree. The close communication between developers and users(‘ advocate) can help to ensure increased success of the project, where “success” is defined as meeting the needs and solving the problems the application is ultimately meant to address. Yay, success.

Of course, there’s not always a(n effective) users’ advocate, let alone access to the users themselves, when software is being created. In many cases, a corporation sets out to create a “product”, with the intent that by solving some problem that has not already been solved, or at least not as effectively or with as many bells and whistles, it can make boatloads of dough for the board of directors and keep all the company’s employees in Cheetos and Pepsi (and mortgage payments and so on). These corporations have developer teams (or, worse yet, departments populated by cubicles) that almost operate in a vacuum, basing designs off ideas that have worked in the past, and off their experience of what features people have tended to like in an application, without really having access to the core problems that must be addressed. As a result, we get things like Microsoft Office, Adobe Pagemaker, and Norton Antivirus, which sorta do what’s needed but frustrate the hell out of their end users a nontrivial percentage of the time.

For application development of that sort, there’s a better way: make the users into developers. When the people writing code, designing interfaces, and speccing out application architectures are doing so because they have a personal stake in getting an application that will solve their problems, the “why” question gets answered. Putting the developers together in a round table to consider the matter of what needs to be solved when the developers are also the target users is a great way to develop software that kicks ass.

Do you know where that sort of thing happens? I’ll give you a hint: it doesn’t happen in the context of major software vendor corporate offices where proprietary, closed source, commercial applications are developed.

It happens in open source development, when a handful of people get together and say “Woah, nellie, there isn’t a high-functioning browser out there that doesn’t suck.” They look at the situation and decide they can do a far better job of defining the project specs for such a thing than anyone else seems to have done thus far. Then they do it. They don’t stop solving the problem until the problem is solved to their satisfaction, and being the target market of end users themselves, that means it gets solved well.

Guess what: there isn’t a high-functioning browser out there that doesn’t suck. Some friends and I have agreed on that. We’re discussing the idea of creating the browser we’d like to have. It should, at minimum, do what Firefox (actually Phoenix initially, then Firebird) originally set out to do: provide a lean, lightweight, secure, stable, high-functioning browser that is extensible rather than bloated. For a long time, Firefox’s previous incarnations did a passable job of achieving that end, but the project seems to have gotten too caught up in the “alternative to Internet Explorer” aspect of the problem, sacrificing much that was good about the idea to try to lure IE users away with familiarity and similar features.

The Firefox development team has lost the plot. Hopefully, we (these friends and I) can pick up the original plot and start over, doing it “right” this time. I’m perfectly willing to be a bullwhip-wielding harsh taskmaster, keeping feature creep and bloatware sensibilities out of the project, and the other people that seem interested in getting involved are similarly inclined. We need to start with some kind of list of needed functionality for the browser and other project specs, though, so we’ll have somewhere to start. I’ll provide such a list here, in this post. I will edit it as needed when the project goals become more clearly defined. Ultimately, this will probably be moved elsewhere (a weblog post seems like a strange place to maintain project specs), but it’ll do for now. If you think you have something to contribute to the composition of this list, please feel free (and encouraged) to comment. This is starting out as my wishlist, of course, subject to alteration.

  • no Java in the browser source: this is in part an attempt to stave off the “use Java in feckin’ everything just ’cause Java gives good marketing head” impulse that can screw up so many software development projects
  • configurable keyboard shortcuts
  • convenient local bookmark management
  • tabs
  • configurable external application MIME association
  • GUI configurability (location, color, icon, size)
  • the ability to deactivate JavaScript functionality
  • extensibility
  • plugin support, preferably with resource usage restrictions (sandbox?)
  • total application size less than 10MB
  • total (initial) application RAM requirements less than 20MB (one browser, one window, one tab)
  • per-tab resource requirements should be about the same as the difference between a browser window with no webpage open and a browser window with one webpage open, if possible
  • easy upgrade capabilities
  • easy installation
  • Gecko rendering engine
  • shell interoperability
  • minimal library dependencies
  • SSL certificate support (but not necessarily any autotrust for certificate authorities)

Things that are probably extensions:

  • RSS/ATOM discovery and rendering
  • popup blocking
  • support for additional protocols (FTP, SFTP, et cetera)
  • secure web browsing using SSH instead of SSL

Some of those items in the first list might actually be “default extensions”, distributed with the standard web browser software package, rather than actually integrated with the core application. Such remains to be seen.

Ideas? Thoughts? Complaints? Let me have it. Revisit this page regularly to check for changes in the proposed project spec lists.

28 March 2006

consistent navigation and upgrade

Filed under: Geek,Metalog — apotheon @ 07:26

Internet Explorer screws up the CSS

Faithful visitors, you may note the mysterious appearance of a tiny little navigation element in the bottom right of the page. Of course — unsurprisingly — it’s utterly broken in Internet Explorer. Instead of a fixed-position menu in the bottom right corner of the browser, I expect that to IE users it looks like a menu that bleeds off the bottom of the bottom-left corner of the page with the same scrolling-position as the rest of the page. I plan to fix that, but for now, it’s just broken. Click on the IE thumbnail to see a larger image that shows how the navigation elements render in IE on the CCD CopyWrite page.

The RPG link in that little navigation element leads to a page that doesn’t exist yet, so don’t bother clicking it. The other three all point at subdomains of apotheon.org though: this one, and two others. The same navigation element exists on all three of those domains, the only difference being the color scheme. I intend to get that RPG page in place ‘ere long, and when I do the navigation will be on that page, too.

In other news, the scripts used for SOB are going to get upgraded to a newer version on the 30th. I’ll back up the database (hope the backup works) in case there are any problems (hopefully the backup won’t be needed anyway), but there shouldn’t really be any interruption of service or need to repopulate the database with data or anything like that. It should just be a basic drop-in replacement dealie. Knock on wood.

what standards compliance gives you Back to that navigation menu thingie. . . .

I tried slapping a position: absolute in there, since IE fails to support position: fixed, but that didn’t work out so well. Anyhow, if you would like to see how the navigation elements are supposed to look, click on the Firefox thumbnail here.

Older Posts »

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License