I have had a strong writer’s block this last month, which has manifested itself as writing to the weblog. As contrary as this seems, what this means is that instead of focusing on the writing I need to do to make a living, I’ve been puttering around here. Unless ya’ll decide to chip in and pay me a salary, I must be more disciplined with my time.
Luckily, reviewing the O’Reilly books helped me get a better understanding of both my audience and the writing style I want to follow, something I’ve been having some trouble with recently. They’ve also confirmed my impression that there is a good audience for books on technical topics that are not directed at geeks.
Clay Shirky’s new essay has also confirmed my preferred audience. He uses the term situation software to describe the quickly built, purposed, not meant to scale applications that power most small organizations Internet (and not) software needs. One aspect of this, and a growing aspect at that, is that programming is seen more as a secondary skill, rather than the primary skill:
So with programming; though all the attention is going to outsourcing, there’s also a lot of downsourcing going on, the movement of programming from a job description to a more widely practiced skill. If by programmer we mean “people who write code” instead of “people who are paid to write code”, the number of programmers is going to go up, way up, by 2015, even though many of the people using perl and JavaScript and Flash don’t think of themselves as programmers
In my opinion, this started in the days when professionals were scarce and we could command big bucks. Tools allowing smaller organizations to do their own development suddenly started to get more popular, and as they became more accessible, more and more people thought to themselves, “Hey! I can do this!”
Though the programmer-as-secondary-skill market has been around for some time, it has been powered primarily by Visual Basic, ASP, Java Applets, and Access in the past. Now, though, we’re seeing strong movement towards Flash/ActionScript, PHP, and MySQL, especially MySQL. On this database Clay writes:
You can of course build these kind of features in other ways, but MySQL makes the job much easier, so much easier in fact that after MySQL, it becomes a different kind of job. There are complicated technical arguments for and against using MySQL vs. other databases, but none of those arguments matter anymore. For whatever reason, MySQL seems to be a core tool for this particular crop of new applications.
I agree.
As for scripting, the use of JavaScript continues to be popular, but sites aren’t building in the dependency on it they used to. There is much less use of DHTML, but I think that’s due to the influence of Flash. Unfortunately both have been and are still used improperly at times, which I’ll demonstrate later.
Returning to Clay’s situated software, one challenge with these niche or communal applications, especially those created by non-traditional programmers, is that they they don’t always take advantage of existing components to do some functions that overlap between applications. The reason is either because they have someone who wants to ‘try it out’ themselves (and though that’s comendable, I’d rather incorporate code that’s been tested by hundreds of users), or they don’t know about the concepts of reusable components, and that these types of scripts exist.
The main reason I recommend PHP for most web sites is that there are thousands of pre-built and thoroughly tested open source PHP components (or codelets if you prefer) on the Internet just free for the download. Not only that but there are forms generators and various other tools that do three-quarters of whatever you need doing for a site–including interface with MySQL.
There is no need to code a mail handler application, or hand write a form that uploads data to a MySQL database. You don’t have to create your own user management system, or worry about how to upload photos. The only problem you might have is choosing among all the variations of any of these codelets that are online.
(To find, Google on “PHP scripts” and be prepared to be overwhelmed.)
In addition to not making use of existing code, inexperienced web site developers can also get caught up in the ‘cool stuff’, and make some serious mistakes in fundamental site design. A demonstration of how this can happen can be found in the web sites for the two library systems I use to get all my books and movies.
The first site is for the St. Louis Public Library. It’s not particularly polished looking, or pretty; however, it works, and it works rather well. Key elements in the design of this site are: good clean use of web forms for catalog searching; easy to read results pages from the searches; a front page that directs new users directly to the information they’re most likely to want; and good navigation between the site pages. The page that covers all the branches is based on a graphic, but the library also lists all of the branches below using plain hypertext links.
The only point I have to pick on the site is that they don’t have a direct link to a person’s account from the main page. You have to go into Catalog to find the link to “My Account”. What this does is make a person more apt to bookmark the Catalog page than the Main page and doing so they’re not as likely to see new events the library is promoting (which could be more prominantly displayed, themselves). Main pages aren’t just for newbies–they should have something for everyone.
(Under no circumstances should a main page have a Flash demonstration that has a “skip this” button to click. Not unless the site is selling Flash. )
The other library system I use is the St. Louis County Library, which looks more polished than the city library system, but right on the first page, it has a major strike against it: a Java applet based navigational menu.
Never, ever, under any circumstances, whatsoever, do you use anything other than a hypertext link to handle site navigation. You do not use DHTML. You do not use Flash. You do not use JavaScript in anyway. You do not use Java Applets. Slap, slap, slap! Bad!
(I once wrote a tutorial on this, writing that site developers should never make the navigation hard to find or use, forcing the reader to wave their mouse over the page like a magic wand, hoping to uncover an actual working link. To prove the point, I coded the tutorial to use graphical buttons for navigation, but when the person’s mouse was over the button, I would use DHTML to move it before they could click on it. They’d have to chase the navigation buttons around the page and hope they could click it faster than the DHTML could move it. It was fun.)
Chances are with the County library, you probably don’t even see the Applet menu (it doesn’t work with most of my browsers), and the site does provide a text-based menu, but that just forces a person to have to go to another page immediately. This doesn’t even mention the havoc that a bad Applet or DHTML menu can have on the many different browsers that people use. As for accessibility issues–forget it.
If you must have a pretty, pretty for your navigation, incorporate it as a secondary page. Or use CSS and set the hover value to change the hypertext link font.
The site also has some other errors, including the hated “You should be using…” specific browser notices. I used these once a long time ago before slapping myself upside the head, reminding myself that I want people to visit, not go away until they’re properly equipped.
Other than these issues, the County library’s main page does have nice features, including prominant mention of special events, and highlighting services the institution wants people notice. As for the secondary pages, the library does have some very fancy search engines, as well as other interesting tools. The search results are very comprehensive, including providing thumbnails of the book (or other object), and availability at each branch. It also provides one click requesting of the item, which I frequently use. Additionally, you can filter results based on age or year of publication or any of a number of factors–something you don’t think about until you have it and then you go, ‘Wow. This is handy.”
It is a feature like this, handy but not essental that can make niche or community software, or Clay’s situated software, grow and grow unless scope is set and ruthlessly enforced. In fact, the two major factors that lead to escalating costs on any software project, big or small, are analysis paralysis (trying to meet all needs for all people for all time), and scope creep (“Ooo. That’s nice. But can we make it also do this and this and this…”)
