Meil: Design motivations

This post is part of a diary-style series of posts that catalogue my design and development of Meil—an IRC client application for the Mac. See the first post in the series, “Making a better IRC client”, for the background.

I have a confession to make. I first decided to try writing a new IRC client because I play pen & paper role-playing games¹ (a.k.a. tabletop RPGs or TTRPGS) online,² and no existing IRC client is as good for that purpose as I would like.

People have all sorts of odd wants, needs, and preferences when it comes to software. For me, RPG gaming is a big part of what I use chat programs for. I’m going to talk about that in a later post; for now, bear in mind that at least some of what I want from an IRC client is unusual.³

Anyway, this post is about design motivations. Not requirements, mind you; that comes later, further into the design process (and after a good deal of research and analysis). Right now, I’m asking: why am I doing this? What do I want? How will I know when I have it?

Features

The spectre of empty buzzwords rises to haunt us as we utter the word “full feature set”, but in this case we’re safe from its soul-draining touch. All I mean by “full feature set” is that various IRC clients let users do many interesting and useful things, and I’d like Meil to do as many of those things as possible. As I said in the first post of this series, Snak’s feature set is the bar to clear. The venerable (but, sadly, long defunct) Ircle is another giant of feature-richness among the pantheon of Mac IRC clients past and present, and I’ll definitely be mining it for functionality ideas.

Setting sane priorities will be critically important, and the goal of “implement literally every possible feature” is both unattainable and ill-advised. But the key point is: Meil should work as a primary or only IRC client for most users, rather than any sort of supplementary or special-purpose app that people run alongside their primary IRC app. It should—other design goals permitting—do (at least) most things that (at least) most people want their IRC client to do.

Expect many more posts about Meil’s feature requirements and related issues.

Gaming

As mentioned, I use IRC to play TTRPGs online. Obviously, Meil will have to be at least as good for this purpose as any existing IRC client (and, what’s more, at least as good as any existing chat client of any other protocol — see “Why IRC?”), or this entire exercise loses much of its appeal. Of course, the actual goal is loftier than that: I want Meil to be utterly perfect as an IRC client for the way I game (and as close to perfect as possible for the way other people game, too).

A future post will go into detail about this particular design motivation, and the features it demands.

Compatibility

Meil should run on the computers I use. I shouldn’t have to upgrade operating systems in order to run it; neither should it force me to use an older system than the one I’d otherwise use.

There are limits, of course. The latest version of the Mac OS is 10.11 (El Capitan). I use OS X 10.9 (Mavericks), and I use OS X 10.6 (Snow Leopard), and I also use OS 9. (I also use Windows and the occasional Linux, BSD, etc., but never because I want to, so I am not terribly interested in actively pursuing compatibility with those systems.) Making sure Meil runs on 10.6 and above seems like a reasonable goal. Making sure Meil runs on older OSes, down to OS 9 and older, is… probably possible. Maybe. But I’m not going to seriously attempt it.

In short: Meil must run on Macs running OS X 10.6 and above, else the endeavor is moot. Everything else is negotiable and secondary.

Expect later posts to discuss any technical challenges that may arise when making sure that Meil is compatible with those Mac OS versions.

Usability

In a perfect world, I wouldn’t need to talk about how my application will be easy, effective, and satisfying to use. Announcing my explicit commitment to usability best practices and the ideals of good UX should be vaguely bizarre, like declaring that “ensuring that my app won’t cause your computer to explode or melt is one of my most important design goals”.

That would be a glorious world indeed, but it is not yet our world, so here we are. The following is what I mean by usability:

Meil should be easy and pleasant to use, using it shouldn’t frustrate the user or require unreasonable effort or contortions, and it should behave in the correct and proper way in all situations and use cases. Every part of the program, every aspect of its design and functionality, should have these qualities. Everything about the program should function in such a way as to most effectively and unobtrusively let the user do what they want to do on IRC.

This has many implications, for the design and development process and for the way the final product will look and act. Expect many posts on this topic.

Aesthetics

I get aesthetic pleasure from using programs with good-looking UIs, and aesthetic displeasure from using programs with ugly UIs.

Of course, aesthetics is in the eye of the beholder. I am the beholder whose ocular goings-on concern me most; but I’d like Meil to be useful to others besides myself. And I know that my aesthetic preferences are unusual, in many ways, which means that I dislike many popular things (through no fault of their designers). So if I do not design for myself, then who will design for me? But if I design only for myself, then what kind of designer am I?⁴

So the goal is: make Meil aesthetically pleasing, for myself and for others. I’ll have much more to say about this in a later post.

Rectitude

This is a tough one to put into words.

Parts of it have to do with usability: there are certain unambiguous best practices—things that go beyond competing user needs or heuristic guidelines—and deviating from them is poor form, at best.

Parts of it have to do with compatibility, security, stability, or other aspects of good software engineering: a program ought to be stable, it should follow accepted patterns of software behavior for the system it’s on, and so on, it should run on as broad a range of systems as is reasonable, etc. (Some, though definitely not all, of these things overlap with what is traditionally discussed under the “usability” umbrella.)

Parts of it has to do with features: there are things which a program of a given kind should be able to do, and if you create a program of that kind which can’t do it, you’re simply negligent. Failing to add a spell-checker to a word processor is an absurd oversight, for instance; nor must a modern IRC client lack an interactionally easy way to send ACTION messages. Users have certain expectations for these sorts of things, and rightly.

Other parts of this have to do with what’s variously called ethics, manners, consideration, being a good (internet) citizen, and many other things. Adherence, whenever possible, to standards and specifications falls in this category. So does not violating the user’s privacy.

In general, there are various situations in which there is, for a program and for its creator, a Right Thing to do. Sometimes the Right Thing is given by the output of some official decision-making body. Other times, knowledge of the Right Thing comes from generally accepted principles that aren’t formally encoded as The Rules. Sometimes we—designers, coders, and users—simply know what the Right Thing is, by strong intuition. (And sometimes we argue about it endlessly on IRC.)

Absent a compelling reason not to, Meil should always do the Right Thing. (And it almost goes without saying that I’ll have much more to say about this in future posts.)

* * *