Ticket #6 (assigned enhancement)

Opened 3 years ago

Last modified 3 years ago

Usability report

Reported by: devurandom@users.berlios.de Assigned to: giblet (accepted)
Priority: normal Milestone: rbot 1.0
Component: misc Version:
Severity: normal Keywords: usability feedback
Cc: devurandom@users.berlios.de

Description

Hi!
Some notes about usability, after a short time of using rbot. In my opinion the best time to tell about usability issues, because you dont know the program a lot and thus look at it in a unbiassed way.
(Note: I used supybot before for some days and now want to try something else for some reasons. That's why I sometimes refer to this bot. Perhaps you know supybot; Then it will be easier for you to understand me.)

First thing that made me wonder is that even if I said "rbot -h" it still wanted to start rbot instead of giving me usage information.

Second was, after I searched through the code to see how you load the config, that even after I wrote "rbot ." at the commandline you still did not create a new config file and instead want to start with the default config. I see reasons for that if you intended to only overwrite some settings with the configfiles I have in the specified folder.
So I would suggest to add a rbot-wizard, like supybot has. It sets up a config in the current directory. It asks for the network I am using, what nick the bot should have, whether I want to create an owner and how his nick and password will be. Even what plugins I want to load.
You could ask for advanced or newbie options. This should include the question whether I want to import the default config from /etc/rbot or create my own from scratch.
Such a tool would be very nice. (I suggest you try it to know what I mean.)

I think you should keep an eye on the command names. Currently you use rmlart, but delquote and such. Would be better if both use rm or del. (I think this applies to other commands, too. So this is only an example.)

How do you handle the fact that there could be more than one plugin defining the same command? This will not happen if all plugins are written by you, I agree. But what if I want to use 2+ 3rd party plugins? I would suggest using Plugin.command for that.

You also send more than one message at a time (if the response is too long for one message). I liked the method of supybot to only give me one message and telling me that there are "(N more messages)". So I don't accidently spam a channel. I would do it like this:
Write a @@more@@(or similar) in each description. Cut the description at @@more@@ if it would be too long and provide the next message on "more" command from the user. If there is not @@more@@ tag, simply truncate the string at the position where it is too long and provide the rest as above.

Supybot uses bold text and keywords. That enhances the clarity. I can see at one view what I want to know. E.g. it bolds the command and parameters in the help message.

help shows something like: lart|praise|addlart|addpraise|rmlart|rmpraise in the plugins section. wtf?
If I did understood this correct, you want to list the plugins. But as I dont think there is a plugin of such a weird name. So you seem to list all of the plugins commands. I think you should really only show the name of the plugin here. That would be much cleaner.

You also give me help to more than one command if I only requested help on one of them. If you intended to show related info, use something like "See also:" in manpages. Or better: Show the plugin this command is from. So I can ask for help on that plugin if I want related commands.
I would prefer something like this:
---
<<me>> help Plugin
<<rbot>> Plugin: This is a plugin to do this and that. You could even do something. Do you want more information?
<<me>> more
<<rbot>> Plugin: dothis, dothat, dosomething
<<me>> help Plugin dothis
<<rbot>> Plugin.dothis <arg1> [<arg2>]: Do anything usefull. <arg1> means this.
<arg2> means that.
---
The sentence "Do you want more information?" would perhaps reflect your way of conversation like commands and responses better than "(N more messages)".

Supybot also has an interesting way of storing and accessing configuration. Dunno how you do this. My idea:
---
<<me>> config Plugins.Plugin1
<<rbot>> @group, someGenericOption
<<me>> config Plugins.Plugin1.group
<<rbot>> anotherOption, #channelDependentOption, @yetAnotherGroup
<<me>> config Plugins.Plugin1.chanDepOption
<<rbot>> "Default string for new channels"
<<me>> config Plugins.Plugin1.chanDepOption.#channel1
<<rbot>> "Some string that was configured for channel1"
<<me>> config Plugins.Plugin1.chanDepOption.#channel1 "Much shorter string"
---
This is again with ideas from supybot.

Notify me if you dont understood me(unknown command) or if I used the command in a wrong way. I think "What a crazy fool! Did you mean |help stats?" should tell me something. But I dont know what you mean with the last part.

Optional plaintext responses would be nice, too. Simply "Error: This or that is wrong." or "Operation succeeded.". For more demure channels.
Would imply: Short version of the more thingy: "(N more messages)" (What version is used would depend on the plainResponses config option.)

Think I am finished for now. ;)
I'll write more when I get more ideas. I also will try to write some plugins after I read the ruby book. ;)
I hope if you don't want to implement something for this or that reason you will tell me. And perhaps we can discuss it.

Thanks for this bot,
Dennis

P.S. I never intended to say supybot is better than rbot or anything like that. It just has some ideas implemented, that I like. But it is not how I would imagine a bot to be. That's why I came to use rbot.
I saw the very easy way of writing plugins, with it's fast to understand hooks. I hope this continues in the UI part. :)
See this posting as my way to try to help you making the best know IRC bot.

Change History

07/21/05 17:13:14 changed by anonymous

One addition: Would be nice to be able to select what plugins to load. This would reduce the number of commands I get in the help and would dedicate the bot more to what I want. Next step would be runtime loading of plugins. (At least this has to be kept in mind.)

07/21/05 19:27:59 changed by giblet

  • keywords set to usability feedback.
  • status changed from new to assigned.
  • severity changed from normal to enhancement.
  • milestone set to rbot 1.0.

Excellent feedback - I'll work through it and see what I can apply to rbot. Agreed with you on various points.

07/23/05 12:08:30 changed by anonymous

  • cc set to devurandom@users.berlios.de.

07/25/05 15:01:46 changed by giblet

Gonna follow up on some of these individual points:

help shows something like: lart|praise|addlart|addpraise|rmlart|rmpraise in the plugins section. wtf?

If plugins set a name, their name is used in help - if they don't, an amalgam of their message handlers is used instead. This is so multi-purpose plugins can have all their features documented. However for single purpose plugins with lots of handlers, the name should be set so that this doesn't happen. I'll fix the core plugins to ensure they all provide a name to avoid the above (the lart handler is probably the worst offender)...

I'm reworking the config stuff and will include some "default config" stuff, including, possibly, a wizard.

07/25/05 17:55:25 changed by devurandom@users.berlios.de

This is so multi-purpose plugins can have all their features documented.
I don't know if multipurpose plugins are a good idea.
Not only they might provide features the user doesn't want to have. They also don't have a defined purpose, if you are searching for a plugin to do this or that.

Under this circumstances:
If plugins set a name, their name is used in help
Why not use the pluginname? And make this one meaningful?
If I understood you correctly, you can't determine the pluginname automatically.
Why not use their classname? (Which should be equal to the filename, so one can find the matching file.)

P.S. I did not have much time as I was busy with other stuff. Chapter 3 of the online book. :(

07/25/05 23:41:37 changed by giblet

I don't know if multipurpose plugins are a good idea.

I don't want to set too much policy at the rbot level. rbot is a multipurpose, flexible IRC bot and users should be able to customise it however they want, including writing whatever kind of plugins they want. The main aim for rbot's plugins is that they are very flexible - by imposing such policy I would limit that.

Why not use their classname?

I don't want to use plugin's classnames for plugin names because that's a classic example of the bot's implementation language (ruby) creeping into the view of users where it should be transparent. There are various limitations around ruby Class names that I don't want to impose on rbot plugin names.

Example - you have a plugin that can encrypt and decrypt strings. It exposes two methods to users - "encrypt" and "decrypt" - you want them in the same plugin file because they share a lot of code and libraries - this is a valid use for a "multi purpose plugin".

By default rbot will display your plugin's name as "encrypt|decrypt" in help. This is deliberate as it shows the users immediately what they can do with the plugin, however you can also define a name for the plugin so that it is displayed as "crypto", for example.

I'm keen to maintain this level of flexibility in the bot. However I'll do my bets to ensure that the core plugins I provide with the bot all behave consistently.

07/27/05 14:10:10 changed by giblet

Okay as of about [41], rbot is installable (install.rb), and has a startup wizard for basic configuration on the first run. I'm working on more advanced runtime configuration at the moment. At this rate 1.0 should be along shortly.

08/02/05 06:20:13 changed by vampjon@gmail.com

Hi. Having been experimenting with the current svn version of rbot, would I be right in saying that currently a random user can do "config set auth.password whatever", and gain master access to the bot?

Great work anyway, looking forward to your 1.0 release.

08/02/05 07:01:30 changed by anonymous

The default configuration specifies a "config" level of 90, and assigns a level of 10 to random users. This means that only the auth'd owner, with the default settings, could issue config commands.

However if you configuration has different levels, or none, then certainly this would be possible. I have been thinking about reworking auth/levels/users before the 1.0 release and I might rethink how the default configuration for these thresholds is chosen at that time. Right now templates are copied into your rbot config directory but only if it doesn't exist already.

08/02/05 07:46:45 changed by vampjon@gmail.com

The default configuration specifies a "config" level of 90, and assigns a level of 10 to random users. This means that only the auth'd owner, with the default settings, could issue config commands.

Yes, that's what I expected. I was experimenting with a clean installation and had not changed any settings from the defaults. I saw the "config" level was set to 85, and this did stop me issuing certain commands as a random user, such as "levels" and "users", but not, it seems, "config". So I was able to change the password and gain master access:

13:26 <vampjon> levels
13:26 <rbot> insufficient "config" auth (have 10, need 85)
13:26 <vampjon> users
13:26 <rbot> insufficient "config" auth (have 10, need 85)
13:27 <vampjon> config set auth.password whatever
13:27 <rbot> fine
13:27 <vampjon> auth whatever
13:27 <rbot> Identified, security level maxed out
13:27 <vampjon> levels
13:27 <rbot> Current levels are: addlart(5) addpraise(5) addquote(5) auth(100)
 config(85) delquote(15) getquote(5) http(80) join(50) keycmd(5) keyword(5)
 lart(5) msginsult(12) nick(80) nickserv(80) opmeh(70) part(50) quit(90)
 remind(5) remind_other(12) rmlart(5) rmpraise(5) say(70)

08/02/05 07:49:12 changed by anonymous

Ah right. That's not intentional :)

Thanks for the report, will fix. I suspect this is a bug in the auth support of my new MessageMapper?.

08/15/05 07:33:59 changed by devurandom@users.berlios.de

I just tried the svn from today and found out that it happened to the config, what I didn't like about supybot: Having to change the command to walk through the config options. (Makes the IRC-client's command history nearly useless or at least makes it more complex to use.)

I would rather like it to be like this:
(With ca. this formating, to make it very fast to read/overlook.)

config

lists all available modules

config MODULE

lists the keys and groups in the root of the MODULE (Groups are important for plugins with several config options, to stay maintainable)

config MODULE.KEY (Or: MODULE KEY, whatever...)

Shows the setting of KEY
eg: > OPTIONAL HELP MSG Setting: ... Type: Bool/Int/Enum:[ 'option1', 'option2' ]
with Setting: ... and Type: ... being autogenerated

config MODULE.KEY OPTION

Sets KEY to OPTION
eg: > KEY set to OPTION
or: > Invalid type

config MODULE.GROUP

Shows an (optional) description/help of the group and lists it's subkeys
eg: > OPTIONAL HELP MSG Subkeys: bar, @blub, fuu
with Subkeys: ... being autogenerated.

config MODULE.GROUP.KEY, config MODULE.GROUP.KEY OPTION and so on...

The change is from several commands to get and set and list keys and get their help to have only one command ('config') which decides what to do depending on it's parameters. This is easier/faster to use in my opinion.

08/15/05 07:56:14 changed by giblet

agreed - I was coming to the same conclusion myself. Targetted for 1.0

09/04/05 15:06:39 changed by DevUrandom

I'd like to see a "whoami" command, to get to know as whom rbot recognizes me and how. (returns the hostmask)