Introduction

This tutorial is for any level of scripting, whether new to mIRC dialogs or advanced. At the time of writing this tutorial, take note that the mIRC version is 5.91.

There will be dialog examples taken from other people's scripts. I do not intend to insult these scripts that are shown here as examples, but I only attempt to illustrate the common problems of mIRC scripters when they design dialogs and to provide suggestions on how they might be improved.

This tutorial doesn't mean that my ideas are the be-all and end-all when it comes to dialog design. My aim is simply to highlight some problems encountered by scripters, provide good and bad examples, and provide possible solutions.

Take note that I sometimes use the term dialog controls and sometimes I use the term dialog items. Whenever I refer to these things, I am actually referring to the same thing. By items or controls, I will be referring to buttons, checkboxes, groupboxes, and so on.

Basic Principles

In mIRC scripting, designing dialogs becomes a problem usually because the scripter just starts to create a dialog without having a plan. If you think that planning for a script is funny, then you should rethink your idea. A good solid script is usually very well planned - whether you are dealing with simple aliases or complex remote events. This immediately makes designing dialogs a part of that plan.

When creating dialogs, always try as much to make sure that the dialog is:

• task-suitable: Don't offer so much functionality that it confuses the user or harms functionality. In other words, try as much as you can not to overwhelm your users with options in a single dialog.
• understandable : When the user uses the application for the first time, the user should be able to see quickly what it does and how to use it.
• navigable: The user should always be able to tell where he/she/it is. Don't restrict navigation too much.
  
• conformable to expectations : The application should be consistent throughout.

In short, keep it simple and clean.

Personally, I think the best way to create dialogs is to attempt to create dialogs that will seamlessly integrate with mIRC. What this means is, if you try as much as possible to make your dialogs look as though they are part of mIRC, then there are more chances that your script or addon will look professional.

One rule that should be followed is: never assume . Just because you think that it is cool to do things your way, there will never be guarantees that people who are going to use what you wrote will find it cool as well. So how do we solve this problem? Try and be moderate. If users can accept how mIRC looks, then they will have no problems in getting used to your dialogs if you emulate regular mIRC dialogs. Once again, keep it simple and clean.

For those of you who are interested in flashy dialogs or picture window dialogs, that is a different issue altogether and will not be touched in this tutorial.

Capitalization and Terminology

The first issue that we will deal with is on the text and labels that you put in your dialogs.

Capitalization. Usually, there are two types of capitalization: Title Case , and Sentence case . The Title Case is when the first letters of the words are in capitals (except for some words such as "for", "in" or "to"). This usually applies for text in menu, titlebars and not dialog items. The Sentence case is when the first letter of the text is capitalized. This is what is usually used for most controls, or in mIRC terms: for most dialog items.

In mIRC scripting, however, this seems to be abused. There are so many scripters who use AlTeRNaTiNg CaPs , and sometimes there are those who write everything in lower caps . While writing in lower caps have become acceptable for mIRC scripts, I must emphasize that using alternating caps is very bad when it comes to User Interface . This will only make things difficult to read and understand.

In line with that, try to avoid having so many symbols in your dialogs. Don't put exclamation marks !, colons : , and whatever character if it is not necessary. These things will only make your dialogs look more cluttered. As I mentioned earlier, a good dialog is one that is easily understandable , that anyone who takes a look at it for the first time will immediately have an idea what it does.

Terminology. When we mention Terminology , what we mean here is the words we use in our dialogs. Below is a practical example:



Here we see the scripter allowing options on how the lists should look like. But in doing so, he or she has failed to take into account that not everyone knows what he or she means . This goes back to the principle: never assume . Just because you understand those terms, it doesn't mean that everyone else does. To quote a famous saying: to assume is to make an ass out of u and me .

Thus, as a suggestion, the words Flat sb , nosortheader , and noheader should be spelled out or explained.

Simple alignment

Another problem in dialogs is that the controls are not aligned properly. Try as much as possible to align things. Users normally like to see order in dialogs. For example:


As you can see, the Group Box for the themes and the Group Box for the about theme are not aligned. The image below is a suggestion on how to solve this:


The dialog automatically would have a different feel to it. There is still an issue of group box that will be dealt with later in this tutorial.

Note: I got rid of the editboxes in the suggested dialog. Simply because the original editbox is not editable. There's nothing to edit and it will never be enabled. So I might as well use a simple text and just use the /did -o command to update those text.

Alignment not only applies to Group Boxes. It is also important when dealing with other controls such as buttons. Below we have an image that shows a row of buttons.

Personally, I think these buttons look odd. For one thing, they are of different sizes and yet they are side by side. Perhaps, the better way of doing this is to make the buttons of the same size, and space them out nicely.

Here is my suggestion on how to change the position and sizes of the buttons:

Note: The reason why I'm making the Ok and Cancel buttons slightly farther away from the other three buttons is because they are not really of the same category. The Help, Load..., and Save buttons performs specific tasks that are not the same as accepting or rejecting the modified setting changes in the dialog. Besides, since the Ok and Cancel button closes the dialog, it's more logical to put them there.

Grouping controls

Most of the time, a single dialog will contain controls that are not directly related to each other, even if they fall in the same category. For example, in an away system, you would group the away nick and away message settings together with the away toggles (such as pager, logging, etc) . This is where a Group Box comes in, or in mIRC scripting terms, a box .

Many scripters are confused with the function of a Group Box and they end up making it do other things. Remember that a Group Box is to group certain controls that are directly relevant to each other. Below is an example of a misuse of a box :



Here is my suggested dialog for the same thing above:

The first thing that you'll notice is that the dialog got bigger. The reason for this is because we have used three Group Boxes . This consumes some space inside the dialog. Plus, I added room for the editbox and widened the space for the buttons.

I removed the Regular Nick editbox because there's a $me identifier that you can use. The proper way of scripting this would be to set it to a variable and then set your nick back to that variable when you set yourself back. Why should a user be asked to type something extra? The script should be smart enough to remember what nick you were using before you set yourself away.

I criticized the existence of the Email editbox earlier but I still included it. But there is one difference: I added a checkbox asking whether the email should be shown in the away message or not . This makes the email entry logical. Users will then automatically know what is the purpose of having your email address there. Then again, strictly speaking, there shouldn't be an editbox for the email because the $email identifier already exists and this should be used by the scripter.

The grouping becomes much more logical. The first box contains anything about basic user information. In the second box, it concentrates on the away message only, plus maintaining the two editboxes earlier. If my assumptions are correct, that's what the original scripter intended: to have one editbox where the user can specify the current or default away message, and another editbox for the default autoaway message. The rest of the controls are pretty much self-explanatory.

This just proves that a scripter needs to think and plan ahead before doing anything. You must ask yourself questions such as:

What options do I want to give my users?
Which option goes with what option?
Is an option redundant (or does mIRC already provide for it)?
How do I make the group items logically arranged?

These questions are not only important when identifying which items to group, but also in general dialog design.

Sometimes, the scripter doesn't realize that there is a need to group things accordingly. Below is an example:

As we can see, this dialog has an option to prevent unwanted messages. It also shows a combo list box and buttons to add or remove something. This brings us to the first problem: what is the combo list box for? Is it there to add channels? Or is it there to add trigger words? Or is it there to add addresses of spammers?

The second problem is: what are those + and - buttons for? If they are for adding and removing items in that list, why are they floating there on top of those checkboxes?

The third problem: Shouldn't those checkboxes be in a different group because they have no direct relation to adding and removing items?

And finally, what does the "20 secs after join/part " mean?

This illustrates that what we find logical isn't logical for other people. Everyone thinks differently, and for things like dialog controls, you have to take into consideration the fact that your users do not think like you all the time.



Below is the suggested dialog to solve those question problems:

I modified the text so it explains what the list is for. This makes it more logical unless the original scripter wanted the combo list to do something else.

I put the checkboxes in a single group because I believed that they have nothing to do with the adding and removing of items. And I also removed the 20 second option because I did not know what it does.

If the space in the dialog is too small, the box for the options can still be put below the list. But whatever the case, the point is not to mix everything if they are not of the same category.



And yet here is another example of a dialog that I personally find cluttered:


The reasons why I find this cluttered are as follows:

• The group boxes are not used properly. They are simply used to set a border as in the case of the Header Styles.
• The Titlebar styles probably needs radio buttons instead of check boxes. There's a difference between the two. Checkboxes allow for multiple options, whereas radio buttons disable the other options in its group.
• The Listview options is cluttered and the word List View is mentioned 4 times.
• The descriptions for the options in the Header Style are cryptic and may not be understood immediately.

Below is my proposed dialog that deals with the above reasons (Although I am not sure of the list header terms because I am not a regular user of this DLL).



And finally, here is an image that shows a Group Box that is completely out of place. Perhaps the scripter thought that having it there makes the button more prominent. However, it only makes things look unnatural and adds a single useless line in your script file.

A better way to deal with this is to simply remove the box. Users will have no problems in comprehending what the button does.



Tabbed lists

At the time of writing this tutorial, tabbed lists are still not supported internally by mIRC. A DLL is required to achieve this. But nevertheless, I find this an important issue to be discussed. This tutorial will not deal with the topic on how to create tabbed lists in mIRC dialogs. What we want to deal with here is how to use tabbed lists effectively.

Tabbed lists and group boxes. One big question that scripters encounter is whether a tabbed list should be enclosed inside its own Group Box. I would say that it is not necessary and not recommended to have a Group Box solely for a tabbed list. But again, this would depend on whether the list has a header or not.

Below is an image that shows a combination of a tabbed list and a group box.

I do not think that the words Lists should be there because there are already headers for the list itself. Putting the Group Box with the text Lists makes the dialog redundant (and wastes a few more seconds of your time when scripting).


Here is my suggestion on how to fix this situation:






The reason why we do not have the Group Box for the list is because the header of the list already tells you what that list is for.

Tabbed lists and practicality . Sometimes a scripter simply creates a tabbed list without considering whether it is practical or not. Here is an example:

The image on the left shows the usefulness of a tabbed list being defeated. While this kind of list allows for different headers, the scripter doesn't seem to realize that and made three different lists for different types of users.

In the end, the Query and the Whois buttons had to be made three times when it could have been there only one time. They became redundant (notice how many times I used this term).

The proper solution is to create a single tabbed list and make it have two headers. One header to show the person's nickname, and the second header to show their status in the channel (see above pic). In that way, there are fewer whois or query buttons to deal with, and fewer listboxes to deal with. All he or she would need to do is whois and $gettok() the first token from the selected line.

Plus, using a single list makes the whole thing readable and much more organized.



There are also cases where a tabbed list is not necessary and yet the scripter uses it. For example:

On the left side is the original image that shows a Group Box that has a tabbed list inside it. And on the right shows my suggested solution to make the dialog better-looking. First of all, having a box and a list with a header makes the Canales appear twice. This is not needed. The users don't have to be told twice that what they are looking at is, in fact, a channels list. Secondly, if the scripter still wanted to use the tabbed list, then he or she may do so but must be sure to remove the Group Box as well. And finally, (not really relevant to the current list topic) I made the buttons slightly bigger so that the users would be able to read what the buttons actually do. (Hopefully, I have gotten the language correct).

Colors, Fonts, and Forcing options

A common problem among scripters is that they intend to impose their preferences on their users (yes, I have been guilty of this in the past). I have learned over the years that what you think looks nice doesn't look nice to others (as mentioned above).

It is preferrable to be normal (not dull) as compared to flashy or colorful. For one thing, if you stick to normal dialog appearance, chances are, your dialogs will appear just like your user's dialogs appear. If you have a user that uses different color schemes or fonts for their dialogs, and at the same time your script has its own colors and fonts, it would mean that you are not respecting the user's preferences.

The biggest problem with scripters is when it comes to colors. Sad to say, some scripters just don't have good taste. And sometimes, their taste just don't fit with yours. And this is usually the case.

If you still want your own colors and fonts or whatever, make sure that you add the option to your users to set things differently. After all, a public script should be about the users.




Observe the image below:


Notice that the icons and the buttons are too big. The scripter might have thought that having icons of this size looks great and would help in the visibility of the buttons. But how can he or she be so sure that majority of the users will love it? If he or she still wanted to have icons of this size, then he or she should have added an option for small or large icons (just like Windows, browser, and other software allow you to change the size of their icons).

One relevant subject comes to mind. If you release a script, there is no need to repeatedly remind your user what they are using. It should be enough that they are using your script. If there are banners of your script everywhere, it will end up looking like those softwares that are called ad-wares.

Here is an example of an overly-large advertisement for a script:

What is the purpose of having a large banner telling your user that they are using your script? Since somebody is already using your work, then there's no need to advertise it to them.

Granted it looks good. But sometimes, there are things that shouldn't be in a dialog - and a script banner is one of those things. Always remind yourself of the purpose of a dialog.

It is also a good idea to be modest with your script. What I mean is, you do not have to keep advertising your script. The more it is advertised, the more people will not like it.

The same is true for the dialogs within the script - and especially for those dialogs. There's really no point to have all these huge banners.





Logical dialogs

The most important thing you have to remember is that dialogs have to be logical. They should give a sense of order. Always remember that users do not know what you are thinking. A scripter should never predict that his or her script user will automatically know what he or she is trying to imply in a dialog.

On the left is an image of an away dialog. I have numbered certain areas so that we can address the problems of those areas.

For number 1, The text for reason and its editbox overlap each other (unfortunately, the image quality has degraded so it's not visible). It is also too close to the away nick option.

Number 2. The display box does not specifically state what it is going to display. It might take a while for a user to realize that the display actually refers to the away message, i.e. whether you want it to display the away message repeatedly at  a certain interval.

3. The scripter did not mention what silent and public is all about. For a seasoned script user, they'll immediately associate those with the method in setting yourself away. But would a regular user know that?

The fourth problem shows two radio buttons that will enable or disable the away logging. What the scripter should have done is just to make a single checkbox. This would have lessen the number of dialog items he or she has to deal with.

For the fifth problem is that there are is a + and a - button (yet again). We can also see a checkbox that simply states set. This is very confusing. Obviously, the scripter wanted the + and - buttons to increase or decrease the auto-away time value. This should have been done better with a dropdown combo box. It would have been easier to deal with the values, and once again, there will be less dialog items to deal with. Unfortunately, I'm still not sure what the set checkbox does. I can only assume that it is actually to enable or disable the auto-away system. In which case, it becomes an inconsistent dialog. Earlier on, there were radio buttons to enable or disable the away logging, and suddenly there's a checkbox for the auto-away.

Moving on to number 6: we have two radio options, and two buttons. The problem that I see here is that the View and the Clear buttons are cryptic (same as in away log options). It took a while to figure out that they are to view or clear the pager messages received because of the fact that they are too close to the radio buttons.

What I find most disturbing about the whole dialog is that there are group boxes inside group boxes. If you carefully study professional software dialogs such as Mozilla, MSIE, Fireworks, and so on, you'll never see a group box within a group box. Instead of the group box being useful, it only made the small dialog cluttered and confusing. I have already discussed this in the Grouping section above.

Creating a logical dialog also means avoiding useless info. For example, see the following image:
As we can see, the scripter wrote opers to signify the number of operators in that channel, and followed it with voices. What makes this useless is the fact that in the editbox, the text shows 7ops and the editbox for the voiced users shows 6+v. Now, not only are those two inconsistent, they are also redundant. If you have written opers there, then there's no need to put the ops after the 7. The 7 would do. The same is true for the voices.

The above pic can also be used to illustrate inconsistency . It would not have been so bad if the scripter used similar terms. For example, using ops and voices, instead of using ops and +v. Or he or she could have used +o and +v, or simply @ and +. At the very least, there would be some consistency in the dialog.

Finally, here is a very good example of a very cluttered dialog:



You should never do this. The treeview showing the directories seems out of place, the editboxes are out of place. And the icon is out of place.

Using a feature for graphical reasons

Just because a scripter can implement something, there's no need to implement it if it is not necessary. With the DLL capabilities of mIRC, there's always the temptation to do something because one can do it. By all means, a feature should only be implemented:

• to simplify tasks
• if it's a feature from a separate DLL, to use it because mIRC doesn't support it yet.

It is rather unfortunate that many scripters have fallen into the trap of implementing something because it "looks cool". Below is an example:

This image shows an away system that has a tree-view list. The tree-view shows the following:

Reason
Options (further divided into Nick and Automessages)
Ready?

What I'm seeing here is possibly a useless tree-list. It seems to me that if you click on one of the categories in the list, you'll see a different display, perhaps editboxes allowing you to change the settings. But I don't see the point to this. Making a user click many times than usual is annoying. And why would anyone need a separate area just to view the settings when you can already view it from where you changed it?

I created a dialog below to show that perhaps the away system above can be improved. It's much much simpler and direct to the point.

As you can see, the tree-view is gone and the dialog is much smaller. But if you look closely, the same functions are still there. There's an editbox for the away nick and the reason, two checkboxes for the Auto messages option and the three buttons below.

This dialog greatly reduces the amount of dialog items. Less work for the scripter, less work for the end-user as well. And it didn't even need a tree-view.




The Little Things

Based on personal experience, users will appreciate little things that you add. Even if they don't notice that they are appreciating it. It's that little effort that you do to make your script look cleaner and feel orderly that makes users love your work.

For instance, it is always useful to have Ok, Cancel, and Help buttons. These are very important. Whenever a user makes a change in the settings, it is not necessary that you do the changes in real time. Sometimes they might make a mistake. This is why it's better to have the Ok button handle all the changes. Here's a scripting example:

; Let's assume that the id for the Ok button is 1.
on *:dialog:MyDialog:sclick:1:{
  ; This assumes that the id 2 is a checkbox for the Autoaway toggle.
  set %Away.Auto $did(2).state
  ; This assumes that id 3 is an editbox for your away msg for autoaway.
  set %Away.MsgAuto $did(3)
  ; This assumes that id 4 is an editbox for the normal away msg.
  set %Away.MsgNormal $did(4)
}

It's easier to do this because there's no need to script for every sclick event for every checkbox, for every listbox, and so on. There are identifiers and properties for those identifiers that will allow you to grab the settings only after the user has clicked the Ok or Cancel button. This gives more freedom to whoever uses your script - especially to those who are fickle or undecided.

And of course, don't ever forget the Help button. Since the purpose of dialogs is to make things easier, there should be by all means a fallback option just in case the user still finds your dialog cryptic or difficult to understand.

Little things also include having shortcut keys in buttons. This is very easy to implement. Simply put an ampersand or a & before the letter you wish to create as the shortcut key.

Finally, it's not a bad idea to improve your English language: but only if you want to release a script in English. There's no need to have a perfect English - just having enough knowledge would do. Besides you won't be writing sentences or paragraphs. Just make sure that the languages do not get mixed up.

Conclusion

A good interface plays a very important role in creating a good script. It takes hard work (and lots of it) to be able to create a really good user interface.

Having a good interface would also allow you to tell your users that you have this or that feature in your script. Sometimes, a script may be feature-packed; but because the scripter doesn't know how to present those features to the user, they become hidden or useless.

It is important for scripters to be able to come up with a good dialog design. These days, scripts tend to be more and more similar in terms of features. As such, the scripter must be able to create his own way of designing dialogs. That doesn't mean to say that the basics should be forgotten. There must always be logic in design, because apart from the actual scripting abilities and imagination of a scripter, a good user interface is also a decisive factor in making a script worthwhile. It is only when you know the rules, that you will be able to bend them.

Please visit KDE User Interface Guidelines for more info on UI basics.