IE Developer Tools Usability Issues

By Ahmed M.Orabi

The most common way that we use to debug JavaScript code in Internet Explorer is using Developer Tool that comes with the IE browser to provide the required functionalities to debug the code and all other necessary HTML and CSS files. However, when the js code is referenced/compressed/obfuscated /evaluated it becomes not displayable. Also the CSS files will be placed at random selections, and you will not be able to search for styles in one search action. In addition, there is no quick way to search for specific JavaScript content in all JavaScript files. 

1. Requirements:

Internet Explorer must be installed and Developer Tool is configured.

We will use some open source code examples from:

http://www.opensourcescripts.com

2. Code navigation is not keyboard accessible and provides redundant entries

When start debugging a website, you will get a list of JavaScript files that exist in that website. The list can be too large for the large projects and especially if the code is not obfuscated. Moreover, when the code is not obfuscated as in the debug mode, the list of displayed js files could be more. So, it is important to avoid having redundant entries and support keyboard accessibility.

Let us try with a simple example on the website:

http://www.fabulant.com/downloadcenter/eyeq/eyeq.html

Open your developer tool from the tools menu:

And then select “Start Debugging”. You will find a list of files as follows:

First, you will notice that there are redundant entries. This is because the code is evaluated or queried more than once and thus the tool will list a new entry for the same code file and this ends up with having these duplicate entries. If you open the entries for a file like “render_ads.js”, you will find that their contents are identical. Which means that are duplicate and they are also the same.

Now, try to use the keyboard to navigate to “ey”. You will type “e” and then “y”. What will happen is that the tool will stop at the first “e” entry in our menu. The reason is that the developer tool does not provide a way for sequenced keyboard accessibility.

In addition, items are not alphabetically ordered. They are ordered based on their file parents. Thus, even if we decided to get to the items that start with “e”, we will need to finish this set of items that start with “e”, and if we could not find our item, then we will need to go to the other set of items, and so on.

This example is a simple one as we are able to see all items in the list. But for the development case, you are going to find a list of hundred of times, and this will make it complicated to use as move up and move down navigation is not supported.

In addition, the other accessibility keys such as page up, page down, home, and end keys do not work in that menu which makes it even worse as you will need to use page down/up for quick navigation given that your only option here is to manually locate the file.

2.1 Suggestions

We must eliminate the duplicate entries especially when they have the same contents. If there are different versions of the same file, then we have to make sure to eliminate the obsolete versions that they are unused in the current context. If they are all necessary, then make sure to eliminate the versions that have the same content.

We must be able to have sequenced key access to the entries in the list, so we can locate items directly by entering the required key sequence.

Entries in the list must be listed in an alphabetical order so it will be easier to locate. Or make it as a preference if someone prefers that order way.

We also must have an option to search for specific script file name. At the moment, we can only search for specific content for the current selected file, which is not that helpful for that scenario.

3. Evaluated Code is not reachable

The code that can be displayed in the developer tool must be the code from the current files in the website. If there is code that was created using “eval” call, this code will be anonymous, and the developer tool unfortunately will not be able to set a name for it or to categorize it properly, and we will be a get a set of entries with the label “anonymous code”:

The way that these anonymous classes are displayed is useless as realistically we will not be able to go through each eval class to find out which one we are looking for. This is a major usability issue as there can be a lot of places that were created using eval calls which means that at this point, we will not be able to debug them unless we locate them manually in the same manner or find out a way to program them in a different way other than the anonymous creation.

3.1 Suggestions

Anonymous classes must be placed with proper labels. A way is by finding out the main label for an anonymous class definition. If there is no unique name, then we must provide a way to have an id for each eval code, and must have any way to make it unique so the user will relate that name to their class that they are looking for. Still not too usable way, but at least will save the time for next tries once the user knows how the tool lists this class.

In addition, under any circumstance, the code must be displayed for any selected entry regardless it is anonymous or not, as the developer tool for many cases shows empty code contents if the classes are anonymous and created after the first loading time.

The best usability experience here would be providing a way to search for code contents at different classes so we can just simply search for the code, and locate the anonymous classes.

4. CSS Search is for the selected entry only

 When we go to the CSS tab in the developer tool, we get a list of the CSS files for the current website that we are debugging. We select one CSS at a time in order to get its list of CSS entries:

This means that we will not be able to display all CSS contents at once. We have to select an item each time. At some cases, when you would like to locate a guilty CSS class that is causing a CSS issue, we will need to disable CSS incrementally till we locate that CSS entry. With the current approach, we will need to do that for each selection, which is an usable.

In addition, CSS has the same issue as the script tab with displaying redundant entries

And here is the main issue, “mostly”, there is only one entry that will have effect on the website. Thus, you may find yourself trying to edit CSS for a useless CSS entry.

In addition, the CSS search here only search for CSS contents in the current selected CSS entry.

4.1 Suggestionss

We must be able to display CSS contents for a list of entries not a single entry only. This can be by providing a checkbox for each entry, and when we check that entry, its list of CSS will be displayed.

The CSS search must search for CSS in all files, not only in the selected entries or at least provide an option to enable search in all places.

Also, the developer tool must not display obsolete CSS files that do not have effects on the website. For instance, old versions of the CSS file will not leave any effect so having them displayed will only bother the users and cause them to spend more time.

5. Conclusion

Developer tool is the main way to debug JavaScript contents in Internet Explorer. However, it has a lot of usability issues that cause the developers to have hard times investigating JavaScript issues. Some of the major usability issues are related to the difficulty to navigate and search for JavaScript files and contents. In addition, it becomes even worse with the evaluated codes that are displayed with untitled labels, and sometimes with empty contents. In addition, the CSS tab displays unnecessary CSS files, and do not leave us a way to investigate CSS in all files at once, which makes it more difficult to detect and resolve CSS issues.