Usability concepts

[aaronNGi]

Hey there. I'm a long time ii user who has invested quite a bit of time in brainstorming how to improve its usability and writing my own version of an ii-like irc client. I've just found your project and wanted to share some of the concepts I came up with. It's mostly things which make front-end development a lot easier so I was surprised you don't do some of those things in hii. Maybe you find some of it useful.

For instance, it's very hard to figure out your own nick, which you need to know if you want to display your own messages differently or if you want to highlight messages mentioning your nick. It's way easier to do this in the back-end instead and simply prefix ones own nick (and surround every mention of it in messages from others) with some unprintable character. Not a pretty solution, but this is the easiest to parse in the front-end. You can pipe a snippet of a log to your front-end and it will be able to highlight your own messages even if you don't know what nick you used at the time.

My back-end writes quite a bit of information to different files. That includes a list of joined channels, own nick, (per channel) channel topic and channel users (nicklist). Since I was also afraid of too frequent writes, I have those files and the in-fifos reside in tmpfs/shm. I recently thought about extending this even further and ignore MOTD and other info messages send at the beginning of a connection and simply write them to separate files (motd & server_info). That way, connecting will only ever generate a handful of messages instead of the excessive log spam.

Another big usability problem with an ii-like client is keeping track of new private message channels (I will call it query). A solution is to manually check by using ls or something like inotifywait. Much easier to write a message to the root log if a new query channel was created. I also do this for highlights. That way it's easy to monitor important events in one central location.

For channel auto-join, I made the back-end execute external files for certain events like on_connect, on_highlight, on_join, on_query etc. It checks if the respective file is executable and runs it, handing over a bunch of useful arguments (mostly your own nick and the path to the in-fifo). I think this is the most KISS, unixey and flexible way of doing automation. For instance, I do my channel auto-join in on_connect (in my case simple #!/bin/sh) and mobile notification push-service in on_query and on_highlight. I have on_ctcp in case I want to reply to simple requests like VERSION, PING etc. With on_join it's also very easy to automatically open new tmux windows when joining channels.

With all of this, my front-end is quite usable which basically consists of a 63 loc awk formatter script and a couple lines in some of the on_* files.

[nmeum]

Hey, thanks for your input and sorry it took me so long to respond. I think some of the concepts you outlined are very interesting and I commented further on them below, to be perfectly honest I didn't invest as much thought as you did into improving the usability of ii regarding frontend development. I simply implemented the changes I needed for my own frontend.

For instance, it's very hard to figure out your own nick, which you need to know if you want to display your own messages differently or if you want to highlight messages mentioning your nick.

That's indeed a problem for which I didn't have a solution at the time you opened this issue. I really liked the idea of using non-printable characters for this purpose, even though I agree that it is a bit hacky, and implemented this in hii recently. So thanks for sharing that idea!

My back-end writes quite a bit of information to different files. That includes a list of joined channels, own nick, (per channel) channel topic and channel users (nicklist). Since I was also afraid of too frequent writes, I have those files and the in-fifos reside in tmpfs/shm.

I also considered writing more information to different files but since I didn't want to use neither FUSE nor rely on a TMPFS (since I wanted persistent logs) I decided not to do that.

Another big usability problem with an ii-like client is keeping track of new private message […] Much easier to write a message to the root log if a new query channel was created. I also do this for highlights. That way it's easy to monitor important events in one central location.

hii also creates a per-server log file in the server directory containing messages received from "private conversations" and messages received in channels which mentioned the users nick name. I find this to be very useful as it easily allows me to figure out if I missed any important messages while idling.

With all of this, my front-end is quite usable which basically consists of a 63 loc awk formatter script and a couple lines in some of the on_* files.

My frontend is a bit more complex, I guess, it consists of ~10 programs/scripts written in C, AWK and POSIX shell and makes heavy use of tmux to create an irssi-like terminal UI frontend. It can be found here: https://github.com/nmeum/insomnia