I've worked for a number of different clients and companies designing and implementing user-centric applications, usually in the form of web applications, but also occasionally standalone apps (this is in contrast development of backend libraries or in scientific computing).
Recently, I came into a point of tension with a somewhat micromanaging client when doing design work for a web application that was supposed to ship under a tight deadline. As deadlines were tight, I was trying to concentrate on getting out data model nailed down. I was approached by the stressed out client who proceeded to tell me that I was not working correctly, because as everyone in the industry knows, it is standard practice to design a UI and then develop based on that UI.
At the time, I was too bleary eyed and not in the mood for an arguement- particularly with a non developer. However, the incident forced me to concretize some personal approaches to software design in contrast to what I have often seen in the market:
Fallacy 1) Design should stem from the UI down - This approach generally does not work out. The more fascist the client is about managing a project within the paradigm, the more inflexible the code base generally becomes. In the several times I have worked in this uncomfortable position, I have found that the client basically treats the UI like their living room. That is to say, they do what they want to the UI on an intuitive basis because they feel it is easy. Of course, requirements engineering is a practice in itself, and the reality is to really manage the direction of a software project on that resolution, you must become a slave to use cases. Documenting the use case is an analytical task from which you should have a sortable list of requirements. While this should be a no-brainer, the urge for a client to express their repressed inner artist on the UI is best reserved for a lifestyle change.
Fallacy 2) The only type of user is the user of the GUI - The most notable time I encountered this was on an eXtreme Programming project. One of the goals of the project was to create a modular code base that could easily be hacked on by the community at large. The project lead correctly and religously followed XP practices of generating use cases. However, the project lead only thought of the user as a person using the end application. This thought process completely discounted engineers as potential users as well. The XP paradigm in this case would have worked out great if the lead were to consider sysadmins and other developers as users of the application (though in a different context), as the project was intended to be open source and widely modified.
Fallacy 2a) Your user is not an intelligent user: This is a subtle form of cultural bias imposed on the user, and ties in tightly with use case reasoning. This is particularly applicable to very data oriented projects. While many users will use the point and click interface, invariably, if you are going to form partnerships with your users then the format in which the data is delivered will change. One example of this is making your data accessible not only through a UI, but also web service, raw data, etc. Yet another no-brainer that I've constantly seen ignored- often by the mindset of keeping your data "closed" (usually for reasons of perceived profit)... keeping this in mind will force you to decouple your logic and presentation layer;
This form of reasoning is also what causes tension between a user-base and software publisher. The software publisher wants for whatever perceived reasons, ONE USE CASE and one use case ONLY. To put it flatly, this is cultural discrimination in it's most reduced form. People have radically different customs and rituals and creativity than you do. To one person, a USB cable is for plugging in an mp3 player, another it's a cable for hacking all sorts of data streams, to another it makes for great fishing wire. Likewise, if your application is at all succesfull, it will be used in ways that you haven't conceived, and this a wonderful source of cultural variation and human creativity. The minute you try to avoid this, you box yourself in. Some people take this a step further and make the DMCA.
Fallacy 3) UI for end users is about expanding choice: While this seemingly runs counter to the above 2 arguements, it's something to keep in mind as a design principle. If you are building an application that users will use more than once, then your UI is about taking away choice, not expanding it. Choice is for people who have time to make decisions. Ideally, the UI will have only one button: the "go" button, and the rest will happen by itself. While the opposite side of this is reflected in the unix philosophy: more options, more power... more choice inevitably creates a class of people who understand the ramifications of the choices. As with any powerful tool, this is not a bad thing or something to avoid... However, if you are indeed going after the clueless end user, then in the end, you should be making as many decisions as possible for them.
Fallacy 4) AI is really easy to implement - a little off kilter, but also something I was asked to do recently. My client came to me and asked "can't you just make some sort of fuzzy logic system to deal with this?" (referring to parsing of natural language documents into a queryable data structure).
Okay, I have to take a hardline on this one. You should never, EVER EVER use the words "fuzzy logic" to an engineer, software or otherwise. Fuzzy Logic is banned from vulgar use. Unless you have specifically read a book on how an algebra of a fuzzy logic system would work, OR in detail describe the Church-Turing Hypothesis, fuzzy logic is a TECHNICAL term for professional use only. Otherwise, feel free to use fuzzy logic amongst all your hippy friends: (Woah far out man, we can use some fuzzy logic expert system with our homeopathic organic medications to reccomend a combination of hemlock and 1x100 tincture of placebo).
Fallacy 5) methodology is superior to intuition: Your intuition is the best voice to guide you to the outcome you want. The most productive teams feed off of good vibes, and methodology is a a tool that when used correctly can induce knowledge discovery, accounting skills, as well as acting as a common idiom with people who are new on a project.
Ugh... So I've just written a philosophical guide. All my hacker friends will laugh, but I'm sure they've experienced similar...
Okay, first... I'm LAME... I'm sorry to everyone who has emailed me and I haven't responded to yet, and all the people I haven't talked to or hung out with for seemingly all fall. I should be getting time soon.
Second, this blog, like all living systems, suffers from link rot if you don't maintain it. Deleting 720 comments worth of blogspam is a major pain in the ass...
Anyway, more importantly, it's the time of year again to go vote. In the past, I've talked to many people who were of the "no-vote" philosophy. This predominantly anarchist form of dissent was always something of a mystery and irratation to me. While I was an anarchist itself, not voting as a form of dissent seemed counterproductive, and really, you should use all means possible to further your goals whether it is "legitimized" or not no? Ironically, this election I am the most disaffected and apathetic I have been of any election. When I actually visualize myself in the ballot box giving a vote for some rich dude as a method of protest of another rich dude, and having the "alternative" vote be a populist demagauge that specializes is sucking money from naive college kids.. And having my hopes of reform through ranked-choice voting dashed by Australia's recent election of a far far right wing minister. I'm more than happy to think about my own life and not about slimebags that make a lot of money for people other than myself. When I think about this, I feel very much like I'm voting for what size nail one should hammer your coffin with.
However, that aside, I *am* going to vote this election. My primary concern is not so much on the presidential level, but rather on the California level. The ballot props, as usual for california legislation, pulls stuff in interesting directions. Here are my "endorsements" - however, I'm strangely undecided in a lot of them. If anyone has any useful guides or suggestions on these ballot props, let me know.
Okay THERE. That's my coverage. I'm more than open to intelligent counterarguments. Anyone want to pitch one?