Yamoxic design document

I want feedback! Feel free to edit the /Feedback page, or find me on IRC. I'm usually on #linux.se on IRCnet or #icecap on Freenode, my nickname is pv2b.

My ideas are of two main types – ideas to be implemented mainly in the Yamoxic client, and ideas implemented mainly inside Icecap itself.


Yamoxic-specific GUI ideas

GUI Design goals

Easy to use, yet designed with the power user in mind. Use the abilities of a GUI to enhance the IRC experience rather than just slapping a GUI on top of what's at heart a command line environment without any real usability ideas. There are lots of things a GUI can do that is difficult or impossible to do in a command line, yet very often these things are ignored when writing IRC clients.

The client should be unobstrusive. It shouldn't blink and bounce all the time just because someone mentions you in an IRC channel. It can maybe use sounds to notify you, but *only* if the actions directly concern you – if you're mentioned in the IRC channel, or if you're kicked or you get a message or an action or something. It shouldn't sound every 2-3 seconds just because you're in a channel with lots of joins, parts and quits etc. It could use a nice unobtrusive "dock badge" to notify you as well. (It would be cool if you could badge minimized windows. I wonder if you can do this?)

It should not attempt to be too generic, do too much stuff, or look like an IM client. IRC is not instant messaging, and lots of features most people don't use will only confuse and make it take too long to find stuff. (Microsoft Word is a perfect example of what Yamoxic should not try to emulate.) Sometimes it's nicer to have several small applications. :-)

It should adhere to the Apple HIG when appropriate. It should feel like a Macintosh app. However, the HIG is just a set of guidelines, and not the definite source of dogmatic UI principles.

Yamoxic will become a Mac OS X-only application. A lot of what I want to accomplish is a great GUI. And it's hard to do that while being cross-platform and having to compromise with different GUI philosophies. And there are already plenty of other Clients in development for other operating systems as it is. :-)

General principle and window switching

One window, one recipient. This applies to windows specific to certain channels or users. This does not apply to the "action window" described below. This is to avoid confusion and weird drop-down boxes for choosing a destination. This is sensible, but you might object that it could cause a lot of annoying pop-up-windows etc, but see the "action window" below on how that will be avoided in an elegant way.

Every window could have a keyboard accellerator shortcut in the titlebar, like terminal can have it you configure it for it, so the titlebar could say something like "#linux.se - ⌘2", meaning that you should press ⌘2 to get to the window. (This idea is blatantly stolen from Apple's Terminal.app.) So you don't have to use the mouse to switch between windows all the time if you don't want to.

Maybe there could be a feature, so you press a button, and all the windows combine into one compact tabbed window, if you want a compact window when you want to put something else next to it, and again to expand back the windows in their original positions when you want to devote your attention 100% to chatting again full screen. :-) This can also be combined with TimoSirainen's overview window idea – a single window providing you with a view of what's happening in all your channels, in a compact manner. Also, clicking on a channel in this overview window could bring up a larger chat window for that particular channel, so that the overview window would double as a sort of tab switcher.

Text encodings

The client should make it easy to select encodings for a channel or single user, and not bury it in advanced options somewhere. It can well be a accessible by a button in the window's toolbar, just like in Colloquy. There could be a "retroactive" option as well as a "non-retroactive" option (so you can see earlier messages posted in another encoding maybe). How to implement this in a "nice" way UI-wise? Maybe retroactive encoding change should be a power feature requiring you to press option while you're changing the encoding? Maybe one submenu with "change retroactively" and one "change for future messages". That might be a violation of something being "easy" to change. But this is typically a change you do only once, and a list of lots and lots of encodings isn't really "easy" to select from in the first place, so it's maybe not a big deal.

Yamoxic should not try to revolutionise the IRC world by defaulting to UTF-8 or something stupid like that. It should default to encodings people actually use on a daily basis. Defaulting to UTF-8 on a non-UTF-8 channel just makes people annoyed, and if a user joins a UTF-8 channel using the wrong encoding, most of the time people won't be as annoyed by it.

Channel window

Generally, only things everybody in a channel sees should go in the channel window. With some possible exceptions:

Nick list on the right. Attached to the window as the folder list on the left in Mail.app. Should allow hiding by dragging the divider all the way to the right or double clicking the divider. Or maybe as a drawer. I used to think drawers were unsuitable for this, but it can often be handy to be able to hide the user list to manage screen space better.

At the bottom of the nick list could be a "channel administrator panel" or something, like in X-Chat or AMIRC. It would be hidden by default, and slide out automatically if the person gets opped. (It might look a little like the album art window on the bottom left of iTunes.) If the person gets deopped, it should not hide, but the buttons should grey out. The user could open this panel himself if he wanted to, but everything would be greyed out.

Finally, there should be a "channel administration drawer" where you can change channel settings, bans etc. Sort of what you get in mIRC when you double-click in the channel window. The drawer should be at the bottom of the window, since it is a "wide" window, and doesn't really fit on the side of a window.

User window

There should be a "user window". This window would be primarily associated with sending messages to and from the person, but also for other actions.

It would also have a nice little toolbar on top which would allow you to send files, initiate DCC chat, invite a person to a channel, /whois them (this information might appear in a drawer or something), ctcp them, ignore them and whatnot.

The window would be opened by double-clicking a name in the nicklist of a channel, a name during the chat, or be manually creatable through a menu option by typing the nickname. (Or maybe a toolbar button in the action window.)

What can I call this instead of "user" window? User is a too technical programmer/admin-centric a word. And I don't want to say "buddy" because it's presumptuous imo. "Chat window" or "message window" is too narrow a word. "Private window" maybe? Hmm. Or "Contact window". Ideas? /Feedback please.

Action window

A solution to the mess of pop-up message windows, etc. One central UI element will be the action window, where all actions that are not specifically linked to a channel will appear, for example, DCC requests, messages, notices, invites, wallops, etc.

Messages, for example, would get a line on the event window. When clicking the reply button or some-such, a new window, let's call this the user window (see above), should appear, (possibly with some nice zooming animation or something) with the chat lines at the top.

Allow advanced mode which will also show "unrecognised" events. Add a button to report unrecognised events that an advanced user believes should be handled by Yamoxic (or Icecap, whichever is relevant). The normal mode would also hide CTCP requests by standard. (Who cares if someone is curious about your ping time or version if you're not an advanced user? No reason to confuse them with the information if they're a newbie.

Drag-and-drop

Drag-and-drop should work in all expected and unexpected places. :-) Dragging a user to another channel should invite them to it. Dragging a file onto a user should send the file to them. Dragging a link from a web site should also be possible.

Dragging a file onto a channel should also be possible. This can be implemented in a few ways. Maybe using a tiny web server integrated into Icecap? (See the Icecap Mini HTTP server section lower down for more information.) Or maybe it can be configured to upload to some nice web space you have somewhere? The possibilities are eeeendless! :-)

Log browser

There seems to be this idea that infinite scrollback is a good thing. However, infinite scrollback has one huge problem -- the fact that it is infinite.

Ignoring for now the technical problems of scrolling in and especially horizontally resizing and reflowing a very large amount of rich text (which are difficult to make fast, but ultimately possible), you essentially make the scrollbar useless.

How useful is the scrollbar thumb when looking for information inside a day's worth of scrollback in a busy channel? Barely. Now, imagine a week of scrollback or a year. Clearly, the scrollbar model doesn't scale to the huge amounts of sheer text that IRC can provide.

Instead, I suggest an upper limit on the amount of lines scrollback can provide to keep the scroll thumb sane (the user can configure this at their own convenience if they wish), and instead provide the user with a log browser, which divides logs into managable "pages" or "chunks" and makes it easy to search inside logs or read logs by date. To make it less frustrating for a user hitting the top of the scrollback, there could be a button at the top of the scrollback leading to the same place in the log browser, or optionally, making it possible to click a button "add more scrollback" adding another 10% (or so) of scrollback to the window. This scrollback will disappear again when scrolling down from the additional scrollback in order to keep the scroll thumb sane again.

Ideas? Comments? /Feedback!

Stuff NOT to implement


Ideas for implementation in all Icecap-capable clients and in Icecap itself

Server chooser and network awareness

Typical in most IRC clients is a connection manager to create connections. These windows tend to be either too simplistic or too complicated. Yamoxic should try to set a reasonable balance between these two sides. It should be possible to simply select a network and click "connect". Then, Icecap could use several heuristics to find a good server to connect to.

The best solution would be if Icecap could provide a web site somewhere where you could download updated network definition files, containing a list of IRC servers and their capabilities. (How many kicks per command, how many modes per command, etc.)

The user could choose preferred servers himself as an advanced option, but the IRC client should be smart enough to choose a good IRC server for the purposes. It could send out a bunch of ping requests to every server on the list and try and choose the server with the lowest ping first. On networks such as IRCnet where you have to connect to a local server to be let in, going to lower-ping servers first makes it likelier to strike a working server quickly.

As an added heuristic, a bot connected to a web server could retrieve information about I-lines, i-lines, G-lines and K-lines to tell the clients what servers to avoid and what servers to prefer. (This should be possible using the STATS command in IRC I think.) This information should of course not be gathered too often, once every 24 hours should be more than enough. I don't want to incur the wrath of server operators by getting a rumor of being an evil bot annoying the network with /stats requests every 30 seconds. But this might actually not be neccessary, since the ping time heuristic should be enough to quickly find permissible servers.

MOTD window

Show MOTD when connected, every time as standard, to inform users about the policy of networks. Don't just hide it like some IRC clients do, the information is important in many cases!

However, showing the MOTD window every time you connect just annoys people. You could make an option to tell the client "only show me the MOTD if it has been updated". Store a copy or checksum of the MOTDs on the hard drive to make this possible, along with the last-change date. If the copy is stored on the hard drive, you could then do a nice graphical diff of the two MOTDs in the event they do change, making it more likely that the user is actually made aware of the changes to the MOTD rather than blindly dismissing it.

UPnP support

Icecap should use UPnP to open ports for DCC sends and other nefarious purposes ;-) such as allowing Icecap access from outside hosts if requested.

Icecap Mini HTTP Server

It'd be cool if Icecap could act as a Mini HTTP server for sharing files to channels. A user could drag and drop a file onto a channel, and a URL would pop up for the channel where it can be downloaded, shared by the web server built into Icecap. Thttpd might be a good project to borrow code from. This could also be used when pasting large chunks of text.

It could even use information from /who together with what IP addresses are connected to see who clicked on the link (although this obviously wouldn't work with people behind bouncers).

And… it would of course use UPnP to poke a hole in the friendly neighbourhood NAT router. :-)


Problems

Clients/Yamoxic/Design (last edited 2009-03-15 22:42:39 by localhost)