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.


  1. RSS/ATOM discovery and rendering. Or would that be an extension?

    Comment by Sterling Camden — 29 March 2006 @ 11:22

  2. At a guess, I’d say probably an extension. It’s something to run past the other people involved.

    By the way, you’re welcome to get involved if you like. I, for one, have no doubt you’d be an asset. You’d just have to agree to be constrained by the desire for a “minimal” browser, with the understanding that additional functionality can always be added later by way of extensions.

    Comment by apotheon — 29 March 2006 @ 11:27

  3. Well, what else does Firefox have beyond what you’ve listed? I mean, I agree with you that Firefox is porky, but is that a result of less-than-optimal code and memory management, or of feature creep?

    As for your take on users as programmers, I don’t disagree with it. Every developer should strive to write software as if they’re the ones who have to use it. A former boss called this “eating our dog food.” When we had to deal with our own pig code as an end-user, we were highly motivated to fix it.

    However, your distinction between closed-source and open-source software is, I think, oversimplified. The implication seems to be that “being profitable” and “serving the users’ needs” are somehow mutually exclusive, when in fact achieving the former isn’t possible without the latter!

    In the Web development world, where I’ve hung my shingle for the past 6+ years, the goal ultimately is to turn visitors into customers (at least for e-commerce). Now I work on Web apps that support the company’s service mission (in my current job, that would be telecom expense management). But in either case, serving the customer’s needs is paramount. The problem is that sometimes the process and methodology gets in the way of achieving that goal, and that becomes exacerbated the larger a company grows.

    Comment by Brian Martinez — 29 March 2006 @ 12:18

  4. I don’t think that serving the users’ needs is incompatible with being profitable. I just don’t think it’s necessary to it, either. They are, in the software industry, almost unrelated.

    What’s needed for profitability is the mere appearance of serving the users’ needs. If a user thinks his needs are served, he’ll keep paying money, whether those needs are served or not. Certainly, the best way to achieve that is to actually serve the users’ needs, but as has been proven by the sheer volume of business that Microsoft is doing it’s entirely possible to server very little need at all and still dominate the market.

    re: browsers It’s likely that Firefox’s problems include a hefty sampling of both feature creep and poorly coded software. I’d like to avoid both.

    Comment by apotheon — 29 March 2006 @ 12:50

  5. I would say that FF is bloated because of bad code for sure. I went and downloaded the sources for the latest FF and the latest Seamonkey [ full suite ] and the suite is significantly smaller in number of files, amount of disk space used for the source tree.

    the problems with the ssh and ssl differences are the staefull connection of ssh and staeless of the http protocol of ssl. adding support via an extention for ssh and creating an apache module to interface with ssh to work with it wouldn’t be hard, but the difference of statefull and stateless make a huge difference in if it would be used. Would a system admin be willing to add people to the ssh users? Would people be willing to loose whatever privacy they think they have when using an ssh powered secure site? it might be an idea to put that last out in the form of a question on a very high traffic site, to see what people think about it.

    Comment by Jaqui — 31 March 2006 @ 01:09

  6. It shouldn’t be difficult to allow a passwordless SSH connection with very limited nonshell access, I’d think. All you really need is per-connection authentication, after all, not an actual account. What’s needed, specifically, is just a means of ensuring that the current connection is part of the same series of communications as the previous connection made with a given client.

    Are there better ways to ensure that sort of secure same-source authentication?

    Actually, what’s really needed is a way to make HTTP stateful for a specific set of operations of arbitrary length. That is, in fact, what SSL does: it provides a statefulness work-around for the statelessness limitations of HTTP. The problem with SSL’s solution is that it authenticates the server with the client rather than the other way around, which is really not a very useful way to handle it. We need the client to identify the client with the server and maintain a stateful record of that connection for a transaction process of arbitrary length using encrypted communications.

    One way to handle this might be through forcing the user to register a username and password. Pass the client a one-use encryption key token when the client first connects to the secure site that expires the next time the browser window/tab loads a page — presumably upon sending the token back with some registration data.

    I’d prefer a means of providing secure transactions without requiring username and password, though, so that 100% of a person’s interactions with a given website could be encrypted (even those communications that should not require registration and user authentication). Anonymity maintenance as well as two-party data privacy would be required for me to consider web encryption truly “successful”.

    The SSH protocol seems like the perfect fit for this. It provides strong encryption, data compression, is not certificates-based, and has the security reputation of the OpenBSD project behind it (when using OpenSSH). Only the problem of implementation details remains, including whether it’s really practical to implement in the manner I envision.

    Comment by apotheon — 31 March 2006 @ 07:42

  7. count me in — not sure to what degree of involvement…leave that up to you mostly. What language(s)?

    Comment by Sterling Camden — 31 March 2006 @ 11:00

  8. C/C++ is pretty much a given for languages, unless there’s a miracle revolution and we decide to do everything in Haskell or Objective C (highly improbable, even considering their relative benefits). Aside from that, I’m really not sure. We’re still in initial discussion stages, though I’m planning on reorganizing my home network this weekend, and may have a version control server running by Monday.

    As things currently stand, a friend local to me is going to be the project manager and chief architect, and I’m going to be the cat herder and chief bottle washer. Everyone else contributes as they’re willing and able.

    Speaking of cat herding and bottle washing, I should set up a mailing list this weekend, too.

    All input is welcome, even if it gets ignored. I’m pleased to have your volunteer spirit engaged, Sterling.

    Comment by apotheon — 31 March 2006 @ 11:09

  9. Been doing C/C++ for 22/15 years now on UNIX, Windows, and even OpenVMS — I’d be glad to help out however I can. Is this going cross-platform? What UI framework(s) are you considering?

    Comment by Sterling Camden — 31 March 2006 @ 02:04

  10. You’re probably the only regular Windows user in the bunch so far, so there’ll probably be more focus on a unixy version than a Windows version with current dev team makeup, but I think everyone would like to see the thing be cross-platform. I’ll certainly advocate for portable code where possible, even if we don’t really specifically code for anything outside the realm of free unices, so that porting to other platforms wouldn’t be difficult.

    Tk, wxWidgets, and GTK have come up as likely candidates for GUI toolkits. Qt has been mentioned, but I don’t think anyone really wants to use it. Without actually knowing enough about them to be sure they’d be good ideas, I’d say I wouldn’t be opposed to using Gorm or Renaissance, but I don’t think it’s likely that we’ll do any Objective C oriented work, so that’s probably out.

    I’d like to know more about wxWidgets before I really throw what weight my opinion has behind any toolkits. If it’s easy enough to implement the sort of functionality we need, I would be fine with Tk, in fact. I, for one, don’t care about “pretty” as much as “usable”.

    EDIT: Someone mentioned FLTK to me as well. I started checking around for information about it, and the more I read, the more I like. wxWidgets seems to be widely regarded as overly complex and some say it produces sluggish applications on low-power systems, which is something I’d like to avoid. FLTK opinions seem to indicate, on the other hand, that it produces lightweight applications, is very flexible, and is reasonably simple to understand. I haven’t really gotten opinions from others about various toolkits yet, though, and am still waiting to hear from the other involved parties.

    Comment by apotheon — 31 March 2006 @ 02:34

  11. You missed the most important thing about browsers.

    CSS/HTML/XHTML/XML rendering. It needs to be at spec. Yes, the spec is ever changing but for starters a specification needs to be chosen (CSS 2.1, HTML 4.01 Strict, XHTML 1.0 Strict, not sure where XML is at) and it needs to be done properly. Firefox gets the closest of all the popular browsers (IE, Opera, Mozilla, Netscape and Firefox itself) but there is definite room for improvement and this is the one area that has stagnated.

    One thing we need to avoid doing is making our own javascript up. We need to find what the most common javascript is and standardize on it.

    We need to avoid making up our own HTML tricks (glow started out as an IE only thing and then became part of the spec). I know that’s how the spec gets updated, but lets not do it.

    Image support is another issue. We need to support bmp, gif, jpg, gif89a, png, jng, and mng. Without support of at least up through png this is not a browser I would use or advocate.

    Um, other then that, I think we’re good. ;)

    Comment by Joseph A Nagy Jr — 1 April 2006 @ 08:24

  12. Addendum: GTK, I think, is the most widely used out of those mentioned. GAIM and the GIMP both require it no matter what platform you’re on.

    Comment by Joseph A Nagy Jr — 1 April 2006 @ 08:27

  13. Standards-compliant rendering will be handled by the Gecko rendering engine (mentioned in the bullet points at the end of the main entry). I don’t intend to invent my own rendering engine for this when the GRE works better than any of the others for standards-compliance already, and is provided with documentation on how to incorporate it into a browser.

    We’re not reinventing the wheel, here, just giving it better tires.

    Comment by apotheon — 1 April 2006 @ 10:06

  14. But rendering is my biggest complaint with Gecko. I can understand not wanting to re-invent the wheel, but when we have the oppurtunity to go in and give it a tune-up, we should take it.

    Comment by Joseph A Nagy Jr — 1 April 2006 @ 10:58

  15. What’s your problem with it?

    In any case, I’m not going to ask that we create a new rendering engine. That’s rather more work than is likely to get done by my circle of friends any time soon.

    You could always start contributing to the Gecko project.

    Comment by apotheon — 1 April 2006 @ 04:25

  16. My problem with it? It mis-renders a fair portion of the CSS spec (if it renders it at all). It handles HTML/XHTML fairly well, though. My biggest issue is that I cannot, without browser hacks for Gecko and IE both, do half the stuff I should be able to with CSS. I’m not completely suggesting a new rendering engine, but perhaps an overhaul of Gecko. It could also lead to removing a lot of bloat from it as well.

    Comment by Joseph A Nagy Jr — 1 April 2006 @ 10:47

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

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