The Review
Since people keep asking us what our view is on the usability review seele recently did about Quassel IRC, I thought I should blog a little something.
First of all, it didn't hit us as a surprise. We've been in contact with kubuntu about their plans before, and we've ongoing discussions with seele and other kubuntu devs about how to make Quassel suitable for new users, in particular for kubuntu's main target group. Many things seele mentions in her review have been on our TODO list for a while now, but of course, being developers, we tend to put such issues off in favor of new features... now this whole thing shifts our priorities to focus on usability for a change. Sorry guys, this also means scripting support has to wait again...
Meanwhile, apachelogger is busy making the Quassel packages rock on kubuntu, and now provides nightly Quassel builds via Project Neon. And the Quassel developers, of course, are now busy to convert the review into code :)
Read on for some specific points.
The main issues we have on our agenda now:
- Streamline the monolithic client to act more like a traditional IRC client
- Provide better defaults
- Make configuration easier
The first issue, of course, is key to provide a good first-run experience for users who are not familiar with Quassel's client/core concept, or who are just looking for a "normal" IRC client. Of course, we mainly had that use case in mind when we decided to provide a monolithic client. As seele points out, currently our core connection dialog does not make it obvious how to use Quassel like that. We will streamline this to make the internal core more prominent (i.e. don't ask for creating a remote core account), and probably add a way to directly enter network and identity settings if one wants to use the internal core. We won't completely remove the ability to connect to remote cores from the monolithic clients; we'll rather make it clear that this is an advanced feature. For kubuntu, we will probably add a compile-time option to hide the remote core options altogether by default. This should help new users to quickly get started with Quassel, and still allow advanced users to use remote cores.
"Better defaults" mainly concerns the buffer views we show when you start Quassel for the first time. Many of our users don't even know that they can create custom views which allow the hiding and rearranging of channels. Instead, we plan to create a sensible set of custom views by default, and hide the "All Buffers" view. In fact, EgS has recently added a way to unhide hidden channels without resorting to the All Buffers view. Lack of that ability was the main reason for even having the All Buffers view, so this is the first step in making this better.
The configuration dialogs need some love as well. seezer is already busy fixing many of the UI issues seele pointed out, and I will tackle the styling options soon (i.e., make setting colors and fonts easier). With KDE integration enabled, you already get the standard "Configure Notifications" dialog from KDE rather than our own notifications, which should help to remove confusion about all the different options.
There are more issues, of course, and we'll see how far we get with those until kubuntu goes into version freeze. Rest assured that the Quassel developers put a lot of effort into this, so the next release should have some visible improvements for you guys :)
Back to hacking now. Oh, and a Happy New Year!
~ Sput
Scripting in an IRC client isn't nice -- it's vital
As someone who has been opping IRC channels for years now, well in excess of a decade, I think it's necessary to keep in mind that IRC isn't exactly newbie friendly at the best of times.
Then again, any effort to make it more so needs to be encouraged and applauded.
But NOT at the expense of a scripting interface. Script support isn't a nice to have for those of use who op channels, it's a MUST have. It is to auto voice in channels where bot support is dicey, on networks such as DAL and Undernet (only the two biggest) where bots have to go through extensive approval processes or where it's totally non-existent.
This is for things like voicing, inviting, banning and enforcing bans, kicking and so on.
And for communicating with the newbies when they ask questions I've answered a zillion times and I'd rather turn over to a script to answer. (For example: what's notify? or how do I do that? [when people use the /me command].)
What I'm seeing looks great but not at the expense of Kubuntu, for example) holding up the implementation of a scripting interface (perhaps one that reads and executes mIRC scripts? :) )
In the meantime, for someone like me and we are a a lot of potential users this is something nice and compelling but utterly useless in terms of what we do day to day on IRC. Let's keep in mind here that some of us are trying our best to keep IRC as free as possible of spammers and other nasties so it doesn't turn into another Yahoo, MSN or (heaven forbid) Google chat client. We can't do that without a scripting interface. Pure and simple.
Oh well, there's always aging XChat, I guess.
ttfn
John Wilson
Scripting is BLOAT
It's really just ridiculous for Multi-User Chat clients to support scripting. Using scripts technically makes YOU a bot, so if the network bans bots, there is no reason that shouldn't be considered a ban on scripting too.
Scripting is *NOT* BLOAT
Obviously you've never OPed in a large channel. I'd like to see you manually squash mass flooding, or typing in the same long kick/ban messages over and over again, ad nausium.
Besides, quassel already depends on Qt, and SQLers. Adding a tiny scripting engine is hardly going to make system resources evaporate (hint, see irssi). And there's nothing stopping the quassel devs from making scripting engine support an optional plugin (other than the lack of plugin infrastructure).
No developer can cover 100% of IRC usage cases, it's impossible, that's why IRC clients provide scripting interfaces. And if you try to cover all usage cases, you just end up with another version of Konversation. And if you really want to hide advanced scripting and plugin options away from newbies then just make the interactions for those through commands /plugin {add,remove,options,etc} and /script {ditto}. If you don't cater to non-n00b usage, it'll just be useless to the majority of folks who use IRC.
And frankly, by offloading optional code to plugins and scripts, you drastically cut down on development effort, compilation times, bloat, and feature creep of static and rigid applications.
If I want to read my email, or tell amarok to play the next song in my playlist through my IRC client, I'll bloody well do it.
Scripting is ESSENTIAL!
nt
Kubuntu
Great!
Quassel is now officialy in (K)ubuntu: http://packages.ubuntu.com/search?keywords=quassel