Chad Perrin: SOB

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.

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